01 October 2006


Reinforcing usability

As promised, a followup to my post about usability from last week. Having gotten even more vague thoughts, I will cover more than usability alone - although, one can consider everything that has to do with user interaction, to be part of usability.
First an anecdote that I didn't write down earlier. The coffee at aKademy was served as hot water and small sticks of instant coffee (image). To help people on how to open those sticks (you could not tear just somewhere), they had a large arrow at one end, over the entire width of the stick, with the text "tear here". Of course, everyone tried tearing in the direction of the arrow... But no, you had to start tearing where the arrow pointed at. Is this us being techies, or do "normal" people have the same problem?
Which leads me to the following. Traditionally, techies have formed the core group of KDE and other similar projects. Even most people that contribute in other ways than coding, have had some sort of a technical education, meaning that they all have a partially common mindset. Especially since most contributors have a quite tight connection to some others, ideas and terminology cross over very easily. On the other hand, our users, even if it has been decided that the most important target group for KDE is people that have at least some knowledge of computers, will not. So if we go and design, create, and document our program the way we consider it fine and "usable", there might very well be a gap.
Luckily, we have the usability and HCI people to save the world :) Seriously though, I have been spent part of my time at aKademy reading up on usability stuff and that led me to think about how user documentation and program usability are connected. There are a few areas where those two fields intersect or should complement each other.
If someone starts using a program, he will want documentation to find out the basics and follow some examples on how to use it. When he's been using it for a while, he has become more acquainted with its features and will want to read up on how to get the maximum out of the tool. So, documentation should provide information on different levels. Another thing (thanks to Ellen for coming up with this one) is the "What's This" help, which is available in a number of program dialogues by right-clicking on a UI item. This is basically a quick help text - why not make that text include a link to the full documentation, which ought to describe the option anyway?
So many thoughts, so many ideas everyone has, so little time.

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?