Shadows on buttons - Minimalist Skin 4

[amilica]

True, true. Thanks for the suggestion!

Here is how idea 1 would look in action, in edit mode on the home page:

[vmassol]

Thanks. That looks good to me. Have you verified that there’s no WCAG contrast issue between the light grey buttons and the white background (for Iceberg at least)?

Since you brought up idea 2 and mentioned certain contexts where shadows could be better, do you have examples in XWiki where idea 1 wouldn’t look that good?

[mflorea]

@amilica

I think this might need to be taken as an issue of its own. I’ll search if there is one already created. What does the hidden input do?

Yes, it’s a separate issue. The hidden input is needed in order to be able to have xclass properties that have the same name as one of the action buttons. See XWIKI-6936: Cannot save a class after creating a property named 'acti… · xwiki/xwiki-platform@d7562e6 · GitHub .

@amilica

Let me know what do you think about this

I like it. Good point about the “transparent” disabled buttons.

[CharpentierLucas]

@amilica

Button States (with shadows)

I’ve made this graphic containing the details of these states:

Looking great!
I don’t like the transparent disabled buttons because they introduce unexpected contrast violations. With transparency, contrast always drops. For example, I took the transparent button on the second line (black background). The contrast was not enough to meet WCAG requirements → Colour Contrast Checker
I’d rather use an explicit color to convey this muted state (for text color, the .muted mixin works well). It’s easy to find or check contrast if you only use full colors. The issue with using semi-transparent elements is that we get a range of colors in the theme, that are not ‘really’ part of the theme, but a variation from two of its colors. E.g. the text color (white) is fine on this background (dark grey), but somewhere, an element uses transparency and now we have two new colors (light grey for text and grey for background) that were not part of the color theme and don’t have enough contrast.

The icon would make things better, I’m not sure it would look good though.

Mentioned in this article about accessibility of button states, it seems like there is a debate on whether this kind of contrast should be considered as a failure, it’s a difficult issue to solve for everyone.

-0 for transparent disabled buttons,

---

Except this, this change looks good to me +1

@vmassol

Have you verified that there’s no WCAG contrast issue between the light grey buttons and the white background (for Iceberg at least)?

I checked the last combination of grey buttons in the original post picture ‘Look in XS’ (which seemed to me like the least contrasted in this picture), and it passes contrast requirements for WCAG

[amilica]

@CharpentierLucas

I’d rather use an explicit color to convey this muted state

I totally understand your concern on the contrast violations of a “transparent look” button.

The only problem that I have with setting a fixed gray color on this disabled button is that the user is absolutely able to set the main button or another button to a variation of gray. Now we would have two buttons that look very similar and the user has to use his memory each time to differentiate between the two (or get frustrated in the process of trying to figure out why his button is not working).

I feel like the lock icon might be a good answer in both ideas (both the fixed gray background disabled button and the semi transparent button).

@CharpentierLucas

The icon would make things better, I’m not sure it would look good though.

Here is how it would look for the “transparent” buttons:

While hovering on the lock icon a warning box is displayed beneath the disabled button stating why the action of the button is forbidden to the user.

What do you think?

I guess the disabled button could be a proposal in itself, but maybe we could find a solution in the context of this current discussion ^^

[amilica]

@vmassol

Since you brought up idea 2 and mentioned certain contexts where shadows could be better, do you have examples in XWiki where idea 1 wouldn’t look that good?

At a quick glance, I don’t believe there are contexts in which buttons without shadows wouldn’t work. I will make that audit of elements I was talking about in the Rounded Corners discussion and maybe some case will arise.

There are definitely cases in which the lack of shadows would negatively affect other components (modals, notifications dropdown), but I don’t think buttons would be one of them. If we solve the issue with disabled buttons, no shadows buttons could be a good choice, too

[CharpentierLucas]

@amilica

The only problem that I have with setting a fixed gray color on this disabled button is that the user is absolutely able to set the main button or another button to a variation of gray. Now we would have two buttons that look very similar and the user has to use his memory each time to differentiate between the two (or get frustrated in the process of trying to figure out why his button is not working).

There is a lot of places in the color theme where “if the user does X, it breaks this” already.

Note that AFAIK this kind of button is not found in a lot of places, except on WYSIWYG edit mode, see the fix we merged about this issue in the current theme at XWIKI-19145: Edit button must be unaccessible for keyboard while in edit mode by Sereza7 · Pull Request #2191 · xwiki/xwiki-platform · GitHub (solved XWIKI-20908 Disabled buttons lack contrast).

@amilica

Here is how it would look for the “transparent” buttons:

Looks good to me
Note that most buttons keep the same color for text and icons so far (with Font Awesome, because Silk doesn’t support color variations), but it makes sense to change this practice here since there isn’t enough contrast between the text and the background.

@amilica

What do you think?

I guess the disabled button could be a proposal in itself, but maybe we could find a solution in the context of this current discussion ^^

I think it’s a good solution
I don’t think it’s worth spending time to create another proposal, you described it pretty well here already and it’s a marginal change

[mflorea]

@amilica

Here is how it would look for the “transparent” buttons:

While hovering on the lock icon a warning box is displayed beneath the disabled button stating why the action of the button is forbidden to the user.

What do you think?

I’m not convinced by the lock icon. Can you point us to other places where this pattern is used? I see three problems:

• some buttons have icons, in which case the icon represents the action (e.g. the pencil on Edit button); when you have such a button near a disabled button it’s not easy to know if the lock icon represents the button action (“to lock something”) or the disabled state. My guess is that most of the users will think that it represents the action.
• disabled state can be toggled which leads to an annoying UI flickering (in some cases where the width is limited it could even shift the content down or move the button to a different “line”), if the button doesn’t have an icon already (which is common);
• I don’t think the lock icon is a good representation for the “disabled” state; the lock icon is often used to mean “you’re not authorized to perform this action”, so related more to access rights

For these reasons I’m -0 for using the lock icon on disabled buttons.

Thanks,
Marius

[lucaa]

Hello @amilica , all,

For the disabled state it appears that Bootstrap 5 has a solution based on what appears to be lighter colors: Buttons · Bootstrap v5.0 . Is it something that we could reuse? (same for all the other button states).

Also, lock label is confusing for me as well, for the reason that @mflorea mentioned, it being a new pattern we haven’t used before.

Thanks,
Anca

[lucaa]

For the original question, I am also for the no shadow choice, it looks good to me.

I would also want no border-radius (or less than the 7x, which looks too much to me), but I don’t know if this is the discussion here or not.

Thanks,
Anca

[mflorea]

@lucaa

I would also want no border-radius (or less than the 7x, which looks too much to me), but I don’t know if this is the discussion here or not.

I see you already replied to Rounder corners everywhere - Minimalist Skin 3 - #13 by lucaa .

[amilica]

@lucaa

For the disabled state it appears that Bootstrap 5 has a solution based on what appears to be lighter colors: Buttons · Bootstrap v5.0 . Is it something that we could reuse? (same for all the other button states).

Yep, aware of this and already explored in a way this idea a bit earlier in the discussion, with @CharpentierLucas.

If we are talking light backgrounds with white text there is a contrast issue which fortunately or unfortunately is not documented as a requirement by WCAG (see 1.4.3) Even if a minimum color contrast is not required for inactive components, I think we should still strive to make every important element available for everyone using XWiki (and I consider disabled buttons important)

If we have black text and the background becomes lighter, sure, we don’t have contrast issues, but if the text remains as black as before, it will feel like a normal button or, worse, may feel even more important than the actual normal button.

[amilica]

@lucaa

I am also for the no shadow choice, it looks good to me.

Oki, nice, thanks for your feedback!

[vmassol]

@amilica

From my perspective, knowing that our users are pretty technical, I believe they wouldn’t have any trouble differentiating between a flat button and a button with soft shadow, if the contrast against the background is right.

Hi @amilica . About this, it’s not correct to assume that our users are technical. Our goal is to make a software that can be used by non technical users at all and that is the simplest to use for them. That’s very important to understand since the design we propose need to go in this direction.

More generally, we need XWiki to be as simple to use as possible by default for simple users but also offer advanced features for advanced users (see https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing#HSimpleandAdvancededitingprofiles for the concept of simple and advanced users).

[amilica]

@vmassol

About this, it’s not correct to assume that our users are technical. Our goal is to make a software that can be used by non technical users at all and that is the simplest to use for them.

Okay, true, true.

Do you believe that the skillset of a simple user of XWiki would be correctly confined in:

"a person that uses often enough a big variety of websites to be accustomed with many types of interfaces and behaviors, able and in need of editing, creating pages, using templates, using the most popular extensions, but that doesn’t have a need or a lot of expertise in adding custom code or in setting very specific configurations in their XWiki instance "?

This definition would imply that these users would recognize the proposed buttons with or without shadows if they can see the buttons (enough contrast).

[amilica]

@mflorea

some buttons have icons, in which case the icon represents the action (e.g. the pencil on Edit button); when you have such a button near a disabled button it’s not easy to know if the lock icon represents the button action (“to lock something”) or the disabled state. My guess is that most of the users will think that it represents the action.

This is a really good point, thank you for highlighting it!

Do you think that having the icon next to the transparent button would help?
Something like this:

Of course, this solution would still suffer from this:

@mflorea

disabled state can be toggled which leads to an annoying UI flickering (in some cases where the width is limited it could even shift the content down or move the button to a different “line”), if the button doesn’t have an icon already (which is common);

@mflorea

I don’t think the lock icon is a good representation for the “disabled” state; the lock icon is often used to mean “you’re not authorized to perform this action”, so related more to access rights

Related to the last point, I understand your concern on the meaning it may convey. My bias towards it may come from the often encounters I had with the lock icon in the gaming industry. The lock is always used to say “you haven’t unlocked this yet” / “you are not allowed to do this yet”… “but you could at some point or in some circumstances”.

Here is an example of usage in Read Dead Redemption 2:

I totally get that this may be easily understood by the typical gamer, but not by the usual XWiki user, but let me know what you think.

In this article, they explore how to use icons in disabled buttons. It’s a bit different then what I proposed as they signal something is happening different with the button by using a info icon:

[amilica]

@mflorea

I don’t think the lock icon is a good representation for the “disabled” state

Another option for the icon would be the cancel icon or ban icon:

[vmassol]

I don’t think you need any specific skills to be able to click on a button… Or said differently we can assume that any xwiki user will know how to use a mouse, a computer screen and be able to click on a button (basically have prior experience of using a web site).

Regarding the specific definition of XWiki personae, it could be interesting to refine them and document them on dev.xwiki.org. Caty worked on this in the past but AFAIK it’s not been written in documentation. What I’ve found is:

• UX: Personas (Proposal.Personas) - XWiki
• Survey Personas (2017) (Proposal.SurveyPersona) - XWiki

If you’re ok and when you have some free time, it would be good if you could propose some personae on this forum and once we agree about them we could document them on xwiki.org. ATM we have at least 3 known personae (but probably not clearly defined):

• Simple & Advanced users - see Page Editing (XWiki.org)
• Admins

Thanks

[amilica]

@vmassol

I don’t think you need any specific skills to be able to click on a button… Or said differently we can assume that any xwiki user will know how to use a mouse, a computer screen and be able to click on a button (basically have prior experience of using a web site).

Agreed.

@vmassol

Regarding the specific definition of XWiki personae, it could be interesting to refine them and document them on dev.xwiki.org. Caty worked on this in the past but AFAIK it’s not been written in documentation. What I’ve found is:

• UX: Personas (Proposal.Personas) - XWiki
• Survey Personas (2017) (Proposal.SurveyPersona) - XWiki

If you’re ok and when you have some free time, it would be good if you could propose some personae on this forum and once we agree about them we could document them on xwiki.org. ATM we have at least 3 known personae (but probably not clearly defined):

• Simple & Advanced users - see Page Editing (XWiki.org)
• Admins

Yep, this definitely would be interesting to do, I’ll put in my list of things to do. Thanks a lot for the idea!

[CharpentierLucas]

@vmassol

I don’t think you need any specific skills to be able to click on a button… Or said differently we can assume that any xwiki user will know how to use a mouse, a computer screen and be able to click on a button (basically have prior experience of using a web site).

As a side note, I found an interesting presentation about ageism a few months ago, and this topic was a good part of it: Ageism in Interfaces. It highlights how important the choice of icons can be for the UX of tech unsavy users. The timestamp in the link is relevant for generic usability, the rest of the presentation is focused on accessibility.