No Accordion in Revolution Sidebar...

There may be some design reason to have the side nav in Revolution (Web Resources, Content Elements, Files) be in an accordion, but it drives me crazy. I would like to be able to see all of my pages, and snippets, and chunks, etc. all at the same time without having to constantly click click click click click... Come to think of it, it would be nice if the open state of the folders would be saved through a refresh so that you don’t have to keep re-opening everything all the time when editing pages.

This is fairly minor, though. The revo manager is a huge improvement over evo in terms of efficiency.

What happens when you get 50+ Resources, and you have open all 3 panels? Scrolling becomes an issue then.

This is always up for debate. The UI isn’t finalized.

Do others have opinions on this as well?

I had stated before that I prefer to have everything opened all the time as well.

The issue of a tree to become to long could be solved several ways:
- Setting max. heights and using scrollbars, when larger.
- Letting the user determine whether or not he/she wants to have it opened.
==> You open and close everything now already, but it would have to remember the state it’s in, instead of going back to its default state.

I also think that the side navigation can be improved in Revolution. Too many clicks / refreshes are required to do things, and too much time is wasted. It’s even more important as everything in MODx is done through the manager; there are no external files for snippets/chunks/templates/resources that could be handled separately in our favorite code editor.

I have no idea of what the best solution would be, but I agree that remembering the open state of views and using scrollbars would already be an improvement.

It seems like Categories would be one method (which I use a lot) to keep the overall length of the list down... Heavily categorize your objects, and you will only be expanding the things you want to look at at any given moment.

This makes me think, too, about being able to click on a category (somewhere on the side) and see all the objects that belong in that category (regardless of object type)... just a thought - anyone else care to comment?

An overview by Category could be good, but it would have to keep all the different types separated too.
If it’s like this:
- A Page (doc)
- Breadcr (snip)
- CenteredPage (tmpl)
- Document2 (doc)
- ExampleCh (chunk)
- FirstTv (tv)
.. than it’ll be hard to find something.

But if it’s done like this:
- A Page (doc)
- Document2 (doc)

- ExampleCh (chunk)

- Breadcr (snip)

- CenteredPage (temp)

- FirstTv (tv)

... it would keep things organized, while it an still show everything that belongs to one Category.


Note: This is how I’d do it, if it would be done like this. Although I don’t think it’s the best thing to do.

I like the current version and I think the elements have to be grouped by element (as they are now) before being split in to categories.

I would *love* the current version if it didn’t keep slowly redrawing itself especially when I’m just saving an existing item so the redrawn tree will look exactly like the current one -- I actually shout at it).

On keeping all parts expanded, I think the key is that people will want to do that when there are few things in the tree or all are categorized but not when the tree gets really full.

I think the ultimate option, then, is to provide an icon that locks a section (or the whole tree) open -- maybe a little doorstop.

Second choice, a system setting with the current accordion as the default.

Quote from: BobRay at Aug 17, 2009, 02:49 AM

I would *love* the current version if it didn’t keep slowly redrawing itself especially when I’m just saving an existing item so the redrawn tree will look exactly like the current one -- I actually shout at it).

Well, what happens if you save the Doc and change the parent? Or title?

I think the ultimate option, then, is to provide an icon that locks a section (or the whole tree) open -- maybe a little doorstop.

Interesting idea; but I don’t think ExtJS’s accordion panels support this. We’d have to do one or the other, I think.

Second choice, a system setting with the current accordion as the default.

That would be quite a bit of work; I’d much rather just do one or the other.

Quote from: splittingred at Aug 17, 2009, 08:11 AM

Quote from: BobRay at Aug 17, 2009, 02:49 AM

I would *love* the current version if it didn’t keep slowly redrawing itself especially when I’m just saving an existing item so the redrawn tree will look exactly like the current one -- I actually shout at it).

Well, what happens if you save the Doc and change the parent? Or title?

Fair enough, but why redraw the whole tree if the parent hasn’t changed and why redraw it at all if neither the parent nor the title has changed?

Quote from: BobRay at Aug 17, 2009, 03:30 PM

Quote from: splittingred at Aug 17, 2009, 08:11 AM

Well, what happens if you save the Doc and change the parent? Or title?

Fair enough, but why redraw the whole tree if the parent hasn’t changed and why redraw it at all if neither the parent nor the title has changed?

Well, here are the cases where it would need to change:
- Parent change
- Description change
- Title change
- Published state change
- Hide Menu state change
- Container change
- Menu index change
- Access Permission change
- Class Key change


That’s a lot of different types of changes to make exceptions for. Plus, it doesn’t redraw the whole tree (or at least, it shouldn’t) - it just redraws its parent. So, one node up.