Page tree
Skip to end of metadata
Go to start of metadata


This page is intended to present some ideas and create a discussion space around the topics of ContentViews and Chooser Dialogs.

What are ContentViews?

In an app, ContentViews are the different ways of looking at the app's content. For example, the pic below shows the three content view buttons of the Assets app. Currently selected is the "tree view", but you could also show the content in "list view" or "thumbnail view".

What are Chooser Dialogs?

Chooser Dialogs allow a user to choose some content from an app, for example for use in another app. Typical use case would be to pick an image from the Assets app while editing content in the pages app. A Chooser Dialog looks like this:

Note that the chooser dialog, like the app itself, also uses the ContentViews to show the content.

Discussion of Problems

Unfortunately there are a number of problems around ContentViews and Chooser Dialogs that I have identified based on personal experience and customer feedback. The magnolia projects I am involved in are now using magnolia 5, and depending on the project have up 150 editors of varying levels of computer skills. Some of the websites managed by these editors are "big", the largest has 10000+ pages, with the DAM (Assets) containing >100GB of data storing >20K assets in total.

As mentioned, the editors have different levels of computers skills. Typically they are experts in another domain, and have to edit content as a "side task". Computer operations which may seem trivial to an experienced developer (simple things like finding an asset in DAM) can be quite difficult for users who are not so comfortable with computers, and only use the system every few days.

So what are the problems?

1. ContentView: tree view problems

The "tree view" ContentView is quite useable. It opens quickly for all workspaces, regardless of the amount of data stored there. It works more or less as the users expect. The following problems were identified:

  1. Different apps have different default behavior in tree-view: some apps allow editing of data in-view on double-click, others do not have in-view editing. Some apps open a sub-app on double-click, others do not and require an action to open the sub-app. It seems to me that while third party apps would be expected to exhibit such divergent behaviors, the standard apps created by magnolia should all work the same way. It's annoying and complicated for users when they don't.

  2. Depending on the content type, tree view does not help the editor find their content well. This is because the "identifying information" is not always displayed in the tree. This is dependent on the type of content: some content (e.g. in the pages app) will be well-identifiable by the node name or title, so if the tree shows the node-name and title, an editor can quickly identify the page he wants. Other content (e.g. the assets app) cannot be readily identified by name/title - see the image below:

    Which is the image with the nice background? If you don't happen to know it's "DSC_3957_07.jpg", you're going to have to click on each image to see the preview. Of course, in a perfect world the editors would name each asset in a easily identifiable way, but that just doesn't happen when you're dealing with 10000s of images.

  3. Moving content around in tree view is not well solved. Moving content by drag and drop is only possible for destinations that can currently be seen on-screen. If the target location is not visible, the tree view does not scroll when you move to it's edges. The move dialog is quite unnatural, editors don't know this way of working from other systems. Even with the move dialog, it can be hard to then find the correct destination because of problem #2 above.

2. ContentView: list view problems

List view will not be discussed in detail, since it is essentially useless. The only purpose for list view is in combination with search, for displaying search results. Otherwise, there is no situation in which the editor would want display all the content of a workspace as a flat list.

Also, list view has the problem 2 described under tree view: depending on the content type, name/title isn't enough to identify the content.

In addition, for workspaces with large amounts of data, list view is not functional - switching to list view freezes the front-end UI and causes high load on the server. The reasons are still being investigated, but I think this happens when the amount of content is so large that magnolia needs a large amount of time just to get the total item count from JCR.

3. ContentView: thumbnail view problems

Some apps (eg the assets app) also offer thumbnail view. Thumbnail view is a nice idea in theory, and a nod to the problem 2 identified above, that image content types can't always be well-identified by name/title. Unfortunately, thumbnail view is useless for my editors:

  1. Opening thumbnail view on works fine. Opening it on our system does not: thumbnail view displays the entire content of the workspace in one long list. While in theory it should use lazy-loading, in practice there is some kind of problem when the workspace contains large amounts of data. Opening thumbnail view on our "big" assets workspace just makes the client browser freeze while causing high load on the server. Then nothing happens. The reasons are being investigated, but my suspicion is that magnolia/Vaadin are counting the number of items in JCR, and this takes too long on a big workspace.

  2. Even if the thumbnail view were theoretically to open quickly, it would still be completely useless. Finding the image you want among 20000+ thumbnails is practically not possible. There would be so many items in the view, scrolling the scrollbar by even one pixel would jump over 100s of images. It's not useable.

4. Chooser dialog problems

The problems of the chooser dialog are partly already described above, but they are exacerbated by the context of the operation. In the chooser dialog, an editor is always trying to find and pick some content, and 80% of chooser dialog operations will be in the assets chooser.

  1. No preview – in the chooser dialog, there is no preview at all!! So all you have to go by is name/title. Looking at the tree in the image above it is evident that the editor will have considerable difficulty picking the right image. If he/she chooses wrongly it requires many clicks to correct the mistake. It's frustrating for the editors. I've filed an issue for this in magnolia JIRA, but it is under discussion, as apparently the chooser is working "as designed".

  2. Thumbnail view is theoretically available in the chooser dialog, but as described for thumbnail view above, it does not work for large amounts of content, and would be useless even if it did.

Personally I think that to offer an "image picker" where the editor has no way of seeing the images is ridiculous, and cannot be considered a good solution.

Solving the problems

So how can we solve these problems? This page exists to think about that, and here I present some initial thoughts I have had on how to improve the situation.

Default app's content views:

  1. Remove list and thumbnail views from the app screens. They can't be used, so why offer controls to switch into them?
  2. Keep list view around in the background for displaying search results.
  3. Remove the current thumbnail view completely.
  4. Find a way to display thumbnails directly in the tree view.
  5. Create a new, useable thumbnail view (I call it explorer view), this is described below.

Chooser dialog:

  1. Add at least the "preview on click" function available in the main app also to the chooser dialog. At least the editor will see a preview of the image currently selected
  2. Find a way to show a thumbnail for each item in tree view.
  3. Offer a new useable thumbnails view (see below).

Displaying thumbnails in tree view:

This is not so easy. In theory, you could display a thumbnail instead of the icon for the asset, but in practice I think that will be too small a thumbnail to be useable. An alternative might be to have the thumbnail only on mouse-over. Below are some mock-ups to visualize this:

Either solution would be helpful to the editors. Perhaps the solutions could even be combined, so that there is a tiny preview thumbnail instead of the icon to get you oriented, and in addition you can hover on the image to see a pop-up preview.

Explorer view:

The idea here is to create a replacement for thumbnail view that actually works and is useable. Instead of re-inventing the wheel, lets re-use existing metaphors which have been proven in practice, and which the editors will already be familiar with – explorer view, which works a little bit like "windows explorer". It works like this:

  1. On the left, there is a tree view, but with fewer columns (just name), and containing only the folder items. The user can open/close the items in the tree, and select the folders by clicking on them.
  2. On the right, there is a thumbnail view, but only showing items from the folder that is currently selected on the left.
  3. The items on the right are shown with a preview image (thumbnail). Double-clicking them opens the editor sub-app for the item.
  4. Folders are also displayed as icons on the right. Double-clicking them changes the view into the clicked folder.
  5. Optional: There is a '..' or 'up-arrow' folder displayed in the right-hand side, which can be used to change to the parent folder.

Since I assume you are familiar with windows explorer I think you can imagine what this will look like and how it will work. I personally think it will be a massive improvement for editors, and far easier for them to use since they will be confronted with familiar paradigms. Below is a rough mock-up of this view:

Probably showing the item names under the thumbnails would also be a good idea...

Improving "move item" usability with explorer view:

In explorer view, I think far nicer UX for "move item" can be achieved by switching to a "cut and paste" paradigm. The editor selects one or more items in explorer view's right-hand pane, and then chooses "copy" (for duplicating items) or "cut" (for moving items). The editor then switches to a different folder, using explorer view's left hand pane, and chooses "paste". The items selected get moved/copied as needed.

I think this will be a much more natural way for the user to perform the move function than the current solution.









  • No labels


  1. Richard Unger thanks for this great post. We 100% agree with your investigation, the list of problems and the possible solutions. In fact ATM it's really a big pain to find & select desired images from the DAM app and we respectively our customers are strongly asking for improvements in this regard.

    Magnolia Support: are there any plans / chances to improve Magnolia's DAM in this regard? I think Richard nicely describes the problem and shows IMO usable and appropriate solutions.

    @Community: has anyone implemented a better asset chooser / browser similar to what Richard describes for Magnolia 5.3+? Anyone working on this?


  2. Indeed, yes, a great posto.
    This should be one of the next major things in terms of usability improvements.

    Hope to find something new on next releases.
    Vivian Steller we have something, but not with vaadin native app.. 

  3. Hi Richard Unger. Thanks a lot for this writeup and your ideas.

    I've added my concrete comments and answers directly on the page, but I would also like to see more generally, that I do agree with many of your findings as well as the general picture you draw.

    Most of your points have actually been known for some time, which is why we've already designed solutions for them. We didn't get around implementing the more expensive ones so far, as we have to strike a balance between improving usability and facing other challenges our product faces (examples are how hard it was to develop a site with Magnolia using only JCR-based configuration; how we answer the shift from page-based editing to handle structured content; how we ensure that we can integrate the best services and systems out there).

    But I do see quite some improvements in the releases we've worked on in the last couple of months. We deliberately decided to stay with 5.4 longer to be able to focus on some of our long-standing issues. Some of these - like how we handle items in trees and lists when you add or duplicate them, or how we preserve selection when reloading a page in the page editor - may look small compared to the bigger issues you've noticed, but their impact is equally profound when you work with the UI on a daily basis.

    We will continue to improve our UX. Some of your ideas will make it into the product. We also have plans to productize more of the available solutions that have been developed by partners and customers, if we can convince them to work with us. Productizing existing solution is typically always a longer process than you would think at first glance, but it is still shorter than developing everything from scratch.

    Ok. I hope this somehow helps as a first answer to your concepts. Thanks again for taking the time to write these up and share them with us. Let's keep in touch.

  4. Thank you all for your feedback!

    Andreas Weder (MP): Thank you also for your comments. I have to say that while I hear and understand you clearly, I don't agree that you (Magnolia) has its priorities right: while the discussion above is somewhat general and ContentViews are a general concept of Apps, really we're talking about the DAM and Pages apps here. And providing the end user a DAM chooser with a preview function, or making a useable Move function should really be much higher priority than most of the stuff that's been done in 5.3 / 5.4. New developer features are nice, and also important, but such basic product features (required by ALL users!) should really take priority.

    1. +1: In fact, IMHO Richard Unger is again right. Personally, (speaking as a developer) I'd love to spend much more time using the new and brilliant features. But unfortunately, instead I'm forced to (re-)implement "work arounds"/working solutions for such basic "features" (I even won't call it a "feature" to be able to easily, conveniently & efficiently "select an image") in all projects again and again.... 

  5. Andreas Weder once this gets implemented, please also ensure/consider that double clicking an item selects it and finishes the selection process (resp. closes the choose dialog). This a - IMO valid - requirement reported by our customers. Unfortunately this is not trivial to implement with the current code base, see also