[MGNLUI-3587] New and clearer icons for nodes in trees Created: 30/Apr/15 Updated: 28/Jan/16 Resolved: 28/Jan/16 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | design, tree/list |
| Affects Version/s: | 5.4.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Andreas Weder | Assignee: | Sang Ngo Huu |
| Resolution: | Won't Do | Votes: | 2 |
| Labels: | blocked, is-error-prone, pain-point, tree, usability, user-feedback, ux | ||
| Remaining Estimate: | 2d 1h | ||
| Time Spent: | 7h | ||
| Original Estimate: | 3d | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| 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 | ||||||||||||||||
| Sprint: | Saigon 28 | ||||||||||||||||
| Story Points: | 5 | ||||||||||||||||
| Description |
|
In order to improve legibility in trees, I'd like to introduce two changes:
You'll find the rationale for the changes below. 1. Easier to group nodes on same levelUser tests show problems with identifying tree levels. In particular, report problems associating nodes with their correct parent nodes. In the following example, the "class" and "publicKey" properties are on the same level as the "subscribers" folder. For some, however, they are inside the "subscribers" folder.
Part of the problem stems from the fact that leaf nodes do not have structural icons in front of them that vertically line up with their sibling nodes. Another part of the problem is that the tree layout is too generous (see 2. Open / close arrows are not easy to discernOur current open and close icons for folders are hard to read sometimes, since their direction is not clearly identifiable, especially on small representations. By using minus/plus signs instead of arrows, we can significantly improve the legibility of the open/close state of tree nodes and at the same time make sure they appear lighter. The latter allows the actual icons to stand out more. Note that trees in older versions of Magnolia had both suggested elements already. They proofed to be clear and effortless to read. |
| Comments |
| Comment by Andreas Weder [ 11/Nov/14 ] |
|
Visual design has been improved. Scheduled for 5.4. |
| Comment by Mikaël Geljić [ 30/Sep/15 ] |
|
If you recall, I had played around with a few visual tweaks some time ago, I still have that. In my opinion, the horizontal lines are part of the legibility issue. We could and should perhaps differentiate more the tree view from the list view. |
| Comment by Andreas Weder [ 26/Nov/15 ] |
|
Hi @mika. Yes, we'll take that up. New icons and a different layout (or rather: layout options) are two measure we'll take to improve the legibility in trees. See |
| Comment by Sang Ngo Huu [ 12/Jan/16 ] |
|
Hi weder, in case tree is flat, please see |
| Comment by Andreas Weder [ 12/Jan/16 ] |
|
Hi sang.ngo, thanks for bringing this to my attention. My suggestion would be to try to only show them once we have at least a container item or folder. Not sure how much effort that is and if it will be more confusing than helping - this is an edge case I haven't considered. But if it's easy to build, please do so. |
| Comment by Mikaël Geljić [ 26/Jan/16 ] |
|
Good that we finally attempt to do something here, I'm just unsure whether this clarifies the hierarchy, or what node a property belongs to. Leaf icons significantly differ from +/- toggles; so they tend to be confusing or noisy
Generally, I agree these icons look more researched, generous and personal. One would argue that the *content icons* are the ones that matter, while tree *component icons* should be almost invisible but familiar and intuitive. To address grouping of properties, I've been experimenting too: adjusting the container to display properties before nodes.
How about researching further on this, in spite of the plan to offer different "view options"? |
| Comment by Mikaël Geljić [ 28/Jan/16 ] |
|
We cancel changes for those icons now, we agreed with weder that this doesn't look as originally intended (and needs re-iteration). |