May 12, 2016 | Written by: Holly Cummins
Categorized: Community | Garage
Share this post:
I’m a developer in IBM’s London Bluemix Garage. The Bluemix Garage is one of IBM’s innovation hubs (although definitely not the only one!). One of the thing 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 memorisation-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 is writing 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.
At the time of writing, the race is still ongoing, and our whole team has been glued to updates from the race organisers. They’ve mentioned Simon in their reports on stages 1 and 3, and confirmed that the technology is working well for him (there was a bit of arm waving in the garage at that point). We’ve just now been updated that after twenty-six hours of running across during which he covered almost four marathons’ distance, Simon was pulled out of stage 4 of the race by paramedics because of difficult terrain and heat. His achievement is incredible – he’s run distances most of us couldn’t contemplate, in conditions most of us couldn’t bear, without being able to see where he’s going, and without a human guide. Simon’s grit and technological vision is an inspiration to us all.