Proposal: Reconsidering button variants

[muratcorlu]

Recently, while reading an article, drawing below attracted my attention about how they style button variants:

I noticed that how general style of the buttons here expresses their hierarchy and makes their primary, secondary and tertiary naming more meaningful, regardless of their colors. The example above uses our contained buttons as primary, our outline as secondary and our text as tertiary.

In contrast, the hierarchy of our current primary and secondary buttons is directly -and only- related to their colors. outline and text versions of the buttons doesn't mean a hierarchy in our buttons as opposed to their styles.

I feel that, this creates some confussion especially when we discuss over our color palette. A few months ago, we decided to remove tertiary button because difference between secondary and tertiary buttons was only the color and the -default- colors were very close to each other.

But we also needed a button lower than secondary in the hierarchy in multiple cases.

Now I want to offer to re-considering our button variant naming. I feel like using outline as secondary variant and text as the tertiary variant makes more sense, easier to explain and easier to use.

With those variants, it's very obvious to see the hierarchy between the buttons regardless of their colors.

Then maybe we can use colors as kind to give button to a thematic value. like <bl-button variant="secondary" kind="success">Success</bl-button> can be:

To conclude, I think there is a big value to use primary, secondary and tertiary variants as the replacement of current contained, outline and text kinds and using kind parameter to them with their colors like primary color = default, secondary color = neutral, success and danger. In this case we may also need to rename our primary and secondary colors.

kind \ variant	primary	secondary	tertiary
default
neutral
success
danger

What do you think?

@buseselvi @leventozen @DamlaDemir

[muratcorlu]

kind of the button, in this case, provides a "contextual theme" to the button without indicating any hierarchy. I'm not sure about the default and neutral naming, by the way.

[koulgar]

This seems like more practical than what we've currently. Honestly only thing that bothers me naming kind as a coloring/theme related attribute. Wouldn't it be clearer to name it something like color?
Reason i'm suggesting it something like color or theme seems more applicable to use in other components to unify usage patterns. Does it make sense?

[muratcorlu]

I'm also not sure about the naming kind as the attribute as well, but color feels like it accepts a real color code instead of a color name in the palette. And theme is not convenient here since success or danger is not really a theme. We'll give theming options to Baklava users by setting their own design token variables. Then an attribute named theme will give the feel that you are setting a design theme for that component.

Maybe context can be another option?

[DamlaDemir]

This idea is better and clearer for variant usage. Actually, we discussed with @leventozen before about using the variant when trying to find a new prop name kind. We thought to give color or theme instead variant too. But it doesn't fit our purpose. I agree with you @muratcorlu if we use the color it may mean we can give any color. When I glance at the other UI libraries I saw the names intent, colorScheme for color.

I think, maybe we can use mode instead of kind.
mode=default mode=dark mode=success mode=danger

[leventozen]

Very good perspective. I agree with what you pointed out. However, I think we only need to replace kind with variant for the naming part and everything became ok to me.
Because I tend to think that primary is for primary actions. That is the kind we can say about the button.

Therefore, when we need to specify its kind, those are: primary, secondary and tertiary.

<bl-button kind="secondary">secondary</bl-button>

It is a secondary action, means UX decided this action is secondary, ex: cancelling a dialog screen.
Additionally,

<bl-button kind="primary" variant="danger">primary</bl-button>

It should make the user think that it is the primary action for this but with the danger variant, should think that it may cause some irreversible changes, let's say.

[buseselvi]

As the UX team we agree that it would be better to update the buttons as @muratcorlu suggested, it would be more safe to determine the usage areas of the buttons according to the style rather than the color.

Maybe we can call it state; default, neutral, success, and error terms seem to indicate a state.

[muratcorlu]

As always, naming things is one of the biggest challenges of our work 😊 Let me sum-up da suggestions for the button styles:

• color
• theme
• mode
• context
• variant (use kind for hierarchical names)
• state

Let's give a few more days for more ideas. In the meantime I'll have a look to more component libraries as examples and check dictionaries to understand the differences of the meaning of those words 😊

[muratcorlu]

Just for noting down here, we implemented those changes with #250