40 lines
2.3 KiB
Markdown
40 lines
2.3 KiB
Markdown
# Product
|
|
|
|
## Register
|
|
|
|
product
|
|
|
|
## Users
|
|
|
|
Homarr is for self-hosters and administrators who assemble dashboards for services across home labs and private infrastructure. They need dense, reliable controls and status at a glance, while retaining enough guidance to configure advanced features without hiding how they work.
|
|
|
|
## Product Purpose
|
|
|
|
Homarr provides one place to organize, observe, and operate self-hosted services. Success means users can build useful dashboards quickly, understand their state, recover from configuration errors, act on services, and reshape their workspace without repeatedly leaving the board. Boards must load immediately, stay visually stable, and keep widgets legible across screen sizes.
|
|
|
|
## Brand Personality
|
|
|
|
Direct, capable, precise, and approachable. Homarr should feel calm under load, be truthful about system state, and reward users who refine details.
|
|
|
|
## Anti-references
|
|
|
|
- Decorative dashboards, oversized metric cards, and motion without state meaning.
|
|
- Wizard flows that fight ordinary scrolling or rigid layouts that force one workflow.
|
|
- Hidden configuration magic and implementation complexity exposed before it is needed.
|
|
- Clever custom controls where familiar platform or Mantine interactions already work.
|
|
|
|
## Design Principles
|
|
|
|
1. Keep configuration, consequences, and system state visible.
|
|
2. Make simple tasks short without limiting advanced workflows.
|
|
3. Preserve expert depth while prioritizing urgent information at small sizes.
|
|
4. Reveal dense workspaces progressively through a consistent advanced focus mode.
|
|
5. Isolate failures and show loading, stale, partial, empty, and failed states truthfully.
|
|
6. Use the existing Mantine design language consistently across management and board surfaces.
|
|
7. Keep spatial actions direct: moving, resizing, nesting, and using fixed rails happen on the canvas with immediate feedback.
|
|
8. Preserve predictable widget composition with fixed logical tile sizes and horizontal scrolling before controls become inaccessible.
|
|
|
|
## Accessibility & Inclusion
|
|
|
|
Target WCAG 2.2 AA. Every pointer interaction needs a keyboard and coarse-pointer path. Support screen readers, visible and restored focus, sufficient contrast, reduced motion, non-color status cues, responsive layouts, actionable error messages, and keyboard equivalents for drag and resize operations.
|