This bit of observation put me in mind of the toughest challenge we face as software developers, i.e. how to convey failure.
Toddlers get difference between faulty hardware, operator error
Development focuses on how software works, not on how it doesn’t work. Therefore, error handling and messaging never get the attention they require.
Add to that the fact that the set of what users will try to do to your software has nearly infinite members, and you’ve got a major problem on your hands.
Tons of usage studies show us that people using computers nearly always blame themselves first.
Think about your own behavior. When you encounter an error or silent failure, you always try again, probably multiple times before you accept that the system is at fault.
The problem is that we don’t design for failure very well because it’s practically impossible.
Strange that conceptually, at a very early age, most humans understand the differences between operator error and system failure, but those skills generally fail when applied to software.
Thoughts?
Couldn’t agree more. Exception handling just doesn’t get the design and development exposure it deserves. Error messages are continually up there on list of customer complaints, but the complaints are decontextualized from why these errors occur in the first place and how users really want to recover from them or seek help around them (fixing it themselves, reaching out to others, or contacting the help desk). Usually, messages are discussed at the level of writing text – completely wrong place to start. I discussed this at my session at UA Europe: http://blogs.oracle.com/userassistance/entry/brighton_rocks
Realistically though we’ll never see error messages demo’ed on OOW keynotes…:)
Useful failure handling creates longterm users. I’ve always thought failure handling was an area ripe for innovation and ready for the taking. It’s like ops, you need it, it has to be awesome, but no one wants to do it.
About a million years ago I was forced to do quite a bit of database unit testing.
That taught me a lot about exceptions.
I had a point, but it has escaped me.
Maybe it has to do with (at least from my database perspective), error handling is a lost or non-existent art.
Handling exceptions should be a specialty vs. something handled by traditional development bc it requires different skills from test cases, to execution and error writing. It’s an area ripe for innovation, unsexy but totally worth the investment from a customer happiness perspective.