To know is to understand, and many developers don't

THE VIEW FROM INSIDE
By Walter R. Houser

I can't imagine that developers say to one another: "Let's write some unusable
software today." Yet some things go awry--I know because I've seen a lot of
unfriendly applications. So, trying to make up for poor usability, software developers
substitute more training and documentation.

At a recent National Institute of Standards and Technology symposium on software
usability, I was sobered to discover that usability advocates actually have to market the
concept of usability to management.

Perhaps I was naive, but I thought usability should be a primary design criteria, not
just a desirable feature that must be justified before it's considered in a procurement.
But in light of the dismal performance of many software developers in meeting customer
needs, perhaps I should not be surprised.

What does usable software look like? According to Virginia Tech's Rex Hartson, it is
first of all understandable. I find the term "understandable" insufficient on
its own.

For me, understandable means the software's user interface draws upon life experience
to suggest how it should be employed. The classic example is the famous trash can on the
Apple Macintosh screen. It is no mystery what will happen to files when you drag and drop
them into the trash can.

Although they are less intuitive, the Microsoft Windows applications build on past
experience by reusing icons and pull-down menu options. To let you know what an icon
means, verbal cues appear when you drag the cursor across the button.

Hartson also cites user task performance speed, error rate, program knowledge retention
and satisfaction as characteristics of usability. Performance, errors and retention can be
quantified. But satisfaction, like the concept of economic utility, is hard to quantify.

At best, we can compare satisfaction derived from two software packages. But we can not
determine some absolute measure of goodness or utility that one gets from a specific
software program. Developers strive to improve customer satisfaction, and customers push
up the ante by raising their expectations of software performance.

To illustrate: John Junod's WS_FTP program is free to government and individuals for
non-commercial use. Microsoft's FTP client is included in the price of Microsoft Windows
NT. Both move files across TCP/IP networks, but user satisfaction differs dramatically.
Reminiscent of the Windows File Manager, WS_FTP uses Microsoft's own point-and-click
technology. Until Windows 95 arrived, the Microsoft FTP client employed a command line
interface only a Unix dweeb could love.

An application that shares the look and feel of the other applications on a given
platform will have the advantage of understandability. That understandability leads to
better performance, accuracy, retention and comfort on the part of the user. If the
application behaves completely unlike other applications on the same platform, it fails to
build on the human capital the customer has invested in that platform.

Because it required an understanding of the File Transfer Protocol command language,
the old Microsoft FTP client was not very usable from the perspective of MS-DOS and
Windows customers. But the eminently usable WS_FTP may lose some ground now to NetTerm.

NetTerm is a Windows telnet client that lets users copy and edit Unix files on a PC,
sparing the PC users from the tribulations of VI and other Unix file editors. The VI
editor may have its rabid fans, but frankly I'd prefer dental work without painkillers to
a bout with VI. I never can remember the commands. I get confused about VI's edit and
insert modes.

In stark contrast, NetTerm lets you edit a file without downloading it to the PC,
causing a change in file permissions. Why bounce back and forth between telnet and FTP
clients when one program does both smoothly?

As the great Yogi (Berra, that is) said, "You can see a lot by looking."
Usable software is the result of careful observation and deep insight into the
responsibilities and processes of the solution being automated.

The good software developer is close to the customer, not the specification. The good
developer pays attention to work patterns and rhythms--not only what the tasks are, but
also in what sequence they are performed. The good developer performs the tasks side by
side with other users to acquire a physical and psychological imprint of what needs to be
done, as well as redone.

To get WS_FTP, NetTerm and other outstanding Windows Internet applications, visit
Stroud's Consummate Winsock Applications Web Page at http://cws.wilmington.net/
  To get on the usability bandwagon, send e-mail to NIST's Laura Downey at laura.downey@nist.gov.  (Now that is
a usable e-mail address. And of course, it is an Internet, not X.400, address.)

Walter R. Houser, who has more than two decades of experience in federal
information management, is webmaster for a Cabinet agency. His own Web home page is at http://www.//cpcug.org/user/houser/.