merge: stack widget modernization on dnd kit
This commit is contained in:
940 files changed
+104475
-33649
No files matched your search
+15
-12
@@ -6,31 +6,34 @@ product
|
||||
|
||||
## Users
|
||||
|
||||
Homarr is for experienced self-hosters, homelab operators, and administrators who run several services and want one dashboard for monitoring and operating them. They understand technical data, value density, and spend time tuning dashboards to match their own workflows.
|
||||
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 brings status, data, and safe day-to-day controls from self-hosted services into one customizable dashboard. Success means users can inspect problems, act on services, and reshape their workspace without repeatedly leaving the board.
|
||||
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
|
||||
|
||||
Capable, precise, configurable. Homarr should feel calm under load, direct about system state, and rewarding to experts who refine details.
|
||||
Direct, capable, precise, and approachable. Homarr should feel calm under load, be truthful about system state, and reward users who refine details.
|
||||
|
||||
## Anti-references
|
||||
|
||||
- Consumer dashboards that hide useful detail behind simplified scores.
|
||||
- Decorative glass, oversized metric cards, and motion without state meaning.
|
||||
- Rigid layouts that force one workflow or require leaving the dashboard for routine actions.
|
||||
- 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
|
||||
|
||||
- Preserve expert depth while prioritizing the most urgent information at small sizes.
|
||||
- Make routine inspection, filtering, configuration, and safe actions available from the board.
|
||||
- Reveal dense workspaces progressively through a consistent advanced focus mode.
|
||||
- Treat personalization as a core workflow, not a settings afterthought.
|
||||
- Show loading, stale, partial, empty, and failed states truthfully without discarding valid data.
|
||||
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 AA. Every pointer interaction needs a keyboard and coarse-pointer path. Focus must be visible and restored after overlays close. Motion must respect reduced-motion preferences, and status must never rely on color alone.
|
||||
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.
|
||||
Reference in new issue
Block a user