My latest app project: 5K Race Timer

I happened to attend a meeting a little more than a month ago for the committee that organizes the Dragon Run. This is one of the school’s biggest events and requires quite a group of people to make happen. One of the biggest challenges that the group faces is the timing of the race and management of this data for the 120+ runners that participate in the official event.

The scheme used in previous years has been a very well thought out system of spotters with pencil and paper lists and a race timer placed at the finish line. When runners register, they give an estimated time for their run, which places them in a few different speed categories. Each spotter has a list of runner numbers from each category so that they are searching for particular runner numbers throughout the time span of the race. When a runner crosses, the spotter records the time on their sheet. This time is then later fed into a spreadsheet that gives everyone’s time. These results are then collated and printed to give the results list after the race.

I’m trying not to be a hammer looking for a nail here, but this seemed like a perfect opportunity to try to use the power of the computer to reduce some of the mental and paper load of this task. My learning obsession with Python web apps and even more recent desire to learn about databases quickly helped me see some easy ways to do this. These were the main points that I wanted as part of the UI:

• Upon seeing a runner approach the finish line, the spotter should be able to send a ‘stop’ command at the moment that runner crosses the line. Calculating the finish time relative to the start of the race and recording that information is screaming for a computer solution. This capitalizes on the human spotter’s ability for to recognize a runner’s number by sight, leaving the rest of the work to the program to do.
• We would need a simple interface for starting the race and stopping individual runners with a button press.
• A non-trivial number of runners register on the day of the race. There needs to be a way to manually add runners to the database easily.
• Mistakes also come up in recording times and entering data. Editing a runner’s information, including finish time, is a necessity.
• Manually entering all the runners into the database before the race? Heck no. The organizers use a spreadsheet to record all of the registration information, which is a CSV file asking to be made and inputted to the database automatically.
• Creating a list of runners based on category and ranked according to race finish time is another exhausting task when done purely by spreadsheet. This process in the program should make the most of SQL queries and Python/Bottle template features to generate the race results automatically.
• To properly see if this system would work, I’d need a way of showing numbers passing by similar to what actually happens during a race. I put together a Javascript simulator to do this using Raphael that can be found here. This was especially important in testing the system with my student volunteers.

The organizers agreed to let me run my software as a beta test to see if it would work for future years. More insight and conversation led to the idea of a mobile application to be used to enter runner numbers. I agreed that this would be an easier way to locate runners than looking down a list, but had no idea how to do this. I did research and figured out the jQuery Mobile would be the way to do it. This was a difficult learning process having never done this sort of thing before. I battled with the “ghost click” problem for a while until discovering that the ‘touchend’ event was an easy fix.

Here’s the software as used on race day:

• Running code at http://timekeeper.evanweinberg.org
• Try the mobile app on your mobile device at http://timekeeper.evanweinberg.org/mobile/
• Code source at Github is here.

UPDATE Mar. 2016: I’ve taken down the site to save some memory on my server. Write me if you are interested in the details.

The system worked really well, but ran into some of the same challenges that the pencil-and-paper spotters have been battling since the event’s inception. It’s really hard to simultaneously grab the numbers of a group of 4-5 runners that all come in at once. The system that my students devised for identifying who was going to enter a particular runner approaching the finish line broke down in two specific instances of this, and we missed runners. Luckily pencil and paper picked up the ones we missed. Definitely still in beta. The process of generating results lists and recording times overall worked quite smoothly, and I’m really happy with how it turned out.

Notes:

• Bottle, Twitter Bootstrap, jQuery Mobile, and vanilla Javascript were all in play.
• I learned at the race that there are already software packages out there. Now that I’ve done a quick search, it seems that while there is a lot of software out there, the ease of running it through a web interface (and snagging runners through a mobile interface) is a relatively young feature. This project was about me learning to do some new things, and in the end it cost me (and the school) nothing other than time.
• I learned a lot about user centered design through this project. Usability was a necessity, so I had to start from there and work backwards to build the code needed to make it happen. I really like thinking this way,