Frontend UX Roadmap
The frontend should help game masters, worldbuilders, authors, and campaign organizers answer questions about their projects quickly and reliably.
The primary value of the frontend is not data entry. The primary value is information retrieval. Users should find answers faster than they could with documents, spreadsheets, wikis, or notebooks.
Core Philosophy
Organize the interface around questions, not tables.
The backend stores projects, continuities, entities, relations, facts, secrets, and events. Users should not need to think in those storage concepts. They think in project, continuity, and story questions.
Character questions:
- Who is this person?
- What are they trying to accomplish?
- Who are they connected to?
- What secrets do they know?
- What events were they involved in?
Organization questions:
- Who belongs to this organization?
- Who leads it?
- What conflicts is it involved in?
- What events affected it?
Event questions:
- What happened?
- Why did it happen?
- Who was involved?
- What changed because of it?
Design Principles
Information Before Editing
The first screen should almost always be informational. Users spend more time reading information than creating it.
Selecting a character should show summary, relationships, chronology, secrets, and notes before presenting editing controls.
Minimize Context Switching
Users should not need to navigate through many screens to understand a topic. Related information should appear nearby, important relationships should be visible, and context should remain visible.
Avoid flows like:
Character -> Relationships Page -> Event Page -> Back
Prefer pages that keep the relevant context together:
Character Page
- Overview
- Relationships
- Recent Events
- Secrets
Optimize for Discovery
The interface should encourage exploration and help users discover information they were not specifically looking for.
Useful discovery surfaces include:
- related entities
- related events
- shared relationships
- linked secrets
Treat Search as a First-Class Feature
Search is one of the most valuable features in the system. Users should be able to locate any meaningful object quickly.
Search should eventually cover:
- entities
- events
- organizations
- locations
- facts
- secrets
- continuities
- campaigns
A user should never wonder where they put something.
Hide the Data Model
Users should not need to think about tables, foreign keys, entity relationships, or internal storage concepts. The interface should present information in project terms.
Initial Frontend Scope
The initial frontend should be intentionally small. Its purpose is validation, not completeness.
Project List
Purpose: allow users to discover and access projects.
Features:
- list projects
- create project
- search projects
- sort projects
Questions answered:
- What projects exist?
- Which one should I open?
Project Detail
Purpose: provide an overview of a project.
Sections:
- overview
- entities
- relationships
- continuities
- facts and secrets
Questions answered:
- What is this project about?
- What content exists?
Continuity Detail
Purpose: show one continuity of a project.
Sections:
- chronology
- events
- mutations
- state changes
- visibility-specific view
Questions answered:
- What happened in this continuity?
- What changed from the base project or parent continuity?
Entity Detail
Purpose: provide a complete view of a single entity.
Sections:
- overview
- relationships
- chronology
- secrets
- notes
Questions answered:
- Who is this?
- Why do they matter?
Navigation Model
Keep navigation simple and predictable:
Projects
└── Project
├── Overview
├── Entities
├── Relationships
├── Continuities
└── Facts and Secrets
└── Continuity
├── Chronology
├── Events
└── Mutations
Search Roadmap
The search experience should feel like asking questions about the project.
For example, searching for Aldric should be able to return:
- character: King Aldric
- event: Coronation of Aldric
- secret: Assassination Plot
- relationship: Aldric -> Queen Elara
Search should become one of the highest priority frontend and API experiences after the basic project and entity views exist.
Graph Visualization
Graph visualizations are intentionally deferred.
Reasons:
- high implementation cost
- high UX complexity
- limited value early in development
A graph view should only be implemented after search is complete, entity pages are mature, and relationship navigation is strong.
Technology Strategy
Current target:
REST API
+ Leptos frontend
Future target:
REST API
+ Leptos frontend
+ desktop client
+ mobile client
The frontend should remain a consumer of the API. Business logic should remain in backend services.
Success Criteria
The frontend is successful when a game master, worldbuilder, or author can:
- Find information quickly.
- Understand relationships easily.
- Navigate naturally.
- Discover relevant information without searching for it.
- Manage large projects without becoming overwhelmed.
The measure of success is not visual complexity. The measure of success is reducing the effort required to answer questions about a project, continuity, campaign, or story.