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

  1. Internal QA across screen sizes (tablet, wall display, desktop).

  2. Pilot in 2–3 high-volume kitchens for 2 weeks.

  3. Refine based on feedback; explore advanced layouts (e.g., priority-based grouping).

  4. 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

Popular posts from this blog

KDS Offline Mode

Elevating Chef Efficiency Through Improved Tappable Item Indicators.

Edited Order Highlighting & Configurable New-Item Duration.