rustfs-console-design-guide

RustFS Console Design Guide

This guide is the source of design decisions; use skills/ui-audit/SKILL.md as the companion workflow for audit execution, browser validation, and evidence capture.

Use this guide while shaping the interface, before implementation details harden. Treat Console as an operational tool: the design should help people understand system state, make a deliberate change, and recover when reality is uncertain.

Design objectives

Every screen should make four things obvious:

1. Where the user is.
2. What the system currently knows.
3. What the user can safely do next.
4. How to recover when a read or write fails.

Prefer calm hierarchy over decoration. Density is acceptable when relationships remain clear; visual noise is not.

1. Page composition

Build pages in this order:

1. Page identity: title, concise purpose, and scope such as the active bucket or node.
2. Current state: trusted status, important constraints, and freshness when relevant.
3. Primary task: the action or configuration the page exists to support.
4. Supporting detail: history, diagnostics, advanced controls, and secondary actions.

Keep the primary action near the content it affects. Avoid detached action bars whose target is ambiguous.

On scoped detail pages, keep Back navigation and page-level Add/Refresh actions in the same page header. Do not repeat a second toolbar immediately above the table unless it controls only table-local state such as selection or filtering.

For short authentication forms, constrain the form measure independently from the surrounding split panel. A wider available pane should not make credential fields unnecessarily wide.

Use cards only when content is a distinct surface with its own identity or interaction. Do not turn every section into a card.

2. Visual hierarchy and surfaces

Use visual weight to express containment, not to decorate every group.

Border depth

• Give one visual region at most one complete outline.
• Keep at most two structural frame levels. A nested level should normally use spacing, a muted background, or a one-way separator instead of another box.
• Reserve complete borders for the outer surface, form controls, warnings/errors, and explicit interactive choices.
• Use fieldset/legend, section/heading, or dl/dt/dd to express structure without adding frames.
• Do not place a bordered card inside a bordered fieldset inside a bordered dialog merely to create grouping.
• Use dividers only between peer sections. Keep one aligned divider system per surface; do not add dividers recursively to an ancestor and its descendants.
• A divider is not a generic replacement for a removed box. If it does not clarify which sections are peers, use spacing or a heading instead.