VRPS Wireframe vs Slicer IA — Functional Gap Analysis

wireframe-slicer-gap-analysis.md

Wireframe vs Slicer IA — Gap Analysis

Source: wireframe-vrps.vercel.app
Reference: VRPS Information Architecture · Interactive Slicer Demo
Date: 2026-04-17

---

What the Slicer Requires

The IA defines a single-screen dashboard where all context is URL-encoded:

/dashboard?scope_customer=acme&scope_property=harbor-view&scope_lot=main-surface&view=passes&filter_status=active

Scope, view, and filters are first-class URL params. Navigating between views preserves scope. The LHS nav writes scope + view; the RHS writes filters. Role comes from the session, never the URL.

---

What Maps

Slicer concept	Wireframe equivalent
view=properties / view=lots / view=accounts	Sidebar nav items — Dashboard, Lots & Spots, Accounts, Reports
scope_property	Property switcher widget (bottom-left sidebar, admin portal)
scope_customer (superadmin)	Implicit — superadmin customer list + God Mode drill-in
Breadcrumb "up" navigation	Present on most admin sub-screens
filter_status (partial)	Admin account list has Filter: All types (unit type only, not pass status)

---

Functional Gaps

1. No lot scope (scope_lot)

Lots appear as a nav section ("Lots & Spots") listing all lots for the current property. There is no UI to select a single lot and narrow all subsequent views — passes, offers, blueprints, reports, enforcement — to that lot. The entire scope_lot axis is unmodeled.

---

2. No unit scope as a persistent slicer param (scope_unit)

Units (called "accounts" in the wireframe) are accessed by clicking a row in the Account List, which opens a unit detail screen. There is no "scope to Unit 302 → now show me passes / offers / managers for that unit" navigation pattern. Unit context doesn't persist across views.

---

3. Missing views: offers, blueprints, enforcement, managers

The wireframe has:

• Templates (≈ view=blueprints) — exists as a list but no offers sub-view off it
• No view=offers anywhere
• No view=enforcement within the operator portal (enforcement is superadmin-only revenue reporting)
• No view=managers — managers are shown on unit detail screens only, not as a navigable view

---

4. No cross-view filter persistence

In the slicer, selecting scope_property=harbor-view and switching between view=passes, view=offers, and view=reports preserves the property context throughout. In the wireframe, each sidebar nav item leads to an independent screen — no shared scope state carried across sections.

---

5. No filter_status on pass lists

The manager portal pass list and the admin account detail pass list show all passes with no status filter. The slicer defines 8 filterable statuses (active, expiring_soon, pending_activation, payment_pending, revoked, suspended, abandoned, expired). None are exposed as filters in the wireframe.

---

6. No glob or multi-select scope

scope_lot=visitor-* and comma-separated selectors (scope_lot=main-surface,east-garage) have no wireframe analog anywhere.

---

7. Superadmin has no unified scope_customer drill-through

The slicer allows a superadmin to set scope_customer=acme and then navigate view=properties, view=lots, view=passes — all within one dashboard scoped to that customer. The wireframe uses God Mode (act-as impersonation) instead — a separate session state that switches the entire portal context. These are architecturally different: God Mode is a role switch; scope_customer is a filter param that keeps the superadmin in their own session.

---

Architectural Mismatch

Dimension	Wireframe	Slicer IA
Navigation model	Multi-screen, sidebar → detail drill	Single screen, URL-encoded scope
Scope persistence	Session state per role	URL query string, shared across views
Lot/unit selection	Click-to-detail, no cross-view scope	scope_lot / scope_unit params, all views respect them
URL structure	?journey=connected (wireframe only)	?scope_*=&view=&filter_*=
Superadmin access	God Mode (impersonation)	scope_customer param on unified dashboard

The wireframe models a conventional multi-screen CRUD app. The slicer IA specifies a URL-driven single-screen context manager. The property switcher is the only direct mapping. Everything else needs to be designed.

---

What Would Need to Be Designed

1. Lot picker in LHS nav — selectable lot nodes under each property, same pattern as property switcher but inline
2. Unit picker in LHS nav — selectable unit nodes (or accessible via lot drill-down)
3. view=offers screen — offer list scoped to property/lot/unit, with filter_offer_type
4. view=blueprints screen — blueprint list scoped to lot, with root/child distinction
5. view=enforcement screen — enforcement activity scoped to property/lot
6. view=managers screen — manager list scoped to unit
7. Pass list filter_status — status chips on view=passes
8. Scope-preserving view tab bar — visible tab bar that switches view while keeping all scope params
9. scope_customer in superadmin — replace God Mode drill-in with a customer scope param on the shared dashboard (or at minimum, add it alongside God Mode for read operations)