78 lines
3.6 KiB
Markdown
78 lines
3.6 KiB
Markdown
# GovOPlaN Frontend Layout Principles
|
|
|
|
GovOPlaN modules should choose their page layout by the kind of work the user is
|
|
doing, not by the repository that owns the feature.
|
|
|
|
These concise layout choices are one canonical input to the broader
|
|
[`INTERFACE_PATTERN_LANGUAGE.md`](INTERFACE_PATTERN_LANGUAGE.md). The current
|
|
route and rollout evidence lives in
|
|
[`INTERFACE_SURFACE_INVENTORY.md`](INTERFACE_SURFACE_INVENTORY.md).
|
|
|
|
## Structured Data Directories
|
|
|
|
Use a full-available-space workspace for structured data directories: files,
|
|
addresses, calendars, records, mailboxes, document stores, and similar domains
|
|
where the primary task is browsing, selecting, filtering, inspecting, and acting
|
|
on related objects.
|
|
|
|
Principles:
|
|
|
|
- The module route should use the full available content area.
|
|
- Do not add a separate page heading row above the main workspace.
|
|
- Prefer persistent navigation panes, such as tree panels, source panels, folder
|
|
panels, calendar list panels, or mailbox folder panels.
|
|
- Keep collection navigation and collection-level actions close to the relevant
|
|
pane header.
|
|
- In a list-detail workspace such as Scheduling, keep related lists stacked in
|
|
the left pane and use the remaining main pane for view/create/edit. A single
|
|
Add action stays in the relevant list-pane header and opens the common main
|
|
editor; it does not create an additional menu or launcher.
|
|
- Use bounded widths for navigation/list panes and let the main detail/content
|
|
pane take the remaining space.
|
|
- Keep filtering controls inside the pane they affect.
|
|
- Use overlays, toasts, or floating alerts for transient messages so the
|
|
workspace height does not change.
|
|
|
|
This pattern is appropriate when the user is working inside one coherent data
|
|
domain and needs spatial continuity.
|
|
|
|
## Workflow And Configuration Surfaces
|
|
|
|
Use the standard heading/menu/card visual language for workflow structures,
|
|
settings, administration, dashboards, and pages that collect essentially
|
|
unrelated areas.
|
|
|
|
Principles:
|
|
|
|
- A page heading and subnavigation are appropriate when the page explains a
|
|
task, workflow stage, or administrative area.
|
|
- Cards are appropriate for repeated independent panels, settings groups,
|
|
summaries, and dashboard widgets.
|
|
- Collapsible panels and segmented controls are appropriate when a dense
|
|
configuration area needs controlled disclosure.
|
|
- A collapsible card whose sole content is a table gives that table the full
|
|
available card body; avoid nested cards, duplicate padding, inner max-widths,
|
|
and nested scrolling.
|
|
- Avoid forcing workflow/configuration pages into a file-explorer style unless
|
|
the primary interaction is genuinely directory browsing.
|
|
|
|
This pattern is appropriate when the user is comparing or configuring separate
|
|
concerns rather than navigating one structured object space.
|
|
|
|
## Shared Components
|
|
|
|
Reusable layout components belong in `govoplan-core` WebUI. Modules may consume
|
|
shared components from core, but must not import another module's private UI
|
|
components directly.
|
|
|
|
When a module-specific component becomes generally useful, promote it to core
|
|
with a parameterized API before reusing it elsewhere.
|
|
|
|
Non-self-explanatory fields use Core `FieldLabel`; documented omissions must
|
|
name their accessible-label source. Explicit Discard and dirty navigation use
|
|
the same Core unsaved-changes dialog. Table action sets retain unavailable row
|
|
actions as disabled controls and reserve empty-state slots so Add remains
|
|
aligned. Use central feedback/dialog components; `window.alert` is not an
|
|
authorized product surface unless a product-owner-approved exception is first
|
|
recorded in the Core decision ledger.
|