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:
- 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.
- 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.
- 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:
- Opening thumbnail view on demo.magnolia-cms.com 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.
- 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.
- 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".
- 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:
- Remove list and thumbnail views from the app screens. They can't be used, so why offer controls to switch into them?
- Keep list view around in the background for displaying search results.
- Remove the current thumbnail view completely.
- Find a way to display thumbnails directly in the tree view.
- Create a new, useable thumbnail view (I call it explorer view), this is described below.
- 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
- Find a way to show a thumbnail for each item in tree view.
- 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.
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:
- 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.
- On the right, there is a thumbnail view, but only showing items from the folder that is currently selected on the left.
- The items on the right are shown with a preview image (thumbnail). Double-clicking them opens the editor sub-app for the item.
- Folders are also displayed as icons on the right. Double-clicking them changes the view into the clicked folder.
- 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.