IP Workview Refresh
Mockup Snapshot
Section titled “Mockup Snapshot”| Field | Value |
|---|---|
| Company | JMS |
| Portal | Admin |
| Prototype | https://jms.orchidux.com/admin/ip-workview-refresh?filter_template=2 |
| Jira tickets | JMS-5449, JMS-5450, JMS-4495 |
| PRD | Not linked yet |
| Handoff status | Draft |
| Walkthrough video | Not attached yet |
This mockup is still a draft handoff. Treat it as a reviewable UX direction for the Workview refresh, not as promoted final product behavior.
Purpose
Section titled “Purpose”The IP Workview Refresh shows how a JMS Admin can review one Intake IP workflow across many journeys without losing comparison context. The mockup focuses on dense operational scanning, By Journey and By Task review modes, task-state visibility, filtering, sorting, horizontal matrix navigation, and a safe bulk task-edit flow with recoverable partial failure.
Actors & Use Cases
Section titled “Actors & Use Cases”| Actor | Use case |
|---|---|
| Admin | Reviews many Intake IP journeys at once, narrows the list, compares task progress, and updates workflow task states. |
| Case manager | Finds assigned journeys, checks what remains incomplete, and confirms whether work is on track before follow-up. |
| Operations lead | Filters by team or assignee to understand workload and spot journeys that need attention. |
Primary User Flow
Section titled “Primary User Flow”- The Admin opens the Intake IP Workview for the selected workflow template.
- The Admin narrows the worklist with Search, Status, Assigned, Team, or template filters.
- The Admin chooses By Journey for journey-first scanning or By Task for task-first review.
- In By Journey, the Admin scans pinned journey summary, progress, party statuses, and workflow task columns.
- The Admin scrolls the matrix or uses the horizontal arrows to inspect later task columns while journey identity remains visible.
- The Admin turns on Edit task states.
- Active task pills become editable Complete/Incomplete controls; Inactive tasks stay unavailable.
- The Admin changes one or more task states across one or more journeys.
- The page previews staged changes immediately, including updated row progress and visible unsaved-state indicators.
- The Admin selects Save changes and reviews the backend-effects warning before applying.
- The applying state stays visible until all task updates return a result.
- The result state lists successful and failed updates separately.
- If any task fails, the Admin can retry only the failed changes without undoing the successful ones.
Alternate Flows & States
Section titled “Alternate Flows & States”| State | What the developer should understand |
|---|---|
| By Journey default | The default page is a journey-first comparison surface. The design keeps a dense table and horizontal workflow matrix instead of converting the Workview into cards. |
| By Task mode | The alternate mode lets the Admin review one task across multiple journeys, including task-centered selection and bulk action scope. |
| Filtering | Filters narrow the current journeys and reset pagination. Team filtering is part of the refresh. |
| Mobile filtering | Smaller screens keep Search visible and move filters behind a Filters button and right-side drawer. |
| Horizontal navigation | The matrix supports direct horizontal scrolling and arrow controls. Pinned ID and Journey Name protect orientation while task columns move. |
| Task title overflow | Long task names stay at a consistent width and expose the full title through tooltip disclosure. |
| Progress | Progress is row-derived from active Complete and Incomplete task states. Inactive tasks do not count toward the denominator. |
| Hidden snippets cue | A small help cue beside each progress indicator explains when a case has snippets not shown in this Workview. |
| Edit task states | Editing is deliberate. The Admin must enter the mode before task states become editable. |
| Unsaved changes | Changed task controls show a dashed unsaved state and remain staged until Save changes. |
| Cancel with drafts | Canceling while changes exist requires confirmation so the Admin does not lose staged work accidentally. |
| Backend-effects warning | Saving task changes can trigger downstream workflow effects, so the Admin reviews a confirmation before applying. |
| Applying | The progress dialog is intentionally non-dismissible while updates are in flight. |
| Partial failure | A result can contain both successes and failures. Successful updates stay applied; failed updates can be retried. |
| Empty result | If filters remove every journey, the page should explain that no journeys match without replacing the overall Workview structure. |
Screen Reading Guide
Section titled “Screen Reading Guide”
Desktop default state. Read this screen left to right: filter rail, search and sort controls, By Journey and By Task modes, pinned journey summaries, progress, party statuses, and horizontally scrollable workflow tasks.
Mobile default state. The mockup keeps the matrix model intact: Search and sort stay visible, filters move into a drawer, By Journey and By Task remain accessible, and horizontal navigation exposes additional task columns.
Product & UX Rules
Section titled “Product & UX Rules”- This mockup is scoped to Intake IP Workview review.
- By Journey is the default review mode; By Task provides task-centered review across journeys.
- The selected workflow template appears fixed for this route.
- The journey summary remains visible while workflow task columns scroll.
- Task states must be understandable without relying on color alone.
- Inactive tasks are visible but unavailable for task-state editing.
- Staged task changes update displayed progress before save.
- Save applies all staged task changes together after a confirmation.
- Partial results must account for every attempted task change.
- Failed task updates are recoverable without rolling back successful task updates.
- The shared admin shell is context only on this mockup; route-external actions are not part of the reviewed flow.
Content & Data Notes
Section titled “Content & Data Notes”- Journey names, IDs, assignees, teams, statuses, timestamps, and failure details are fictional review fixtures.
- Production values should come from the Workview journey query, workflow task data, admin identity, permissions, and bulk task-update results.
- The deterministic partial-failure path exists only so reviewers can inspect the failure and retry experience.
- The content contract is draft, so these notes should not be promoted into stable product docs until the mockup is approved.
Open Questions
Section titled “Open Questions”- Should a later Workview milestone support activating or deactivating custom tasks from this page?
- Should production bulk progress come from a job endpoint, server-sent events, polling, or completed-result counts?
- Should Team filtering accept multiple teams in production or follow a single-team behavior?
Walkthrough & Assets
Section titled “Walkthrough & Assets”- Desktop screenshot: open image
- Mobile screenshot: open image
- Walkthrough video: not attached yet
- UX Registry follow-up: attach the walkthrough to the existing row, then set this page’s walkthrough block to the registry
walkthroughVideoUrl