|
Unix Programming - Studying Cases - Case Study: kmail
kmail is the GUI mailreader
distributed with the KDE environment. The
kmail UI is tastefully and well designed,
with many good features including automatic display of enclosed images
in a MIME multipart and
support for PGP key encryption/decryption. It is friendly to
end-users — my beloved but nontechie wife uses and
enjoys it.
Many mail user agents make one gesture in the direction of
discoverability
by having a command that toggles display of all the mail headers,
as opposed to a select few like From and Subject. The UI of
kmail takes this a long step
further.
A running kmail displays status
notifications in a one-line subwindow at the bottom of its window, in
small type over a steel-gray background clearly modeled on the
Netscape/Mozilla status bar. When you open a mailbox, for example,
the status bar displays counts of total and unread messages. The
visual presentation is unobtrusive; it is easy to ignore the
notifications, but also easy to focus on them if you want to.
The kmail GUI is good user-interface
design. It's informative, but not distracting; it gets around the
reason we adduce in Chapter11 that the best policy for Unix tools
operating normally is usually silence. The authors showed excellent
taste in borrowing the look and feel of the browser status bar.
But the extent of the kmail
developers' tastefulness will not become clear until you have to
troubleshoot an installation that is having trouble sending mail. If
you watch closely during the send, you will observe that each line of
the SMTP transaction with the remote mail transport is echoed into the
kmail status bar as it happens.
The kmail developers neatly avoid a
trap that often makes GUI programs like
kmail a terrible pain in a troubleshooter's
fundament. Most design teams with kmail's objectives would have
suppressed those messages entirely, fearing that they would give Aunt
Tillie a touch of the vapors that would drive her back to the
meretricious pseudo-simplicity of a Windows box.
Instead, they designed for transparency — they made the
transaction messages show, but also made them visually easy to ignore.
By getting the presentation right, they managed to please both Aunt
Tillie and her geeky nephew Melvin who fixes her computer problems.
This was brilliant; it's a technique other GUI interfaces could and
should emulate.
Ultimately, of course, the visibility of those messages is good
for Aunt Tillie, because they mean Melvin is far less likely to throw
up his hands in frustration while trying to solve her email
problems.
The lesson here is clear. Dumbing down your UI is only the
half-smart thing to do. The really smart thing is to find a way
to leave the details accessible, but make them unobtrusive.
[an error occurred while processing this directive]
|
