Style Guide

This style guide is an ongoing collection of all things visual that make up the brand, such as colours, fonts, patterns or UI components.

Text

Typeface

We use “Overpass” for regular text. Technical text (e.g. logs or error messages) is set in the monospace variant “Overpass Mono”.

Text style

To make subsidiary elements look less prominent (e.g., hints or labels), the font size and/or darkness of the text can be slightly reduced.

Colors

Buttons

Button labels should have meaningful wording, e.g. “Apply Changes” or “Restart Now” instead of just “Okay”.
Use Title Case.
If ever feasible, call-to-action buttons should only appear once. If there are multiple regular actions side by side, the “regular” action button should be used. As a rule of thumb: the call-to-action button terminates a dialog by triggering its main function; whereas the action button executes secondary operations within a dialog, while keeping the dialog open.
Buttons should be disabled if it’s obvious that an operation cannot be carried out. For example, a “save” button next to an input field should only be enabled if there was an actual change, or if the input field contains something. Don’t disable buttons in non-obvious cases, though, for example when the input format is invalid.

Default Button

For harmless operations like “close” or “cancel”.

Action Button

For operations that do or apply something. (Don’t use for the primary call-to-action.)

Success Button (Primary Action)

For the main (and non-destructive) call-to-action.

Danger Button (Primary Action)

For destructive call-to-actions like “delete” or “shutdown”.

Dropdown Button

A button that groups multiple related actions.

Action 1

Action 2

Action 3

Action 1

Action 2

Action 3

Toggle Button

A button representing a binary state that can be toggled on and off. In contrast to a checkbox, the toggle button is used outside of forms and the click-action is carried out immediately.

Text Button

A button that is just regular text. Only use this for minor actions, and in a context where the default button would look too prominent. The text button doesn’t have a disabled state; instead, it should be hidden.

Click Me

Button for External Links

If a button opens an external website, then it should be an “Action”-type button with an “External Link” icon on the right-hand side. External links should open in a new tab by default.

Open Link

Input

For text input fields that expect non-English words, use any/all of the following attributes to prevent browsers from spellchecking or auto-correcting the text:
```
autocomplete="off"
```
```
autocorrect="off"
```
```
autocapitalize="off"
```
```
spellcheck="false"
```
If there is a call-to-action button associated with an input field, then pressing the “Enter”/“Return” key on the keyboard should trigger the call-to-action. The behaviour should be the same as if the button was clicked with the mouse; that implies that the call-to-action shouldn’t trigger in case the button is in disabled state.
If the input value is required to adhere to a certain format, use the placeholder attribute to help the user intuitively grasp the expected format. The placeholder text should be a made-up but semantically correct value. The placeholder should make it obvious to the reader that it’s just an example value by containing words like “example” or artificial sequences like “1234”. Omit prefixes such as “e.g., ”.
A placeholder is not needed for input fields that expect free text, or when the validation rules are too trivial to allow for expressive or meaningful demo usage.
Make the width of the input field so that it’s reasonably coherent with the expected length of the input copy. Note, though, that there might be other factors for determining a good width of the input field, such as visual alignment with other nearby UI elements.

Example:
Your Website:

Select Field

For input fields that only allow for a certain, predefined set of values or options, you can use a select field instead of a free text field.

Choose Size:

Unless there is a sensible default option, or for additional clarification, you can use a disabled dummy option as first item to imitate a placeholder text.

Font Usage

Use the default font for input fields that expect “free” or regular text. Use the monospace font for “technical” values, to help the user examine the input copy character by character (e.g., IP addresses).

Inline Message

When we want to display a prominent feedback message, we can use the inline-message component:

Error: We use inline errors for “minor” issues that the user can fix right away. For example, validation errors of input fields.

Warning: We use warnings to raise attention about potential problems. In contrast to errors, these don’t necessarily require fixing for the user to proceed.

Info: We use info messages to highlight important information to the user, which is special enough to warrant more prominent styling than just regular text. Info messages are mostly informative, and while they may prompt action, they never require it.

Success: We use success messages to reassure the user that things are functioning as expected. We only use this in specific contexts to highlight a valid and healthy system state. We don’t use this as a general pattern to indicate success of operations.

Some notes about usage:

The text should be left-aligned, even in an otherwise centered context.
If sensible, the text should be prefaced with a short error headword (set in bold) that concisely summarizes what the message is about. For example: Invalid Input, or (for generic messages) just Error or Warning.

Headlines

Use “Title Case” in all headlines.

Overlay Dialogs

Design

Click on the buttons to learn how a dialog inside an overlay is supposed to be designed.

Overlay with Primary Action

This overlay style is used for linear and straightforward flows that have a single purpose or end state, like a prompt or confirmation.

In the bottom row, the overlay should contain a call-to-action button, and a button for aborting the flow.
The button for aborting the flow should be labelled “Close”, and it should be the rightmost one. We deliberately don’t say “Cancel”, to be transparent that clicking the button will terminate the overlay.

Overlay with Feature Panel

This overlay style is used for more comprehensive, non-linear features.

In the bottom row, the overlay should contain a single button, which is labelled “Close” and terminates the dialog.

The overlay may contain “secondary” actions that advance the overlay into a different state. The corresponding buttons shouldn’t be primary ones, and they shouldn’t appear in the bottom row.

Secondary State

The secondary state should have buttons in the bottom row, which follow the same rules as in the “Overlay with Primary Action”, except that …:

The buttons take the user back to the initial overlay state instead of terminating the overlay.
The rightmost button is labelled “Back” instead of “Close”. We deliberately don’t say “Cancel”, as that would make it unclear whether the button terminates the overlay.

Example Success Message

This overlay style is used for when the user reaches a successful state.

Loading States

When the overlay is in a loading state, we generally do not want the user to close it. Therefore, we don’t show any close button, and we also disable the overlay’s `x` close button (see the Contributing Guidelines for details).

Primary Actions

The buttons for primary actions should be located at the bottom of the dialog. These primary actions should either advance the dialog into a different state, or they should terminate the dialog altogether.

Progress Indicator

The spinner is used to indicate that an operation is in progress. The styling can be adjusted through CSS variables.