Wednesday, October 13, 2010

Error handling: Could do better...

I downloaded a new game on my iPhone today - Cut the Rope. I thought my daughter would like to play it on her iPhone, so I decided to copy it from my phone to hers. This is a 2-step process for iPhones, using iTunes. Step 1 was to synchronise my phone with iTunes to upload the game into iTunes. Step 2 was to synchronise her phone with iTunes to download the game onto her phone.

Once my phone was connected and had been detected, I noticed that iTunes thought my phone was full, even though I knew it wasn't. The graphic representing the phone's memory usage showed much more memory being used by apps than I knew was actually being used. Unchecking an app restored it to where it was supposed to be until I pressed the sync button, when it jumped back up to nearly full again.

A quick bit of Googling revealed this to be quite common. The consensus was that the data associated with one (or more) of my apps was corrupt. There was no indication in iTunes that this was the case, or which app (or apps) might be affected. Common sense suggested that the last one added, or the last one used, would be the culprit, but removing and then re-adding these made no difference. So I had to go through all of my apps, one at a time, until the problem went away.

Ok, so I got everything back to normal, and this made me happy. At the same time I was unhappy because I lost the data associated with the apps that I had uninstalled/reinstalled. Also, what I did was not a proper fix - all I did was uninstall/reinstall apps to make the problem go away. I had no idea what the problem was nor what I could have done differently to avoid the same problem in the future.

Software developers around the world are increasingly taking the usability of their products much more seriously these days. Modern software development paradigms pay a lot more attention to what their users want, and how they're going to use the software. A lot of effort goes into designing user interfaces.

It could be argued that Apple are particularly good at this, especially with the iPhone and iPad. Not only are they intuitive and easy to use, they are also stylish and, dare I say it, sexy.

But what this little incident has made me realise is that all of this effort is going into making what I call the "positive" user stories work. Less thought seems to be going into the "negative" user stories - typically when things go wrong.

As a user, I don't want the products I buy to go wrong. I want them to intervene when things don't work, or are wrong, or don't look right, and to try to put them right. If they can't, I want a message in a language I can understand explaining what's wrong, and what I can do to fix it. What the hell, for example, am I supposed to do with an ArrayIndexOutOfBoundsException or with a NullPointerException? No idea, do you?

So come on software developers, think about how users are going to use your product AND how they're going to deal with any errors you're going to throw at them. I would argue that it's even more important to get usability right when things are going wrong than when things are going right because that's when user's are going to be less tolerant.

Incidentally, I did eventually get the game installed on my daughter's phone, and she loved it. Getting her to stop playing it and go to sleep was a different problem.

Nos da.

No comments:

Post a Comment