Recently, discussing eZ Platform version 2, I had a few requests from developers asking to bring back the content tree into eZ Platform main Content area. That’s a great topic, join in the discussion below but first please bear with me, read-on a bit of the context (sorry if it’s a bit long…):
Version 1 of eZ Platform uses the Universal Discovery Widget (UDW) for content repository navigation.
First, the UDW was designed as a “universal” interface to discover content in the repository, to provide a consistent way to do so. It was trying to fix inconsistencies and bad user experience in previous eZ Publish, such as this interface (which I have been struggling with as an editor on and on):
This was achieved with the creation of a new discovery widget, for which we decided for a Browser based on folding/unfolding vertical folders (like the original Mac finder, even if now the finder also has a tree :-)).
And this was really a step forward, as many users told us.
In that modal window context, the folder-based Browser (vs a tree) seems like a great idea, and could be used to provide a consistent way to discover content in all kind of context: in the online editor, in a field edit (content relation), choosing a content to add to a section, choosing a location… you-name-it.
One thing that I like about the Browser, especially in such context, is that it can scale really well. While not yet implemented, it could be used to browse very deep content trees by folding levels and still keeping a good experience, where a tree is not really convenient.
During the development of V1.x, we ended up with a UDW browser that was satisfying and able to browse unlimited number of content items. However, the main discovery interface in the Content tab was a tree that was really sub-optimal and especially not able to browse an unlimited number of content items (each location would display only 50 content items or a fix number to be defined in settings). This was rightly making users quite unhappy.
As you might know, developing the user interface on V1 was taking some time and the team had a lot to do and we couldn’t do everything, so, to unlock users who couldn’t browse locations with many sub-items, we decided to also use the UDW Content Browser discovery (which could be done with almost no development), instead of a content tree that would open from the discovery bar. To some extend, this solved the main urgent usability problem: browsing locations with a lot of items (more than 50…).
It was also bringing something positive: reusing the UDW even on the main Content tab was making content discovery very consistent across all the application, always using the Content Browser, and as a bonus, making less code to maintain.
Now, with version 2, things are changing, we are way faster to move the user interface forward, and we can totally reconsider the main browsing of the content repository, and we can consider implementing a tree. That’s absolutely the right time to look into that, as we are just finishing 2.0.
However, I myself am a bit hesitating to blindly agree with the developers I hear telling me “bring the tree back in Admin UI”
Why? Well first developers are not editors - no offense, and it’s not so obvious that editors like trees. Actually, simpler navigation can be more effective for editorial team. Second, I like reasons and arguments supporting a request, more than just “I want a tree”.
So, it would be great to discuss the topic a bit more deeply here, to help us make the best decision.
My first part to discuss would be:
For the main repository navigation (and not for in context UDW discover), what do you think is the most efficient (forgive the very dirty mockup):
a browser with folders (like currently) but in the main page and not in a modal:
a classic tree (may be with meta data):
both, with a switcher to change mode like in the Finder (of course both seems ideal, but it’s also bloating the interface, so there should really be a reason to do so - personally I find the Mac Finder now too complex…)
any other way to navigate (if so, explain in the comments)?
- horizontally folding browser (like in the UDW)
- classic tree (like in eZ Publish or better…)
- both browser and tree with a toggle
- other (explain in the comment)
More importantly, I personally noticed I use often alternate ways to discover content, when I can (e.g. is Google Drive, OneDrive or Jira, I often use the “recent” list of items).
So I feel like it might make sense to prioritize more features such as:
Simple access to content items that have been recently used
Content that I have bookmarked
Filtered and faceted search, with ability to store my search
Tags / Keyword
Please vote to let us know what you think are the two discovery options the most important we should prioritize in a near future:
- improve tree/folder navigation in the main interface
- implement a way to access content recently used by me or my coworkers
- implement access by bookmark
- implement access via filtered and faceted search (with ways to save my searches)
Any other argument, point of view or input? Please chime in below!