Background
The current button visual appearance together with an unclear/mixed implementation crashes in quiet normal (boldened and Black), quiet progressive (boldened and Blue 600) and links (sometimes normal, sometimes bold and Blue 600)
We don't have a clearly documented and acted on approach:
Button types and variants Codex: https://doc.wikimedia.org/codex/main/components/button.html
Goal
Find a path, solution for the Design System with Desktop Improvements project as most important current project to provide a path to untangle this inharmonious and unclear mix.
User stories
As a user, I would like to know what elements are interaction-able while also not getting too distracted by them.
Acceptance criteria for Done
To be defined around
Design
- Document all use cases and real examples of:
- Links (Regular, Bold, Blue...)
- Quiet buttons
- Evaluate if we should update our quiet normal/progressive buttons
- If yes, update them in our Figma library
Design Style Guide
- Update the Buttons page in the DSG
Codex
- Update buttons in Codex (if needed)
Technical and usability concerns
There's a crucial usability benefit in differentiating links from buttons.
Differentiaton from a standard web user-interface/user-experience POV
| Links | Buttons |
|---|---|
| Links are one of the most basic, yet deeply fundamental and foundational building blocks of the web. Click a link, and you move to another page or are moved to another place within the same page. | Buttons are for triggering actions. When do you use the <button> element? A good rule is to use a button when there is “no meaningful href.” Here’s another way to think of that: if clicking it doesn’t do anything without JavaScript, it should be a <button>. |
Further resources and activities
- Early exploration has been presented at Wikimedia Hackathon 2022 (Etherpad feedback log)
