Participant Management Using NFC-Enabled Nametags
For the previous iterations of nwHacks, we issued standard nametags for all participants on the day of the event. We use these nametags as a means to identify registered participants in our venue, and for marking off when a participant gets breakfast, lunch, or dinner (to ensure that we finish giving out first servings before we give out extra servings for any given meal).
Does this work? Sure, but we aim to optimize and improve all of our processes every year — and this year was no exception. There were two main issues that we could find with the nametags:
- We could only tell if a participant had already eaten a particular meal if they showed us their nametag.
- If a nametag was lost by a participant we would also lose the data associated with the nametag (i.e. which meals a participant had eaten so far).
Both of these issues pointed to a single overarching problem: there was no data collection.
The solution we came up with was to attach an NFC (near-field communication) sticker to each nametag, and create our own event recording application that connects to a database to store this information.
How it Works
The Requirements
- Minimal configuration: Associating each NFC tag with a specific participant should be a quick and painless process.
- Concurrent access: Multiple devices (clients) must be able to check participants into a specific event (breakfast/lunch/dinner) concurrently to prevent the system from being a bottleneck during lineups.
- Data synchronization: The data that’s being accessed must be synced across clients so any given client can accurately tell whether someone has already been checked in for a specific event by another client.
- Flexibility: The event system should be extensible (events can be added and removed by any client). While this system was designed primarily for meal events like breakfast/lunch/dinner, it should also be flexible enough to work for any type of event (e.g. checking people into workshops or sponsor activities during the hackathon).
The Components
Storage
Thankfully, our existing data solution handles the concurrent access and data synchronization requirements — we use a Firebase Realtime Database instance (a NoSQL cloud database service provided by Google). It supports multiple clients accessing the database at once, and data synchronization is no longer an issue because our database is centralized in the cloud.
Registering Events
Instead of hard-coding the events into every client, we stored the list of events in our cloud database — each client would query for this data in order to determine the list of events:
Now we needed to figure out what sort of structure we were going to use to store the data we care about (which participants have been checked into a specific event).
Data Structure
With our current system, we internally associate a unique alphanumeric ID with every user that has applied to our hackathon. Any given applicant’s information is stored in our database under specific nodes that are identified by these unique IDs.
Q: Should we store who has been to a specific event under each event node in the list of events or store which events a participant has been to under their respective ID node?
A: With the former approach, we can easily ascertain how many people attended a specific event. However, we went with the latter approach because we felt that keeping all data about the a given user under their respective node was the most appropriate choice in terms of consistency and maintainability.
So with that being said, here is a (simplified) example of a participant node:
As you can see, this example participant has ID a98dB973KwL8xP1Lz9 and has checked in to three events so far. We also see that this participant ate two servings for lunch.
The Case for NFC
Why not use QR codes or magnetic stripe cards?
The first two options require us to rely on additional printing equipment. NFC tags on the other hand are more accessible and don’t have as much logistical overhead — most modern smartphones are capable of reading and writing data from/to NFC tags. Plus, they can be reused by our participants during and after the event (in fact, one team even used them for their hackathon project)!
Enter the Client
We built the client in the form of an Android application that uses the Firebase SDK and Android’s native NFC library. We’ve also open sourced the client; you can view the source code here. Here are all of the functions that it served during the event:
1. Device Pairing & Writing IDs to NFC Tags
An option was added to our check-in system to pair with a registered client (any mobile device running our Android app). The way this works is we have a number of laptops that have the check-in system open, and each of these laptops selects a unique Android device (running our app) to pair up with (also via Firebase ❤️).
Then when a participant hands us some form of identification, we look them up in our check-in system. Upon selection of the participant on the laptop, it automatically selects that same participant on the Android app running on the paired device. Finally, the participant’s unique ID is written to the NFC sticker on their nametag with a single tap of the phone!
Using this streamlined setup we were able to keep up with a high volume of traffic during initial check-in for nwHacks 2018.
2. Checking Users Into Events
This was the bulk functionality of the app. For each event, we had a handful of organizers who would use the app to scan the tags of participants in the lineup.
Each of these organizers would first select the respective event (such as breakfast) and configure two additional options:
- Allow second servings.
- Allow unlimited servings.
Then the organizers would just tap their phones to each participant’s tag to check them into the specific event!
If a participant tried to check-in twice or multiple times to a single event without the respective options above being turned on, the screen would turn orange to notify the organizer.
If the NFC tag was unformatted or contained an invalid ID, the screen would turn red. In this case, we had a standby laptop to quickly provide participants with new tags.
Otherwise (if successful), the screen would turn green and the device would vibrate.
3. Event Registration
Last but not least, we included a view where a user could add an event. This was used to add events for sponsor activities on the day of the hackathon.
Conclusion
Overall, the system ran well on the day of the event. It was used to write to 662 NFC-enabled nametags and log 1707 meals with 200+ extra servings. The plan was to also use this app for workshops, but doing so would have delayed the start times of the workshops, which wasn’t something we could afford to do with our already tight schedule.
As always, there are definitely some areas for improvement. For next year, we can add support for volunteer and sponsor nametags for a more complete view of event statistics. This requires a bit more work for implementation because the company representatives sent by our sponsors are not on our system prior to the event.
Another useful improvement would be a real-time data visualization platform to use for monitoring statistics during and after the hackathon. But that’s another story that will be saved for nwHacks 2019.
Thank you for reading!
