49 lines
1.5 KiB
Markdown
49 lines
1.5 KiB
Markdown
# Design guidelines
|
||
Guidelines for UI design, covering GUI, CLI, documentation, log messages, etc
|
||
|
||
## Text
|
||
#### Sentences
|
||
Short, single-sentence text do NOT end in a period in the UI.
|
||
|
||
Multi-sentence text ALWAYS ends in a period.
|
||
|
||
#### Casing
|
||
We prefer normal casing, and avoid Title Casing.
|
||
|
||
We only use Title Casing for company and product names (Rerun, Rerun Viewer, Discord, …), but NOT for concepts like “container”, “view”, etc.
|
||
|
||
#### Examples
|
||
Good: `log("File saved")`
|
||
|
||
Bad: `log("file saved.")`
|
||
|
||
#### Dashes
|
||
Use a spaced em dash (` — `) for parenthetical breaks in prose (docs, comments, log messages, UI text).
|
||
|
||
Avoid:
|
||
- Unspaced em dashes (`word—word`) — add spaces around the em dash. <!-- NOLINT -->
|
||
- En dashes (`–`) used as sentence punctuation — use an em dash instead.
|
||
|
||
En dashes are reserved for numeric/range expressions (`2020–2025`, `pp. 10–15`, `~3–4 GB`).
|
||
|
||
#### Line breaks in markdown
|
||
Write one sentence per line in markdown files (`.md`, docs, READMEs, agent guides).
|
||
Markdown joins consecutive non-empty lines into a single paragraph, so this does not affect rendering — but it produces much cleaner diffs.
|
||
Each edited sentence shows up as a single changed line, instead of reflowing an entire paragraph.
|
||
|
||
Use a blank line between paragraphs as usual.
|
||
|
||
### Buttons
|
||
|
||
When a button action requires more input after pressing, suffix it with `…`.
|
||
|
||
Good: `Save recording…` (leads to a save-dialog)
|
||
|
||
## GUI labels
|
||
|
||
We do not use a colon suffix for labels in front of a value.
|
||
|
||
Good: `Color 🔴`
|
||
|
||
Bad: `Color: 🔴`
|