How a screen arranges its tickets

Four layouts

Classic puts one order per column on a rail that scrolls sideways. Tiled is a grid. Split is two rails that scroll independently of each other. Take-out is a vertical list built around status, the time remaining, an item count and a phone number.

A screen nobody has chosen a layout for runs Classic, which is what the rail has always done. Picking a mode adds one rather than altering the one you already had.

The grid does not cut a row in half

How many tiles stack in one column is worked out from the height available and the smallest a tile is allowed to be, and it is always rounded down. A row that does not fit is not drawn, because a ticket half off the bottom of the glass is a ticket a cook cannot read.

It never drops below one row, so a rail shorter than a single tile shows one ticket rather than failing. That holds from a small tablet up to a wall panel without anything being configured for the size.

Tiled fills a column top to bottom before moving right. The iPad build lays its grid out the same way round, so a kitchen running both does not have to read them in two different directions.

Split is cut by where the food goes

Split divides on order type, and the line it draws is food eaten here against everything that leaves the building. It is the layout for a station running dine-in and off-premise from one screen.

That division covers every order type the app has, with none left over. Adding a new order type later stops the build rather than quietly dropping those tickets onto the dine-in side, which would be a ticket the kitchen never sees.

Where this came from

Every statement above was read out of the source code named below, and the build re-reads those files and fails if a statement stops matching them. This article carries no claim that was not measured from one of these files.

• android/app/src/main/kotlin/online/minirestaurants/kds/rail/RailDisplayMode.kt
• ios/Sources/MRAppUI/OrderRail/RailDisplayMode.swift