Usability Team

Instead of the warning, I can see two additional solutions:

1. technical solution: the script should be able to load the tree step by step which would be more DOM friendly, like 50 pages by 50 pages
2. interactive solution: if #1 is not possible, having a button at the end of a bunch of pages which would load another set:

`-- heavy branch
    |-- page 1
    |-- page 2
    |-- page 3
    `-- <button: load more pages>

Why not "onScroll" like for eg: http://msjolund.github.com/autobrowse/
Less irritating for the user and richer User Interaction at the same time :)

How can we prove that problem? Just tested it on a huge dkd project.
For me it doesn't seem to be a performance issue with bigger amounts.

Who reported that, Ben? Can you ask him to post a video of the issue here?

Greez Jens

We claim our selfs an Enterprise CMS .. so there should be an Enterprise Environment, too.
As those calls are only a very small JSON string I don't think that it could a server/conn issue.
It may be the case that the DOM / JS-Engine got an issue with that amount of ExtJS DOM-nodes.
So it's more likely that there are poor clients involved with outdated browsers and to small RAM.

But we need to see "something", to judge/priories that issue.
Rumors are not enough to dig into this technical huge topic!
Mainly it's not about UI changes, more a technical complex thing.
So this should be solved by a technical team and not a Design team.

Greez Jens

hi Jens,

please define "Enterprise Environment".
I'd say no matter how many processing power is involved, it will always be not sufficient if one or more users click on "expand all" in a 10000 pages tree. Besides this there's also a real bug with this feature, see http://bugs.typo3.org/view.php?id=17396

Enterprise mean "professional" to me .. or .. NOT the smallest/cheapest stuff you could get. :)
But you are right - it's a stupid Marketing term and shouldn't be communicated at all ...

I testet it with about 4.000 pages .. and it took a bit
(as expected) but it wasn't horrible slow in my case.

For me, that whole Feature doesn't make any sense - as sad before, I'm against it.
We got a real filter now, and that feature should solve the task instead! There is no use to
see +100 pages open at once .. and there is NO way to create any good User Experience for
that!! We may find a way to improve the performance .. but it will still be still hard to maintain
so manny pages at once .. THATS WHY THERE IS A FILTER!

We didn't had "expand all", in the past and we shouldn't have it in the future.
There is noting like that in other/similar use cases (Explorer, Finder, LinuxTrees ..).
No where there you could expand all folder inside of a whole system.

But we now got a good Filter .. so if that "expand all" doesn't work well, let's remove it!

Greez Jens

I do like the expand/collapse and use it a lot. It would make sense then if it could be easily de-activated or as default not activated and then easily activated ;-)

Ben, can you ask "the person(s)" to publish more infos about the issue?

It should be deactivated by default. And if someone, just like you, likes it,
it could be than activated via UserTS or so :) Sounds like a doable solution.
But I don't think, if you use the Filter more often, you will need it really.

Greez Jens

I discussed it with some developers. I have no example, but I think your suggestion makes sense.