Alpha button

[origami-z]

Follow up from #4188, add button to work with System Status

[mark-tate]

Latte Goal: finish spec

[mark-tate]

Kickoff to be created in Latte

[mark-tate]

@jake-costa we need some a11y help on this

[jake-costa]

@mark-tate working with @dplsek to go over what assistance is required for this. Working to clarify Non-text Contrast 1.4.11.

[dplsek]

I reviewed the design proposal with @bhoppers2008 @joshwooding @jake-costa and they achieve ADA and design requirements.

Got a preliminary 'thumbs up' from @origami-z via email who could not make the call.

Specs for Salt Legacy
Specs for Salt Next

Still need to review this in detail with @pseys and @origami-z to confirm if this is technically feasible, can be wired systematically, and the necessary tokens to do so.

[mark-tate]

Lungo Goal: @pseys & @origami-z to review token requirements

[mark-tate]

Lungo update: reviewed, proposal for implementation by @origami-z

[origami-z]

Thoughts from meeting earlier:

We saw 2 sets of alpha buttons

1. mode agnostic for 500 background
   2.flipped for standard background variants (white/black texts)

1st one is needed for unblocking system status. 2nd one is preferred visual for replacing transparent button within Banner.

As soon as we release the button for system status, the community will ask to use them on other places (e.g. solid background toast, even we don't provide them). So limiting it to be SystemStatusButton won't be a good choice. However, if we don't have time to work on all buttons right now, we can opt for staged approach

1. release SystemStatusButton, constraint for only SystemStatus usage
2. [future] release AlphaButton (or other name), with 2 variants mentioned above, and swap internal implementation of SystemStatusButton to the new button

For alpha button, we need to think about

• Good name for the 2 variants
• Recommendation when used outside of Salt (e.g. BLOM)

Additional question for active state for @bhoppers2008 and @jake-costa, active state are usually transient state when used standalone. What about when the alpha button is used as menu trigger and when menu is open (active state will be kept there). We can't prevent users to pair the new button with overlay or menu for additional workflow.

[pseys]

• release SystemStatusButton, constraint for only SystemStatus usage
• [future] release AlphaButton (or other name), with 2 variants mentioned above, and swap internal implementation of SystemStatusButton to the new button

Does it cause us any complications down the line if we create a systemStatusButton component and then rename it?

[origami-z]

Does it cause us any complications down the line if we create a systemStatusButton component and then rename it?

Rename only works at major breaking change, which would be tied to a specific future event. It's better we plan something not relying on those?

[pseys]

Yes I was thinking it makes more sense that we get the naming right from the start, rather than try to rename it down the road.

[origami-z]

Yes I was thinking it makes more sense that we get the naming right from the start, rather than try to rename it down the road.

Yes, it could work. Do we know a good component name (and potential variant name) we can go to directly? With the complexity of mode agnostic / light+dark + potential different background? I'm not sure whether "AlphaButton" is a safe bet....

[mark-tate]

Macc Goal: How many alpha buttons do we need and how do we name them ?

[origami-z]

Met with Ben, Darrin, Paul and Shey on Friday.

1. Agreed that "mode" shouldn't be in component props/name, given it's option in theme.
2. Not against using appearance to unify Banner and System Status, which could work with other components (e.g. Toast, Tooltip) as Darrin shown. Need to consider additional options, given transparent doesn't apply to Banner.
3. Darrin also shared some potential alpha button usage for any buttons with purpose (e.g. close button of dialog, arrow button of pagination, etc), which could be aligned with semantic icon (Provide a mechanism to swap out built-in component icons to custom icons #3520)
4. If we decide to unite banner, need to make sure we don't lose System status's edge to edge use case (for Pepper)
   Need more thoughts around naming.

[origami-z]

My proposal below, feedback welcome

1. Create a GhostButon, with prop adaptiveAppearance = "solid" | "non-solid", default to "non-solid", to be paired with most default option of "container" type of components
2. Deprecate variant in Banner, replace with appearance = "solid" | "filled" | "bordered", default to "bordered" for backwards compatibility. New filled is introduced to the overall appearance options, to describe design choice of border + light-weight filled background (prior primary/secondary).
3. Deprecate SystemStatus, replace with <Banner appearance="filled">, move relevant use case and guidance to pattern section

See #4280 (comment) above, and more notes below

• Explored options to add "ghost" prop to existing Button component, but it's hard to explain usage guidance when paired with sentiment / appearance options
• Explored options to add "ghost" to Button's appearance prop option, similar to above, can't really explain the relationship with sentiment, and can't work out how to incorporate 2 design choices needed (mode agnostic vs not)
• System status vs Banner: creating a net new component to distinguish some component usage purpose feels against component creation, and could be hard to extend beyond current offering. I'd think System status (use case) is a pattern, together with "edge to edge" advice which could be optional for certain products. Similar to file upload pattern v.s. static list component.

[bhoppers2008]

@origami-z proposal looks good.

1. filled or solid - how did you determine which to use? (Assuming 'filling' inside the border?)
2. Assume full language for appearance is solid, filled, bordered, transparent?
3. Edge-edge - how to support this going forwards? @pseys corner won't be visible as option in new library. Is it prop driven, since JPM Brand is rounded corners?

[origami-z]

1. filled or solid - how did you determine which to use? (Assuming 'filling' inside the border?)
2. Assume full language for appearance is solid, filled, bordered, transparent?

Yes, 4 total options. I'm open to other language as well.
To explain, we could add something to the glossary around the term.

1. there is a hierarchy of "importance" - solid > filled > bordered > transparent
2. define each, e.g. solid - bold background and border color, filled - subtle background + bold border, bordered - no background + border, transparent - no background no border

3. Edge-edge - how to support this going forwards? @pseys corner won't be visible as option in new library. Is it prop driven, since JPM Brand is rounded corners?

Being a pattern, it would be a custom component from BL, which means a small override of corner could be applied there...?

[mark-tate]

Mocca Goal: If we have capacity, add button in code (medium size change) and initial docs
Publish to Labs

[origami-z]

Talked to @Fercas123 about this, with a bit more background information.

The most tricky part would be theme / theme-next wiring, not the component itself. I suggested to look at existing Button set (neutral transparent & caution solid as reference) + System Status (mainly bold foreground) token to scope out potential theme tokens, then can review with @pseys. Initial thoughts:

• characteristics could start with actionable-ghost-*, some palette values could take from existing Button/System Status, use Figma spec as reference. There is a difference in theme current, around caution solid button vs system status foreground color.
• palette layer, likely palette/alpha-next.css could be used, may need extending. Theme current may be more tricky, given neutral palette white/black fade is usually associated with disabled token. This may mean we need to extend more tokens in neutral or make palette/alpha.css (name is easy to change in code)

  • salt-ds/packages/theme/css/palette/alpha-next.css

    Lines 1 to 5 in 7d32518

    	.salt-theme.salt-theme-next[data-mode="light"] {
    	--salt-palette-alpha: var(--salt-color-black-30a);
    	--salt-palette-alpha-strong: var(--salt-color-black-45a);
    	--salt-palette-alpha-weak: var(--salt-color-black-15a);
    	--salt-palette-alpha-weaker: var(--salt-color-black-10a);

  • salt-ds/packages/theme/css/palette/neutral.css

    Lines 1 to 5 in 7d32518

    	.salt-theme[data-mode="light"] {
    	--salt-palette-neutral-primary-background: var(--salt-color-white);
    	--salt-palette-neutral-primary-background-disabled: var(--salt-color-white-fade-background);
    	--salt-palette-neutral-primary-background-readonly: var(--salt-color-white-fade-background-readonly);
    	--salt-palette-neutral-primary-foreground: var(--salt-color-gray-900);

• I also mentioned the potential deprecation of foundations/fade.css which @pseys talked about. I'm not recommending mixing the problems together into this alpha button work. If we can't solve it with existing set up, then we may look into it.

In short, the main goal is to try out whether token connection is possible for both themes.

[bhoppers2008]

PR up and chat in progress in teams (+ chatting with Paul). Goal: to have kick off for alpha button this week.

[mark-tate]

Red Eye: Tokens to be defined by EOS @pseys

[bhoppers2008]

Status update required @dplsek @pseys

[pseys]

Apologies @bhoppers2008 this took a backseat EO last year while I focused on the new libraries. I'll pick it up in this sprint.

[dplsek]

@pseys to create tokens by end of sprint

[pseys]

@mark-tate @bhoppers2008 last year, while discussing the component we started referring to it as ghost button as opposed to alpha button as there is precedent within UI design for the use of the former. Plus 'alpha' relates to the use of particular colour values which we don't include with component or token names as a rule.

Are you happy for me to change the name of this GH Issue to Ghost Button. FYI @Fercas123 WIP build is called GhostButton in Lab already.

[bhoppers2008]

Goal: End of sprint to have the tokens in place and specs finalised.
Ben/ Josh/ Paul/ Darrin to align on call (@pseys to set up call).

[pseys]

Met with @dplsek , @bhoppers2008 and @joshwooding earlier today to discuss progress. Although token names have been proposed, Darrin has also proposed extending the scope of the Button.

• Alpha/Ghost button should support the same appearances as button i.e. Transparent, Bordered, Solid
• It still needs to have two variants to allow for placement on both a light and mid/dark background in light mode.
• Josh confirmed that we could add conditions to the Button component to allow it to support appearance and/or sentiment/alpha options – the alternative is to follow on with @Fercas123 work and provide it as a stand-alone 'ghost button' component
• Ben shared that the approach may impact other components as we may need 'alpha card' etc. in the future
• Paul raised the need to clean up 'legacy' tokens as the way we handle opacity is flawed and inefficient - have begun mapping replacements/deprecations to allow legacy and brand to run off the same set of palette tokens. Doing this will minimise the number of tokens/css files we have to manage as a team and also simplify our Figma libraries considerably.

I've created #4572 as the first part of cleaning up the tokens – this and any subsequent similar issues won't slow or prevent the button from being released

[mark-tate]

Tecno Goal:
Standalone button available in Labs

• connect to the right token and show appearances (paul/fernanada)
• 2 variants it needs to allow it to sit in dark backgrounds have naming assigned (paul)
• call to discuss buttons and make decision on
  • we will need to extend button to avoid creating alpha versions of all components that use button

[mark-tate]

AlphaButton versus extending Button semantics is still being discussed

[mark-tate]

Ontrack to have a decision by EOS

[mark-tate]

Requires another sync up to make the decision
By next standup we should have a decision, this story will slip into next sprint.

Related to pokemon perhaps ?

[mark-tate]

dependent on Pokemon, will stay in PR until we have interpreted the Pokemon matrix
Can have a snapshot release created if required