Page MenuHomePhabricator

Update Hover/Active states in Normal and Quiet buttons
Open, Needs TriagePublic

Description

Background/Goal

There are some inconsistencies in our current Normal and Quiet Codex buttons on hover and active states:

Normal buttons:
  • Destructive active uses white background while progressive and neutral use subtle flavour color backgrounds (normal-destructive should use background-color-destructive--subtle instead)

Captura de Pantalla 2022-08-19 a las 13.41.56.png (1×948 px, 414 KB)

Quiet buttons:
  • Quiet neutral button uses subtle background with border while progressive and destructive use solid dark background (with white text).

Captura de Pantalla 2022-08-19 a las 13.45.22.png (1×916 px, 396 KB)

Design proposal

The proposal is to align the normal and quiet buttons hover and active states to be consistent.

Captura de Pantalla 2022-08-19 a las 14.06.45.png (876×2 px, 738 KB)

Open questions

  • Currently the quiet-normal active button uses border. In the design specs we are proposing to delete the border from quiet buttons since the nature of these buttons is to be quiet and the text color already communicates the state change. Do we need the border/outline in the active quiet buttons for some reasons?

Acceptance criteria (or Done)

Design

  • Redesign normal and quiet buttons hover and active states to be consistent
  • Publish updated buttons in our Codex library Figma file

Code

  • Normal buttons:
    • Destructive: Update hover state with background-color-destructive--subtle #ffe7e6
  • Quiet buttons:
    • Progressive:
      • Hover: update background with combination of background-color-progressive--subtle (#EAF3FF) + opacity-low (0.3)
      • Active: update background with combination of background-color-progressive--subtle (#EAF3FF) + opacity-medium (0.65) and text/icon with color-progressive--active
    • Destructive:
      • Hover: update background with combination of background-color-destructive--subtle (#FFE7E6) + opacity-low (0.3)
      • Active: update background with combination of background-color-destructive--subtle (#FFE7E6) + opacity-medium (0.65) and text/icon with color-destructive--active
    • Neutral:
      • Hover: update background with combination of background-color-interactive (#EAECF0) + opacity-low (0.3)
      • Active: update background with combination of background-color-interactive (#EAECF0) + opacity-medium (0.65) and delete border from the active button

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
bmartinezcalvo renamed this task from Update background color for Active normal progressive buttons to Update Active Normal buttons (progressive and destructive).Mar 9 2022, 11:26 AM
bmartinezcalvo updated the task description. (Show Details)

I have created these proposals to solve the inconsistencies between buttons. You can view the prototypes with the Interactive Components here (open the left menu to compare the Current buttons with Option 1 and Option 2)

  • Option 1: apply Base80 to all active backgrounds for both Normal and Quiet buttons.
  • Option 2: apply the lighter color with flavour on each active button (both normal and quiet buttons).

Option1.png (500×960 px, 13 KB)

Option2.png (500×960 px, 13 KB)

Option 1 works better for me because:

  • We would have more consistence between Normal and Quiet buttons
  • We would keep better the sense of darker when active
  • We would create fewer number of color tokens (using only Base80 for all active buttons)

cc: @Volker_E @Sarai-WMDE

Volker_E renamed this task from Update Active Normal buttons (progressive and destructive) to Update Normal progressive and destructive buttons active state.Mar 9 2022, 1:53 PM
Volker_E added a project: Design.

Option 1 (applying the same background color to all active normal buttons) sounds like the most consistent alternative. Styles would be aligned while the "flavor" would still be communicated by the text color:

Screenshot 2022-03-09 at 15.40.04.png (692×308 px, 39 KB)

Option 1 (applying the same background color to all active normal buttons) sounds like the most consistent alternative. Styles would be aligned while the "flavor" would still be communicated by the text color

@Sarai-WMDE right, flavor would be communicated by text and border color. I also lean towards Option 1, it's more unified and reduce the number of tokens used.

If @Volker_E agree with Option 1 (view prototype here to compare all hover-active buttons) we can move forward with it and update our Figma buttons.

The framed buttons become lighter on :hover and then darker when pressed, the quiet have not followed this. I think Option 1 makes sense in itself.
The only small concern I've got with Option 1 is, that quiet destructive actions are destructive. Emphasizing it with red background was another signal to the user, that they should be sure what they are doing next, is going to be destructive.

Since the decision between Option 1 and 2 was no clear I've tested both with all the designers during the Design Review today (here you can read all feedbacks). After showing them both proposals and telling them the pros and cons of each one, they have all leaned (the absolute majority) for Option 2, explaining that with the flavor color on hover and active, the state of the button is reinforced (as @Volker_E commented in his last comment).

Although with Option 1 we reduced the number of tokens used for this buttons, I think it's better if we use the flavor on hover and active to highlight the action the user will do (specially for destructive actions with red).

Captura de pantalla 2022-03-31 a las 17.41.54.png (1×1 px, 546 KB)

If you agree I will update the buttons in the library with this Option 2.

Thanks for gathering that useful feedback, @bmartinezcalvo 🙏🏻 I think this option is good too. I find it nice to be "true" to the buttons' flavor in each state. Thumbs up from my side.

I guess this means that the style of active quiet buttons is also going to be updated? Please note that there's currently an inconsistency between the style of these buttons' active state in Figma vs. Codex. Should that be tackled in a separate task?

Just as a side note (not a proposal) in case we wanted to respect the "rule" of making framed active buttons darker (mentioned in the description), and use even less tokens, we could always invert colors and use the current styles of active progressive buttons with (all) the normal and quiet types too. This is the approach applied to progressive and destructive quiet buttons in Codex, but not in Figma (this is the inconsistency mentioned above):

Apr-01-2022 13-45-22.gif (444×672 px, 337 KB)

I guess this means that the style of active quiet buttons is also going to be updated? Please note that there's currently an inconsistency between the style of these buttons' active state in Figma vs. Codex. Should that be tackled in a separate task?

@Sarai-WMDE I think we should use this task to update the buttons in both Figma and Codex and take advantage to unify them.

Just as a side note (not a proposal) in case we wanted to respect the "rule" of making framed active buttons darker (mentioned in the description), and use even less tokens, we could always invert colors and use the current styles of active progressive buttons with (all) the normal and quiet types too. This is the approach applied to progressive and destructive quiet buttons in Codex, but not in Figma (this is the inconsistency mentioned above):

Apr-01-2022 13-45-22.gif (444×672 px, 337 KB)

I think we shouldn't use the same active color for primary and quiet buttons since quiet buttons are always more subtle in all their states (even in the active state). Color used for active primary buttons is too dark and highlight for quiet buttons.

STH renamed this task from Update Normal progressive and destructive buttons active state to [Ready for Development] Update Normal progressive and destructive buttons active state.Apr 15 2022, 9:31 PM
STH changed the task status from Open to In Progress.
STH triaged this task as High priority.May 1 2022, 1:21 PM
SimoneThisDot renamed this task from [Ready for Development] Update Normal progressive and destructive buttons active state to Update Normal progressive and destructive buttons active state.May 19 2022, 7:46 AM
SimoneThisDot claimed this task.
SimoneThisDot moved this task from Backlog to Design-System-Sprint on the Design-System-Team board.
bmartinezcalvo renamed this task from Update Normal progressive and destructive buttons active state to Update Active state for normal-progressive and normal-destructive buttons.May 19 2022, 10:16 AM
bmartinezcalvo updated the task description. (Show Details)
bmartinezcalvo updated the task description. (Show Details)
bmartinezcalvo renamed this task from Update Active state for normal-progressive and normal-destructive buttons to Update Hover/Active states in Normal and Quiet buttons.May 19 2022, 10:18 AM

Hey @SimoneThisDot @bmartinezcalvo ; I'm working on removing sprint tasks that are unrelated to our sprint goals (TypeaheadSearch, Testing, or Component Epic Template), but I also want to respect work completed so far.
Do we want to keep this prioritized? Or is it OK to move to our backlog?

Hi @ldelench_wmf (sorry for the late reply)

I am ok for this to be moved out, even more because it is currently blocked by changes that need to happen in the design tokens (not sure if this happened while I was away).

SimoneThisDot changed the task status from In Progress to Stalled.Jun 28 2022, 12:03 PM

This is awaiting multiple changes in the color tokens and decision on the buttons style itself as discussed in last engineer enclave (20th June)

ldelench_wmf lowered the priority of this task from High to Medium.Jun 28 2022, 5:26 PM

Sounds good, thanks Simone! Adjusting the priority & moving back to our backlog.

Volker_E changed the task status from Stalled to Open.Aug 10 2022, 4:38 PM
Volker_E removed SimoneThisDot as the assignee of this task.
Volker_E added a subscriber: SimoneThisDot.

Change 822087 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] tokens: Use design-first Background Color decision tokens

https://gerrit.wikimedia.org/r/822087

Change 822087 merged by jenkins-bot:

[design/codex@main] tokens: Use design-first Background Color decision tokens

https://gerrit.wikimedia.org/r/822087

Change 823725 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update Codex from v0.1.0-alpha.9 to v0.1.0-alpha.10

https://gerrit.wikimedia.org/r/823725

Change 823725 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.1.0-alpha.9 to v0.1.0-alpha.10

https://gerrit.wikimedia.org/r/823725

As we've created our new color tokens and they've been added in the different Codex components, I've updated the Figma proposal with the right color tokens added and I've also updated the task description reflecting the changes we should do in the Codex buttons to be aligned with the proposal (adding the tokens we should use in each case).

Captura de Pantalla 2022-08-19 a las 14.06.45.png (876×2 px, 738 KB)

ldelench_wmf lowered the priority of this task from Medium to Lowest.Jan 20 2023, 7:06 PM

Change 896456 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] Button, styles: Use design-first background color tokens for active

https://gerrit.wikimedia.org/r/896456

bmartinezcalvo raised the priority of this task from Lowest to Low.EditedMar 13 2023, 10:37 AM
bmartinezcalvo added a subscriber: CCiufo-WMF.

Updating the priority of this task. The design proposal was created some time ago and we need to decide if we want to implement it. Although it's not a high priority we could align our buttons hover-active behavior in some moment. cc: @Volker_E @CCiufo-WMF for visibility.

Change 896456 merged by jenkins-bot:

[design/codex@main] Button, styles: Use design-first background color tokens for active

https://gerrit.wikimedia.org/r/896456

Change 898895 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v0.6.2 to v0.7.0

https://gerrit.wikimedia.org/r/898895

egardner raised the priority of this task from Low to Needs Triage.Oct 2 2023, 9:15 PM
egardner moved this task from Needs Refinement to Backlog on the Design-System-Team board.

Removing WikimediaUI-Base as work will be only continued in successor Codex Design Tokens.