Debugging a 75 year old
My father has been a computer user since the early 1980’s and a Mac user for about 2 years. Recently he sent me the following support email:
How to access CDROM ?
Yesterday one disc automatically came out – I pushed it back and it seems to have dropped deep inside the computer
My father uses an iMac G5 with a slot loading CD drive. My initial reaction was amazement that he had gone 2 years without hitting this problem before. It reminded my of a number of issues that he has had over the years that have always been quite fascinating to resolve. My father is an intelligent 75 year old man who can do things with Excel that make my head hurt. Yet there are things that I find easy, “intuitive”, that he has problems with.
PEBKAC
When IT people handle support requests, a lot of the issues are put down to PEBKAC – Problem Exists Between Keyboard And Chair. In other words it is too easy to assume users are not computer literate or are just plain stupid. Once, our brightest user phoned up saying he could not log in to our system and it turned out he had left the CAPS LOCK on. If our most intelligent users can fall prey to such simple mistakes, PEBKAC cannot be the issue. Apple and Microsoft have both tackled the Caps Lock key issue, which shows how these issues can actually be resolved by better user interaction design.
At Apple’s developer conference, John Geleynse, Apple’s User Experience Evangelist, always gives a talk on user interface design. Year after year he presses home the need to understand the user’s “Mental Model”. But this issue goes beyond even the topics John covers in his annual sessions.
My father mentioned that he was used to a physical eject key on the CD-ROM drive. I realised that the Mac’s solution is pretty poor as both the software button in the Finder and the button on the keyboard, whilst easy to access, are both located quite far away from the actual drive. This is a failure to apply the Proximity principle of good design. Of course the current method is still far more sensible than dragging the disk to the Trash.
He also complained that his address labels were no longer printing out correctly and in this case he had in fact been using different sized labels. What was fascinating was the Excel spreadsheet that he used to print his labels. He had adjusted row heights and column widths to represent each label and surrounded each label cell with narrow cells as margins. It was clearly a painstaking effort on his part. I was about to adjust his spreadsheet for the labels he was now using, when he opened up another one that worked perfectly. I considered telling him about Word Label Printing in combination with Mail Merge but concluded he would be more comfortable with the solution he was familiar with.
Again I have often come across intelligent users who have come up with cunning, but fragile, solutions where full solutions already exist. They were unaware of these solutions, that may well have been intuitive and easy to use, but their actual existence was not obvious.
Conclusion
These issues highlight that the problem is not stupid users but stupid user interaction design. All too often as developers we marvel at how users do not understand how the application works. Yet the issue is that we are too familiar with the application to appreciate what it feels like to be inexperienced with it. It is precisely those support issues that strike us a stupid that we should examine the most closely for opportunities to improve the user interaction of our applications. The problems do indeed exist between the keyboard and chair but not those of the users but of the developers.
August 1st, 2007 at 2:44 am
Well said! Often, I’ve been faced with situations where, during testing or production use, the user has come across an issue and my immediate reaction is to dismiss it. When I catch myself doing this, I do my best to sit back in the chair, take my hands off the keyboard and my eyes off the monitor. I try to visualize what the ideal solution would be. I may not have enough time to actually execute the solution due to complex technical issues but it is well worth the 5 to 10 minutes of thought so that, when I have the time or resources, I’ll have a plan. Often, the result is a better understanding, refinement and simplification of the software in places that I would have never expected.
November 1st, 2007 at 6:17 pm
[...] A phrase I often used in the early days of my career was “Problem Exists between Keyboard and Chair”, to imply that a user with a support issue was either stupid or did not understand how the software worked. Inexperienced developers often believe that they have found a bug in the underlying system, when the reality is that 99% of the time, the problem lies in their own code. Similarly even experienced IT staff often assume the problem lies with their users when it comes to support issues, when usually the app should be improved to be less confusing. I covered this in depth in an earlier post. [...]