Replies: 6 comments 11 replies
-
Starting off the conversation here...hoping to keep the integrity of buttons since they aren't really a big issue at the moment (i.e. causing problems) so hopefully we can minimize the work and focus on other needs. We'll definitely want to touch a few things up (e.g. round the buttons a tad more). Consider these as suggestions based on my outsider POV from seeing a hundred other design systems (and I know much of DocsUI came from Bulma). In a DS the difference in button types is not color, but rather the size and whether it's filled or outlined. The type signifies the hierarchy of the call to action: click this first, or click this. There shouldn't be a design that has a primary, secondary, and tertiary all in a row. More accurate use cases:
We want to associate filled-in buttons as primary, and ideally stick to one color (blue). Or in the case of a branded page, we have a different primary color. Secondary buttons are not filled and should be outlined or ghost, there shouldn't be a filled-in color defined as secondary or tertiary. The term "secondary" button could be removed altogether. In the case of success, info, danger, warning, those are global colors that could be applied to other elements (e.g. successful green submission text or a text input error). There could be a use case we want to use a defined color token for a button (e.g. red danger button to delete something) but these should be defined under the approved color modifiers to buttons. Fully rounded buttons should not be a thing, we have one value for button radius. A fully-rounded button is a different element—a clickable tag. For sizes, the default is medium so there is no need to have both. All in all...I don't think we need to modify a whole lot, it's more of a matter of organization and how we talk about them. I want to avoid design using different words like "secondary" in a different context than development so I'm hoping we can use the IA to help align. |
Beta Was this translation helpful? Give feedback.
-
Wanted to shake my thoughts out on this one: I think there is really just these (at least to start us off):
The rough image I show here is NOT actual final color values, just a quick sketch. |
Beta Was this translation helpful? Give feedback.
-
More notes summarizing design direction:
:hover - Darken (Light theme) / Lighten (Dark theme) |
Beta Was this translation helpful? Give feedback.
-
Adding to the button discussion... I think 'buttons' is the place where we don't need to get creative as a platform. I'd recommend aligning entirely with Fluent buttons attributes (sizes, paddings, colors, states, etc), so users benefit from carrying the same mental model across Microsoft products More details on Fluent here Below are some examples of button discrepancies I found around the Docs ecosystem. 2. Command button style variation/affordance 3. Icon button style variation Another important point this will fix - for users who have a touch screen computer, use Docs on a tablet or phone, or have dexterity issues - they don't have the appropriate touch target area that right now is below 48x48dp. |
Beta Was this translation helpful? Give feedback.
-
Here is the latest design documentation for review @jdanyow @wibjorn |
Beta Was this translation helpful? Give feedback.
-
Buttons, as published currently in the Atlas Figma library. |
Beta Was this translation helpful? Give feedback.
-
Let's talk about buttons. 🔘🔼🔽🔲🔳
https://design.docs.microsoft.com/components/button.html
Beta Was this translation helpful? Give feedback.
All reactions