Hi @matmarex, thanks for reporting this - the Design Systems Team will review this by 2023-05-22 and let you know what to expect.

Related: T329963: Provide guidelines on when to choose which basic interaction element in Codex

Hey @matmarex, thanks again for reporting this. Was there an underlying issue you ran into that prompted this, or was it just a general observation when going through the docs?

One of the motivations behind the quiet button is for buttons with icons, like the "Dismiss" buttons in the Dialog or Message components for example (see below).

I agree that the quiet text-only buttons look ambiguous though. I think a first pass would be to provide better guidelines in the documentation (as @Volker_E linked to) instead of adding complexity to the component (i.e. making props available only in specific cases, like if a button includes an icon). Does that sound sufficient? That would be something we would be able to prioritize soon. Updating the component or deprecating the prop would require much more discussion and would be lower priority.

Ignoring implementation details, does it really make sense to consider that control a "button"?

In T336676#8866558, @Xover wrote:

Ignoring implementation details, does it really make sense to consider that control a "button"?

Well it technically is a button, and is commonly represented as one in web UIs. I'm not sure it would make sense to create a whole new component to represent this use case.

I also realized in some instances (see T332767: OnboardingDialog: Add OnboardingDialog component pattern to Codex), there are legitimate use cases for the text-only quiet button. This would be another reason to consider guidelines over deprecation.

Edit: that doesn't mean the accessibility of these buttons can't be improved though.

In T336676#8877517, @CCiufo-WMF wrote:

I also realized in some instances (see T332767: OnboardingDialog: Add OnboardingDialog component pattern to Codex), there are legitimate use cases for the text-only quiet button. This would be another reason to consider guidelines over deprecation.

I assume you mean this one: (and a few variants of the same dialog)

For me, this isn't a legitimate use, but instead it's an example of exactly the problem I am trying to point out! The "Skip all" button looks almost the same as the nearby text. It's only identifiable due to its placement (although imagine the mockup being in Arabic rather than English, with right-to-left text direction: I'm sure none of us who don't speak the language could confidently identify which is the title and which is the button in that case). It's not terrible, but if the button was instead an "x" icon, or if it had a button frame, it would be better. The text-only quiet button is always the worse option.

In T336676#8877517, @CCiufo-WMF wrote:

In T336676#8866558, @Xover wrote:

Ignoring implementation details, does it really make sense to consider that control a "button"?

Well it technically is a button, and is commonly represented as one in web UIs.

If you define "button" as "something that responds to a mouse click", then, sure. But the close widget has distinctively different behaviours from a button qua button. Case in point, we now have awkward "quiet" buttons because we're trying to shoehorn a button into the role of a close widget.

For me, this isn't a legitimate use, but instead it's an example of exactly the problem I am trying to point out! The "Skip all" button looks almost the same as the nearby text. It's only identifiable due to its placement (although imagine the mockup being in Arabic rather than English, with right-to-left text direction: I'm sure none of us who don't speak the language could confidently identify which is the title and which is the button in that case). It's not terrible, but if the button was instead an "x" icon, or if it had a button frame, it would be better. The text-only quiet button is always the worse option.

Point taken. I do agree that just because there are existing uses, doesn't mean they cannot be improved.

Going to backlog this item for now. We'll consider this as part of T329963: Provide guidelines on when to choose which basic interaction element in Codex and this task can be updated based on the outcome there (i.e. the guidance might be that we need to deprecate the text-only quiet button, or it might be that we just need to provide guidelines & usage warnings).

My memory says that when EditPage got the OOUI freshening that the Cancel button got the quiet treatment and there was some consternation about that. T165122: "Cancel" button in action=edit must not look like a red link jumps out at me as one version of it. (T42601 looks to have happened earlier, and T64304 looks interesting too.) JFYI.

In T336676#8970290, @Izno wrote:

My memory says that when EditPage got the OOUI freshening that the Cancel button got the quiet treatment and there was some consternation about that. T165122: "Cancel" button in action=edit must not look like a red link jumps out at me as one version of it. (T42601 looks to have happened earlier, and T64304 looks interesting too.) JFYI.

That's helpful context, thank you!

In T336676#8968635, @CCiufo-WMF wrote:

Going to backlog this item for now. We'll consider this as part of T329963: Provide guidelines on when to choose which basic interaction element in Codex and this task can be updated based on the outcome there (i.e. the guidance might be that we need to deprecate the text-only quiet button, or it might be that we just need to provide guidelines & usage warnings).

It looks like the outcome of that is this note, visible at https://doc.wikimedia.org/codex/main/style-guide/using-links-and-buttons.html#weight:

Use Quiet Buttons for an easily recognizable action that does not detract focus from the content. Be conscious of the fact that Quiet Progressive Buttons can look similar to Links, so avoid using them next to each other.

This is better than nothing, so thank you for doing that, but I would still like to see this design antipattern be discouraged more clearly.

Noting from T235463#9543787 that @matmarex also wrote that new guidelines:

still doesn't explain why you would use this kind of button instead of a normal button.

I would agree with this. The guidelines cover quiet progressive buttons, but quiet default buttons (which are the most confusing) are actually recommended.

From https://doc.wikimedia.org/codex/main/style-guide/using-links-and-buttons.html#buttons

TIP: Use Quiet Buttons to emphasize Normal Buttons when both are combined on the same page.

I still don't know that we need to explicitly deprecate the default quiet button, but maybe the guidelines should discourage its use. cc: @DTorsani-WMF

This can be a tricky one. It is true that Quiet Buttons do not visually denote the notion of something interactive. Always using the Progressive (blue) versions can fall into the trap of appearing as links, which can present other accessibility challenges. In some rare but important and commonly interacted with instances, we style a link as a button to draw more visual attention to it and to fit in with surrounding interface elements. These are all reasons why it is difficult to make one clear decision and difference of what style to use.

The aspect of any action, link or button, that denotes its notion as an action the most is the text used. So my suggestion would not be to deprecate this style of the Codex Button or even discourage its use, but to ensure that the content within a button is properly written. Using verbs and more information about how to write for buttons can be found here https://doc.wikimedia.org/codex/latest/components/demos/button.html#content.

Another issue with quiet normal Buttons is that they look the same as text. So I wonder if we could consider restyling them from color-base to color-subtle so it's visually easier to differentiate the actions from the text when both are placed next to each other.

Current behavior	Proposed change using color-subtle

The most important factor within an action that should denote is actionability is the verbiage used. It should be a verb, as in something that is taking action. For accessibility reasons, such as varying colorblindnesses, low or blurry vision, or the use of screen readers, the color and style cannot be the main factor for what denotes an action. Instead the label should do its best at doing so. That being said, I think the update to using @color-subtle is an appropriate visual update.

El T336676#11623513, @DTorsani-WMF escribió:

The most important factor within an action that should denote is actionability is the verbiage used. It should be a verb, as in something that is taking action. For accessibility reasons, such as varying colorblindnesses, low or blurry vision, or the use of screen readers, the color and style cannot be the main factor for what denotes an action. Instead the label should do its best at doing so. That being said, I think the update to using @color-subtle is an appropriate visual update.

@DTorsani-WMF great, I've created this task for that style change T417659: Quiet Normal Button: Consider updating to new @color-neutral