Improving the UAIX AI Memory Package Wizard
The current UAIX AI Memory Package Wizard is conceptually framed as a seven-step process, but the published experience behaves more like a single long configuration page: it exposes preset selection, metadata, operati...
Metadata
| Field | Value |
|---|---|
| Source site | aiwikis.org |
| Source URL | https://aiwikis.org/ |
| Canonical AIWikis URL | https://aiwikis.org/files/aiwikis/raw-system-archives-uaix-source-site-report-preservation-2026-05-01-agen-0c2c15a4/ |
| Source reference | raw/system-archives/uaix/source-site-report-preservation/2026-05-01/agent-file-handoff/Archive/2026-05-01/Improvement/Improving the UAIX AI Memory Package Wizard.md |
| File type | md |
| Content category | memory-file |
| Last fetched | 2026-05-02T01:47:31.8867765Z |
| Last changed | 2026-05-01T01:52:08.6779911Z |
| Content hash | sha256:0c2c15a4bdcbdc538e0ac200515a1c8979de48d63d1549650c152ed89dc871d8 |
| Import status | unchanged |
| Raw source layer | data/sources/aiwikis/raw-system-archives-uaix-source-site-report-preservation-2026-05-01-agent-file-handoff-archive-2-0c2c15a4bdcb.md |
| Normalized source layer | data/normalized/aiwikis/raw-system-archives-uaix-source-site-report-preservation-2026-05-01-agent-file-handoff-archive-2-0c2c15a4bdcb.txt |
Current File Content
Structure Preview
- Improving the UAIX AI Memory Package Wizard
- Executive Summary
- Open Questions and Limitations
- Concise Current-State Audit
- Pattern Research and Decision Framework
- Proposed Multi-Page Redesign
- Wireframes and Interaction Diagrams
- Implementation Guidance
- Testing, Metrics, and Delivery Plan
Raw Version
# Improving the UAIX AI Memory Package Wizard
## Executive Summary
The current UAIX AI Memory Package Wizard is conceptually framed as a seven-step process, but the published experience behaves more like a single long configuration page: it exposes preset selection, metadata, operating strategy, protocol rules, receiver setup, optional LLM Wiki settings, output mode, advanced options, review actions, and live previews in one surface. That mismatch between the mental model of a wizard and the actual interaction model increases scan cost, makes prioritization harder for first-time users, and encourages premature interaction with exports before the user has confidently finished core setup. The page itself also states that JavaScript is required for most generated exports, while canonical ZIP downloads remain separately available. citeturn1view0îˆ
Research strongly supports converting this experience into staged disclosure. NN/g recommends wizards for processes that are complex, ordered, and performed only occasionally, and describes staged disclosure as a way to make each step simpler and clearer. GOV.UK’s form guidance similarly recommends starting with “one thing per page,†noting benefits for focus, mobile use, error recovery, autosave, and analytics; GOV.UK’s later user research also found that one-question-per-page layouts felt less overwhelming and led to more accurate and complete input. citeturn5view4turn20view0turn18view0turn18view1îˆ
The best redesign for UAIX is not a flashy “stepper everywhere†interface. It is a **six-page, route-based wizard** with a **compact progress indicator**, **page-level validation**, **a dedicated review/export page**, and **inline accordions only for optional advanced settings and generated previews**. USWDS recommends step indicators for fixed multi-step processes, but explicitly warns against them when step counts change based on user input; MUI’s mobile stepper guidance suggests using a progress bar when step counts are many or may change, and Ant Design supports responsive vertical steps on smaller screens. For UAIX, the best synthesis is a fixed set of top-level pages, with optional LLM Wiki details inside a page rather than as a separate variable-count step. citeturn5view3turn9view0turn14view0turn14view1îˆ
Implementation should prioritize resilient, accessible form architecture over visual novelty. At minimum, the rebuilt wizard should use native form elements where possible, proper labels and instructions, fieldset/legend grouping for radio sets, visible focus, an error summary that receives focus and links to invalid fields, status announcements for autosave/export, and a layout that reflows cleanly at 320 CSS px with adequately sized touch targets. Framework-wise, a rebuild is well suited to either **Remix** for strong progressive enhancement around forms and server validation, or **Next.js App Router** for route-based steps and lazy loading, with **React Hook Form**, **Zod**, and optionally **XState** providing ergonomic state, type-safe validation, and predictable branching. citeturn8view5turn6view1turn19search0turn6view5turn8view1turn8view3turn7view0turn22view3turn22view0turn23search0turn23search1turn22view5turn22view2îˆ
## Open Questions and Limitations
This report audits the **published public experience and documented interaction model**, not the underlying DOM, CSS, analytics dataset, or source code. As a result, the report can state high confidence findings about **information architecture, sequencing, copy density, progressive enhancement boundaries, and likely mobile burden**, but accessibility findings beyond what is visible in the published page are framed as **high-risk areas to verify**, not as confirmed WCAG failures. The public page is sufficient to justify a redesign, but not sufficient to replace a full code-level accessibility audit or instrumented usability benchmark. citeturn1view0turn5view6îˆ
## Concise Current-State Audit
The current page combines at least seven conceptual stages with advanced review gates, multiple copy/download actions, a live build preview, and a manifest overlay preview. The result is a page that asks users to think about base configuration, policy, governance, receiver behavior, optional wiki architecture, and export mechanics at the same time. Even conservatively counted, the page exposes **dozens of decisions** before the user reaches a stable review point; the exact number varies with whether the optional LLM Wiki branch and advanced options are expanded. citeturn1view0îˆ
The biggest usability issue is **cognitive front-loading**. The page uses specialist terminology early and often — for example “source authority policy,†“conflict resolution policy,†“release gate,†“evidence ledger path,†“memory update policy,†and “manifest overlay†— with little structural separation between novice-safe essentials and expert-only configuration. NN/g’s progressive disclosure guidance is directly relevant here: advanced or rarely used options should be deferred so that users can concentrate on the core task without first parsing a large, mixed-importance option set. citeturn1view0turn20view0îˆ
A second issue is **progress ambiguity**. The published page literally lists a ready-state sequence from “Pick a path†through “Copy or download,†but the user is not actually moved through discrete pages or focused steps. That weakens location awareness, increases rereading, and makes it harder to know whether a user is “done enough†to export. USWDS recommends a distinct current-step treatment, a heading directly below the indicator, and explicit “[step] of [total]†text so users can track where they are in the process. citeturn1view0turn5view3îˆ
A third issue is **premature export exposure**. The current page exposes copy and download actions for outputs such as the startup packet, system profile, receiver brief, package model, overlay JSON, optional wiki plan, and canonical ZIP in the same overall flow as configuration. GOV.UK’s research on “Check your answers†pages shows that users value a clean review step because it reduces visual searching and makes final verification easier. UAIX should reorganize exports behind a dedicated review/export page. citeturn1view0turn18view1îˆ
A fourth issue is **partial progressive enhancement**. The page explicitly says that JavaScript is required for package model, overlay, system profile, receiver brief, startup packet, and optional wiki plan exports, while canonical starter ZIP downloads remain available from the bundle registry. That means the most useful “assembled†outputs depend on richer client-side behavior. This is not inherently wrong, but it creates a resilience and accessibility boundary that the design should either soften or make more graceful. citeturn1view0turn22view3îˆ
A fifth issue is **mobile and responsive strain**. GOV.UK guidance says one-thing-per-page helps users operate services on mobile devices; MUI recommends vertical steppers for narrow screens, and Ant Design automatically flips steps vertical below 532px. In contrast, the current UAIX surface places long option groups, advanced settings, multiple action buttons, and code-like previews into one long scroll. Even without a CSS audit, that is a high-confidence indicator of harder thumb navigation, longer revisit cost, and more lost context on handheld devices. citeturn18view0turn9view0turn14view1îˆ
A sixth issue is **accessibility risk concentration**. The current page clearly contains many grouped choices, requires good error handling, and includes status-changing actions such as copy/download/generation. W3C requires text labels or instructions for required input, textual error identification and useful error suggestions, visible keyboard focus, programmatically determinable structure/relationships, status messages announced without focus theft, reflow without two-dimensional scrolling at 320 CSS px, and minimum touch target sizing of 24 by 24 CSS px. The public page content suggests these are all important for the wizard, but the page structure should be re-tested once refactored. citeturn6view1turn8view5turn6view2turn6view5turn7view0turn7view1turn8view1turn8view3turn7view1îˆ
A concise issue table is below.
| Area | Current condition | Why it matters | Priority |
|---|---|---|---|
| Information density | Core setup, advanced policy, output actions, and live previews share one page. citeturn1view0îˆ | High scan burden and weak prioritization for first-time users. | High |
| Progress clarity | The page describes seven stages, but interaction is not truly staged. citeturn1view0turn5view3îˆ | Users have to build their own sense of place and completion. | High |
| Error recovery | No dedicated review checkpoint is visible before export actions. citeturn1view0turn18view1turn19search0îˆ | Higher risk of incomplete or misconfigured exports. | High |
| Advanced-option sprawl | Specialist policy controls appear early beside essentials. citeturn1view0turn20view0îˆ | Increases cognitive load and slows novice users. | High |
| Progressive enhancement | JS is required for most generated outputs. citeturn1view0turn22view3îˆ | Limits resilience and complicates no-JS fallback. | Medium |
| Mobile burden | One long form plus previews and many actions. citeturn1view0turn18view0turn9view0turn14view1îˆ | Harder handheld completion and greater scroll depth. | High |
| Accessibility risk | Many grouped inputs, status updates, and likely long focus paths. citeturn6view1turn8view5turn6view5turn7view1îˆ | Needs strict semantic grouping, error, and focus behavior. | High |
The minimum measurement set for the redesign should include **task success rate**, **time on task**, **validation error rate**, **step abandonment/drop-off**, **post-task SEQ**, and a short **session-level UMUX-Lite**. NN/g describes task success as the usability bottom line; SEQ is a lightweight seven-point post-task difficulty question; UMUX-Lite is a two-item instrument specifically intended for short usability checks. citeturn18view2turn18view4turn21search0turn21search12îˆ
A practical measurement set for UAIX is:
| Metric | How to compute | Why it matters |
|---|---|---|
| Wizard completion rate | Completed export sessions / started sessions | Primary top-line funnel metric |
| Median time to completed export | Session start to first successful export | Efficiency for first-time and repeat use |
| Error rate per completed attempt | Count of validation events before completion | Friction and copy/validation quality |
| Step drop-off | Exit rate by page | Diagnoses where users stall |
| Backtrack rate | Previous-step visits / completed sessions | Indicates unclear sequencing or poor defaults |
| Help-open rate | Help/tooltip opens by field | Surfaces confusing concepts |
| SEQ by task/page | 1–7 ease score after task or after review | Fast perceived-difficulty signal |
| UMUX-Lite after session | Two-item post-session score | Lightweight overall usability read |
| Export mix | Startup packet / ZIP / JSON / wiki plan usage | Reveals real output priorities |
## Pattern Research and Decision Framework
The relevant patterns are not interchangeable. They solve different problems and should be combined deliberately.
NN/g distinguishes **progressive disclosure** from **staged disclosure**. Progressive disclosure hides advanced or infrequent options until requested; staged disclosure breaks an ordered task into a sequence of simpler steps, with each page showing only what belongs to that part of the task. Wizards are the classic staged-disclosure pattern, and NN/g recommends them when the process is complex and infrequent. citeturn20view0turn5view4îˆ
GOV.UK’s “one thing per page†guidance is especially influential for form-heavy flows. It explicitly associates multi-page forms with clearer focus, easier error recovery, better mobile performance, autosave opportunities, and question-level analytics. That makes it a better fit for UAIX than a merely collapsible single page. citeturn18view0turn18view1îˆ
The design question is therefore not “single page or multi-page?†but rather “what combination of staged disclosure, progress signaling, and optional inline expansion best matches UAIX’s information architecture?†The answer is: **a route-based multi-page wizard for the core path**, **a compact step indicator or step counter at the stage level**, and **accordion-style inline expansion for optional advanced sections and previews only**. citeturn20view0turn5view3turn17view3îˆ
The decision matrix below summarizes the patterns.
| Pattern | Best when | Strengths | Risks | Fit for UAIX |
|---|---|---|---|---|
| Multi-page wizard | Task is complex, ordered, and infrequent. citeturn5view4turn20view0îˆ | Lowest cognitive load for first-time users; strongest error containment; clean review stage. | Can feel slow if trivial steps are over-split. | **Best primary pattern** |
| One-thing-per-page | Questions can be isolated and some branching may occur. citeturn18view0turn18view1îˆ | Strong mobile performance, better analytics, easier recovery. | Too many tiny pages can annoy expert repeat users. | **Best content rule inside the wizard** |
| Stepper / step indicator | There are 3+ mostly fixed stages and order matters. citeturn5view3turn9view0turn14view0îˆ | Improves location awareness and completion confidence. | USWDS warns against it when steps change with user input; long labels wrap badly. citeturn5view3îˆ | **Use a compact version only at top level** |
| Modal steps | Task is short, contained, and should not displace page context. citeturn17view0îˆ | Keeps users in context; useful for confirmations/help. | Focus trap, inert background, limited vertical space, poor fit for long forms. citeturn17view0îˆ | **Do not use as primary shell** |
| Inline expansion / accordion | Advanced or optional detail is secondary to the main task. citeturn20view0turn17view3turn15search1îˆ | Good for advanced settings and generated previews without cluttering the default view. | Discoverability drops when overused; can become a disguised single page. | **Use sparingly as a secondary pattern** |
Two nuances from modern design systems matter:
First, **Material Design no longer documents steppers as a first-class guideline**, though MUI continues to support them and provides linear, vertical, mobile, and progress variants. That suggests using a **lightweight progress header** rather than over-designing a decorative stepper. citeturn9view0îˆ
Second, **step counts should remain stable**. USWDS cautions against using a step indicator when conditional logic changes the number of steps; MUI recommends using a progress bar when many steps exist or when steps may be inserted during the process. For UAIX, that means the optional LLM Wiki branch should live **inside a fixed page** rather than creating a new top-level step only some users see. citeturn5view3turn9view0îˆ
## Proposed Multi-Page Redesign
The recommended redesign is a **six-page wizard**:
1. **Preset**
2. **Basics**
3. **Operations**
4. **Protocols**
5. **Receiver**
6. **Review and Export**
The top-level step count stays fixed at six. The optional LLM Wiki content appears as a conditional panel on the **Receiver** page, so progress semantics stay stable while the form still branches intelligently. That balances GOV.UK’s one-thing-per-page clarity with USWDS’s warning against variable step indicators. citeturn18view0turn5view3turn9view0îˆ
Defaults should be conservative, safe, and aligned with the current UAIX surface whenever the existing page already suggests a sensible default. For example, the current page already exposes **default locale = en-US**, a default **system discovery prompt**, and a default **first task for the receiver**; the redesign should keep those as seeds rather than making users re-invent them. citeturn1view0îˆ
A concrete page-level specification is below.
| Page | Primary goal | Core fields and defaults | Validation and rules | Help and advanced behavior |
|---|---|---|---|---|
| Preset | Get the user onto the right package path fast | **Preset** (required; no default unless deep-linked), **Also uses LLM Wiki** (default off), optional “Restore draft†if a saved draft exists | Can’t continue without preset. If preset implies wiki export, auto-enable wiki toggle and explain why. | Show short card descriptions for each preset; keep support-boundary note visible but compact. |
| Basics | Capture package identity and sharing context | **Project/package name** (required), **Slug** (auto-generated from name, editable), **Owner/review team** (required), **Locale** (default **en-US**), **Audience** (default Internal team), **Sensitivity** (default Internal), **Target environment** (default Repository handoff), **Review due date** (optional) | Name required, 3–80 chars. Slug required, kebab-case, no spaces. Locale required. Due date must be valid if entered. | Inline examples under name/slug. Auto-update slug until user edits manually. |
| Operations | Define how the package should reflect operational reality | **Collaboration model** (default Single maintainer with AI), **Memory architecture** (default UAI AI Memory only, or UAI + LLM Wiki if wiki toggle is on), **Unit test policy** (default Discover and run when available), **Integration test policy** (default Affected surface only), **Deployment strategy** (default Manual or source-only), **Code review strategy** (default Owner review) | Required single-choice groups. If deployment is WordPress release, surface a note that this is planning, not automatic installation. | Advanced accordion reveals **When tests run** (default Targeted per change), **Release gate** (default Targeted checks recorded), and **System discovery prompt** (prefilled with current UAIX default text). |
| Protocols | Set source of truth, evidence, and governance | **Memory update policy** (default After reviewed project-truth change), **Source authority policy** (default Repository canonical files first), **Change risk level** (default Routine project change), **Conflict resolution policy** (default Constraints and owner decide), **Rollback strategy** (default Record and revert with approval), **Evidence record path** (optional but strongly encouraged) | If risk = production-impacting or security/privacy-sensitive, auto-enable human review gate. If audience is external or sensitivity is Confidential/Restricted, auto-enable redaction review. | Advanced accordion contains review-gate toggles and optional memory update targets. Explain each rule in plain language, not only policy jargon. |
| Receiver | Create the handoff instructions | **Next actor** (required; default inferred from audience), **Success evidence** (required), **First task** (prefilled from current UAIX first-task guidance) | Required text areas; minimum non-empty content; soft character guidance rather than hard short limits. | If **LLM Wiki** is enabled, show a subpanel with **Wiki strategy**, **Memory steward** (default owner/team), **Update moment**, and optional path/pattern fields. Keep this secondary by default. |
| Review and Export | Confirm, preview, and generate outputs | **Check your answers**, **Readiness checklist**, **Primary output mode** (recommended default: Copy-paste file deck + canonical ZIP), preview tabs for generated files | No generation until all required fields validate. Show page-top error summary + section links if incomplete. | Generated previews are lazy-loaded only when opened. Advanced area contains file deck scope and WordPress planning checklist. Canonical ZIP remains a primary CTA, but only after review. |
The current-vs-proposed flow comparison is below.
| Aspect | Current published flow | Proposed flow | Estimated impact |
|---|---|---|---|
| Core interaction model | One long page with seven conceptual sections plus advanced options and previews. citeturn1view0îˆ | Six true pages with explicit next/back/save/review. | Much lower scanning burden |
| Progress visibility | Implicit; user self-manages place in flow. citeturn1view0turn5view3îˆ | Stable step counter plus page heading and review checkpoint. | Fewer “where am I?†errors |
| Essential vs advanced controls | Mixed together. citeturn1view0turn20view0îˆ | Core questions first; advanced accordions only when needed. | Less novice overload |
| Review before export | Exports interleaved with entry. citeturn1view0turn18view1îˆ | Dedicated review/export page. | Lower risk of premature export |
| Mobile behavior | Very long scroll, crowded action area, previews on same surface. citeturn1view0turn18view0îˆ | Shorter pages, better thumb travel, optional previews deferred. | Better handheld completion |
| Analytics granularity | Harder to analyze by question/step. citeturn18view0îˆ | Route- and field-level funnel telemetry. | Faster diagnosis of drop-off |
| First-run task time | Baseline not published | Hypothesized **25–40% reduction** | Modeled estimate |
| Avoidable configuration/validation errors | Baseline not published | Hypothesized **30–60% reduction** | Modeled estimate |
Those two percentage estimates are **design hypotheses**, not measured UAIX production outcomes. They are reasonable because the redesign reduces visible complexity, improves progress clarity, introduces a real review stage, and aligns the flow with wizard and one-thing-per-page research, but they must be validated with instrumented testing. citeturn20view0turn18view0turn18view1îˆ
## Wireframes and Interaction Diagrams
The recommended interaction flow is:
```mermaid
flowchart LR
A[Preset] --> B[Basics]
B --> C[Operations]
C --> D[Protocols]
D --> E[Receiver]
E --> F[Review and Export]
E --> G{LLM Wiki enabled?}
G -- No --> F
G -- Yes --> H[Wiki subpanel inside Receiver]
H --> F
```
Low-fidelity page sketches are below.
**Preset**
```text
+----------------------------------------------------------------------------------+
| Step 1 of 6 |
| Create a UAI AI Memory package |
| Choose the package path first. You can change it later. |
|----------------------------------------------------------------------------------|
| [ ] Project AI Memory Short description |
| [ ] Project Handoff Short description |
| [ ] Agent Session Memory Short description |
| [ ] Onboarding Memory Short description |
| [ ] Decision Memory Short description |
| [ ] Client/Vendor Handoff Short description |
| [ ] Incident/Audit Memory Short description |
| [ ] LLM Wiki Export Memory Short description |
|----------------------------------------------------------------------------------|
| [ ] This project also uses an LLM Wiki |
|----------------------------------------------------------------------------------|
| Support boundary: creates planning files and ZIP links; does not write repos. |
| [Continue] |
+----------------------------------------------------------------------------------+
```
**Basics**
```text
+----------------------------------------------------------------------------------+
| Step 2 of 6 |
| Basics |
| Name the package and define the sharing context. |
|----------------------------------------------------------------------------------|
| Project/package name * |
| [______________________________________________________________] |
| Slug * (auto-generated) |
| [project-ai-memory-example____________________________________] |
| Owner or review team * |
| [______________________________________________________________] |
| Locale * |
| (•) en-US ( ) zh-CN |
| Audience |
| (•) Internal team ( ) AI agent ( ) External vendor ( ) Audit reviewer |
| Sensitivity |
| (•) Internal ( ) Public-ready ( ) Confidential ( ) Restricted |
| Target environment |
| (•) Repository handoff ( ) WordPress site ( ) LLM Wiki extract |
| Review due date (optional) |
| [____ / ____ / ________] |
| [Back] [Continue] |
+----------------------------------------------------------------------------------+
```
**Operations**
```text
+----------------------------------------------------------------------------------+
| Step 3 of 6 |
| Operations |
| Define how the receiver should work with tests, deployment, and review. |
|----------------------------------------------------------------------------------|
| Collaboration model * |
| ( ) Single maintainer (•) Single maintainer with AI ( ) Multi-user team |
| ( ) Multi-team or vendor handoff |
| Memory architecture * |
| (•) UAI only ( ) UAI + LLM Wiki ( ) Reviewed wiki export ( ) Archive-backed |
| Unit test policy * |
| (•) Discover/run when available ( ) Required before merge ( ) When code changes|
| Integration test policy * |
| (•) Affected surface only ( ) Required before merge ( ) Release only |
| Deployment strategy * |
| (•) Manual or source-only ( ) CI/CD ( ) WordPress release ( ) Canary |
| Code review strategy * |
| (•) Owner review ( ) Peer review ( ) Security/privacy review |
|----------------------------------------------------------------------------------|
| â–¸ Advanced operational options |
| When tests run | Release gate | System discovery prompt |
| [Back] [Continue] |
+----------------------------------------------------------------------------------+
```
**Protocols**
```text
+----------------------------------------------------------------------------------+
| Step 4 of 6 |
| Protocols |
| Set source authority, evidence, conflict handling, and risk rules. |
|----------------------------------------------------------------------------------|
| Source authority * |
| (•) Repository canonical files first |
| ( ) Public evidence first |
| ( ) Docs and release trail |
| ( ) Wiki remains background |
| Memory update policy * |
| (•) After reviewed project-truth change |
| ( ) At handoff acceptance ( ) After release ( ) Manual only |
| Change risk level * |
| (•) Routine project change ( ) Public claim change ( ) Production-impacting |
| ( ) Security or privacy sensitive |
| Conflict resolution * |
| (•) Constraints and owner decide ( ) Newest human instruction |
| ( ) Decision record or changelog ( ) External acceptance required |
| Rollback strategy * |
| (•) Record and revert with approval |
| Evidence record path |
| [/evidence/memory-ledger.md_____________________________________] |
|----------------------------------------------------------------------------------|
| â–¸ Review gates and advanced policy |
| [Back] [Continue] |
+----------------------------------------------------------------------------------+
```
**Receiver**
```text
+----------------------------------------------------------------------------------+
| Step 5 of 6 |
| Receiver |
| Create the first-read instructions for the next human, team, or AI. |
|----------------------------------------------------------------------------------|
| Next actor * |
| [Internal AI-assisted maintainer________________________________] |
| Success evidence * |
| [Summarize current truth, confirm constraints, name targeted checks___] |
| First task for receiver * |
| [Read the package, summarize truth, confirm constraints, name touchpoints...] |
|----------------------------------------------------------------------------------|
| [ ] Add LLM Wiki planning details |
| Wiki strategy Memory steward Update moment |
| Optional root / index / pattern fields |
| [Back] [Continue] |
+----------------------------------------------------------------------------------+
```
**Review and Export**
```text
+----------------------------------------------------------------------------------+
| Step 6 of 6 |
| Review and Export |
| Check your answers before generating outputs. |
|----------------------------------------------------------------------------------|
| Summary cards |
| - Preset [Edit] |
| - Basics [Edit] |
| - Operations [Edit] |
| - Protocols [Edit] |
| - Receiver / Wiki [Edit] |
|----------------------------------------------------------------------------------|
| Readiness checklist |
| [✓] Human review gate set where needed |
| [✓] Sensitivity matches audience |
| [ ] Evidence path still blank |
|----------------------------------------------------------------------------------|
| Output mode |
| (•) Copy-paste file deck + ZIP ( ) ZIP only ( ) Planning checklist only |
|----------------------------------------------------------------------------------|
| Preview tabs (lazy-loaded) |
| [Startup packet] [System profile] [Receiver brief] [Overlay JSON] [Wiki plan?] |
|----------------------------------------------------------------------------------|
| [Download startup packet] [Download JSON] [Download canonical ZIP] |
| [Back] [Finish] |
+----------------------------------------------------------------------------------+
```
## Implementation Guidance
The strongest technical recommendation, if the wizard is rebuilt as a stand-alone interaction, is **Remix + React + TypeScript + Zod + XState**, with native forms preserved wherever possible. Remix’s data-write model is built directly on HTML `<form>` and HTTP, then progressively enhanced with pending UI, validation feedback, and optimistic behavior; XState is specifically intended for orchestrating complex application logic as state machines/statecharts; Zod provides a single type-safe schema for validating both client and server input. That combination maps cleanly to a route-based wizard with server-side validation, restore/resume, and predictable branching. citeturn22view3turn22view2turn22view5îˆ
If the preferred platform is already in the React/Vercel ecosystem, **Next.js App Router** is a strong alternative. The App Router is route-based and built around React’s newer primitives such as Server Components and Suspense, which makes it well suited to page-per-step wizard shells. Next also supports lazy loading through dynamic import so that heavy preview panes or export generators can be deferred until needed. citeturn22view0turn22view1îˆ
If the team is Vue-first, **Nuxt 4** is equally capable. Nuxt emphasizes file-based routing, code splitting, and server-side rendering by default, and its rendering model explicitly aims at better initial load performance, accessibility, and lower client-side JavaScript cost. citeturn24view0turn24view1îˆ
For form orchestration inside React, **React Hook Form** is a very good fit. Official docs highlight `defaultValues`, `shouldFocusError`, and schema resolvers, and warn that `onChange` validation can increase re-renders; `useWatch` and `useFormState` isolate re-renders for large forms; `subscribe` is useful for analytics/side effects; and the `Form` component supports progressive enhancement. In practice, that means UAIX can keep each page small, validate on continue/blur rather than on every keystroke, and instrument step-level behavior without wiring bespoke observers everywhere. citeturn23search0turn23search1turn23search9turn23search10turn23search2îˆ
A practical component/data architecture looks like this:
| Layer | Recommendation | Why |
|---|---|---|
| Routing | One URL per wizard page | Supports deep links, browser back, analytics, resume, and focused validation |
| Draft state | Persist draft to session/server on each successful page submit; cache locally for recovery | Matches multi-page autosave and resume expectations |
| Client form state | RHF per page, merged into a central draft object | Keeps each page isolated and performant |
| Validation | Shared Zod schema per page + server validation on submit | Avoids client/server rule drift |
| Workflow logic | XState state machine for branches, autosave, generation states, and export completion | Makes variable logic explicit and testable |
| Export generation | Generate on review/export, not on every keystroke | Reduces unnecessary computation and visual noise |
The accessibility checklist should be treated as a release gate, not a QA afterthought:
| Accessibility requirement | Practical implementation | Basis |
|---|---|---|
| Clear labels/instructions | Every page has a single H1 tied to its main input/group; all controls have visible labels and help text where needed | WCAG 3.3.2; GOV.UK question pages citeturn6view1turn5view2îˆ |
| Programmatic structure | Use native inputs, `fieldset`/`legend` for radio groups, clear heading hierarchy | WCAG 1.3.1; APG radio group citeturn7view0turn17view1îˆ |
| Error identification and correction | On validation failure, show field-level messages plus a page-top error summary with matching wording and links | WCAG 3.3.1/3.3.3; GOV.UK error summary/error message citeturn8view5turn6view2turn19search0turn19search1îˆ |
| Focus management | Move focus to error summary after failed submit; preserve logical tab order; keep visible focus styles | WCAG 2.4.7; GOV.UK error summary citeturn6view5turn19search0îˆ |
| Progress semantics | Put the step indicator above the page heading, mark current step with `aria-current`, and keep labels short | USWDS step indicator citeturn5view3îˆ |
| Responsive reflow | No two-dimensional scrolling at 320 CSS px; keep code previews/advanced panels collapsed by default | WCAG 1.4.10; MUI vertical/mobile stepper; GOV.UK one thing per page citeturn8view1turn9view0turn18view0îˆ |
| Touch ergonomics | Minimum 24×24 CSS px targets for radios, buttons, disclosure controls | WCAG 2.5.8 citeturn8view3îˆ |
| Status updates | Autosave/export success and generation progress announced via status messages/live regions without forcing focus | WCAG 4.1.3 citeturn7view1îˆ |
| Consistent help | Keep help links/tooltips in a stable place on every page | WCAG 3.2.6 citeturn6view7îˆ |
| Reduced repeat entry | Reuse previously entered values, carry forward owner/team and inferred defaults, don’t ask twice in the same process | WCAG 3.3.7 citeturn6view6îˆ |
Dialogs should be used only for **secondary confirmations or help**, not for the main wizard. WAI-ARIA’s modal dialog pattern requires inert background content and a contained tab sequence, which is appropriate for a confirmation like “Discard draft?†but a poor primary container for a long, policy-heavy workflow. citeturn17view0îˆ
Performance should follow the new information architecture. The current page updates previews live as the user changes choices; the redesign should instead lazy-load heavy preview panes on the review page, defer generation until requested, and unmount hidden advanced sections when possible. Next.js supports lazy loading through dynamic import, and MUI explicitly documents unmount strategies for both step content and accordion content when performance matters. citeturn1view0turn22view1turn9view0turn17view3îˆ
## Testing, Metrics, and Delivery Plan
The testing plan should combine **formative usability testing**, **instrumented funnel analysis**, and then **an A/B experiment** against the current page.
A strong formative study can use three realistic tasks:
| Task | Scenario | Success criteria |
|---|---|---|
| Internal package creation | Create a basic internal Project AI Memory package with safe defaults | User completes review/export without moderator help |
| External handoff with governance | Configure a vendor/audit handoff with sensitivity and review controls | User finds and applies the right policy gates |
| Optional wiki workflow | Create a package that includes LLM Wiki planning details | User discovers, understands, and completes the optional wiki subpanel without confusion |
After each task, ask the **Single Ease Question** (“Overall, how easy or difficult was this task?†on a 1–7 scale). At the end of the session, ask the two **UMUX-Lite** items. Pair those perception scores with **task success** and **time on task**. Together, those metrics give a compact view of effectiveness, efficiency, and perceived usability. citeturn18view2turn18view4turn21search0turn21search12îˆ
The usability test moderator script should be simple and consistent:
1. Give the participant a realistic scenario and let them work uninterrupted.
2. Observe where they hesitate, backtrack, open help, or misinterpret defaults.
3. Do not explain terminology unless the task cannot proceed.
4. After each task, record success/failure, time, critical errors, noncritical errors, and SEQ.
5. After the session, ask UMUX-Lite and a short debrief:
- “What felt hardest?â€
- “What felt unnecessary?â€
- “What, if anything, did you expect to happen that did not happen?â€
- “When would you want advanced policy controls to appear?â€
For the A/B test, compare the current single-page wizard against the redesigned multi-page version using the same presets and output actions. The cleanest primary metric is **completed export rate per started session**. Secondary metrics should include **median time to completion**, **validation errors per completion**, **drop-off by step**, **backtracks**, **help openings**, and **repeat exports from the same session**. Segment the analysis by **desktop vs mobile**, **first-time vs returning users**, and **wiki-enabled vs non-wiki flows**, because those cohorts are likely to behave differently. citeturn18view0turn18view1turn9view0îˆ
A sample event taxonomy could look like this:
```json
[
{ "event": "wizard_started", "props": ["preset_entry_source", "device_type"] },
{ "event": "preset_selected", "props": ["preset_id", "wiki_enabled"] },
{ "event": "step_viewed", "props": ["step_name", "step_index"] },
{ "event": "step_completed", "props": ["step_name", "time_in_step_ms"] },
{ "event": "validation_error", "props": ["step_name", "field_name", "error_code"] },
{ "event": "help_opened", "props": ["step_name", "topic_id"] },
{ "event": "advanced_opened", "props": ["step_name", "section_id"] },
{ "event": "draft_saved", "props": ["step_name", "save_latency_ms"] },
{ "event": "review_opened", "props": ["issues_count"] },
{ "event": "preview_opened", "props": ["artifact_type"] },
{ "event": "export_clicked", "props": ["artifact_type"] },
{ "event": "wizard_completed", "props": ["primary_export_type", "total_time_ms"] },
{ "event": "wizard_abandoned", "props": ["last_step_name", "time_since_start_ms"] }
]
```
A realistic small-team delivery plan is:
| Phase | Rough effort | Main output |
|---|---:|---|
| Baseline audit and instrumentation plan | 0.5–1 week | Current funnel map, event schema, success metrics |
| IA and content simplification | 1 week | Final step model, field inventory, defaults, help text |
| Low-fi and hi-fi design | 1–1.5 weeks | Prototype, review/export page, mobile layouts |
| Front-end wizard shell | 1.5–2 weeks | Routed steps, progress header, autosave, validation plumbing |
| Policy logic and generation integration | 1.5–2 weeks | Defaults, conditional wiki panel, export actions, draft model |
| Accessibility and performance hardening | 1 week | Keyboard/focus/error handling, mobile optimization, lazy previews |
| Formative usability round and iteration | 1 week | Prioritized fixes |
| Experiment launch and monitoring | 0.5–1 week | A/B release, dashboard, guardrail alerts |
For a small team of **two product-minded developers plus shared design/QA support**, that puts a credible first production release in the **six- to eight-week** range, with another **one to two weeks** for post-launch adjustments and experiment readout. The rough engineering effort is about **14–20 person-weeks**, depending on whether the generation logic can be reused as-is and whether server-side draft persistence is introduced in the first release. That estimate assumes the redesign preserves existing UAIX package-generation rules and primarily changes UX, routing, validation, and export sequencing rather than the underlying artifact model.Why This File Exists
This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.
Role
This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.
Structure
The file is structured around these visible headings: Improving the UAIX AI Memory Package Wizard; Executive Summary; Open Questions and Limitations; Concise Current-State Audit; Pattern Research and Decision Framework; Proposed Multi-Page Redesign; Wireframes and Interaction Diagrams; Implementation Guidance. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.
Prompt-Size And Retrieval Benefit
Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.
How To Use It
- Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
- LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
- Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
- Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.
Update Requirements
When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.
Related Pages
Provenance And History
- Current observation:
2026-05-02T01:47:31.8867765Z - Source origin:
current-source-workspace - Retrieval method:
local-source-workspace - Duplicate group:
sfg-027(primary) - Historical hash records are stored in
data/hashes/source-file-history.jsonl.
Machine-Readable Metadata
{
"title": "Improving the UAIX AI Memory Package Wizard",
"source_site": "aiwikis.org",
"source_url": "https://aiwikis.org/",
"canonical_url": "https://aiwikis.org/files/aiwikis/raw-system-archives-uaix-source-site-report-preservation-2026-05-01-agen-0c2c15a4/",
"source_reference": "raw/system-archives/uaix/source-site-report-preservation/2026-05-01/agent-file-handoff/Archive/2026-05-01/Improvement/Improving the UAIX AI Memory Package Wizard.md",
"file_type": "md",
"content_category": "memory-file",
"content_hash": "sha256:0c2c15a4bdcbdc538e0ac200515a1c8979de48d63d1549650c152ed89dc871d8",
"last_fetched": "2026-05-02T01:47:31.8867765Z",
"last_changed": "2026-05-01T01:52:08.6779911Z",
"import_status": "unchanged",
"duplicate_group_id": "sfg-027",
"duplicate_role": "primary",
"related_files": [
],
"generated_explanation": true,
"explanation_last_generated": "2026-05-02T01:47:31.8867765Z"
}