[MGNLUI-2598] Rename/delete actions in favourites are difficult to locate Created: 17/Jan/14  Updated: 19/Jun/15  Resolved: 04/Jun/14

Status: Closed
Project: Magnolia UI
Component/s: favorites
Affects Version/s: 5.0.1, 5.2.1
Fix Version/s: 5.3

Type: Bug Priority: Major
Reporter: Rainer Blumenthal Assignee: Christoph Meier
Resolution: Fixed Votes: 2
Labels: aperto, next, support, usability, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Edit favorites action.png     JPEG File screenshot-1.jpg    
Issue Links:
Cloners
is cloned by MGNLUI-2599 Favorite groups not creatable on the ... Closed
causality
is causing MGNLUI-2975 When clicking "edit favorites" title ... Closed
relation
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:

 Description   

You have to click on the symbol ... to get the possibility to rename / delete.

We couldn't figure out how this works with 3 guys, working with Magnolia since many years. The usability is inacceptable. We found out how by accident, after 10 minutes.



 Comments   
Comment by Andreas Weder [ 23/Jan/14 ]

I agree with you that the discoverability of the edit/delete actions is very bad currently.

In fact, the Favorites UI has other short comings as well (it works differently from other UIs; DnD is unsatisfying; no other way to rearrange favorites than through DnD; the UI still doesn't match the visual design). There was a set of reasons that forced us to compromise on usability back when we implemented it. We eventually decided to make favorites easy and fast to use (just a click), and sacrificed making them easy to edit. Which means: the "edit"/"delete" features are there, but you have to learn or be taught how to access them.

However, we do want to change that. My current plan is to make Favorites a focused effort (not before 5.3) and then also add some of the requested features at the same time (e.g. group favorites). Obviously, this would be a bigger effort, and that doesn't help you in the short or middle term.

If we're looking for intermediate solutions, two options I see that also employ the means we currently have, would be:

  1. We add a "edit favorite" action to the toolbar at the bottom, which would show all edit controls at once.
  2. We show the tools on hover.

I like "edit favorites" best, as it is very explicit, is in-line with the design and works everywhere. I'd have to give it some more thought, but I expect this to work. I would not want to show tools on hover, since that doesn't work on tablets and makes the interface noisy when moving the mouse (a short delay might help).

What do you think? And how urgent do you think this issue has to be fixed?

Comment by Christoph Meier [ 22/May/14 ]

We will implement the following:

  • Edit-favorites icon/label on the "header-bar" of the favorites-form (see #1 on the draw above) => this will higlight the edit- and the trash-icons on every favorite and group; a 2nd click on that icon on the "header-bar" of the favorites-form will disable the icons on the items
  • no more single-click-handler on the icon on the left of an item
  • if possible: a double-click-handler on the label of the fav.- and group-items to enter the edit-mode
  • no hover on the edit- and the trash-icons of the items => no implementation of what #2 of the draw above
Comment by Christoph Meier [ 23/May/14 ]

Functionality implemented and committed to onto branch "MGNLUI-2598". (See http://git.magnolia-cms.com/gitweb/?p=magnolia_ui.pub.git;a=commit;h=32614df3db9cc68a8fa9ded64f9356aa66c7fa31)
Unit- and UI-tests not yet done.

Comment by Christoph Meier [ 26/May/14 ]

TODO: Grey out the functionality "Edit favorites" if there is no favorite, yet.

Comment by Christoph Meier [ 30/May/14 ]

Note: We want to have the favorites-app every time when (re-)appearing to be in its initial state - that means, all icons should be hidden, every field in non-editable mode.
=> This is +/- possible, but the setting of initial state slightly takes place AFTER the transition (=re-appearing) of the fav.-app.
Unfortunatly, currently, changes in the state of the app. cannot be done BEFORE the transition.

Concerning UI-Tests: info.magnolia.integrationtests.uitest.FavoriteUITest#ensureOnlyOneFavoriteIsSelected has been removed, since setting an item selected is no more possible (not necessesary) with the new approach to show/hide the delete- and edit-icons of all the items when clicking on the appropriate link/icon of the header-bar of the favorites-form.
(Instead, new test has been added.)

Comment by Christoph Meier [ 30/May/14 ]

Commits:

m_ui ; on branch "MGNLUI-2598":

ce-bundle (for the UI-tests); on branch "MGNLUI-2598-UI-Test":

Comment by Christopher Zimmermann [ 03/Jun/14 ]

Reopen:

  • Cannot set selection in the edit field with a mouse as one normally can. Usability problem.
  • FavoritesView#itemsAreEditable() I recommend having it return a boolean instead of a Boolean. It could return false when there are no items as well. And I would add a separate method FavoritesView#hasItems() which is also a boolean. I think the code where they are used would be easier to understand.
  • FavoritesItem.createItemId - is there a good reason not to simply use the counter? (KISS). I would rename counter to uniqueIdCounter.
Comment by Christoph Meier [ 04/Jun/14 ]

Re-resolved:

  • Improved / fixed the UX-problem - even better now than before (The described UX-problem was introduced with 1st fix-attempt of this ticket, but only for the favorite-item; on a group-item, it already existed; now it is fixed for both).
  • changed FavoritesView#itemsAreEditable , returning boolean instead of Boolean;
  • added FavoritesView#hasItems();
  • renamed FavoritesEntry#counter to uniqueIdCounter

Impl. of FavoritesEntry#createItemdId i did not changed; to use jcr-item-uuid (if existing) makes sense, and usage of date+counter is safe (and if it's more than safe, it doesn't hurt)

(See https://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=commit;h=086658ca511a0a576d7b2c45b5d81ac786510df3)

Comment by Christopher Zimmermann [ 04/Jun/14 ]

Coolio!
Two small things:
1. Please change the style so that cursor turns into text insert indicator.
cursor: text;

Maybe this style??:
.favorites .v-textfield.v-widget.editable.v-textfield-editable {
cursor: text;
...

2. Please remove comment FavoritesPresenter#initializeViews
//boolean itemIconsVisible = itemsAreEditable() == null ? false : itemsAreEditable().booleanValue();

Generated at Mon Feb 12 08:58:16 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.