containers
Navigation history & breadcrumbs
The navigation redesign was approved at the UX Check In meeting on 2025-11-13 with a hybrid approach combining:
Browser-style history buttons
- Back/forward buttons positioned in the title bar near the search functionality
- Similar to Slack and VS Code patterns for familiarity
- Dedicated history navigation separate from structural navigation
Hierarchical breadcrumbs
- Shows current location in application hierarchy (where you ARE)
- Remains in traditional page location below the title bar
- No longer shows navigation path (where you’ve BEEN)
Key design decisions
- Compatible with both Podman Desktop and Kortex
- Long-press/hold on buttons reveals navigation history dropdown → Phase 2
- Phased implementation starting with basic functionality before advanced features
Wireframes
Phases
Phase 1 (approved for immediate implementation):
- Basic back/forward button functionality
- Hierarchical breadcrumbs in traditional page location
- Telemetry to monitor usage patterns and inform future decisions
- Consider starting with only the “back” button for the simplest possible implementation
Phase 2 (based on Phase 1 telemetry and usage data):
- History dropdown menu accessible via long-press on buttons
- Keyboard shortcuts (similar to Slack/VS Code patterns)
- Advanced navigation features informed by user behavior
Phase 3 (future consideration):
- Additional features based on continued telemetry analysis
Phase 1 constraints
The following items are explicitly out of scope for Phase 1:
- Form state restoration (complex implementation, potential stale data issues)
- Keyboard shortcuts (deferred to Phase 2)
- History dropdown menu (deferred to Phase 2)
- Extension API integration (requires epic-level planning)
Phase 1 decisions:
- History resets on app restart (simpler implementation, consistent with browser behavior)
- History limit: 20 entries (adjustable based on telemetry)
- Deleted resources: Show placeholder page with "This resource no longer exists" message and link to list view
- Stopped machines: Allow navigation (machine is still a valid resource, just in a different state)
- Search queries: Preserve when navigating back
Critical technical questions requiring resolution
1. History persistence behavior
- Should navigation history reset on app launch or persist across sessions?
- Current recommendation: Reset on launch (simpler implementation, browser-like behavior)
- Requires validation through user research
2. History retention limits
- How many pages should be retained in navigation history?
- Unlimited history would create unwieldy dropdown menus
- Need to define reasonable limit (10 pages? 20 pages? 50 pages?)
3. Deleted resource handling
- What happens when navigating back to a deleted container’s detail page?
- What happens with stopped Podman machines?
- Options: Show empty placeholder page, display “resource no longer exists” message, or prevent navigation
4. Form state restoration
- When navigating back to pages with forms/search queries, should the state be restored or reset?
- What happens when users navigate back after submitting forms?
- Some users expect browser-like behavior, but it is complex to implement
5. Visual glitches and edge cases
- @benoitf raised concerns about potential visual issues during navigation
Current API integration problems discussed on the UX meeting:
- Extensions (AI Lab, Kubernetes) currently maintain separate breadcrumb systems
- Extensions don’t contribute to application-wide navigation history
- No unified API for extensions to register navigation events
References
@jiridostal Hey, could you please help us prioritize this ticket implementation?
@vancura Sure thing. Do you consider this proposal as ready to be implemented? If yes, I'll go ahead and include it in the planning.
@jiridostal I feel like we'd need a finished design first. Which could be done as part of this ticket, but I think would do better as a separate, smaller, issue for the first phase. I agreed to help @vancura with that, but can I ask one of you to create the issue for the phase 1 design, please?
Once created, it would need to be assigned to a sprint - I suppose we could add it to the current one.
Just added the "Phase 1 constraints" to the description above. /cc @MariaLeonova