Skip to main content

ux-findings

Full in-depth UI handoff​

Use this as the UX/frontend review handoff for work you want to continue in your good local checkout.

The right mental model is:

  • this workspace produced useful UI review, contract clarification, and prototype hardening work
  • but it should now be treated as research and handoff material
  • your good local checkout should become the implementation source of truth

What this handoff is for​

This handoff is meant to preserve the useful frontend/UI work that happened here without dragging along the Docker/bootstrap/debugging work that made the workspace noisy.

It captures:

  • what looked strong already
  • what the frontend contracts implied
  • what the questions page was doing well
  • where the real gaps were
  • what the later hardening wave tried to fix
  • which files are highest-value to revisit in a new workspace
  • what to ignore from this workspace

High-level conclusion​

The frontend work reviewed here was not a dead end. In fact, the UI direction was mostly promising.

The biggest positive takeaway is that the frontend was already moving toward a coherent shared system:

  • shared shell
  • shared inventory primitives
  • shared drawer model
  • shared status contract
  • shared navigation primitives

The main problems were consistency and contract alignment, not “throw it all away and start over.”

That means the best next move is not to salvage this entire workspace, but to carry forward the design and implementation findings into your good checkout.

Core UI/product decisions that came out of this work​

These are the most important decisions to preserve.

1. Peek drawers are allowed and useful​

Supported entities may use a read-only context drawer peek for browse/review flows.

That means:

  • users can inspect context quickly
  • tables and inventory views can stay fast and lightweight
  • review does not always require a full page transition

2. Canonical links should still be full-page links​

Even when drawers are used, the actual canonical entity link should still point to the full page.

That is important because it preserves:

  • shareable URLs
  • open-in-new-tab behavior
  • cmd/ctrl-click behavior
  • a stable full-page destination for deeper work

3. Only normal click should intercept into a drawer​

The shared EntityLink behavior should only intercept an unmodified normal click.

It should not break:

  • middle click
  • cmd-click
  • ctrl-click
  • new-tab expectations

That interaction model was one of the strongest findings and should be preserved.

4. Full pages remain the edit path​

Peek drawers are for browse/review/inspection.

Full pages remain the path for:

  • editing
  • deep workflow
  • richer context
  • more complex interactions

5. Questions and evaluations can participate in the peek model​

Earlier review raised concern that questions/evaluations might be treated incorrectly under peek interception rules, but the later UI contract update settled this more clearly:

  • questions/evaluations can participate in peek behavior on drawer-enabled surfaces
  • but canonical hrefs should still go to the full page
  • edit/deeper workflow should still be full-page

6. Shared contract layers matter​

The system is healthiest when user-visible semantics are owned by shared layers rather than page-local logic, especially:

  • status labels
  • status tones
  • navigation rules
  • shell patterns
  • inventory interactions
  • localized copy

Shared shell, drawer, and navigation findings​

What looked good and should be preserved​

URL-driven drawer state was already strong​

The drawer model was directionally solid because it was tied to route/page state and URL semantics, rather than being purely ephemeral local component state.

Good qualities observed:

  • drawer state could be derived from URL/page state
  • tab state was carried through the drawer model
  • unrelated query params were preserved
  • open/replace semantics were sensible

This matters because URL-driven UI state gives you:

  • deep linking
  • better browser back/forward behavior
  • recoverable state
  • easier consistency across surfaces

This was one of the best parts of the shared system.

The shared entity link behavior preserved:

  • real anchor tags
  • canonical hrefs
  • normal browser interaction expectations

And only intercepted a plain left-click when a drawer-enabled interaction was appropriate.

That is exactly the kind of shared primitive worth keeping.

Focus and dismissal behavior were built on reasonable primitives​

The drawer/dialog stack was not ad hoc. It used real dialog-style primitives for:

  • focus trapping
  • ESC handling
  • focus return

That is good foundation work. It means accessibility was not an afterthought structurally, even where individual UX flows still needed cleanup.

Inventory primitives were worth investing in​

The shared inventory primitives were not fake abstractions. They already had real reuse value.

The review found value in the direction of:

  • InventoryTable
  • FilterBar
  • SavedViews
  • inventory shared types/helpers

These were already doing meaningful work around:

  • selection state
  • row rendering
  • saved views
  • sort/filter structure
  • pagination
  • reusable shell composition

The right conclusion was to continue investing in them, not replace them with per-page custom widgets.

Shared status handling was a good idea​

The contract-level status dictionary and the StatusChip approach were the right direction.

The page became stronger whenever statuses were routed through:

  • shared mapping
  • shared labels
  • shared tone decisions

rather than page-specific handwritten logic.

Shared shell/navigation gaps and risks​

What still needed work​

Root-layout drawer hosting was still not fully settled​

One of the most important architectural gaps identified was that drawer hosting/coordinator behavior was not fully enforced from the true root layout contract.

Why that matters:

  • new routes can drift
  • drawer behavior can become opt-in instead of systemic
  • some routes may bypass shared behavior entirely

This was more of a platform shell architecture issue than a questions-page issue.

I18n discipline was incomplete​

A recurring problem was that some shared shell and demo/reference surfaces still contained hardcoded strings or partially localized text.

That created risk because:

  • demo routes often get copied into production routes
  • hardcoded strings multiply quickly
  • localization debt spreads quietly

This applied to areas like:

  • shell labels
  • dialog labels
  • drawer copy
  • dev reference route copy
  • some inventory UI labels

Shared inventory contract was useful but incomplete​

The inventory system was promising, but the review still saw gaps in shared support for things like:

  • bulk action affordances
  • freshness/manual refresh
  • live announcement behavior for accessibility
  • fully standardized table-shell behavior

This did not mean the inventory system was poor. It meant it was promising but not yet contract-complete.

StandardHub looked like scaffolding, not a mature shell contract​

StandardHub was seen as helpful starter structure, but not yet a truly complete hub pattern.

The concern was that if future product hubs lean on it too early, they may each reinvent:

  • banners
  • tabs
  • activity regions
  • higher-order shell behaviors

Shared shell/navigation risks that were explicitly identified​

Architecture drift risk​

If drawer hosting and shell behavior are not enforced centrally enough, routes may each evolve their own slightly different drawer models.

IA drift risk​

If shared entity-link behavior is not consistently documented and enforced, primary assets can drift between:

  • full-page-first navigation
  • read-only peek-on-click navigation
  • inconsistent mixed behavior

Localization debt risk​

If demo/reference routes keep hardcoded strings, that copy will spread into product routes.

Readiness risk​

Shared inventory primitives may look convincing in demos but still be incomplete for larger-scale authoring use if bulk/live/accessibility behavior is not completed.

Questions page review findings​

The questions page review was one of the most valuable pieces of work.

The key conclusion was:

  • the page was closer to the target architecture than it may have looked
  • its remaining problems were largely consistency and contract issues
  • it was not a “burn down and rewrite” situation

What was already good in the questions page​

It was using the right family of shared primitives​

This was a major positive.

The page was already built in the right direction using shared UI pieces like:

  • shell
  • filters
  • saved views
  • inventory table
  • entity links
  • drawer state

That is important because it means the page was already participating in an emerging platform UI language rather than going fully bespoke.

Bulk authoring direction was good​

The bulk flow had meaningful strengths:

  • preview/apply separation
  • preserved selection context
  • per-item outcomes
  • attention to idempotent behavior

That is the sort of thing that often gets done poorly, and the review explicitly called out that this direction should be preserved.

Drawer wiring was already in the right model​

The questions page was not inventing a custom drawer pattern from scratch. It was already aligned with the route/page-state-driven drawer model.

That made it a strong candidate for hardening rather than replacement.

Some localization discipline was already present​

It already used things like:

  • locale-aware date formatting
  • plural-aware formatting in at least some areas

So even before cleanup, it was not entirely raw or hardcoded.

Questions page gaps from the original review​

1. Hardcoded copy was the biggest gap​

This was identified as the largest and clearest problem.

There were still too many page-owned user-facing strings for:

  • table labels
  • drawer labels
  • bulk-toolbar copy
  • status text
  • health/error text
  • saved-view interactions
  • prompts/confirmations

This mattered because the docs were treating localization discipline as a real release/readiness expectation, not a “nice to have later.”

2. Status semantics were page-local instead of shared​

Question statuses were being handled too much inside the page.

That created risk because:

  • labels drift
  • filter labels drift
  • chips drift
  • semantics get duplicated
  • future routes repeat the same mistake

The correct direction was to push status semantics into shared contract/state layers.

3. Error handling was inconsistent with the table contract​

A specific issue identified was that fetch/list failures were not flowing cleanly into InventoryTable’s own error state.

That could produce a bad UX pattern where:

  • a page-level error appears above
  • but the table itself looks empty rather than errored

That is confusing to users, because an error and a genuine empty result are not the same thing.

4. Usage/dependency handling was still too thin​

The page was still mostly showing counts where richer dependency/usage presentation may be needed.

The review noted that if backend graph/dependency information exists, the UI should eventually do more than show bare numeric usage counts.

5. Navigation contract needed reconciliation​

During the review, there was a tension between:

  • the older written contract
  • the current shared implementation
  • the questions page behavior

That was later clarified by the updated peek-drawer contract, but during review it was rightly flagged as an area needing explicit alignment.

6. prompt / confirm flows were weak UX​

This was especially important.

Using browser-native prompt() / confirm() for things like:

  • saved view creation
  • deletion confirmation
  • bulk confirmation

was identified as poor for:

  • accessibility
  • localization
  • mobile/iPad task-tier behavior
  • consistent product UX

This was one of the clearest page-level UX problems.

Questions page risks identified in review​

Translation/fallback risk​

If the page continued to own its own strings, shared localization guarantees would remain weak.

Error-vs-empty-state confusion​

If the table was not given an explicit error state, users could misread failures as “no results.”

If questions-page behavior diverged from the shared link contract, future routes would learn the wrong model.

Mobile/accessibility weakness​

The prompt / confirm style flows were particularly poor fits for:

  • assistive-tech UX
  • controlled confirmation behavior
  • mobile-safe explicit interaction patterns

What the UI hardening wave was trying to accomplish​

After the review, the follow-up work moved from “findings” to “selective hardening.”

The hardening wave focused mainly on two layers:

1. Docs/shared contract layer​

This established the intended navigation model more clearly.

2. Questions page layer​

This applied the contract more cleanly to a real product surface.

Conceptual outcomes of the docs/shared contract hardening​

The peek-drawer model became explicit​

Instead of living as an accidental implementation detail, the docs were updated so the peek-drawer model became the written expectation.

That is important because without docs, later teams can mistakenly “fix” the behavior back toward the wrong model.

Canonical full-page links were preserved​

The shared navigation behavior stayed aligned with:

  • full-page canonical href
  • drawer on normal click where appropriate
  • full page for open-in-new-tab / deeper workflow

This is the most important interaction contract to preserve.

Dev reference routes became more useful exemplars​

The dev/ui routes were aligned more closely to the approved model, making them more useful as references instead of misleading demos.

Conceptual outcomes of the questions-page hardening​

These are the most important behavior-level changes to preserve, even if you reimplement them from scratch in the new workspace.

Copy moved toward shared localization​

The page was hardened to replace page-local hardcoded copy with more shared/localized message-driven behavior.

This matters because it reduces drift and keeps future UI work aligned with the product language system.

Statuses moved toward shared contract ownership​

Question status labels/chips/filter labels were moved toward shared status ownership rather than page-owned switch statements and duplicate strings.

That is a meaningful architectural win, not just cleanup.

Table error handling improved​

The page was hardened so that list failures were intended to flow into the table’s error state rather than living only in page-level error copy.

That removes one of the clearest UX inconsistencies from the original review.

prompt / confirm flows were replaced by app-owned UI​

This is a meaningful UX improvement.

The reviewed hardening direction replaced browser-native prompts with more controlled/app-owned interaction patterns such as:

  • inline saved-view UI
  • app-owned confirm dialog patterns

That is better for:

  • accessibility
  • localization
  • consistency
  • future design evolution

Drawer-peek + full-page behavior was preserved correctly​

The page was hardened around the clarified navigation model:

  • drawer peek for browse/review
  • canonical full-page links preserved
  • full page still available for edit/deeper workflow

That interaction model should be considered part of the intended finished behavior.

Historical verification results from the UI wave​

This is important because it tells you what to trust.

Positive evidence​

At the point where frontend dependencies/build state existed locally in this workspace, the targeted frontend hardening direction had evidence like:

  • targeted questions-wave unit tests passing
  • cd frontend && npm run check passing
  • cd frontend && npm run build passing

That suggests the UI hardening direction was viable.

Important caveat​

npm run lint was still red.

But that failure was classified as a mix of:

  • changed-surface lint issues
  • broader repo lint debt

So the right interpretation is not “the UI direction is broken.” The right interpretation is:

  • the UI direction looked viable
  • some lint cleanup remained
  • some lint debt was broader than this wave

What was considered changed-surface vs broader debt​

From the verification notes, changed-surface lint failures included files like:

  • frontend/src/lib/components/shared/patterns/drawer/DrawerCoordinator.svelte
  • frontend/src/routes/dev/ui/context-drawer/+page.svelte
  • frontend/src/routes/dev/ui/inventory-table/+page.svelte
  • frontend/src/routes/questions/+page.svelte

Broader repo lint debt also existed in files outside the focused wave, including some shell/shared components and unrelated routes.

That distinction matters when you move into the new workspace:

  • do not assume all lint issues are caused by this UI handoff
  • separate “handoff surface issues” from “repo debt”

Highest-value files to revisit in your new workspace​

These are the most important carry-forward surfaces.

Docs / contract​

  • docs/ux/UX-FRONTEND-CONVENTIONS.md
  • docs/ux/UX-SHARED-COMPONENTS-CONTRACT.md

Shared navigation / drawer​

  • frontend/src/lib/components/shared/entity-link.ts
  • frontend/src/lib/components/shared/EntityLink.svelte
  • frontend/src/lib/components/shared/patterns/drawer/DrawerCoordinator.svelte

Shared status contract​

  • frontend/src/lib/contract/status.ts
  • frontend/src/lib/contract/index.ts
  • frontend/src/lib/components/shared/StatusChip.svelte

Questions route​

  • frontend/src/routes/questions/+page.svelte
  • frontend/messages/en.json
  • frontend/src/routes/questions/page.test.ts
  • frontend/src/routes/questions/test-stubs/*

reference/demo surfaces​

  • frontend/src/routes/dev/ui/context-drawer/+page.svelte
  • frontend/src/routes/dev/ui/inventory-table/+page.svelte

Secondary files worth evaluating later​

These are important, but less immediate than the questions page and shared contract surfaces.

  • frontend/src/routes/+layout.svelte
  • frontend/src/lib/components/shared/AppShell.svelte
  • frontend/src/lib/components/shared/GlobalNav.svelte
  • frontend/src/lib/components/shared/StandardHub.svelte
  • frontend/src/lib/components/shared/bits/DialogSheet.svelte
  • frontend/src/lib/components/shared/inventory/*

These matter more if you decide to continue into deeper shell/platform cleanup rather than just carrying over the UI hardening work.

This is the order I’d recommend if you open a fresh workspace on your good local checkout.

Phase 1: Reconfirm the contract​

Before implementation, re-read and confirm:

  • the peek-drawer contract
  • canonical full-page href expectations
  • edit-vs-review interaction model
  • shared status ownership direction

This avoids reintroducing earlier ambiguity.

Phase 2: Reapply shared navigation/doc alignment​

Make sure:

  • docs match intended behavior
  • EntityLink behavior is correct
  • drawer/open-full-page flow is consistent
  • reference routes are not teaching the wrong model

Phase 3: Reapply questions page hardening​

Focus on:

  • copy localization
  • shared status contract use
  • table error-state wiring
  • accessible replacement for prompt / confirm
  • preservation of drawer-peek + full-page behavior

Phase 4: Run focused verification​

Prefer targeted runs such as:

  • questions page tests
  • status contract tests
  • entity-link tests
  • npm run check
  • npm run build

Treat lint as a separate cleanup lane if broader repo debt remains.

Phase 5: Decide whether to continue into shell/platform follow-ups​

Only after the core questions/shared contract work is in good shape should you decide whether to tackle:

  • root-layout drawer hosting
  • deeper inventory contract completion
  • StandardHub maturation

Open UI follow-ups still worth considering later​

These were not the first priority, but they were real findings.

Root-layout drawer enforcement​

Should drawer hosting/coordinator logic be made more truly root-level so routes do not drift?

Inventory foundation completion​

Should the shared inventory system gain:

  • shared bulk-action affordances
  • refresh/freshness patterns
  • accessible live announcements
  • stronger table-shell guarantees

StandardHub maturity​

Should it remain light scaffolding, or become a more complete hub contract?

Richer usage/dependency UX​

Should question usage evolve beyond simple counts where richer dependency info exists?

Bottom-line UI recommendations​

If I reduce all of this to the most important carry-forward points, they are these:

1. Preserve the shared-primitives direction​

Do not revert to bespoke route-by-route UI if your good checkout still supports the shared shell/inventory/navigation path.

2. Preserve canonical full-page links​

Drawer support should never destroy real-link behavior.

3. Use drawers for browse/review, full pages for edit/deeper work​

That interaction model is the cleanest outcome from this whole effort.

4. Move semantics into shared contracts​

Especially:

  • status labels
  • status tone logic
  • navigation rules
  • localized product copy

5. Reapply questions-page hardening in the new workspace​

The highest-value route-specific carry-forward work is:

  • copy cleanup
  • error-state cleanup
  • status-contract alignment
  • accessible confirmation flows
  • preserved peek-drawer behavior with canonical full-page links

My practical recommendation for your next workspace​

When you open a new workspace on your good checkout, the best prompt will be something like:

  • use the UI findings handoff from the old workspace
  • recreate a clean plan for the UI track only
  • ignore Docker/bootstrap/local-env work
  • start with the shared navigation/docs/questions-page hardening path