A Reflection of 2024's Registration Technology
- 35 min read - Text Only- Let's talk about the money
- Vendor sign-ups
- Volunteer timekeeping
- Badge rangers
- Check-in process mishap
- Parent- and kid-in-tow Badges
- Internet for swag and security
- Product configuration
- Payment processing
- Payment failures
- Unit testing
- Scanners
- The new frontend
- Lost badge tracking
- Upgrades and reprints
- Scanner lookup
- Overall
This year's tech updates made a huge difference for staff as they ran FurSquared this year. Attendees and staff benefited from a unified and holistic platform that served the lifecycle of the convention. From attendee registration to vendor onboarding, swag distribution, and volunteer time keeping, FurSquared's technology platform is maturing in running a smooth and successful convention.
That said, there are and will always be areas of improvement to act on, especially as conventions are fated to grow exponentially and the growing scale creates even more problems. The scope of this technology has grown and will continue to grow over time to meet the needs of this and possibly more conventions in the future.
There will be exceptions to this! For example, there are many capable programming and events solutions like pretalx, which can be self-hosted. For me and those that work with me, we will have a far greater impact by contributing elsewhere.
A retrospective is appropriate to decide what we will work on next, and that starts with pointing out all the things that went wrong.
Let's talk about the money
I've hinted at cash being a flop earlier. It did work, just not as well as I had hoped. The registration form worked really well! However, cash payments flopped for a different reason.
Here's the critical design flaw with cash: A cash transaction would happen first, and then they got a QR code for a partially completed form, they would then fill out the form, and then they'd wait for their badge to print.
First, it turns out that not everyone knows how to scan a QR code. They are not accessible enough for less tech-literate folks to use.
Second, some attendees used third-party QR code scanner apps that open web pages inside the scanner app. It then injected ads into the web page. This breaks a lot of things, including date inputs of all things.
Third, some do not have a phone or do not wish to use their phone.
We got a laptop for these cases! However, we had no physical space or table to set it up outside for this audience to use, nor staff to assist if help is needed. Hopefully, that will change next year.
Fourth, it did not solve the problem where people in the cash line were blocked by the person ahead of them.
I had hoped that the registration lead handling cash would tell those filling out the form to stand to the side while they handle the next person, and when their badge is printed, they cut to the front to pick it up. This was too complicated for an already-taxed registration lead to do, and the QR code process was too confusing and problem-prone to the point where the registration lead had to be on standby for support.
Those using cash have a variety of circumstances and they need more support than the rest. We should support them just as well as those that have a credit card.
At least, we no longer had to use cash receipt books with copy paper. The thermal printers are here to stay!
Vendor sign-ups
A highlight of just about every furry convention is a curated group of vendors on site. Often called "Dealers' Den" on site, the convention hosts approved vendors at the convention for a fee.
Vendors finalized their application by paying a fee through the registration platform. That part worked great! The whole process in front of where I came in is where we had problems.
Vendors must submit information on their wares, provide a tax identifier, branding, and an example image of how they would set up their spot for a single table. This goes through a Google Form, which ends up in a Google Sheet.
Staff then filter out drop shippers and vendors that are not tied to the furry fandom, like "locally roasted" coffee beans. Following that, merchants are grouped into types, and we typically try to have a fair variety of merchandise types sold in the vendor space.
For example, if everyone accepted sold pre-made tails, hardly any merchants would have a satisfactory outcome of vending there as there is too much competition. So, we aim to have things like posters, books, leather gear, dragons, body pillows, plushies, and all sorts of things too. Past success will also affect whether someone can get in, as we do wish to have some new vendors each year too.
Once a primary and standby list is prepared, staff use the registration platform to send invites to approved dealers. From that point on, insofar as technology goes, the process is quite smooth as I've had a hand in its design.
The last two years have been messy once an application gets in. Very messy.
Through the built-in version history in Google Sheets, we have found that mistakes were made in filtering out applications. Destructive copy-pasting led to vendors having their data mixed over one another, leading to vendors being assigned the Night Market instead of the Weekend Dealers event.
After some turmoil and turnover before the convention, we had to collect tax information again from everybody that was approved and manually re-enter it on more than thirty entries. Those that got accepted and paid for the wrong vending type had to be prioritized ahead of the standby list. Again, we could not sell space that did not exist.
We need to do better. It should not be possible to mix or overwrite vendor information. The process of filtering vendors must be ergonomic and should have a clear auditable event as to why the filter was performed. It should be straight forward to label and group vendors by the type of merchandise they are carrying. Staff should have a structured workflow in processing vendors and advancing them to the payment process.
Volunteer timekeeping
The fact that we are recording the hours in the registration platform and it ties into swag distribution is amazing. And I managed that in only thirteen hours.
It could be better in several ways.
The interface was a quick and dirty Django admin form.
While it got the job done, it could be more ergonomic.
That's just the end of the story. What about the rest of it?
The convention lifecycle for volunteer work is entirely in someone's head and only written on paper at the very end before being committed to the form shown above.
I was too tired on Saturday to make competent analytical decisions. The same could be said for the volunteers lead who assigned an accessible needs individual to a role without accommodations to be successful. Given the mentally exhausted nature of operating a convention, I have to wonder, would more structure be helpful here?
Could departments signal they need volunteers in a structured way, which could then be sent to volunteers interactively? Such requests could be claimed by volunteers through Telegram and then timestamped and signed off by staff.
This could eliminate the paper form in the middle, lighten the load on the volunteers leads, and even offer a chance to game-ify the volunteer rewards system. The moment someone's time counts over the minimum to get a shirt, they could just go and get one.
If we had an interactive channel like this in place, volunteers could even get reminded to go pick up their shirt before the convention is over! We missed out on giving out what people have earned at the convention. Automation like this may be the way forward.
Remember that not-so-ergonomic form above? With an interactive system described above, we could avoid making another custom administrative interface.
Badge rangers
In 2023, I introduced a pre-printing process. By printing all pre-registered attendees before we opened to attendees, and by automatically printing badges as soon as a purchase was confirmed, we circumvented the most blocking process in the registration line. Asynchronous printing allowed us to have more check-in stations than printers and eliminated our contention on printers at our current scale.
Pre-printing is optimal as long as the time it takes to find a badge is shorter than the average duration it takes to print it on demand.
Badge rangers are critical to the pre-printing process, as they allow the operators to remain fixed in place while they move in to capture the card from inventory and deliver it to the operator just as they finish checking the attendee's identification. They also hole punch the badges fresh from the printer and sort it into inventory.
With four operators and two badge rangers stuffed into the size of two cubicles and the noise of one hundred people nearby, it becomes very difficult for badge rangers to hear and confirm which badge the operator requested.
If we can overcome the need for verbal communication, we can shrink the latency on badge fetching during peak times and make this role accessible for volunteers and staff with hearing disabilities.
Check-in process mishap
A risk comes with pre-printing. Badges can leave inventory without being marked as picked up. The check-in frontend lacks a safe means to change from the badge confirmation view to the badge look-up view.
One staff member was not marking badges as handed out and would close out the badge confirmation view without confirming it.
This happened for two reasons. First, there was not adequate training on how to use this software. A printed reference book was prepared, but not used by staff who needed it. Second, there was no friction in switching states without confirming that a badge was not handed out. Third, the flat POS-like design made it unclear what was a button and what was a status indicator.
The check-in software needs to double check actions like this, where a badge can be handed out without recording it as such. It should also be more ergonomic in clearly identifying buttons. We should switch training from a written format to a visual demonstration that can be consumed in two minutes or less.
Parent- and kid-in-tow Badges
We offer two kid-in-tow badges per attendee for children 12 and under, as well as badges for parents who are there to accompany a minor who is registered.
Like volunteer timekeeping, to print these, staff used a Django admin form to fill in the information and then an action dropdown to print them. It was un-ergonomic and required staff to use the browser back button to find and access this functionality.
While parents were understanding, as their children tried to think up a name to put on their badge, the confusion from staff on how to proceed was less than spectacular.
Staff had to go through a dropdown list of all the attendees when creating these badges.
It would be best if these linked badges could be created from the same check-in screen staff were familiar with. It would even get the benefit of having an automatic association with at least one attendee.
This software has to work with minimally trained staff who are sleep deprived. That is only possible if the software clearly shows what affordances (archived) it has to offer. Good UI design is critical to pulling this off.
It would also be nice if parents could fill out a parent-in-tow badge or kid-in-tow badge during the registration process.
Internet for swag and security
We distributed "swag" rewards, such as t-shirts, posters, bags, briefcases, cups, etc. to those with higher registration purchases.
These tables were a distance away and could not use the wired network we had from the convention.
During the convention, the hotel's customer-facing free-WiFi went out of service for a few hours.
I had to set up my second phone as a hotspot to keep the swag distribution going for a few hours. Security was also not able to access the registration portal during this time. Meanwhile, the hotel's internal internet continued to function for registration in the registration room.
Next year, we need a way to extend network access from registration to swag distribution and security.
Product configuration
One move from 2023 to 2024 was to separate pricing from the registration level and to have a unified product model for what could be purchased, when, and for what price.
After all this configuration, there was no proper way to preview the active configuration at a specific date and time.
Upgrades made it more complicated too. I essentially had to run this script manually and then maintain all the data afterwards, twice. One for pre-con pricing and one for during-con pricing.
for (const level in registrationLevels) {
for (const higherLevel in registrationLevels
.filter(l => l.baseCost > level.baseCost)
) {
createUpgradeProduct(
level, // from
higherLevel, // to
higherLevel.baseCost - level.baseCost
);
}
}Next year's product configuration should be simpler to enter and maintain. It should be accessible to preview for sign off by leadership. Pricing should be something I can delegate to someone else.
Payment processing
This is more of an internal thing. There are four code paths for processing payments which realize the effects that are being paid for.
- Registration for attendees, staff, etc.
- Vendor spot fee
- Upgrading registration for one individual
- Invoice workarounds
As mentioned, I needed a workaround to upgrade vendors from Night Market to Weekend Dealers. I restored the existing invoice system to support this. When a payment is received for an invoice, it would apply the new registration level or vendor type to the attendee that paid. It was also shoehorned into the upgrade flow for attendees, which made it even more awkward.
With four payment flows comes a lot of code duplication. Now that the payment needs and effects are well understood, it should be unified. This would enable us to take registration and vendor spot fees in one transaction too.
Payment failures
Some attendees had cards with banks that refused to authorize a transaction with us. Whether Apple Pay, direct card entry, or through Link, their card would not work.
Upon the page reloading once the transaction is declined, it failed to rehydrate some information in the form. It might have been the badge name or something like that. The required information blocked the form from resubmitting and the attendee had to go back and refill the form.
This was frustrating for them, and it got to the point where staff thought they were being gaslit too.
When in fact, the banks gaslight us in the error codes they give. Wrong CVC? Wrong Zip Code? It could be entirely all correct, so they try again and again, only to be told something that isn't true.
It may be better if the description read as "The bank declined this transaction."
Unit testing
There was none! End-to-end tests are there for all attendee-centric flows and functionality, but none for the various kinds of configuration or administrative flows outside the scope of the next convention.
We absolutely need unit tests for payment processing, payment failures, and so on.
Scanners
We ordered a bunch of DS4208-DL scanners from eBay. There are many DS4208 scanners available for cheap as they are no longer supported.
eBay sellers would co-mingle DS4208-DL scanners with DS4208-SR (standard range) scanners. We did not have enough DS4208-DL scanners for the convention because of this. Security and vendors had the DS4208-SR scanners with the workaround configuration I made. This led to confusing events when they would scan driver's licenses printed outside of Wisconsin.
We need to get more scanners and make sure they are the correct model before the convention.
The new frontend
It is spaghetti.
I'm not all that great at frontend, and it shows. End-to-end testing helped me relax after concluding that the frontend is now hardly maintainable.
I can do server-side React to generate static pages. I can do a bit of client-side Angular to make pages interactive. What I can't seem to do well is make maintainable frontends with React.
Instead of using Redux or some other state management library, all data is stored in structures managed with react hooks. When needed, data is passed upwards with callback functions and passed downwards upon initialization. Registration is technically all one big React component. Upgrades and dealers' purchases are another big React component. And above that is my own home-grown routing component.
I like my applications to be lightweight. I do not want attendees to download a 1MB JS file to run our website.
It is arguably better than the multi-inheritance Django forms + jQuery HTML rewriting that happened in 2023 and prior.
The frontend could either be redone or have a blended backend plus frontend-as-needed scripts.
Lost badge tracking
There is no functionality to mark a badge as lost — only that a reprint was made. It should be feasible to record the original badge as lost, while the reprint remains valid. For example, lost badges should not be able to claim swag.
Each badge has a QR code encoded with a unique token to the registrant. This will have to change if we create a one-to-many relationship between registrants and badges.
Upgrades and reprints
Whenever someone upgrades after they receive their badge, a thermal ticket is printed with instructions on what to do when they return. These instructions were not followed, resulting in some upgraded attendees and staff running around with a badge with the reprint effect on it.
An upgrade should be treated with great care, they are after all funding next year's convention.
Like the other issues stemming from clerical ergonomics, reprints required staff to go through the Django admin forms.
It should be easier for staff to do the right thing with the interface they're already familiar with.
Similarly, for paid reprints, staff had to use the invoice workaround functionality to add an "Upgrade" option to the attendee's registration info page.
Like all other Django admin processes, it was not ergonomic. While instructions were in the on-site handbook, it was not referenced.
Issuing a reprint fee should also be available in the interface staff are already familiar with.
Scanner lookup
The average lookup time to process an attendee improved with driver's license scanning. However, by looking up by name and birth date, it introduces ambiguity in the lookup process.
Not everyone types their identifying legal name into registration exactly as it is written on their identification. Not everyone types their birth date correctly. There are people with the same name and the same birth date And some people come to the front of the line never having registered.
While making the check-in interface for 2023, I added a fallback mechanism for those without a QR code. A form with fields for badge number, first name, last name, and birth date would perform a search. If there was only one result, then it would transition to permit check in. Staff would enter just the birth date for the attendee to look them up.
This was adequate at a smaller scale. However, with growth, we run into the pigeonhole problem with birth dates.
The fuzzy search prioritized birth date, as names could be typed incorrectly by staff.
If someone had the same birth date as one other attendee and typed their name wrong online or never registered at all, then the other attendee would come up when searching their birth date in 2023. The same issue resurfaced in 2024, as the scanner integration merely filled out the fuzzy search form and submitted it automatically.
Staff were confused when a registration came up with conflicting details, as if the system were confident that it had found the right person. While no badges were handed out to the wrong attendee, the risk is too high for me to stomach.
If there is an exact match, it should proceed as it did before. If there are any details that differ, or there are more than one exact match, it should prompt for a review.
Overall
There is a lot of work to do… more work than can be done for next year by myself.
The above needs to be prioritized by when it will be most impactful. For example, it makes no sense to implement a solution for badge rangers until just before the convention. Helping vendors sounds like the first thing to do, given the complexity and its operations prior to the convention.
Cash has to be fixed before the convention. While we have less than 100 people that use cash, we need to do better on keeping the line flowing.
Volunteer time keeping could be solved this year or next year. The same goes for product configuration. The idea I have for volunteer time keeping would likely occupy someone's spare time for months. It isn't something I can prioritize right now.
A solution for badge rangers is necessary before the convention starts. The idea I have, which will be described in the next article, will be lightweight to do.
I doubt I'll get to redoing the payment flow or writing unit tests for everything. I also doubt that someone would want to volunteer just to unit test someone else's code.
The check-in interface must expand in features and safety. It may need to be re-thought entirely to be more ergonomic. This will likely take up the rest of my time.
We're quickly maturing a technology base in running a convention, and there is a lot of room to join in and contribute.
I am also researching for 2026 and beyond! Remember, scale is a problem, and we need a solution for when we break 3000 attendees. Details on my ideas for these issues and future research for scale are in the next and last article!