ThothII/frontend/prototypes/administration-review

Administration design review V2

Throwaway prototype, 2026-09-10. No variant selected yet.

Question: which page structure best supports the five existing administrative workflows inside the space allocated by Omics Portal?

Run

From frontend/:

npm run prototype:administration-review

Open http://127.0.0.1:5175/?thoth_route=administration/workspace&variant=A. The development-only configuration rejects production builds. No production imports, API requests, real credentials, patient records or host writes are used. Google Fonts loads the same Manrope/Fraunces families as the current frontend; system/Georgia fallbacks remain usable offline.

The original prototype remains untouched at ../administration-pages/ on port 5174, preserved in commit debb63d8 on codex/prototype-administration-pages. The incomplete production changes already present in the working tree were not continued by this review. The previous specification/tickets are suspended drafts.

Confirmed after the renewed grill

1. Preserve existing features and authoring/persistence contracts. Workspace definitions are Git-managed; Evidence uses external Markdown editing and local consolidation; Memory has web CRUD; Database owns its catalog binding and metadata operations; Pi configuration remains installation-authored.
2. Share the administrative Workspace selection across relevant pages, without changing the Workspace selected for core work. Pi has installation scope.
3. Share visual hierarchy and interaction conventions; allow each module's content and internal structure to differ. Do not invent a resource list for Pi.
4. Use explicit saves and unsaved-change protection, including browser traversal. Preserve filters and selection. Leaving a page must not implicitly cancel an existing server-owned job. Actual API/job recovery limits must be audited in the subsequent spec; the prototype only models the intended experience.
5. Final mounting and integration happen on the server, not in the owner's local Omics Portal checkout. If Omics Portal code changes, the owner can pull those changes locally afterward. Record server integration as an explicit delivery/validation step, respecting existing operational migration gates.
6. Five peer pages, right-side navigation, English UI chrome and workspace-language content remain accepted. Namespaced thoth_route supports page restoration; thoth_workspace holds the stable administrative selection.
7. Full preprocessing belongs to Workspace readiness, with Database prerequisites and cross-links. Each workspace currently has at most one catalog binding; this design does not introduce shared database entities or a many-to-many model.
8. Preserve all prototypes. Proceed to to-spec and to-tickets after the owner selects the new layout(s). No new specification or tracker tickets were published in this review turn.

Alternatives

Variant	Structure	Useful when	Tradeoff
A: Workbench	Persistent list/section navigation next to detail; Pi uses its installation sections	Frequent switching between records, catalog inspection and Memory curation	The detail pane has less width; narrow containers stack the areas
B: Focused pages	Full-width list, followed by a full record page with section navigation and return to list	Sustained reading and editing; Evidence and complex forms	Switching records takes a return to the list
C: Operations first	Contextual operational summary, section navigation, collapsible record choice and detail	Workspace preparation, diagnostics and occasional maintenance	More vertical space and less immediate access to the full record list

All five routes render domain-specific content in all three variants. This is a representative interaction prototype, not an exhaustive replacement for existing forms. Advanced Memory link editing, all Database grids, detailed review histories, permissions and full API validation are implementation/spec work, not new scope.

The V2 prototype uses a separate development entry beside the previous prototype because the production worktree contains interrupted, unapproved implementation. Its portal frame represents header/sidebar geometry only; it is not a running Django/Bootstrap integration. No Omics Portal files were changed.

What to try

• Switch all five modules from the right rail (the navigation button when narrow).
• Change Administrative workspace, then open another module. Core workspace stays PSD Clinical; Pi explicitly says All workspaces.
• Open a Memory card, edit its title/content and save. Attempt navigation while dirty and cancel the browser confirmation. Create/delete sample cards as well.
• Open Database Connection, edit the sample host and save it in memory.
• Follow Database to Workspace and back. The administrative selection is retained.
• Start a simulated preprocessing job, visit Pi, return and complete the demo job.
• Open Evidence maintenance/source comparison and Pi diagnostics/host instructions.
• Use Review settings to simulate ready/attention/running/empty/error states and 960/390px host containers independently of browser width.
• Use Back/Forward and reload. Module, Workspace and variant are in the URL; fixtures, edits and simulated jobs reset on reload. Real job resumption requires the subsequent backend-aware implementation.

Layout variants are selectable with the bottom review bar, or left/right arrows outside interactive controls. These controls are not proposed production UI.

Design decisions

Impeccable's product guidance informs a daylight-office, warm-light presentation: institutional bordeaux host header, restrained action color, distinct neutral surfaces for navigation and content, readable statuses with icons and words. Manrope carries operational controls and A/C headings; B uses Fraunces for the page and record titles. Prose has bounded line lengths, forms use consistent labels, and responsive changes depend on container width. The host owns its red topbar; Thoth does not add a second red page banner.

Verification performed

• Isolated TypeScript check of the V2 entry passed.
• Chromium: 3 variants × 5 modules × 4 viewport widths (1600, 1280, 960, 390): 60 initial views with no document-level horizontal overflow or runtime errors. Tables can scroll inside their own bounded container.
• A 390px simulated host within a 1600px browser had a 372px content area and no overflow beyond the host. The inline navigation collapsed at container width.
• Twelve browser behavior checks passed: unsaved navigation cancellation, Memory save, shared administrative context/core isolation, Pi scope, job navigation, connection save, Back, routed Workspace on reload, B detail/return, mobile navigation, creation from an empty Memory state, and error/retry.
• Desktop A/B/C and mobile screenshots were visually inspected. The prototype was opened in the in-app browser for review.
• Standalone Playwright WebKit was unavailable (browser executable not installed). No cross-browser, real-device, Bootstrap collision, authentication, backend or server-integration acceptance is claimed by these prototype checks.

Verdict pending the owner's selection. The next specification must distinguish demonstrated UI decisions from simulated data and behavior.