Manager Speed

I think much of what it perceived as slowness in the Revo Manager is due to re-drawing the tree and waiting for the tree to redraw accounts for over 95.36% of the frustration with the manager interface.

I was wondering if it would be feasible to have an automatic/manual redraw option setting for the tree, maybe as a new system setting (user setting?). Developers and advanced users could turn off automatic redraw and the tree wouldn’t change until they manually refreshed it.

People are more tolerant of delays for tasks that they start themselves (versus ones that they have no control over).

The problem with this is:If I edit a resource, and then it doesn’t accurately show in the left tree, then wouldn’t that lead to confusion?

I think most people who complain about the tree-redraw-slowness haven’t used Evo and Revo side-by-side. Evo reloads the whole page (and posts a waiting page to boot). Revo redraws one part of the page (and usually only the parent node of the Resource, so only a part of a part of the tree).

Quote from: splittingred at Nov 10, 2009, 03:24 PM

The problem with this is:If I edit a resource, and then it doesn’t accurately show in the left tree, then wouldn’t that lead to confusion?

That’s why I’d have that option off by default so only people who understood what it did would turn it on. It might be annoying to keep having to refresh the tree manually, but I thought it might be worth trying. Right now, it seems like the tree is redrawn every time I take a breath, so it seems like it would be a relief to have it under my control. Quick Create is a great alternative, but sometimes it’s not appropriate -- e.g. if I want to create a long series of documents and set TVs as I do it.

It should be easy to implement (easy for me to say -- since I’m not implementing it ).

I think that’s a good idea, Bob. A lot of the time, I wouldn’t care if the tree remained un-updated until I specifically told it to.

BTW, is there a reason the Resources tree has to be cleared and completely redrawn whenever I right-click on a resource and select "Edit Resource" (FF 3.5.4). That’s over half of the annoyance factor right there since the new tree is identical to the one that was cleared and it happens quite often.

Quote from: BobRay at Nov 11, 2009, 06:29 PM

BTW, is there a reason the Resources tree has to be cleared and completely redrawn whenever I right-click on a resource and select "Edit Resource" (FF 3.5.4). That’s over half of the annoyance factor right there since the new tree is identical to the one that was cleared and it happens quite often.

Redrawn? What do you mean? Do you mean when the page loads? If so, yes, because the nodes are loaded via ajax...

Right. Whenever I click save when editing or select and edit a resource or element, the tree collapses and then is redrawn. I thought that only the right panel would need to be redrawn since the tree is not changed, but maybe I’m misunderstanding how it works.

Quote from: BobRay at Nov 12, 2009, 12:07 AM

Right. Whenever I click save when editing or select and edit a resource or element, the tree collapses and then is redrawn. I thought that only the right panel would need to be redrawn since the tree is not changed, but maybe I’m misunderstanding how it works.

Well, if you’re loading a new page, such as when you switch to the edit resource page, everything has to be redrawn, so I don’t understand the concern there. We’re not in frames any longer (Evo is built around a frameset).

As for when you save while editing, it should only collapse the parent node of the resource you’re editing (if in the root level, this will be the "tree"). And the tree very well could be changed. These following field changes can change the tree’s contents:
- Pagetitle
- Longtitle
- Published
- Menuindex
- Hide from Menus
- Class Key
- Access Permissions

Basically, half of the fields on the resource tree.

And ok folks, let’s be honest - clicking save while editing a document (not a new one, but an existing one), takes far, far, far less time than in Evo. Evo has to reload the page entirely. Revo only redraws the tree - that’s it. No page reloading. Nada. I’ve timed it, and Revo is faster when saving an edited document.

Fair enough, it was dumb of me not to realize that those fields could change the tree. It might be worth having a refresh_tree flag that gets turned on when one of those fields changes, since in a finished site probably > 90% of saves will involve a change to the content field only and redrawing the tree is unnecessary.

I know squat about Ajax, but I always thought that the main advantage of it was being able to do real work without having to reload whole pages. I’m used to GMail where you can do a lot of work in the right panel (editing drafts, sending and deleting messages, replying, marking messages, etc.) without having the left sidebar redrawn.

About Evo, I just checked and you’re absolutly right. The page saves in Revo take about half the time they do in Evo. But, that just makes it more of a mystery why the Evo Manager feels so much snappier than the Revo manager.

One thought I have is that it’s fairly distracting to have the whole tree disappear and then reappear (or when you’re not at the root level, to have the whole tree shift up and then back down again as that node disappears and reappears).

Is it possible to leave the old version of the tree in place longer by reordering the steps of the redraw or to fade in the new tree on top of the old one?

BTW, I don’t mean to make this sound like a bigger issue than it is. I much prefer working in the Revo manager. It’s just that several people have mentioned this and perception is reality when it comes to "look and feel" issues.

Quote from: BobRay at Nov 12, 2009, 02:25 PM

I’m used to GMail where you can do a lot of work in the right panel (editing drafts, sending and deleting messages, replying, marking messages, etc.) without having the left sidebar redrawn.

It’s true. But GMail uses the closure library where every line of script written especially for one specific task and non-relationship DB.

Offtop, but interesting. Can xPDO be adapted to use document-oriented DB like a MongoDB? Is it possible to rewrite the MODx manager with closure (for example), using the existing php connectors?