HN user

komlan

81 karma

Founder at darkaa.com (QR code based physical items tracking platform)

komlan.kedji@trak.codes

Posts3
Comments22
View on HN

This is the fundamental weakness of every self-check-in system. QR codes are just information, and information can already be transmitted instantly and faked (GPS, etc.) if needed.

If you care about reliability, there's no way around scanning the codes yourself (instead of making attendees scan), so you can be sure that each scan maps to an actual attendee, and you're not getting 30 scans from 10 people actually present.

I guess self-check-in became popular in zoom calls during the covid area, but people that need reliability instantly prefer the alternative, when available.

Shameless self-plug: this is precisely why my Google Forms/Sheets check-in plugin is named "Qr code ticket per attendee" [1], because the unique ID per person is what makes it more reliable than self-check-in.

Yes, people can still send friends, but most of the time, you don't care, and it's too much of a hassle for the attendee. People sometimes worry that check-in won't be quick, but QR code reading is very fast [2], and you're only limited by how quick people move.

[1] https://qr-code-ticket.com

[2] https://www.youtube.com/watch?v=-fkgCX3H7so

Ah, I was assuming numeric data rendered as hex, like UUIDs. Decimal works wonders for those, because the numeric mode of QR codes is the most efficient.

Physically bigger pixels help a lot indeed. The encoding mode also helps make pixels bigger.

This is very convenient when you control the QR reader and need to represent long numeric identifiers like UUIDs.

For example:

  9728983f-7d7d-4189-b624-f92781e36650 (lowercase UUID):
    => length=36, 15 pixels between markers
  JWM9GFVXFN0RKDH4Z4KR3RV6A0 (base32 UUID):
    => length=26, 11 pixels between markers
  9728983F-7D7D-4189-B624-F92781E36650 (uppercase UUID):
    => length=36, 11 pixels between markers
  200924207194334734815443970355691218512 (decimal UUID):
    => length=39, 7 pixels between markers
The uppercase UUID has bigger pixels because it used a different encoding, and gets the same results as the shorter base32 uuid.

The decimal UUID is a longer string, but results in much bigger pixels because it can use numeric encoding.

I have a QR code base attendance tracker [1], where attendees show the code [2] on their phones (glares, etc.), in bad lighting conditions, etc. Bigger pixels means scanning stays quick. Same with parcel tracking [3] where field agents might need to scan QR codes in barely-lit hallways, etc.

[1] https://workspace.google.com/marketplace/app/qr_code_pass_fo...

[2] https://share.darkaa.com/!qntvtzNPWJ

[3] https://admin.trak.codes/

Wow, happy to find another QR code enthusiast here! They simplify a lot of things, indeed.

Great use case! I did a tool inventory management use case once, with the underlying platform [1].

It starts with generating QR codes for sticker papers [2], from the app. Those never expire and are all different (v4 UUID). You can then assign a QR to any new item, then scan it for registration in the app, specifying room, drawer, etc. (and gps, picture, etc. if needed).

You can browse tools per room, drawer, etc., and scan anytime to record an update. Each tool gets a history trail.

You can even make data-entry easier by making special QR codes for drawers; scanning them fills some form fields with presets, so you don't have to manually select stuff and make mistakes.

I mostly see use-cases where other people scan a QR you made, but there are use cases where the QR codes are only ever scanned by you and your staff.

[1] https://admin.trak.codes/ [2] https://share.darkaa.com/!9DXEQQTg2z/trak-qr-codes-demo-hn.p...

Thank you!

The main platform is currently used by national post offices (physical mail tracking), health organizations (biological samples), banks (fixed assets tracking), manufacturing plants (parts inventory tracking), etc.

QR codes make it easy to avoid data-entry errors in quite a large set of use cases with physical objects.

Indeed. This happens when the form is configured to collect "verified" emails.

A form can use a custom field (doesn't require login), user input managed by Google Forms (named "Email", doesn't require login), or the google email of the user ("verified" email, requires login).

This add-on supports every one of these options.