- Design revision 3 after two review rounds; quiet-ui skill for clean UI - gix model: lanes for local, remote and worktree branches, in-memory conflict checks - Live server on 127.0.0.1: ref polling, background fetch, SSE graph updates - Panels for branch, merge preview and commit diff, with copy-ready git commands - Gate tests against git merge-base, rev-list, merge-tree and a recorded GitHub response
79 lines
3.9 KiB
Markdown
79 lines
3.9 KiB
Markdown
---
|
|
name: quiet-ui
|
|
description: Use before designing, reviewing or building any screen of this project (canvas comps, maud templates, CSS, client script). Keeps the UI clean and uncluttered for an expert user who keeps it open all day. Load it for mock-ups, UI code and UI review.
|
|
---
|
|
|
|
# Quiet UI
|
|
|
|
Language models add. They put every fact on screen, wrap each fact in a pill,
|
|
give each state its own colour and add a legend to explain the colours.
|
|
This skill pushes the other way: the screen shows what the user needs for the
|
|
next decision, and the rest is one click or one hover away.
|
|
|
|
The user is an expert in a working tool. The page is an instrument on a second
|
|
screen, open all day. The tool should disappear into the task.
|
|
|
|
## Budgets
|
|
|
|
Count before you ship. Over budget means cut, not shrink.
|
|
|
|
- **Colour:** neutrals, one accent (selection, focus, unseen), and at most three
|
|
state colours, used only where the state asks for action (conflict, CI
|
|
failing, ready). Every other state is a neutral plus a word.
|
|
- **Type:** one sans for the interface, one mono for refs, hashes, counts and
|
|
code only. Three sizes, two weights.
|
|
- **Per row:** one name, one number group, at most one status word. No pills
|
|
in rows; status is coloured text.
|
|
- **Top bar:** at most five things. Filters with defaults that are almost
|
|
always right go behind a single control, not one checkbox each.
|
|
- **Panel:** one heading, one status sentence, the one decision list, at most
|
|
two commands. Facts that do not change the decision go into a disclosure.
|
|
- **Always-visible chrome:** no shortcut footer, no permanent legend of more
|
|
than one line, no permanent log. Show them on `?`, on hover, or when the
|
|
panel is empty.
|
|
|
|
## Rules
|
|
|
|
1. **Name the one decision per surface.** The graph: "which branch needs me?".
|
|
The panel: "what do I do with this ref or commit?". Every element that does
|
|
not feed that decision goes.
|
|
2. **Progressive disclosure over density.** Author, PR number, upstream state,
|
|
worktree path: on hover or in the panel. The empty panel is a useful
|
|
default view (what changed since I looked), not a blank.
|
|
3. **Hierarchy through weight and space, not colour and boxes.** Separate
|
|
groups with space. Borders only where they divide work areas. No cards
|
|
inside panels, no boxed metadata grids, no coloured side borders.
|
|
4. **Say it once.** If the colour says "ready", the row does not also say
|
|
"ready". If the panel heading names the branch, the commands do not repeat
|
|
a label for it.
|
|
5. **Neutral is the default state.** Most branches most of the time need
|
|
nothing. They should look calm; only the exceptions carry colour.
|
|
6. **Motion carries meaning only.** One movement: things that change place
|
|
glide; new things fade in. No hover bounce, no scale effects, no pulsing.
|
|
Respect `prefers-reduced-motion`.
|
|
7. **Standard controls.** Real buttons, inputs and links; visible focus;
|
|
keyboard paths for everything. Icons are inline stroke SVG, one weight,
|
|
never Unicode glyphs or emoji.
|
|
8. **Contrast.** Text ≥ 4.5:1, large text ≥ 3:1. Muted text is still readable.
|
|
States that must be told apart differ in lightness or shape, not hue alone.
|
|
|
|
## Delete pass
|
|
|
|
Before you hand over a screen, go through it element by element and ask:
|
|
|
|
- Would the user miss it on the first day? If not, delete it.
|
|
- Is it said elsewhere on the screen? Delete the second one.
|
|
- Is it there "for completeness"? Move it behind hover or a disclosure.
|
|
- Does it need a legend to be understood? Change it until it doesn't, or
|
|
label it in place.
|
|
|
|
Then check the five-second test: with the screen open for five seconds, can
|
|
the user name the branch that needs them and why? If not, the exception
|
|
signals are drowned; remove more.
|
|
|
|
## Credit
|
|
|
|
Budgets and the delete pass condense the "distill", "quieter" and "operate"
|
|
guidance of Impeccable by Paul Bakaus (Apache 2.0,
|
|
https://github.com/pbakaus/impeccable), rewritten for this project.
|