cameleer/cameleer-server
1
0
Fork 0
Code Issues 41 Pull Requests Actions Packages Projects Releases Wiki Activity

UX overhaul: streamline navigation from search results to route diagram #69

New Issue
Closed
opened 2026-03-14 22:34:42 +01:00 by claude · 2 comments
claude commented 2026-03-14 22:34:42 +01:00
Owner
Copy Link

Priority: HIGH — Core navigation refactor

Problem Statement

The current UI requires 3 interactions to reach the route diagram from search results: (1) click row to expand, (2) scan past processor tree to find sidebar button, (3) click "View Route Diagram". This is the most important user journey in the application and it's buried behind an indirect, non-obvious path.

Users coming from observability tools (Jaeger, Datadog APM, Grafana Tempo) expect one click to go from a trace row to the detail/visualization view.

Current Flow (3 clicks)

Results Table → click row → inline expand → find button → click "View Route Diagram" → RoutePage

Target Flow (1 click)

Results Table → click row → RoutePage (diagram + execution overlay)

UX Audit Findings

1. Row click should navigate directly to RoutePage

  • Current: Click row toggles inline expand/collapse panel
  • Proposed: Click row navigates to /apps/:group/routes/:routeId?exec=:execId
  • The inline expand panel is eliminated entirely
  • This is how every major observability tool works

2. Inline expand panel duplicates the RoutePage

The expanded row shows Processor Tree + Exchange Details — both already exist as tabs on the RoutePage. The user sees partial data inline, then navigates to a page showing the same data again. This creates confusion ("where am I?") and wasted screen real estate.

Solution: Remove the inline expand. Move Exchange Details to a new Exchange tab on the RoutePage. All execution detail lives in one place.

3. RoutePage becomes the universal detail view

After refactor, RoutePage tabs become:

  • Diagram — route topology + execution overlay (default tab)
  • Performance — stats, throughput, latency charts
  • Processor Tree — execution tree (currently a tab, keep as-is)
  • Exchange — exchange body, headers, metadata (moved from inline expand)

The RoutePage works with or without ?exec= — without it, shows the route topology only.

4. Route column in results table should be a clickable link

The "Route" column (exec.routeId) should be a link to the route diagram (without execution context). This gives a fast secondary path for users who want to see the route topology without drilling into a specific execution.

5. Add "Applications" to TopNav

TopNav: [Transactions] [Applications] [Admin]

/apps shows groups and their routes. Clicking a route goes to RoutePage without ?exec=. This makes route diagrams discoverable from top-level navigation without requiring a search first. (See #54)

6. Preserve table state on back-navigation

When navigating back from RoutePage to ExecutionExplorer:

  • Restore search filters, page offset, scroll position
  • Highlight the previously-clicked row briefly (visual anchor)
  • Store state in URL search params or sessionStorage

7. Consider split-panel layout (future)

Alternative to full page navigation: clicking a row opens a right-side panel with diagram + detail while the table stays visible on the left (like email clients, Kibana Discover, Azure App Insights). This keeps search context visible while exploring executions. Higher effort — consider for v2.

Implementation Plan

Phase 1: Direct navigation (core change)

  • Make table row click navigate to RoutePage with ?exec=
  • Remove inline expand panel (ResultRow expand logic, detailRow CSS)
  • Remove "View Route Diagram" button
  • Keep expand chevron column but repurpose as visual row indicator or remove

Phase 2: RoutePage as complete detail view

  • Add Exchange tab to RoutePage (move content from ExchangeDetail.tsx)
  • Ensure RoutePage works without ?exec= param (diagram-only mode, no overlay)
  • ExecutionPicker in toolbar is the way to browse/switch executions

Phase 3: Table enhancements

  • Make Route column a clickable link (/apps/:group/routes/:routeId)
  • Preserve search state in URL params for back-navigation
  • On back-nav, briefly highlight the previously-visited row

Phase 4: Top-level navigation

  • Add "Applications" link to TopNav
  • Implement /apps page with group → route hierarchy (see #54)

Files Affected

  • ui/src/pages/executions/ResultsTable.tsx — remove expand, direct nav on click
  • ui/src/pages/executions/ExchangeDetail.tsx — move to RoutePage as Exchange tab
  • ui/src/pages/routes/RoutePage.tsx — add Exchange tab, handle no-exec mode
  • ui/src/components/layout/TopNav.tsx — add Applications link
  • ui/src/router.tsx — add /apps route
  • ui/src/pages/executions/ExecutionExplorer.tsx — state preservation
  • ui/src/pages/routes/ResultsTable.module.css — remove detail row styles

Design Principle

Reduce the number of clicks between "I see a problem" and "I see the diagram" from 3 to 1. Put UX first, no compromise.

Related Issues

  • #54 — Applications list page (Phase 4 of this refactor)
  • #62 — Slide transition (view transitions stay, but no longer needed for inline→page; now table→page)
## Priority: HIGH — Core navigation refactor ## Problem Statement The current UI requires 3 interactions to reach the route diagram from search results: (1) click row to expand, (2) scan past processor tree to find sidebar button, (3) click "View Route Diagram". This is the most important user journey in the application and it's buried behind an indirect, non-obvious path. Users coming from observability tools (Jaeger, Datadog APM, Grafana Tempo) expect **one click** to go from a trace row to the detail/visualization view. ## Current Flow (3 clicks) ``` Results Table → click row → inline expand → find button → click "View Route Diagram" → RoutePage ``` ## Target Flow (1 click) ``` Results Table → click row → RoutePage (diagram + execution overlay) ``` ## UX Audit Findings ### 1. Row click should navigate directly to RoutePage - **Current**: Click row toggles inline expand/collapse panel - **Proposed**: Click row navigates to `/apps/:group/routes/:routeId?exec=:execId` - The inline expand panel is eliminated entirely - This is how every major observability tool works ### 2. Inline expand panel duplicates the RoutePage The expanded row shows Processor Tree + Exchange Details — both already exist as tabs on the RoutePage. The user sees partial data inline, then navigates to a page showing the same data again. This creates confusion ("where am I?") and wasted screen real estate. **Solution**: Remove the inline expand. Move Exchange Details to a new **Exchange** tab on the RoutePage. All execution detail lives in one place. ### 3. RoutePage becomes the universal detail view After refactor, RoutePage tabs become: - **Diagram** — route topology + execution overlay (default tab) - **Performance** — stats, throughput, latency charts - **Processor Tree** — execution tree (currently a tab, keep as-is) - **Exchange** — exchange body, headers, metadata (moved from inline expand) The RoutePage works with or without `?exec=` — without it, shows the route topology only. ### 4. Route column in results table should be a clickable link The "Route" column (`exec.routeId`) should be a link to the route diagram (without execution context). This gives a fast secondary path for users who want to see the route topology without drilling into a specific execution. ### 5. Add "Applications" to TopNav ``` TopNav: [Transactions] [Applications] [Admin] ``` `/apps` shows groups and their routes. Clicking a route goes to RoutePage without `?exec=`. This makes route diagrams discoverable from top-level navigation without requiring a search first. (See #54) ### 6. Preserve table state on back-navigation When navigating back from RoutePage to ExecutionExplorer: - Restore search filters, page offset, scroll position - Highlight the previously-clicked row briefly (visual anchor) - Store state in URL search params or sessionStorage ### 7. Consider split-panel layout (future) Alternative to full page navigation: clicking a row opens a right-side panel with diagram + detail while the table stays visible on the left (like email clients, Kibana Discover, Azure App Insights). This keeps search context visible while exploring executions. Higher effort — consider for v2. ## Implementation Plan ### Phase 1: Direct navigation (core change) - [ ] Make table row click navigate to RoutePage with `?exec=` - [ ] Remove inline expand panel (`ResultRow` expand logic, `detailRow` CSS) - [ ] Remove "View Route Diagram" button - [ ] Keep expand chevron column but repurpose as visual row indicator or remove ### Phase 2: RoutePage as complete detail view - [ ] Add **Exchange** tab to RoutePage (move content from `ExchangeDetail.tsx`) - [ ] Ensure RoutePage works without `?exec=` param (diagram-only mode, no overlay) - [ ] ExecutionPicker in toolbar is the way to browse/switch executions ### Phase 3: Table enhancements - [ ] Make Route column a clickable link (`/apps/:group/routes/:routeId`) - [ ] Preserve search state in URL params for back-navigation - [ ] On back-nav, briefly highlight the previously-visited row ### Phase 4: Top-level navigation - [ ] Add "Applications" link to TopNav - [ ] Implement `/apps` page with group → route hierarchy (see #54) ## Files Affected - `ui/src/pages/executions/ResultsTable.tsx` — remove expand, direct nav on click - `ui/src/pages/executions/ExchangeDetail.tsx` — move to RoutePage as Exchange tab - `ui/src/pages/routes/RoutePage.tsx` — add Exchange tab, handle no-exec mode - `ui/src/components/layout/TopNav.tsx` — add Applications link - `ui/src/router.tsx` — add `/apps` route - `ui/src/pages/executions/ExecutionExplorer.tsx` — state preservation - `ui/src/pages/routes/ResultsTable.module.css` — remove detail row styles ## Design Principle > Reduce the number of clicks between "I see a problem" and "I see the diagram" from 3 to 1. Put UX first, no compromise. ## Related Issues - #54 — Applications list page (Phase 4 of this refactor) - #62 — Slide transition (view transitions stay, but no longer needed for inline→page; now table→page)
claude commented 2026-03-15 10:12:55 +01:00
Author
Owner
Copy Link

Dependency note: Phase 1 (direct row-click navigation) currently works around the missing group field by looking up the agent registry at click time (ResultsTable.handleDiagramNav). Once #37 lands and group is on ExecutionSummary, this lookup can be removed and navigation becomes a simple URL build from row data.

Also: the "Application" column currently shows agentId (instance ID) instead of the application name (group). #70 tracks fixing this. With the terminology clarification:

  • group = application name (e.g. order-service-eu)
  • agentId = individual instance ID

The /apps/:group/routes/:routeId URL pattern is correct — it uses the application name, not the instance ID.

**Dependency note**: Phase 1 (direct row-click navigation) currently works around the missing `group` field by looking up the agent registry at click time (`ResultsTable.handleDiagramNav`). Once #37 lands and `group` is on `ExecutionSummary`, this lookup can be removed and navigation becomes a simple URL build from row data. Also: the "Application" column currently shows `agentId` (instance ID) instead of the application name (`group`). #70 tracks fixing this. With the terminology clarification: - **group** = application name (e.g. `order-service-eu`) - **agentId** = individual instance ID The `/apps/:group/routes/:routeId` URL pattern is correct — it uses the application name, not the instance ID.
claude commented 2026-03-17 10:12:40 +01:00
Author
Owner
Copy Link

Fully implemented — ResultsTable row click navigates to /apps/{group}/routes/{routeId}?exec={execId} with view transitions and highlight-on-return. Closing.

Fully implemented — ResultsTable row click navigates to `/apps/{group}/routes/{routeId}?exec={execId}` with view transitions and highlight-on-return. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
Accessibility (a11y) improvements
 bug
Something isn't working correctly
 cleanup
Code cleanup, dead code removal, refactoring
 epic
Epic: groups related issues
 feature
New functionality
 pmf
Product-market fit: critical for first market offer
 route-diagram
Route diagram page and execution overlay
 security
Authentication, authorization, RBAC
 ui
Frontend / React UI
 ux
UX/usability improvements
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: cameleer/cameleer-server#69
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?