Comanda la masă cu QR: cum se gândește fluxul

Comanda la masă cu QR are cinci pași: clientul scanează codul, citește meniul în limba telefonului, alege, trimite, iar comanda apare pe tableta din restaurant. Mai jos e fiecare pas și de ce merită făcut așa.

1. Scanezi și ești în meniu, fără aplicație

Nimeni nu instalează o aplicație ca să comande o cafea. De aceea comanda la masă merge cel mai bine ca aplicație web: camera telefonului citește codul, iar meniul se deschide în browser. Pentru comanda la masă, codul de pe fiecare masă trebuie să ducă la același meniu, dar să spună și de la ce masă vine comanda, ca ospătarul să nu întrebe.

Asta schimbă și ce trebuie tipărit: codul rămâne același pe masă, iar meniul din spatele lui se poate schimba oricând. Despre meniurile digitale în general găsești mai multe pe pagina de meniuri digitale.

2. Meniul în limba telefonului

Un turist din Germania nu ar trebui să caute butonul de limbă într-un meniu în română. Browserul îi spune site-ului ce limbi preferă omul: proprietatea navigator.languages întoarce lista lor, în ordinea preferinței, cu prima limbă la început. Aceeași listă ajunge la server în antetul Accept-Language.

Așa că meniul se poate deschide direct în limba telefonului. Un buton de schimbat limba la vedere rămâne totuși util: telefonul nu e mereu setat în limba în care omul vrea să citească, iar unele browsere trimit, pentru intimitate, o singură limbă.

3. Alergenii, lângă fiecare fel

Regulamentul (UE) nr. 1169/2011 cere ca informațiile despre alergeni să fie date și la mâncarea servită pe loc, nu doar la cea ambalată (articolul 44), iar Anexa II enumeră 14 grupe de alergeni. Statele pot decide prin ce mijloace ajunge informația la client.

Într-un meniu digital, cel mai simplu e ca alergenii să stea chiar sub fiecare fel, în limba aleasă de client. Un turist cu alergie la susan nu are cum să întrebe ospătarul într-o limbă comună, dar poate citi pe ecran.

4. Coșul, pentru degetul mare

Omul comandă cu o mână, de multe ori cu paharul în cealaltă. Butoanele trebuie să fie mari și departe unele de altele. Standardul de accesibilitate WCAG 2.2 cere, la nivelul AA, ca țintele pe care apeși să aibă cel puțin 24 × 24 de pixeli CSS, cu câteva excepții. E o limită de jos, nu o țintă: butoanele folosite cel mai des, „adaugă” și „trimite comanda”, merită să fie mult mai mari.

Înainte de trimitere, coșul trebuie să arate tot: ce ai ales, cantitățile, observațiile („fără ceapă”). O comandă greșită trimisă la bucătărie costă mai mult decât o secundă de verificare.

5. Comanda apare pe tabletă, live

Partea pe care restaurantul o simte cel mai tare e tableta. Comanda trebuie să apară pe ea imediat, fără ca cineva să reîncarce pagina. Pentru asta, tableta ține deschisă o conexiune prin care serverul îi trimite comenzile noi pe măsură ce vin.

O tehnică potrivită pentru asta se numește server-sent events: o conexiune într-un singur sens, de la server la browser, care se redeschide singură dacă se întrerupe. Pentru o tabletă pe Wi-Fi-ul unui local, unde semnalul mai cade, reconectarea automată contează. Documentația MDN mai notează o limită: fără HTTP/2, un browser poate ține cel mult 6 astfel de conexiuni deschise spre același domeniu. E un detaliu de care ții cont când alegi serverul.

Dacă vrei o aplicație cu comenzi live pentru afacerea ta, găsești pe pagina de servicii App Dev cum lucrăm.