On URL Versions: I find it odd that governments (eg Australia) that mandate QR codes to check-in to places have such complex information and detailed codes. This makes scanning the QR code more difficult due to the smaller dot size. This results in people huddling around a single point at a door for longer and closer proximity.
A little tech love such as using short URL’s with an intermediate backend that redirects to the complex site URL with a dozen query parameters would allow much lower resolution (lower version) QR codes that can be scanned faster and/or from a further distance away resulting in better health outcomes. Or at least minimise the negative health outcome from the scanning process.
That’s actually exactly the topic of my next post, and the reason I even started looking at this. :)
As the sibling says, there’s some data that is useful to store in every code to enable user-friendly offline check-ins, but they could indeed be much easier to scan and still retain this property.
Have you deciphered the metadata that is associated with the url?
It is odd that we are looking at a paragraph of metadata on a url, however a manual check in is six alphanumeric characters with the Victorian government's system.
We know that none of this data ever changes, these sheets are printed once and are not actively replaced
Yeah, the NSW ones contain a base64-encoded JSON blob storing: the id of a business (a short numeric string), the business name (shown in the app even during an offline check-in) and the business address.
I haven’t investigated the Victorian ones deeply, but I would imagine that the name is only used as a confirmation for the user, and a minimal or manual check-in requires only the ID.
Also phones scan CAPS URL’s just fine. So all you need is:
HTTP:// <SHORT DOMAIN> / CODE
Dropping S in HTTPS gives one extra character if you do a 302 redirect. This is fast enough if the server is hosted in same country (which it should be for health data).
To fit Version 1 (lowest possible resolution 21x21) using only capital letters including colon and forward slash, you have 25 chars available for low ecc, and 20 chars for medium.
Since the QR code is such low simple resolution we can use Low ECC.
That allows for a domain ending with .state.gov.country (assuming state is 3 chars, country is 2). For example:
HTTP://Q.NSW.GOV.AU/ABCDE
There’s your 32M codes available as a Version 1 QR.
However, it loses some of the niceties for offline check-in (the business name, in particular), without an in-app data source.
And, unfortunately, it low resolution doesn't help that much with error correction: v1 does seem to be slightly easier to scan, but only a little, and the ratios of codes scanned is pretty much the same across all versions:
ec_level L M Q H
version
1 38 46 54 65
2 32 39 49 52
3 32 41 43 50
4 32 40 46 49
5 30 39 42 49
...
39 32 41 46 50
40 31 41 47 51
total 1257 1600 1839 2001
(This is the table in the "Error correction really does make scanning more reliable" section broken down by version.)
By this table, the most-scannable encoding under the experimental conditions from the post for that data is ec level H, which requires version 3 (without considering the field-of-view required).
A little tech love such as using short URL’s with an intermediate backend that redirects to the complex site URL with a dozen query parameters would allow much lower resolution (lower version) QR codes that can be scanned faster and/or from a further distance away resulting in better health outcomes. Or at least minimise the negative health outcome from the scanning process.