Community

How the Bluemix Garage is helping a blind athlete run marathons – solo

Share this post:

Follow Simon

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.

Ascot 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.

Discussion in the London Garage 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

Screenshot of the eAscot applicationA 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.

Epilogue

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.

Resources

More Community stories
August 3, 2018

Five Exciting Things About Istio v1.0

Istio, an open platform to connect, secure, control, and observe microservices, was launched on May 24, 2017, with joint force by IBM, Google, and Lyft. Over the last year, numerous new features and improvements have been made to get to the current production-ready version 1.0.

Continue reading

July 18, 2018

Part III: Wimbledon Facebook Bot on IBM Cloud

Delivering at scale: In the final part of the series, we discuss integrations with on-site systems at the All England Club and how we used Multi-Region within IBM Cloud to ensure scale and availability.

Continue reading

July 12, 2018

Db2 on Cloud Announces Disaster Recovery Node

The Db2 on Cloud team is excited to announce Disaster Recovery (DR) capabilities for Db2 on Cloud. It leverages Db2's HADR technology and lets users add a DR Node on demand in an offsite data center of their choice. In an unlikely event where the primary data server is affected by external circumstances, such as a natural disaster, users can failover to their Geo-Replicated Disaster Recovery Node with a few clicks.

Continue reading