KDS — Layout Options Feature
KDS — Layout Options Feature
1. Background
-
Current KDS displays all orders in a single horizontal card flow.
-
Kitchens use different hardware setups (EPOS tablets, wall-mounted displays, countertop screens).
-
A fixed layout forces staff to adapt, increasing visual scanning time, cognitive load, and errors, especially during peak hours.
2. Objective
Introduce a Layout Options setting so each device can choose the most suitable layout.
The selected layout applies to both Open and Completed screens, and persists across reloads.
3. User Value
-
Faster and easier order recognition.
-
Layout that adapts to different screen sizes and mounting positions.
-
Reduced missed items and smoother workflow during rush hours.
4. Proposed Layouts (MVP)
1. Horizontal (Default)
-
Cards flow left-to-right, wrapping to next row.
-
Larger card area for details.
-
Ideal for wall displays or large EPOS devices.
2. Vertical List
-
Single-column, full-width stacked cards.
-
Best for narrow tablets or chefs who prefer list-style scanning.
3. Compact Grid
-
Smaller cards arranged in 2+ columns.
-
High-density view for very busy kitchens needing maximum visibility.
5. UX Specifications
Settings
-
Location: Settings modal (device-level).
-
Control Type: Radio buttons with small preview thumbnails.
-
Persistence: Save selection in local device storage.
-
Apply Behavior: Update layout immediately—no reload required.
Visual Feedback
-
Show a short toast message: “Layout updated — {Layout Name}”.
Accessibility
-
Layout change must not remove keyboard focus.
-
Maintain ARIA live regions for real-time movement of orders.
6. Acceptance Criteria
-
User can select one of the three layouts in Settings.
-
Selected layout updates both Open & Completed screens instantly.
-
Layout persists across reloads and device restarts.
-
All existing features work in every layout (item tap, recall, new-item highlight).
-
Preview icons/text available in Settings.
-
No data loss or disruption to queued actions during layout change.
7. Success Metrics
-
Reduced time to locate orders (measured in pilot sites).
-
Improved staff satisfaction on visibility and scanning speed.
-
No rise in missed items or sync errors after rollout.
8. Rollout Plan
-
Internal QA across screen sizes (tablet, wall display, desktop).
-
Pilot in 2–3 high-volume kitchens for 2 weeks.
-
Refine based on feedback; explore advanced layouts (e.g., priority-based grouping).
-
Roll out widely; optionally add store-level default in Admin Console.
9. Engineering Notes
-
Apply layout using a single parent CSS class:
-
.layout-horizontal -
.layout-vertical -
.layout-grid
-
-
Persist selection in localStorage or device configuration.
-
Track layout usage via telemetry.
-
Layout change should only affect presentation layer—avoid unnecessary re-rendering or server requests.
-
Test keyboard navigation and screen reader compatibility.
10. Open Questions
-
Should admin be able to set a default layout per store? (Recommended: Yes, future phase.)
-
Should layout be per-user or per-device? (Recommended: Per-device for kitchen shared hardware.)
Comments
Post a Comment