Following this discussion, we need to decide whether we want to allow Live Data actions icons to have a color different from the text.
There are two use cases I know of:
the delete action which used to be red by default in Livetables (and are not anymore for those migrated to LD, so part of the discussion is deciding if this is a regression).
the lock/unlock actions on the users administration, which are orange/green (and that I’m currently migrating to Live Data).
The pros are:
colors are an additional hint for users that an action has specific side effects (e.g., removal of an element, user becoming unable to access the wiki).
consistency with the ways things were
The cons are:
we don’t have explicit guidelines I know of regarding the choice of colors
additional concept to support and maintain for Live Data
I feel like colors are an important part of a good UI, therefore I’m +1 to allow action icon to be colored (and consequently the lack of color on the delete action to be a regression).
WDYT?
Thanks.
No color for actions that don’t modify anything or blue color for actions that don’t modify anything (to be decided)
Yellow color for actions to modify something
Red color for actions that destroy something (even if recoverable)
More?
EDIT: do we have such rules somewhere already on xwiki.org (in our frontend resources for example)? We already color edit or delete buttons for example so we might
Those colors would be from the color theme I suppose? The customization would allow for any color of my choice? Or would it be restricted to a few categories like the ones you described?
My thinking is that any action that have next intermediate steps (e.g., move, rename, edit) shouldn’t have a specific color. Only the final performative action (e.g., the form validation button) should have a color.
Correct, so following this logic, delete actions shouldn’t be colored as there is additional steps (or confirmation modal in the case of attachments) before actually removing the entity.
But, locking/unlocking users should, as there is no further confirmation after the click.
Also, removing a user from a group should be in red as there is currently no confirmation step.
There’s a link to bootstrap in our front-end resources doc, and there must be some info somewhere in the bootstrap 3 doc about those.
The link on our frontend resources didn’t even redirect to the bootstrap 3 doc but to the bootstrap welcome page which redirects to doc for a different version I updated it to make it relevant.
From what I know, this is everything we have about it. I would have expected something in SpecialCSSClasses if we had anything.
+1 to allow colored action (font) icons in LD, but I’d use them only when:
it’s important to highlight the action
to make the user more cautious
or because the action has a state (e.g. a toggle action) and we want to highlight a particular state (on or off)
or because the action is disabled
and there is a clear (known) association between the color and the action
I don’t think we need to highlight the edit action for instance and I don’t think the edit action is associated with any particular color.
On the other hand we might want to highlight the delete action because it’s dangerous, and there is a clear / known association between delete and red color.
As for disabling and enabling a user, this is a toggle action, so it has a state and I think it’s useful to highlight the less common state, which is disabled. So I’d be in favor of using yellow for disabled users and normal text color for enabled users. I think yellow is a good choice because it warns you that some user is disabled (and I think we should limit the number of colors we use on the actions) but I’m open to use a different color also.
I don’t disagree, but clicking on the delete button on LD is usually not dangerous, as there is a few configuration steps before actually performing the delete.
Now I’ve the feeling by reading the discussion that it’s mostly about defining the color regarding the level of danger of the actions. IMO the color on the action shouldn’t have only this purpose: it should also conveys what’s the most common action a user would do on the entry. So for an index LD where you can have multiple actions I wouldn’t put a color for each of the actions, but only for the important ones / most common ones. The danger if you put color for any actions is that you’ll obtain LD with 3 actions having same yellow / orange color which defeat the purpose IMO.
I don’t think I agree. Colors should actually highlight the uncommon actions, otherwise edit would be in red most probably.
I feel like colors should highlight uncommon or dangerous actions which deserve some thinking before clicking.
The goal is not to make a rainbow
And indeed, if all actions need colors, or if several actions need the same color, either the rule is not good, or the LD requires some design improvement.
I’m clearly in the minority that is not a very big fan of this. I don’t think we should necessarily highlight certain actions with color as they are explained with words.
Of course, this is not the only reason.
My fear is that the red or any other color of the actions will make it hard for the user to focus on the important data in the table.
No colour on actions
Nothing distracts the attention with colour, everything seems more or less equal.
Colour on icon (the acceptable version)
If only the icon gets colored, I wouldn’t oppose, tbh. It’s not that distracting.
Colour on the whole action (distracting)
Which actions to be colored
If we still go ahead with coloring actions, I’d really insist on coloring only the “critical” actions - the ones that the user has to take a tiny bit of extra time to think about. Actions like move or edit, toggles, checkboxes, etc. do not need coloring.
We have a general agreement that basic actions should not be colored.
We also have a general agreement that there is a risk of color inconsistency (e.g., two distinct actions using the same color)
I would even add that most actions should not be colored (i.e., only outstanding actions should have colors, for a definition of “outstanding to be defined”).
we did not get any complaints regarding the colors missing when migrating from LT to LD (spanning at least a full LTS cycle).
we don’t have a clear agreement on a general rule to decide which actions must be colored
@mflorea argues for making delete action colored even when there are several steps before the actual deletion, while @vmassol and I argue the opposite. There is also no agreement for the lock/unlock colors.
@surli argues for using colors to illustrate the most common actions, which is a quite different axis
@amilica argues that colors might hurt readability by forcing bring the eye to secondary elements (note: the “Colour on icon (the acceptable version)” is the one proposed in the discussion)
So in summary, I think we have two options:
Option 1: No colors
The fact that nobody complained about missing colors could be interpreted as a sign that colors are not important. But, that’s also not a proof that having colors wouldn’t improve the UX of actions.
Option 2: A few colors
In this case we need to agree on a rule. Note that based on my current search, we will be able to define guidelines, but it’s likely that we define a rule with no ambiguity (i.e., it’s likely we’ll need to debate again for some actions in the future).
Closed set of colors:
warning: to be used for dangerous actions with a possibility of revert (e.g., locking a user)
success: to be used for the action reverting a warning action
danger: to be used for dangerous actions with no possibility of revert
Definition of dangerous: any action that is leading to the least one user losing access to resources. Either by disappearance of the resource (i.e., delete), or by a user not being allowed to access the resource anymore (e.g., rights change, user locking…)
Option 2.1: Colors based on the final outcome of performing the action
In this case, an action would get a color based on the final outcome of performing the action. For instance, if clicking on the delete action leads to a new form before actually removing the entity, the action would be colored nonetheless.
Option 2.2: Colors based on the direct outcome of performing the action
In this case, an action would get a color based on the direct outcome of performing the action. For instance, if clicking on the delete action leads to a new form before actually removing the entity, the action would be not be colored as that click itself is not dangerous, only finalizing the form is.
Conclusion
I’m +1 for option 1 as we did not identify a strong usability pain related to LD actions.
I’m +0 for option 2.(1/2) with the current rules as I fear the complexity of the rules outweigh the potential usability benefits.
I updated it to make it relevant.
