UI update planning complete

This commit is contained in:
Jim Lancaster
2026-08-02 11:33:19 -05:00
parent 5946867ff3
commit ed6f9dfe25
11 changed files with 456 additions and 60 deletions
+13 -12
View File
@@ -4,6 +4,7 @@ Purpose: Define how a user should interact with the UI to create and manage a Do
Scope: This document describes intended user interaction for the Document UI. It is the UX contract for the Document entity.
Companion schema mapping: schema-mapping.md
Companion acceptance criteria: acceptance-criteria.md
## 1. Overview
@@ -273,7 +274,7 @@ A user can reach a Document detail page by:
The Document detail page should include:
1. a header area with document name, document type, and key date values
2. a metadata section with location_created, notes, and archive_identifier
3. system metadata where created_at and updated_at are shown as read-only values
3. System metadata where created_at and updated_at are shown as read-only values
4. a related people section
5. a Sources section
6. a Jobs section
@@ -294,9 +295,9 @@ If no related records exist:
### 11.5 Read Success Criteria
A successful Read experience means:
1. user can identify the Document immediately
2. user can see whether work has started
3. user can navigate directly to document-scoped Jobs and Sources workflows
1. The user can identify the Document immediately
2. The user can see whether work has started
3. The user can navigate directly to document-scoped Jobs and Sources workflows
## 12. Update Document Journey
@@ -307,7 +308,7 @@ The user wants to correct or enrich metadata after creation without touching job
### 12.2 Update Entry Point
From the Document detail page:
1. user selects Edit document
1. The user selects Edit document
2. UI opens edit mode or a dedicated edit view
### 12.3 Editable Fields
@@ -346,10 +347,10 @@ On save:
### 12.6 Update Failure Behavior
If save fails:
1. show a clear error message
1. Show a clear error message
2. keep user edits in form where possible
3. do not show stale success messaging
4. allow retry without losing context
4. Allow retry without losing context
## 13. Delete Document Journey
@@ -360,7 +361,7 @@ The user wants to remove a Document only when it is safe and unambiguous.
### 13.2 Delete Entry Point
From the Document detail page:
1. user selects Delete document
1. The user selects Delete document
2. UI opens a confirmation dialog explaining permanence
### 13.3 Delete Guardrails
@@ -376,15 +377,15 @@ Delete is blocked when:
### 13.4 Blocked Delete UX
When blocked:
1. show an explicit reason that related Jobs or Sources exist
2. show which dependency types are present
1. Show an explicit reason that related Jobs or Sources exist
2. Show which dependency types are present
3. provide links to filtered Sources and Jobs for cleanup
4. keep the Document unchanged
### 13.5 Allowed Delete UX
When allowed:
1. show final confirmation with document name
1. Show final confirmation with document name
2. perform delete
3. show success confirmation
4. return user to Document page list
@@ -392,7 +393,7 @@ When allowed:
### 13.6 Delete Failure Behavior
If delete fails due to system error:
1. show a clear error message
1. Show a clear error message
2. keep user on Document detail page
3. preserve ability to retry