Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Visitor check-in logger series ~5 min read

What the log is actually for

Designing backwards from the evacuation produces a different system from designing forwards from the reception desk, and almost every requirement worth having comes from that direction.

Key takeaways

  • It must work with no network and no power in the building.
  • Order by host, because hosts are the people who can confirm.
  • Show the arrival time and the last confirmation, so age is visible.
  • Mark uncertain entries rather than omitting or including them silently.
  • Somebody other than the usual person will be reading it.

The conditions

What the roll call has to survive

  • No mains power in the building, and possibly no wifi.
  • Outside, in whatever the weather is doing, on a phone screen.
  • Read by whoever is there, which may not be reception or the fire marshal.
  • Under time pressure, with a fire service asking whether the building is clear.
  • Possibly on more than one device, at more than one assembly point.
  • Everything else about the system can fail gracefully. This cannot.

That list rules out a design where the roll call is a web page served from somewhere. It has to be cached on the devices that might need it, refreshed continuously while the network exists, and readable from that cache when it does not.

It also rules out anything requiring a login at the point of use. Somebody standing in a car park does not have time to fail a password twice, and the roll call contains names and arrival times rather than anything sensitive.

How it is ordered

How the fire roll call is ordered and confirmedA vertical chain of five steps entered by a box labelled The alarm goes, open the roll call. Step one lists who is inside, checked in and not out. Step two groups by host rather than alphabetically, with a side box explaining that the host can confirm. Step three shows certain entries first, those who arrived recently. Step four shows uncertain entries, people here a long time with no confirmation. Step five allows a tap to confirm that a person is out. A note says grouping by host turns one long list into several short ones somebody can answer.AWS ACCOUNTThe alarm goesopen the roll callWho is insidechecked in, not outGrouped by hostnot alphabeticallyWhythe host can confirmCertain firstarrived recentlyThen uncertainhere a long time,no confirmationTap to confirm'this person is out'Grouping by host turns one long list into several short ones somebody can answer.
Fig 1. How the roll call is presented. Grouping by host is the single most useful choice because it matches how the confirmation actually happens.
  • Compute
  • Machine learning
  • Management
  • Analytics
  • Front-end & mobile
  • People

Grouping by host

At an assembly point the useful question is not “is Sarah Chen here?” asked of a crowd; it is “you had two visitors this morning, are they both out?” asked of the person who was with them.

So the list is grouped by host, hosts are listed by name, and each host’s visitors sit under them. Somebody walks the assembly point asking four people about eleven visitors, rather than shouting eleven names.

Showing uncertainty

A visitor who checked in at nine and has not been confirmed since is more likely to have left than one who checked in twenty minutes ago. Sorting by arrival time and marking anybody over a few hours as unconfirmed gives the reader information they can act on.

The alternative — a clean list of names with no indication of confidence — is worse in both directions. It sends people looking for somebody who left at eleven, and it gives false comfort about the accuracy of the rest.

What the list looks like

A visitor roll call compared with who is actually in the buildingA stacked bar chart with two bars. Two series: arrived in the last two hours in green, and arrived longer ago and unconfirmed in orange. On the list: six recent and eight older. Actually inside: six recent and one older. A note says seven of the eight older entries had left, and that is a normal afternoon.05101520~14On the list~7Actually insideArrived in the last 2 hoursArrived longer ago, unconfirmedSeven of the eight older entries had left. That is a normal afternoon.
Fig 2. A roll call against reality on a typical afternoon. The recent arrivals are reliable; the older unconfirmed ones are mostly people who have gone.

That chart is why the check-out problem gets its own post. The system is accurate for the people who arrived recently and unreliable for everybody else, and both facts should be visible on the screen rather than averaged into one list.

More than one assembly point

Larger buildings have several, and the confirmations need to reconcile: somebody marked as out at the north point should disappear from the list at the south point within seconds, and if the network is down, both lists have to merge sensibly afterwards.

The pragmatic version is that each device holds its own confirmations, they sync when they can, and a person confirmed out anywhere is out. It is not perfect and it is considerably better than two separate paper lists.

Next: how little to collect.

All posts