Rephase UX redesign roadmap
This commit is contained in:
@@ -293,21 +293,20 @@ This creates a stable reading rhythm across rows with uneven prose length.
|
||||
|
||||
### 4. Critical Cell Editing
|
||||
|
||||
The edit popup should become a result editor with automatic re-parse support.
|
||||
The edit popup should become a compact result editor with automatic re-parse support.
|
||||
|
||||
### Editing goal
|
||||
|
||||
A curator should be able to type the minimum required raw text and let the system fill the normalized card structure automatically.
|
||||
A curator should be able to correct a result quickly in a dense popup without giving up space to a separate preview panel.
|
||||
|
||||
### Default editor content
|
||||
|
||||
Show:
|
||||
|
||||
- a live preview of the resulting critical card
|
||||
- raw cell text
|
||||
- description text when manual override is needed
|
||||
- affix chips/effects
|
||||
- branch cards
|
||||
- one-line result text editing when manual override is needed
|
||||
- compact inline affix/effect rows with the same badges/icons used in read mode
|
||||
- compact inline condition rows with their own effect chips
|
||||
|
||||
Hide from default editing:
|
||||
|
||||
@@ -319,12 +318,12 @@ Hide from default editing:
|
||||
|
||||
### Editor structure
|
||||
|
||||
1. Result preview
|
||||
2. Raw text input
|
||||
3. Parsed sections the user can adjust
|
||||
4. Save actions
|
||||
1. Raw text input
|
||||
2. Compact inline parsed sections the user can adjust
|
||||
3. Save actions
|
||||
4. Optional advanced diagnostics disclosure
|
||||
|
||||
The preview should always answer, "What card will the GM/player actually see?"
|
||||
There should be no dedicated preview panel in the popup. The edit rows themselves should carry the same affix badges, branch labels, and visible wording that the final result uses.
|
||||
|
||||
### Re-import / re-parse behavior
|
||||
|
||||
@@ -334,13 +333,14 @@ When the user edits `RawCellText`:
|
||||
- optionally support debounced auto-parse after input stabilizes
|
||||
- regenerate description, effects, branches, and conditions from shared parser logic
|
||||
- preserve user edits only where the user explicitly overrode generated values
|
||||
- surface parser notes in advanced disclosure instead of spending default popup space on them
|
||||
|
||||
### Manual override model
|
||||
|
||||
A critical result should support two states:
|
||||
|
||||
- imported from the pdf
|
||||
- raw input manually overridden and derived fields generated from raw input or also manually overriden
|
||||
- raw input manually overridden and derived fields generated from raw input or also manually overridden
|
||||
|
||||
This avoids the current problem where re-imports using the tool discards user curations.
|
||||
|
||||
@@ -350,19 +350,22 @@ Adding affixes should not require editing raw structured records.
|
||||
|
||||
### Proposed interaction
|
||||
|
||||
- show affixes as chips
|
||||
- include a chip with a plus icon
|
||||
- clicking the plus chip opens a compact inline editor
|
||||
- user chooses the affix type from a dropdown
|
||||
- user enters the numeric value or expression when needed
|
||||
- saving immediately creates the new chip
|
||||
- show each effect as a compact inline row with its affix badge and dropdown
|
||||
- keep add/remove actions small and local to the row
|
||||
- let the user choose the effect type from the same row they are editing
|
||||
- show only the minimum value input needed for that effect type
|
||||
- update the visible badge and label directly in the row without a separate preview area
|
||||
|
||||
### Requirements
|
||||
|
||||
- chip labels must use user-facing terminology
|
||||
- the affix legend and effect codes must map cleanly
|
||||
- the editor should support symbol-driven and numeric affixes
|
||||
- deleting an affix should be one click from the chip
|
||||
- deleting an affix should be one click from the row
|
||||
- do not waste space on a redundant title when the dropdown already identifies the effect
|
||||
- do not show a `Target` field for `direct_hits`
|
||||
- do not show a `Permanent` checkbox in the default editor
|
||||
- keep source metadata and internal links out of the default row layout
|
||||
|
||||
### 6. Condition And Branch Editing UX
|
||||
|
||||
@@ -370,11 +373,11 @@ Branch editing should follow the same interaction model as affixes.
|
||||
|
||||
### Proposed interaction
|
||||
|
||||
- branches render as condition cards
|
||||
- include a plus chip or plus button for "Add condition"
|
||||
- user selects condition type from a dropdown
|
||||
- user enters the condition value or free text when required
|
||||
- the branch card is created immediately
|
||||
- branches render as compact inline condition rows
|
||||
- include a small add button for `Add condition`
|
||||
- user selects or types the condition text directly in the row
|
||||
- user enters optional outcome prose inline
|
||||
- branch effects are edited with the same compact affix rows used on the base result
|
||||
|
||||
### Branch card contents
|
||||
|
||||
@@ -485,101 +488,98 @@ Create a new assembly for critical import/domain transformation logic, for examp
|
||||
### Web editor workflow after shared parsing
|
||||
|
||||
1. User opens a critical cell.
|
||||
2. The app shows the rendered card preview and raw text input.
|
||||
2. The app shows raw text and compact inline edit rows for the visible result.
|
||||
3. User edits raw text.
|
||||
4. The app calls shared parsing logic for that cell.
|
||||
5. The parser returns normalized description, affixes, conditions, branches, and validation messages.
|
||||
6. The UI updates the card preview automatically.
|
||||
6. The UI updates the inline editing rows automatically.
|
||||
7. The user makes small manual fixes only where generation is insufficient.
|
||||
8. Save persists both raw text and the normalized result.
|
||||
|
||||
This is the key UX shift: the system does the import work again at cell scope instead of forcing the curator to manually edit every derived field.
|
||||
|
||||
## Proposed Rollout Phases
|
||||
## Implemented Foundation
|
||||
|
||||
### Phase 1: Strip visible technical noise
|
||||
The following groundwork is already implemented in the web app as of March 15, 2026:
|
||||
|
||||
Status:
|
||||
- visible technical chrome has been removed from the primary lookup and table flows
|
||||
- lookup result cards now lead with gameplay outcome instead of parse metadata
|
||||
- the critical table browser is framed for play use rather than import administration
|
||||
- critical cells support re-parse from shared parser logic
|
||||
- advanced diagnostics have been separated from the primary editing flow
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
These changes are real and complete, but they are no longer the active roadmap because the detailed acceptance checklist still has unfinished items.
|
||||
|
||||
## Remaining Implementation Phases
|
||||
|
||||
### Phase 1: Complete live lookup flow ergonomics
|
||||
|
||||
Scope:
|
||||
|
||||
- simplify home page copy
|
||||
- simplify lookup result card
|
||||
- remove technical metadata from default visible surfaces
|
||||
- add dice buttons to the attack and direct critical lookup inputs
|
||||
- support fast reroll without manual typing
|
||||
- tighten any remaining lookup prompts so a first-time GM can move through the flow without reading extra copy
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- no SQLite/import/debug references in primary play flows
|
||||
- lookup result card shows gameplay outcome first
|
||||
- both lookup flows support random roll entry without typing
|
||||
- the main lookup page fully satisfies the live-play checklist item for random lookup support
|
||||
|
||||
### Phase 2: Clean up critical table browsing
|
||||
|
||||
Status:
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
### Phase 2: Compact inline cell editor
|
||||
|
||||
Scope:
|
||||
|
||||
- reframe tables page around reading and selecting outcomes
|
||||
- bottom-align branch stacks inside critical cells
|
||||
- keep the affix legend but present it as play help, not import metadata
|
||||
- remove the dedicated preview panel from the critical cell popup
|
||||
- convert effect editing to dense inline rows with badges/icons and minimal controls
|
||||
- convert branch editing to the same compact inline model
|
||||
- remove redundant effect titles and any non-essential controls from the default edit surface
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- dense table rows remain visually aligned
|
||||
- the page reads as a usable table browser during play
|
||||
- the popup spends its space on actual editing rather than preview duplication
|
||||
- common effect and branch corrections require less scrolling than the current popup
|
||||
- `direct_hits` has no unused `Target` field in the default editor
|
||||
- the default editor has no `Permanent` checkbox
|
||||
|
||||
### Phase 3: Redesign the cell editor
|
||||
|
||||
Status:
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
### Phase 3: Generated versus overridden state model
|
||||
|
||||
Scope:
|
||||
|
||||
- add live result preview
|
||||
- remove parse/debug/import fields from default editing
|
||||
- add chip-based affix and condition editing
|
||||
- explicitly track which values are parser-generated and which values were manually overridden
|
||||
- ensure re-parse refreshes generated values without silently discarding intentional edits
|
||||
- define how save and future import refresh flows respect manual overrides
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- editing focuses on the resulting card
|
||||
- common corrections require materially less scrolling and fewer fields
|
||||
- shared parsing can regenerate derived data without clobbering preserved overrides
|
||||
- the manual override model described in this document is implemented rather than only implied
|
||||
|
||||
### Phase 4: Shared parsing assembly
|
||||
|
||||
Status:
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
### Phase 4: Compare and review workflow
|
||||
|
||||
Scope:
|
||||
|
||||
- extract shared parser/normalizer logic from the import tool
|
||||
- consume it from the web app
|
||||
- support single-cell re-parse from raw text
|
||||
- add a clear comparison surface for generated result versus current edited result
|
||||
- let curators review what changed after re-parse before accepting or keeping overrides
|
||||
- keep this comparison workflow in advanced curation, not in the primary live-play path
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- import tool and web app produce the same normalized result for equivalent raw cell input
|
||||
- raw text changes can regenerate card fields automatically
|
||||
- curators can inspect generated-versus-current differences without reading raw JSON first
|
||||
- compare tooling exists for the override workflow described above
|
||||
|
||||
### Phase 5: Advanced curation and diagnostics split
|
||||
|
||||
Status:
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
### Phase 5: Final tooling boundary cleanup
|
||||
|
||||
Scope:
|
||||
|
||||
- move debug/import details into a separate advanced surface
|
||||
- optionally add diff/compare tools for generated vs overridden values
|
||||
- verify that normal curation mode contains only user-facing correction tools
|
||||
- move any remaining engineering-only diagnostics into a separate developer or admin surface if they still leak into curation mode
|
||||
- leave advanced curation available without forcing ordinary users through engineering concepts
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- primary editing surface stays clean
|
||||
- engineering diagnostics remain available without polluting live-play UX
|
||||
- the primary play flow stays clean
|
||||
- compact curation remains available
|
||||
- engineering diagnostics remain accessible without defining the normal correction UX
|
||||
|
||||
## Detailed Acceptance Checklist
|
||||
|
||||
@@ -622,4 +622,4 @@ Mitigation:
|
||||
|
||||
## Recommended Next Step
|
||||
|
||||
Implement Phase 1 and Phase 2 first. They offer immediate UX improvement with low architectural risk and create the visual foundation for the editor redesign and shared parsing work that follow.
|
||||
Implement the new Phase 1 and Phase 2 first. Dice-button support and the compact inline popup editor close the most visible gaps in the detailed acceptance checklist and should be completed before the override and compare workflow phases.
|
||||
|
||||
Reference in New Issue
Block a user