making assistive technology devices

Making assistive technology

This post presents a few of the lessons that I have learned from building assistive technology projects over the last few years. This is so that others may avoid some of the mistakes I made. Comments are welcome.

Summary

Work back from what you want the end-user’s experience to be and choose the technology accordingly.

Define what success looks like

The currency of success in academic is publication. This brings closure to a project and passes on some of the lessons learned.

Building something to be used in the Real World, outside of academia, is a different level of Pain. Instead of a prototype fit for doing a few user studies, we need a fully working and dependable device which is safe to leave with the end users. We need to supply documentation and the other resources needed to get the device working and to maintain it. You don’t receive much credit for this in academia.

Are you cherry-picking the technology?

Have a look at the Gartner Hype Cycle:

Getting to the ‘Plateau of Productivity’ - the real world - entails crossing the ‘Trough of Disillusionment’. I call this the ‘Valley of Despair’.

For example, I tried to use a camera based game controller, the Microsoft Kinect as assistive technology by recognising hand motion. I tested my idea with several wheel chair users. The device would not build a skeleton model of somebody in a wheel chair due to the occlusion caused by communication devices mounted on the front of the wheel chairs. It didn’t matter how good or how bad my code was, the underlying firmware/software was not able to cope with my user group.

Similarly, I tried to use a hand tracking device, the Leap Motion to identify hand motion. This would not reliably track the motion characteristics of the user group I was working with.

Academic papers flooded the Computer Human Interaction field based on user interactions with the Microsoft Kinect when this device first came out. It sat on the Peak of Inflated Expectations. I couldn’t get to the Plateau of Productivity with the technology.

Instead of using tried and tested technologies, I went for the latest and greatest new technologies. Often it takes a few years for the limitations of a new technology to become widely known and the bugs in the supplied supporting software to be identified and fixed.

Ultimately I succeeded with the project by using simpler technology: handshake

Make a presentable device

I was advised at the start of my attempts to create assistive technology that nobody wants to wear an ugly kludge. Everybody wants to use something that looks good. This idea is expanded in the book Design Meets Disability.

I found an off-the-shelf arm band holder some of my micro:bit based projects. I did make one myself, but the store bought model looks better.

I made a real kludge of an ugly prototype for a flex-sensor based project. It was ugly! So I spent some happy hours with a 3D printer and openSCAD to make a case to put it all in. Far from perfect, but a lot better than it started out.

Test early, test ugly

This is in direct conflict with the previous paragraph! We need to identify as quickly as practical if an idea is worth pursuing. Spend time testing prototypes with the end user. It can be difficult to get time with the end users. It can be difficult to venture out of the comfortable bubble of the labs many of us work in. However, it is the only way to know if we are progressing.

I would have saved time with the Kinect based project if I had tested earlier. But I wanted to showcase a wonderfully interactive user experience I built using the latest and greatest Microsoft toolkit.

So how do we square these two contradictory requirements? If we know that the prototype is just that - only for testing - and we are sure that we will retain posession, then we can lean towards the ugly end of the spectrum. Especially if we are not testing with the intended end-users. I had one prototype taken away by a test subject as she was so pleased with the idea! Luckily, in this case, the device was a single micro:bit and I had put it in an off-the-shelf case for testing, so I was happy to see it used. This was for this project.

Documentation

Naively, I thought that if anybody showed an interest in my projects, I would then blaze into a frenzy of writing and produce detailed instructions to enable them to implement the project. Wrong. Nobody is going to beat a path to your door on the faint promise of something that looks good on a video or your website. We need detailed ‘how-to’ guides, preferably including videos to enable somebody who does not have a background with technology to painlessly implement our ideas. Documentation and videos take a lot of time to produce.

I use mkdocs for creating documentation and host the output on my GitHub site.

The software packages I use for creating videos are:

kdenlive for editing video.

audacity for recording and editing audio.

Many projects fail

A project definitely fails if you don’t start it though. Knowing when to keep on plugging away and when to give up is a skill that I am still learning. This is where having good collaborators makes all the difference. Knowing ‘when to hold and when to fold’.