Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

About trees and folders

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 :slight_smile: 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” :slight_smile:

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)?

Please vote:

  • 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)

0 voters

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)

0 voters

Any other argument, point of view or input? Please chime in below!

1 Like

I think both are important at the end.

UDW is really great, but the representation of the Content Repository is probably better as a tree.
I really miss the ability to:

  • see the complete tree
  • put icons to more easily identify contents at one glance
  • remove some content type from that tree to clean it.

UDW is great for embed relations, selecting contents etc. but a tree is better to “see” the Tree.

UDW: fetching
TREE: viewing (but also fetching)

That is why a tree by default to view would be great and an option in the UDW too.

My 2 cents :wink:


Thanks @Plopix!

I totally agree with the icons in that context, and I think @inaki.juaniz-velilla has this in his backlog, am I wrong Inaki?

Hi there. I am one of those devs trying to bring bacj the tree. :). But is good to know and seems really reasonable to know what you go for this option. It also happens that i’m not a mac user,so to me, the starting point was, well, windows explorer. But yes comparations with Finder looks a good point.

Moving the repo navigation to the main window also looks good to me. If I had to choose I would for content tree with metadata, but again probably this is because I am a dev and not an editor. So, if the mode could be switcher and probably kept in any kind of preference, I would accept option one as the default one.

While on it, this could probably help with a issue we have now:

  • you create a content with related fields.
  • You try to add a related content, universal discovers appears and you select create new.
  • this new content has also related fields. You try also to add related content for this new one and it looks uwd cant handle that.

I dont know if with the repo navigation in the main window this can be tackled. A nice to have and not the most important thing anyway :slight_smile:

For the discovery, I have to talk with my pillow about :).

Oh, and btw. I really like the idea of having the entire window for the navigation. I was more thinking in a tree in the left (as the legacy) and content in the middle, but this seem to be a very intereting option too…


As you said yourself: " I use often alternate ways to discover content", people tend to find content in different ways so there should be more ways to do so in the interface. Also, eZ is used for very different kind of projects so there is no single best interface that will be good for all use cases.



In my humble experience, i found that people really liked the content/media tree on the left-side. They like visibility and/or the fact that it was easy to place ourselves while contributing.
But since we show them how to use the browser-based display, they found ourselves just like in front of their computer (impressing i know ^^’) and not as lost as they could be in a brand-new just discovered interface.

On a developper side, the bigger space i could get in my interface, the happier i will be. Keeping a left tree will not help me that much but i also like the way we have the same browsing display while moving on our view and on the edition interface.

So having a toggle could be the best-way i guess, depending on each and everyone habits.
Hope i helped the talk :slight_smile:

1 Like

“Developers are not editors”: No offense taken, but DX is pretty much as important as editor experience. And tree is very useful if you work with content on a larger scale, when you need a big picture of your content and site structure.

A toggle to switch between tree and a browser is definitely the way to go in my opinion.

Not sure if I should vote here, as employee :slight_smile:
Anyway, if Mac now is moving away from their old Finder towards trees like in Windows, that means pretty much all editors will be familiar with using trees on a daily basis, so that should be the first priority if we consider familiarity.

Agree with points about seeing the whole tree, or at least the parts of it I expand. Then you can customise the view to the task at hand. I also like the way the legacy tree remembers what branches are expanded and not.

You mention bookmarks and search. That reminds me of how you can tag/bookmark a search in Jira. This is a useful feature for advanced editors, but probably shouldn’t be top priority. Like: Bookmark a search for all Articles in News section containing “bicycle”.

1 Like

For navigating content, I think that the current iteration of Google drive is pretty good and could be copied from.

  • I always found the 3-cols navigation in Apple’s Finder both unintuitive and not conductive to either navigation or content discovery
  • nav tree on left gives power users all the power they want (to ‘jump’ quickly from A to X and back)
  • list of contents in ‘current container’ in the middle gives non-power-users the simplified view they need not to get lost
  • could do with the ‘details of selected content’ panel on the right, with toggle on/off, but not mandatory
  • important: the breadcrumbs path at top (or bottom) of screen to be able to jump quickly back to high level nodes and keep a good mental model of how the contents are structured

This is kinda of an in-between the 2 models, imho, and probably a switch would be unnecessary.

Now that I describe it, I kinda realize that this description also basically applies to windows explorer since around 95 :smiley: Which shows that people are most comfortable with what they use on a daily basis (I know Roland has been on Macs since forever :-P)

ps: agree w Gunnstein that ‘bookmarked searches’ are useful but probably won’t be used for the same purpose as the tree, which is: ‘daily navigate around all content’. Saved searches will be used more like ‘dashboards’, ie: ‘give me quick access to a specific set of contents’

I totally agree with that (and never said the opposite by . the way :slight_smile: ), developer experience is as important as editor experience for eZ (which is not true for other CMS with other positioning by the way…). And also, editorial experience can not be seen through the lense of one single editorial persona, this would be a mistake. There are casual editors and power editors, there are editors of a website (thinking page) and editors of a content repository (thinking structure…) etc… So yes, I can see the toggle as a good option :slight_smile: .

1 Like

I agree that there is a ton to learn from Google drive, good and bad things, but they are taking it in the right direction imho.

Are you on Mac now?
Fake fact that I have been on Mac for ever, I’ve switch in 2003 and before, my favorite OS was NT4, quite unbreakable, and with a relatively modern U.I. (back then.)
Now looking for my next OS but that is another story :slight_smile:

Many good points in this discussion already, so I keep my post short.

  • UDW is fine for searching for (related) content, but much too cumbersome for creating/editing content
  • I prefer a tree as in legacy admin (meaning: with icons, selected content types, remembering the state)
  • a simple search within the tree would be a welcome addition
  • filtered and faceted search, bookmarks to be added to the dashboard

Yes Roland, we know about this request and how icons help to scan content faster within the UDW.

Seems like it’s just devs in the community commenting on this? Should we organize an effort to bring in some power editors from our clients? Maybe there’s an editor-focused e-mail template we could send out?


That would certainly be interesting, to get the editors view on this as well.

Hello, thinking on our daily experience working on a multisite environment and having the possibility to compare different tree branches is critical. Working without it will be very very hard.

Indeed, ezplatform.com is clearly mostly dev.
On our side, at eZ, @inaki.juaniz-velilla is doing more and more user testing / polling (quali, not quanti) but we could and should definitely think about other ways to get inputs. For that we might want to make a bit of progress on some more “cilckable” mockups though. We’ll chat about it internally!

1 Like


Thank you for bringing back this topic to us . Both ways have their advantages. For me best is to give both ways and let each user be able to choose which way they want to use and see. I find myself tree structure better than browser one.

Limitation of 50 or 100 items is not a real problem, because i believe that most of the editors use search instead of browsing deeply in tree. So a good search is most important i think. Our editors who manage websites with millions of objects use search as much as possible. They really don’t browse thru the tree so often, but they like to have the tree view on left site, because of the fast access to main nodes.

1 Like