Simon is an ultra-marathon runner who also happens to be blind. How did IBM engineers create an app to help him run solo? In celebration of International Day of Persons with Disabilities (IDPD) on December 3rd, Holly Cummins, technical lead for the IBM BlueMix Garage in London, shares her experience working with Simon to create an app that helped overcome his challenge to do what he loves – running.
By Holly Cummins
I’m a developer in IBM’s London Bluemix Garage, one of IBM’s innovation hubs (although definitely not the only one!). One of the things I love about working in the Garage is the surprising projects which cross our threshold, each one opening my eyes to a previously hidden world.
I’ve learned a lot about weight management, youth work, artificial intelligence, and lorry driving, but I’ve never worked on an app quite like the one the Garage is writing for Simon Wheatcroft. Simon is an ultra-marathon runner, who also happens to be blind. This is a pretty enormous achievement in itself, but Simon also runs solo.
At walking-speeds, Simon relies on his adorable guide dog, Ascot, but Ascot doesn’t really do huge distances at high speeds. This is where technology comes in. Simon uses the Runkeeper app (running on IBM Cloud) to track how far he’s run, and that allows him to know where he is relative to memorised landmarks.
Of course, on an ultra-marathon course, there are a lot of landmarks to memorize. And even the most committed runners don’t run the same ultra-marathon course over and over again for memorization purposes. What Simon needed is something that did satellite navigation, but with a user interface more like a car’s parking sensor. This is what the London Bluemix Garage wrote for Simon. We’ve named the app eAscot, after Simon’s guide dog.
The Importance of the User
We invited Simon into the Garage for a design workshop. All of us definitely had our horizons broadened about physical and mental endurance required to run an ultra-marathon – I wasn’t the only one wincing when the conversation turned to shredded feet, insects, and vomiting.
As engineers, our natural tendency is to write an algorithm direct Simon along the optimum route. After all, why would he want to go along a non-optimal route? It turns out there are good reasons – Simon’s a person, not a robot, and running in the desert is hard. As well as being physically draining, running in such tough conditions is mentally draining. This means Simon wants to focus on what’s really important, which is putting one step in front of the other, instead of always thinking about fine-tuning his course. So we designed the app to not be picky about small course deviations.
Another area where our assumptions about what would work best for the user turned out to be wrong was the user interface. In order to avoid over-loading Simon, the interface needs to be aurally lightweight, and that means short beeps instead of long strings of synthesised speech. Simon also needed the interface to be hallucination-proof, which is a definite first for all of us in the Garage. He was sure that he was less likely to hallucinate beeps than voices, although I have to confess the Garage never did figure out how to test hallucination-resistance to see if he was right.
Normally, the applications we design are beautiful. For Simon, we knew he cared about how the app sounded, not how it looked, so we made a simple, accessible, interface, and then focussed our design efforts on the sound interface. The app isn’t especially pretty (as the screenshot below shows), but the listening experience is great!
Testing and Continuous Deployment in the Desert
A core part of the Bluemix Garage method is constant feedback. In terms of programming, this means test-driven development, and in terms of our broader development process, it means continuous deployment and user feedback as often as we can get it. We’ve got a lot of unit tests, especially for the navigation algorithms, we’ve been using the eAscot app when we walk places, we’ve been using eAscot to guide us on our runs, and Simon’s been using eAscot on his walks and runs. Simon also ran the Boston marathon, which was a great opportunity to try out eAscot on a longer run.
There are some things we just can’t cover, though, with automated testing, testing in England, or testing in a crowded urban marathon. How does the app work on a course which is utterly unfamiliar? How does it work in a lonely place? What’s the user interface like when you have blisters and dehydration-sickness?
Continuous deployment in the desert was also a huge challenge for us. Well, actually, it was more than a challenge, it was flat out impossible. The industry is moving to continuous delivery, and with good reasons – it’s more efficient, better for developers, better for customers, and better for quality. Our normal model is to make a series of fine adjustments to deployed applications in response to feedback. However, there’s no data connectivity in the Namib desert; we couldn’t push out any changes, and the app couldn’t give us any updates about how it was doing.
The connection between design, development, and the user is a core part of what we do in the Garage. In this case, what the user is doing is pretty amazing, and the help our app gives isn’t just business-critical, it’s life-critical. I’d be lying if I said I wasn’t a bit nervous before he headed off to the desert. I’m proud at the part my colleagues and I are playing in stretching the limits of human achievement.
Holly Cummins is the technical lead of IBM’s Bluemix Garage London, and the former delivery lead for the WebSphere Liberty Profile. She is a co-author of Enterprise OSGi in Action and has spoken at JavaOne, Devoxx, JavaZone, The ServerSide Java Symposium, JAX London, GeeCon, and the Great Indian Developer Summit, as well as a number of user groups. Outside of her work at the Garage, Holly enjoys, cake engineering (“baking”), running, and sewing.
This article first came out on the IBM Cloud blog.
Discover what you can do at IBM: http://ibm.co/jobs