# Rice Box Pickup Interface — Two-Screen Field of Study Handoff **Status:** Live design prototype **Decision owner:** John Peterson **Direction approved:** Two synchronized customer-facing screens over the existing KDS daemon **Prepared:** 2026-07-11 ## Live design samples These links use fixed fictional orders so the composition remains reviewable outside store hours. - **Screen 01 — Order Progress:** https://pickup-preview.riceboxed.com/kitchen/ - **Screen 02 — Ready at Pickup:** https://pickup-preview.riceboxed.com/ready/ Live operational versions: - **Screen 01 — Live:** Production endpoint assigned after cloud KDS migration - **Screen 02 — Live:** Production endpoint assigned after cloud KDS migration Store can be changed with `location=heights`, `river_oaks`, `rice_village`, or `hedwig`. ## Product intent This is a pickup hospitality instrument, not another kitchen dashboard. It answers four questions without requiring a guest or driver to interrupt the team: 1. Was my order received? 2. Is it still being prepared? 3. Is it ready? 4. Where do I retrieve it? The experience should reduce pickup anxiety while feeling like a real Rice Box command terminal. ## Architecture boundary Keep the existing KDS daemon as the only Toast ingestion and state engine. The two screens are a second, customer-safe face over that engine. ```text Toast webhooks + 30-second reconciliation ↓ Existing KDS daemon ├── Internal operations face └── Customer-safe public projection ├── Screen 01: Order Progress └── Screen 02: Ready + Handoff ``` Do not create an independent Toast polling service or duplicate order-state logic in the visual overlay. ## Screen responsibilities ### Screen 01 — Order Progress - Header: `YOUR ORDER IS IN THE KITCHEN` - Shows pickup and delivery orders that are not yet bumped ready - Does not show dine-in tickets - Does not show estimated countdowns, late warnings, item counts, full surnames, or internal prep details - Footer: `WE'RE MAKING IT FRESH. WATCH THE READY SCREEN FOR PICKUP.` ### Screen 02 — Ready at Pickup - Header: `READY AT PICKUP` - Shows only orders actually bumped READY in Toast - Shows the physical pickup destination for each order - Footer: `DON'T SEE YOUR ORDER? OUR TEAM IS RIGHT HERE.` - A newly ready order may use one restrained arrival pulse, then return to a calm state ## Identification hierarchy 1. **Toast order number** — primary identity 2. **First name + last initial** — human recognition 3. **Order source badge** — resolves same-name and driver ambiguity 4. **Short platform code** — shown only when available and useful 5. **Pickup zone** — shown only on the Ready screen Name is recognition. Order number is identity. Channel resolves ambiguity. ## Public source labels | Toast / operational source | Public label | Pickup destination | |---|---|---| | Take Out | ORDERED HERE | CUSTOMER PICKUP | | App Pickup / owned web pickup | RICE BOX ONLINE | CUSTOMER PICKUP | | Call In / phone | PHONE ORDER | CUSTOMER PICKUP | | App Delivery | RICE BOX DELIVERY | DELIVERY PICKUP | | DoorDash | DOORDASH | DOORDASH ZONE | | Uber Eats / Postmates | UBER EATS | UBER EATS ZONE | | ezCater | EZCATER | CATERING PICKUP | | Grubhub / Favor / rare sources | Named when recognized; otherwise OTHER DELIVERY | DELIVERY PICKUP | The physical shelf and display must use the same labels. If the screen says `DOORDASH ZONE`, the shelf should not say `THIRD PARTY A`. ## Customer-safe data contract ### State endpoint `GET /api/public-state?location=` ### Live stream `GET /api/public-stream?location=` The stream uses Server-Sent Events and pushes a complete current state after connection and after every order change. ```json { "generated_at": "2026-07-11T15:00:00-05:00", "location": "heights", "mode": "live", "screens": { "kitchen": [ { "order_number": "142", "display_name": "Jordan P.", "source_key": "ordered_here", "source_label": "ORDERED HERE", "pickup_zone": "CUSTOMER PICKUP", "public_status": "making" } ], "ready": [ { "order_number": "139", "display_name": "Taylor M.", "source_key": "doordash", "source_label": "DOORDASH", "pickup_zone": "DOORDASH ZONE", "public_status": "ready", "platform_code": "91AF" } ] } } ``` ### Privacy boundary The public projection intentionally excludes: - Full customer surname - Dine-in tickets - Raw Toast channel data - Placed time and internal elapsed time - Estimated fulfillment time and countdown - Prep time - Item count and item names - Internal order payloads ## Brand system Source: live Rice Box site CSS and saved brand canon, 2026-05-22. | Role | Hex | |---|---| | Tactical slate canvas | `#151D28` | | Cyan teal operating tone | `#88D7D4` | | Neon magenta action signal | `#CE4CAB` | | Cyber yellow attention signal | `#E1E652` | | White highlight | `#FFFFFF` | Typography: - Display: Eurostile Extended, 900 weight - Interface: Eurostile Condensed - Telemetry: OCR-B Std - Typekit kit: `yrv7owv` Vibe: Chinese takeout bar from the future, presented as a real tactical control surface. Prometheus bridge crossed with a Hong Kong neon storefront. The interface must feel operational, not decorative. ## Design requirements - Assume 16:9 commercial displays. - Optimize for recognition from several feet away. - Keep order number as the largest row-level element. - Keep status as the page-level hierarchy, not a small badge. - Channel must be communicated by text as well as color. - Ready screen must feel stronger than the progress screen. - Ready destinations should mirror physical staging left to right. - Preserve a deliberate empty state outside busy periods. - Provide an unmistakable reconnecting state if the live feed drops. - Keep motion restrained and functional. - The interface must respond to live order count without clipping. Current validated density behavior is: 1–8 orders use large relaxed cards; 9–12 use proportionally compressed cards; 13+ use a single-line high-density card. At every density, retain order number, customer name, source label, and pickup destination. ## Field of Study scope Field of Study is recreating the two-screen interface only. The daemon, Toast webhook ingestion, reconciliation polling, order-state classification, customer-safe projection, and SSE delivery already exist and remain owned by Rice Box. Field of Study should: 1. Use the two fixed demo links as the approved information hierarchy and interaction reference. 2. Design both 16:9 screens as one paired physical system. 3. Preserve every required data field and all low-, medium-, and high-volume states. 4. Design the empty, reconnecting, newly-ready, and busy-board states. 5. Mirror the final physical staging-zone labels and left-to-right shelf order. 6. Build against `GET /api/public-state` and `GET /api/public-stream`, or return implementation-ready visual specifications and assets for Rice Box to connect to those endpoints. 7. Return final typography, color, spacing, animation, screen-resolution, and physical-installation specifications. Field of Study should not alter or duplicate any daemon, Toast, webhook, polling, status, privacy, or customer-name parsing logic. ## Do not do - Do not reintroduce the internal three-by-three kitchen grid. - Do not expose dine-in tickets on these screens. - Do not show READY based on an elapsed clock or ETA. Only the Toast kitchen bump can make an order ready. - Do not show full surnames or raw order details. - Do not turn the empty state into an advertising carousel. - Do not use generic corporate dashboard styling, pure black, primary blue, soft shadows, serif typography, or playful rounded fonts. - Do not create separate Toast state logic inside the overlay. ## Current implementation notes - One daemon continues to serve all four retail stores. - Public projection and both screen routes are live. - Seven automated tests cover channel mapping, name privacy, dine-in exclusion, route allowlisting, stream sanitization, and the rule that an overdue ETA cannot create a READY state. - Both 16:9 sample screens were visually inspected with all sample orders visible and no browser console errors.