mirror of
https://github.com/smogon/pokemon-showdown.git
synced 2026-03-21 17:25:10 -05:00
Add design standards to CONTRIBUTING.md
This commit is contained in:
parent
a8e8604967
commit
6329d0cfd1
|
|
@ -41,6 +41,32 @@ Your submitted code should be MIT licensed. The GitHub ToS (and the fact that yo
|
|||
For simplicity (mostly to make relicensing easier), client code should be also be MIT licensed. The first time you make a client pull request, we'll ask you to explicitly state that you agree to MIT license it.
|
||||
|
||||
|
||||
Design standards
|
||||
------------------------------------------------------------------------
|
||||
|
||||
We strive to be maximally intuitive and accessible. "That's what they all say", but the currently-popular flat design trend straight-up sacrifices usability for aesthetics, and we try to take the other side of that trade-off.
|
||||
|
||||
Some principles we try to design by:
|
||||
|
||||
- Less text is better
|
||||
- The fewer words you use, the less likely someone is to gloss over it, and the easier it is to find the important information. Compare "1234 battles" with "There are currently 1234 active battles being played on this server" - more words are usually only clutter that makes it hard to find the information you want.
|
||||
|
||||
- Buttons should say what they do
|
||||
- Buttons and links that say "Click here" or "Look at this" are bad for a number of reasons, but the most important one is probably because it violates the principle that you shouldn't need to read outside the button to know what the button does. The way people use interfaces is by looking for buttons that do what they want, not by reading every word from beginning to end.
|
||||
|
||||
- Remove unnecessary clicks
|
||||
- Whenever you give a user a button to click, always think "in what situations would a user want to click this? in what situations would a user not want to click this?" Dialogs like "Are you sure?" can often be replaced with just doing the thing with an "Undo" button. Buttons to show more details can often be replaced with simply showing more details by default.
|
||||
|
||||
- Remove unnecessary scrolling and mouse movement
|
||||
- Similar to unnecessary clicks - if a user has a large screen and you show them a lot of text in a tiny scrollable region, that's incredibly user-hostile. Either the user wants to read the text or they don't: the perfect use-case for a "read more" or expand/collapse button.
|
||||
|
||||
- Affordances are important
|
||||
- This is why we depart from flat design: Years of UX research have taught us that it's important for buttons look like buttons. Making clickable things "look 3D and pressable" or underlining them is good practice. We can't always do this (dropdown menus would look pretty ugly if every item was beveled and embossed) but we do what we can.
|
||||
|
||||
- Feedback is important
|
||||
- If a button doesn't react instantly, it should be replaced with a "Loading" screen or some other indication that it's doing something. If something's failed, it should come with an error message so the user knows what's wrong.
|
||||
|
||||
|
||||
Commit standards
|
||||
------------------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user