The tree

This thread is where I'm going to vent my frustrations with the tree, and discuss some ideas on improvements, alternatives, and other navigation concepts. Feel free to chime in however you want.

The tree is killing productivity and enthusiasm on my team. At least 15 minutes of every 1-hour meeting we have is spent wrestling with and complaining about the tree.

Resources seem to move up and down in the menu order for no known reason.

Sometimes when you open a manager page, the tree will be open to a resource/container that you've never edited, or at least not in a long time.

Sometimes an entire element type (usually chunks) suddenly appears as non-expandable.

Sometimes everything in a tree panel disappears.

Sometimes the refresh button in the panel works, sometimes it doesn't.

Sometimes you are working with an element, then save it, then after the refresh, the resource panel appears instead of the element panel.

(And vice-versa).

Generally, the tree is unresponsive, quirky and frustrating.

I know a lot of these conditions are brought on or enhanced by some of our use habits - being logged in on multiple machines, with multiple browsers, multiple tabs in each browser. And having lots of root-level resources to sort through. But those are pretty typical power-user habits, and a powerful CMS should be able to handle them without crippling compromises to basic usability.

Now that I've ranted, here are some ideas on ways to improve Manager navigation, tree and otherwise.

1. A per-user editable setting to hide certain resources - either by resource group or by specific resource (I'm thinking root-level resources mainly).

It is mainly users in my admin group that have the most trouble with the tree. We have full rights to every resource group, which means we see dozens and dozens of root-level resources. (End users who belong to specific user groups only see their corresponding resource group, so their tree experience is a lot cleaner - I haven't really had any complaints from them).

Usually a given admin user is only working within 2-3... maybe 4-5 tops... root-level resources in any given week. All the rest is just frustrating clutter. But I don't want to add/remove these users from access lists - I want them to have PERMISSIONS to view every single sub-site on any given day. I just would like them to be able to hide most of the stuff they aren't using, so they can navigate more cleanly through the stuff they ARE using.

Thoughts?

2. A per-user editable setting to hide/show certain element categories.

This is along the same lines as #1 - there are just way too many elements in our installation to make navigation manageable. And typically, any given admin user is only working with elements in a handful of categories at any given time. I'd like to see a preferences screen where they could hide/show element categories by toggling a checkbox. Or "hide all" and then check the boxes of the categories they want to see.

To sum up, it sounds like the basic interaction experience, inconsistencies and unexpected or almost erratic behaviour of the tree rather than the existence of the tree.

The fact that you use the word sometimes indicates just how inconsistent the tree behaviour is. So even if you wanted to get used to the idiosyncratic nature, there's no predictability or rhythm.

Let me try to describe your expectations and desirable behaviours:

• You want to be able to be logged into the manager in multiple browsers/tabs.
• You want the refresh button to work every single time
• You want the active resource on login/launch to retain the last used [li]state or, if you session just expired (browser close) to the collapsed tree.
• The refreshing of the tree for the element or the resource panel should maintain focus on the active panel.
• The tree should be there, always when in the context where you're working with Resources, Elements or Files.

Have you had an opportunity to see if there are reported bugs on any of the complaints/issues you've encountered, James? We're actively working on improving the user experience and interface in 2.3 and all of these fixes could be incorporated in this activity. I know of a number of folks who could test and solve these issues sooner than later.

3. An always-available list of the last N-number most recently edited resources/files.

One of the most frustrating aspects of having to deal with a quirky tree is that most of the time, I'm looking for a resource or element that I was JUST editing (10 minutes ago, an hour ago, yesterday). If that list was always available in a tab or dropdown (like the "recently edited" dropdown in MS Office), a user could avoid the tree entirely in those scenarios.

In the Manager Dashboard, there is a panel for "Recently Edited Resources".

4. An option to view elements sorted FIRST by category SECOND by element type.

Often I'm editing chunks and snippets (and sometimes TVs, Templates, and Plugins) that are all in the same element category. When you're editing a snippet, and then need the related tpl chunk, it can be a real pain dealing with the tree to access that chunk - even when the tree is behaving properly. Especially when the tree is being quirky and stupid.

If there was a way to easily group all of the elements of a certain category all together... that would be smooth.

Thoughts?

5. Element quick search & element name in query string

A search field w/ auto-complete in the tree area for searching an element by name.

The ability to hack the URL with an element's name instead of its ID number, to quickly bypass navigation in finding an element.

Thoughts?

Quote from: sottwell at May 30, 2013, 09:21 AM

In the Manager Dashboard, there is a panel for "Recently Edited Resources".

This would be a more useful feature, IMO, if it was available from the resource edit screen. Having to go back to the dashboard feels awkward, like having to go back to the home page of a website in the middle of a session.

Can only agree, specially with the odd behavior of the tree especially when you got multiple tabs open for the same manager. If I recall right the whole tree and what it opens is cookie based which in my opinion is a bad bad idea. MODx has the registry to work with the tree and could store the session data there.

Dashboard is the least used feature of MODx for me atleast, it is pain in the bum if you don't have network connection and you have forgotten to disable all XHR requests it makes. never been user, always a admin. From user point of view the dashboard could be usable but no experience on that.

Maybe new tab for the tree should be introduced, it is not a bad idea that you could browser last edited resources, chunks etc... from it. The tree could easily have 5 of each simply categorized and possibility to "load more" if required.

Personally have almost always 2 to 5 tabs open when building snippets, chunks or just plain getResources call to easily see where I am going with the row chunks and to keep myself up with the naming of tpl's. I don't know how many really use the file browser, it could have own menu really and could integrate the modxSDK directly. Even with the ACE editor and all possible solutions, would guess that people still prefer true IDE's when they are developing sites and upload the files and do not directly edit the files onsite unless are really required. Like missing ftp/ssh credentials

The tree is perfect solution otherwise. If you compare how pages get cluttered with WP or Dru#¤%#¤% the tree is awesome solution with contexts and everything. It just does not make sense always.