-
-
Notifications
You must be signed in to change notification settings - Fork 707
Shell Design Guidelines
This document is intended to provide some recommendations for how things should look and feel in the Sandstorm UI. Developers making changes to the shell or other Sandstorm properties should endeavor to follow these guidelines where possible to produce a consistent look and feel.
The typefaces we currently use are:
- Source Sans Pro Regular
- Source Sans Pro Semibold
- Source Sans Pro Bold
- user-agent's default monospace typeface (likely Courier)
All sizes in this document should be considered to refer to the appropriate Source Sans Pro metrics.
Use font weights and sizes to hierarchically structure content. Use bold sparingly to call attention to the more important elements on a page.
Larger type is generally better for usability - it's easier to read for both people with good vision and otherwise. However, larger type makes less content visible on a fixed-size viewport at a time. We aim to strike a balance between showing useful information, and showing it in a maximally-readable manner.
TODO: pick specific size/style. Consider adding a horizontal rule below the element (or border-bottom)
TODO: pick specific size/style
Primary content should be font-size: 13px or larger.
Less important text, e.g. verbose explanation of features or data semantics should be 11.5px - 12.5px font size.
Capitalization: - always mixed caps with the first letter capitalized
<input type="text">: Text inputs should have text with font-size at least 13px, and the elements themselves should be at least 32px tall.
TODO: figure out guidelines for border-radius for inputs, buttons, etc?
Colors for the general shell UI should be neutral for the most part, so that they do not clash with whatever app may be currently displayed. In pages that are fullscreen (admin settings, account settings, etc.) more color is permissible.
Color values should be specified as variables in shell/client/_colors.scss, to avoid repetition and unnecessary duplication. Strongly consider using an existing color (perhaps under a new variable name), rather than picking a new hex value. Colorschemes look best and most consistent when there are only a few colors in use, rather than a huge collection of different colors and shades.
Highlights are appropriate for links or primary action buttons, e.g. $sandstorm-purple-color, especially if there's no app currently visible that we'd be distracting the user from.
Text and icons should have high contrast with their background for readability, particularly to help people with poor eyesight or with displays that have subpar contrast.
Interactive elements should invite interaction.
To ensure that they can be hit easily by users on both desktop and mobile, we should make click targets large enough that users will not miss them, or worse, trigger the wrong target.
Click target acquisition speed (and in turn, usability) is a function of target size. This relationship is known as Fitt's Law.
Most click targets should be at least 32px tall and 32px wide. Infrequently-used buttons (i.e., not the main form on the page, no other elements in the form) may be as small as 26px in one dimension if needed (or to indicate their reduced importance), provided they are larger in the other dimension.
Some users use a screenreader or have limited mobility. All interactive elements should be reachable without use of a mouse. With few exceptions, interactive elements should be one of <a>, <button>, or <input>. Browsers, particularly mobile browsers, use these tags (and the presence of tabindex and event handlers) to determine which
Specify appropriate roles for elements, per the ARIA guidelines. In particular, make note of the menu, menuitem, tab, and tabpanel roles. Mark intermediate DOM tags that are only used for presentation as role="presentation". Mark DOM nodes that are only intended for sighted users (say, an image label) as aria-hidden="true".
TODO: discuss managing focus and changes on the page
Buttons should react to cursor hover (which makes it easier for users to know when they would trigger a click target), and they should visually indicate focus in some way to allow keyboard-only users to see what is happening. Links and buttons should make the cursor turn into a pointer on hover.
However, since many users are on mobile, hover should NOT be necessary to discover that an element is interactive. Its default appearance should also communicate its function.
When using checkboxes or radio buttons, be sure to use <label>s appropriately so that clicking on the label-text will activate the control. This makes the click targets for small checkboxes or radio buttons much larger. Users also expect this convenience.
When designing forms, use a grid, and prefer to place the labels above the field, because users are better at reading the forms that way.
Always use separate labels for form fields. Use the <label> tag for better accessibility and so that clicks on the label activate the labeled input. Do not use the placeholder field as a label.
- left align text, especially large blocks of text that need to be comfortably readable.
- icons with labels should place the image left of the text.
- Dropdown arrows are an exception; they should be placed on the right side of the button, following the text.
Most icons will be associated with a button. Buttons should be sized as described above. Their icons should generally be 24x24, and aim for a 1:1 aspect ratio of content, though some variation is permissible to make things look satisfying.