Allow colors for Live Data action icons

Development
#1

Hello all,

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.

#2

I’m ok for having colors for LD actions but I think it’s not enough and we also need rules:

  • Are all actions colored?
  • If I add an action, what color should I use?
1 Like
#3

Something like:

  • 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

#4

Based one the current use cases, I’d suggest:

  • red (i.e., danger) for actions that remove something
  • yellow (i.e., warning) for actions that remove access to essentials features (e.g., access to the wiki)
  • gree (i.e., success) for actions that revert the effect of a yellow action
#5

I prefer my proposal for this one :slight_smile:

  • Yellow color for actions to modify something

Unless you think that editing a page for example shouldn’t be yellow.

#6

hmm what about an undelete action for example?

#7

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?

#8

Actually, it could be argued that editing a page doesn’t modify anything, since you need to hit save for that. I’d still prefer yellow I think. WDYT?

#9

Yes, the colors are illustrative and the value in parentheses are the technical one, that are mapped to the color theme in practice.

#10

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.

#11

Same for deleting something then (like a page), no? (since you get some confirmation page or confirmation dialog)

#12

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.

#13

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 :confused: 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.

#14

+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.

Thanks,
Marius

#15

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.

#16

+1 to allow colors in actions.

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.

#17

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 :slight_smile:
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.

#18

Ok maybe I wasn’t clear enough: I meant “presence of color”, not the actual color used.

Yes that was my point.

#19

Hello! I might be a bit late on this, but:

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.

no color

Colour on icon (the acceptable version)

If only the icon gets colored, I wouldn’t oppose, tbh. It’s not that distracting.

delete icon red

Colour on the whole action (distracting)

delete button full red

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.

#20

Thanks for all the inputs.

Let’s try to summarize.

  • 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.

1 Like