diff --git a/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md b/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md index d962b99..e98ef72 100644 --- a/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md +++ b/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md @@ -1,4 +1,4 @@ - + > Mirrored from `/mnt/DATA/git/govoplan-core/docs/GOVOPLAN_MASTER_ROADMAP.md`. > Origin: `repository`. @@ -53,6 +53,53 @@ end. - GovOPlaN should scale from a small local installation to a larger deployment with separately scalable web, API, worker, storage, and database components. +## User Experience Direction + +GovOPlaN should expose the full power of the platform without forcing +non-technical users to face every field, flag, and internal representation at +once. The default experience should feel guided, explainable, and calm. Expert +depth should remain available, but it should be layered behind deliberate +interaction patterns. + +Core UX rules: + +- Use progressive disclosure. Common decisions stay visible; advanced, + hazardous, or rarely used options live in collapsed panels, secondary steps, + or explicit advanced areas. +- Do not use raw JSON as the primary configuration UI. Every configurable value + should have an appropriate control, validation, and plain-language help. + Import/export and diagnostics may show JSON as a secondary artifact. +- Prefer guided flows over option dumps. Connector setup, package import, + module installation, policy changes, and destructive operations should use + wizards that explain what is happening, why it matters, and what will happen + next. +- Discover values when the system can infer them. For example, a Nextcloud file + connection should start with the base URL, discover the WebDAV endpoint, and + fill technical fields for review instead of asking the user to know them + upfront. +- Make explanations always available without making every screen verbose. + Inline helper text should be short; richer explanations should be reachable + through expandable help, tooltips, side panels, or review steps. +- Explain blocked actions in actionable language. A disabled control or failed + step should say what is missing, who can fix it, and where to go, for example + "A system administrator must allow this provider" or "Configure the provider + in Settings > File Providers before linking a folder here." +- Reuse visual language and placements consistently. Similar configuration, + policy, connection, credential, review, and confirmation flows should share + components, button placement, modal behavior, problem lists, and empty/error + states. +- Use modals and step flows for focused creation/editing where they reduce page + clutter. Reserve large always-open pages for overview, comparison, and + repeated administration work. +- Treat diagnostics as product UX. Validation results, preflight blockers, + policy explanations, permission denials, and missing capabilities should be + understandable to a non-technical operator before exposing internal details. + +This is a product quality gate. New admin/configuration surfaces should not be +considered complete if they expose all options at once, require JSON editing, +hide why an action is unavailable, or use a one-off layout where a shared +pattern exists. + ## Focus Rules 1. Build one reference journey per wave.