Style Live Data actions as buttons

[mleduc]

Hello all,

Currently, livedata actions are presented as an icon + a corresponding label

This leads to some limitations, for instance to migrate the users administration page, where some actions are represented by colored icons.

When migrating those to LD, I noticed that the labels, if of the same color as the icon, do not have a good contrast against the background.

A solution proposed by @CharpentierLucas is to style the actions as buttons instead of links.

Here are a preview of what buttons could look like when presented as buttons:

But, not that mixing buttons and links style is not always so pretty

Reminder, the configuration of an action currently looks like this

{
  "id": "copy",
  "name": "Copy",
  "description": "Copy entry",
  "icon": {
    "iconSetName": "Font Awesome",
    "cssClass": "fa fa-copy",
    "iconSetType": "FONT",
    "url": ""
  },
  "allowProperty": "doc.viewable",
  "urlProperty": "doc.copy_url"
}

Option 1: list of extra classes

Add a extraCssClasses property on the action configuration.

Pros:

• very easy to use

Cons:

• not portable, assuming we add btn btn-default (bootstap 3), migrating to another design system will be a pain

Option 2: predetermined set of buttons

The idea is to have an optional botton property, with a closed set of possible values (default, warning, error, success, info, primary, secondary…), and to let server side handle the mapping to the current design system.

Pros:

• Flexible and anticipate the migration to another design system

Cons:

• We don’t really have a mechanism to adapt the result based on the current design system

But, if we centralize all the code related to button generation in a single place, which a closed set of choice. We’d only have this single piece of code to change to adapt to a new design system.

Conclusion

I’m +1 for option 2. WDYT? Let me know if you see another interesting option.
Bonus question: which should be the good button size? I’m -0 for the default size at it take too much horizontal space, +1 for sm or xs

Note: I’m not proposing to change the default style of actions, LD implementers are in charge of styling their buttons as they see fit.

[vmassol]

@mleduc

This leads to some limitations, for instance to migrate the users administration page, where some actions are represented by colored icons.

Why not migrate to: <pencil icon> Edit <lock icon> Lock?

@mleduc

Here are a preview of what buttons could look like when presented as buttons:

By looking at the proposed screenshot, I find that the colored buttons are too visible and the actions are over-represented in the UI vs the LD content.

Also, The “Copy” button style feels different from the rest and looks a bit weird to me in term of consistency.

What are we trying to fix? Is it because you believe that the current <icon> <text> actions are not good enough for some reason? Is it because you believe that some actions are more important than others and need to be more visible?

I’m not sure how you’d choose different styles for different actions and why one action would be more important than another (and thus be more visible or draw more attention).

Thanks

[CharpentierLucas]

Thanks for this proposal!

Proposing a style option for the actions would have the advantage of aligning the design of those action links with most of the others action links we have in the XWiki UI Examples given:
All of the buttons in the document action menu are action links styled like buttons

Both the disable account and edit buttons are action links styled like buttons

@mleduc

There might be a bit of tweaking to do to make sure every class is properly displayed, .btn-default text color here looks a bit too light.

@mleduc

Cons:

• We don’t really have a mechanism to adapt the result based on the current design system

I’m not sure we would need a mechanism. From what I understand, with this solution, we can update the set of buttons when updating the design system and be done with it. As far as I know, we only support one design system at a time. Updating the result based on the current design system would be way easier / centralized than what would be needed for a migration with option 1.

+1 for option 2

@mleduc

which should be the good button size? I’m -0 for the default size at it take too much horizontal space, +1 for sm or xs

Regarding accessibility, any button size is okay, they all respect the minimum dimensions of 24px

In my opinion we don’t want to give those buttons too much focus from the user, so I’d be +1 for xs

[mleduc]

@vmassol

By looking at the proposed screenshot, I find that the colored buttons are too visible and the actions are over-represented in the UI vs the LD content.

The screenshots are to give an idea of what those buttons would look like. But they are definitely not a good fit everywhere.

@vmassol

Why not migrate to: <pencil icon> Edit <lock icon> Lock?

Also, to give some more context. As I said my initial issue came from migrating the users admin page. The lock/unlock icons are yellow/green in the current version.

When migrating to LD, it would look like this:

But, the disable action contrast is not good.

For this specific case, I could also go the easy way and just open a proposal to get rid of the colors.

But, I thought it was interesting to open a discussion on how to offer more variety on the actions UI while staying accessible.

@vmassol

I’m not sure how you’d choose different styles for different actions and why one action would be more important than another (and thus be more visible or draw more attention).

The same way as for other forms I guess, where destructive actions are presented differently from the rest for instance.

[MichaelHamann]

@mleduc

not portable, assuming we add btn btn-default (bootstap 3), migrating to another design system will be a pain

These classes are so widely used, they are an API and we cannot break them. Regardless of the design system we migrate to, we will need to add compatibility for these classes if the design system doesn’t support them natively.

What I’m wondering is: what about actions where the user should be able to open them in a new tab, like editing, or imagine a Live Data with an explicit “view” action. Presenting them as buttons could be strange and could hide the fact that they can be opened in a new tab. Would the idea be to use a mix of links and buttons here? Or how would we decide when to use links and when to use buttons? I’m also wondering about the inconsistencies this creates.

A more general question here is I think the question of colors and icons. With silk, every icon has a fixed color. With Font Awesome, icons follow the text color. Maybe it would make sense to add a way to specify a preferred color for the icon or to associate Font Awesome icons with colors such that, e.g., the delete icon is always red?

[mflorea]

@mleduc

But, the disable action contrast is not good.

Is it necessary for the link label have the same color as the icon? I don’t see why. If the icon set were image based we wouldn’t be trying to match the color from the image. For me the yellow lock is just an icon. Why can’t we keep the same style when migrating to LD?

Thanks,
Marius

[tkrieck]

+1 for option 2
+1 for option 1 as well =)

My reasoning for implementing both is to provide ease of implementation using a set of parameters (primary, default, destructive, etc.) for buttons (Option 2), but also provide a way for the implementer to add extra css classes for edge cases (Option 1). As an example that both would be required is if I want a destructive option (delete) to be farther away from other actions. For this I would set it as “destructive” or warning" but also give it additional margin with the extraCssClasses.

On a sidenote, would it be possible to throw some actions inside a “more” menu? It would help to manage the use of horizontal space with actions of very limited use.

[mleduc]

@MichaelHamann

What I’m wondering is: what about actions where the user should be able to open them in a new tab, like editing, or imagine a Live Data with an explicit “view” action. Presenting them as buttons could be strange and could hide the fact that they can be opened in a new tab. Would the idea be to use a mix of links and buttons here? Or how would we decide when to use links and when to use buttons? I’m also wondering about the inconsistencies this creates.

In my opinion, this is the job of the developer configuring the Live Data to make sure the appearance of the actions is aligned with its behavior.

@MichaelHamann

A more general question here is I think the question of colors and icons. With silk, every icon has a fixed color. With Font Awesome, icons follow the text color. Maybe it would make sense to add a way to specify a preferred color for the icon or to associate Font Awesome icons with colors such that, e.g., the delete icon is always red?

After our discussion on the chat, this feels like an interesting improvement, but it’s scope is much larger than the one of this proposal.

@mflorea

Is it necessary for the link label have the same color as the icon? I don’t see why. If the icon set were image based we wouldn’t be trying to match the color from the image. For me the yellow lock is just an icon. Why can’t we keep the same style when migrating to LD?

Good point. This is an example of what it would look like:

Note that according to the axe, this version does not suffer from contrast issue.

@tkrieck

On a sidenote, would it be possible to throw some actions inside a “more” menu? It would help to manage the use of horizontal space with actions of very limited use.

That’s currently not possible, but I like the idea of proposing some actions as “secondary” and to group them in a “more” menu.