Panel design system
CraftPanel’s panel is a workspace for running Minecraft servers on your own hardware. Its design helps you answer three questions quickly: What is happening? What needs attention? What can I do next? This section documents the system behind that workspace, from the values in the stylesheet to complete page layouts.
The panel, website and docs share colour tokens and fonts. Their composition differs: the panel is compact and task-oriented; the website has larger displays and product illustrations. A website hero is not a template for a settings page.
Explore the system
Section titled “Explore the system”Principles
Section titled “Principles”| Principle | What it means in a panel screen |
|---|---|
| Make the server understandable | Put identity, lifecycle state and relevant actions together. Keep related values and explanations close. |
| Use colour for meaning | Warm neutral surfaces carry the workspace. Green, amber and red communicate state. Selection and ordinary actions use neutral ink. |
| Keep the hierarchy quiet | Use size, spacing and a small number of borders. Large surfaces stay flat; a stack of decorative cards adds no information. |
| Show what is known | Separate live data, recorded history, loading, unsupported features and unavailable readings. A missing measurement is not zero. |
| Make consequences clear | Explain what a change affects and when it applies. Use specific verbs such as “Save settings”, “Restart server” and “Restore backup”. |
| Keep the system local | Ship fonts and assets with CraftPanel. Do not add CDN fonts, icon scripts or remote embeds to panel screens. |
One system, three layers
Section titled “One system, three layers”- Foundations:
packages/ui/src/styles/tokens.cssdefines palette, semantic roles, fonts and radii. The same semantic name adapts to each theme. - Shared components:
@craftpanel/uisupplies the panel’s React primitives and composition helpers. Use their variants before introducing custom styles. - Product patterns:
apps/web/src/componentscomposes the primitives into server headers, settings editors, performance charts, player profiles and other tasks.
The documentation describes existing implementation where it gives a token, prop, dimension or source file. Recommendations and review checklists define how new work should fit that implementation; they are not a claim that every existing screen has been audited against every criterion.
Starting a new screen
Section titled “Starting a new screen”Start with the task and the data the user needs. Choose an existing page pattern, compose shared components, and fill in loading, empty, error and permission states before polishing the spacing. Check both themes and a narrow viewport as part of the same change.
For implementation details and source links, continue to Implementation. The contributor design notes also cover the website’s illustrations and brand assets.