[MGNLUI-3161] Offer different layout options in list and tree views Created: 18/Sep/14  Updated: 24/Apr/18  Resolved: 24/Apr/18

Status: Closed
Project: Magnolia UI
Component/s: tree/list
Affects Version/s: 5.3.3, 5.4.3
Fix Version/s: 5.4.x

Type: Improvement Priority: Major
Reporter: Andreas Weder Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: estimate-with-uncertainty, is-error-prone, pain-point, tree, usability, user-feedback, ux, visual-design
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 01 Density.compact.png     PNG File 02 Density.normal.png     PNG File 03 Density.generous.png     PNG File 10 View options.tree.png     PNG File 11 View options.list.png     PNG File 12 View options.thumbnail.png     PNG File 20 Density view options.png     PNG File 21 Density view options.png     PNG File 22 Density view options.png     PNG File 23 Density view options.png     PNG File 24 Density view options.png    
Issue Links:
dependency
depends upon MGNLUI-3589 Allow views to offer view options Closed
duplicate
is duplicated by MGNLUI-3588 Allow to view lists and trees at diff... Closed
relation
is related to MGNLUI-3587 New and clearer icons for nodes in trees Closed
supersession
supersedes MGNLUI-2932 Tree view should clearly indicate tre... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: UX pain points 2018
Story Points: 13

 Description   

The layout of the list and tree view is a compromise between a compact list of elements and a generous enough layout to work well on tablet devices. It works well for e.g. a small set of pages, but we also know (and also get feedback that supports this) that it fails in a variety of other cases:

  • Tree levels are not always clearly discernible, as the large padding between rows and the horizontal lines dissociates content that would be easier to read if it was shown in a more compact layout.
  • We have some trees and lists with a lot of nodes, sometimes even on a single level. For these trees, it would be beneficial to see significantly more rows at a time to avoid heavy scrolling.
  • The rows and arrows on tablet devices are actually still too small on tablets to work comfortably and safely - we had a larger padding before, which worked best on these devices.

There's actually no one layout that works well on all devices and in all views. We thus want to offer the user the choice between a small set of layout options with different density levels: a generous, a normal (the current) and a compact appearance of a list and a tree.

  • For regular, "non-technical" content such as Pages and Assets, Events, etc., we show lists and trees using the current, normal layout on desktops and using the generous layout on tablets.
  • For "technical" content or sets with lots of items, we would use the compact layout on desktops and the normal layout on tablets.
  • For every tree and list, the user has the option to choose a different layout than the default layout still.

This issue mainly covers the different layout options and how we choose them. Next steps will be to persist a choice across app restarts and to allow to choose a layout for a given layout in a user's profile.



 Comments   
Comment by Andreas Weder [ 18/Sep/14 ]

I'm linking a support issue which might actually be solved indirectly by offering different layout options in trees and lists to users.

Comment by Andreas Weder [ 26/Nov/15 ]

I've attached the visual design drafts for this. We might have to tweak some details still. The design do show the general appearance of both the view options combobox next to the view selector as well as the three different layouts for trees and lists (compact, normal, generous).

Note that the icons used in this visuals are not those we plan to introduce (see MGNLUI-3587 for details).

Comment by Andreas Weder [ 26/Nov/15 ]

Copy of a comment on the duplicate issue MGNLUI-3588 by apchelintcev:

This could be an interesting feature to play with especially since we could try to utilise Vaadin's Responsive extension capabilities.

Comment by Jan Haderka [ 03/Dec/15 ]

Really? I would expect to have best layout selected for me by the system based on the platform/client I'm on currently. Or if there should be a choice, then I would expect such choice bound to my account/preferences so I don't have to select it every time I open an app. Don't think that it would be wowed by too many users if we went through with what is currently mocked up in attachments.

Comment by Andreas Weder [ 28/Jan/16 ]

That's actually the idea: the system chooses the layout based on the content shown (technical, non-technical) and the available resolution. If you read the 2nd part of the description, that's explained a bit more there.

Still, we can't make a proper choice for all cases, which is why we give the user a choice to change the layout on the fly. I agree it would be nice to have a general setting in the user preferences allowing me to pick my preferred layout. I did sketch that once, since it's not a simple question of just picking one out of three - it also has to be relative to the device/resolution I use.

Comment by Antti Hietala [ 24/Apr/18 ]

Closed as Won't Do. In the next theme we won't be doing user-adjustable density levels (Generous, Normal, Compact). Rather, we find the right balance between text and white space through user testing and then fix the ratio.

Generated at Mon Feb 12 09:03:49 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.