Usability and Software Fitness
Sun, 19 Aug 2001 00:45:57 -0500
So I've been having this ongoing debate with a old friend and ex-employee of
mine for years. This guy is a tremendously talented UI designer. Problem is,
he doesn't consider the context in which technology happens; the most
significant technologies in his life have been BeOS and the Newton. While I
admire those products on a technical front, this perspective is just maddening
to me, and yet it's common in our industry. The net effect of this perspective
is that our industry doesn't advance at nearly the rate that it could, at least
on some fronts. (On other fronts, it's clear that these "edge" things *do*
occasionally push the industry forward. Most often, though, they're lost in the
Anyway, I finally figured out that what *really* bugs me about this: while we
all consider "usability" of software from an ergonomics and aesthetics
perspective to be extremely important, few people consider the other qualities
that make a product "usable." It's a ridiculous and useless "l33t1st" attitude,
and it's a huge part of why much technology is and remains so difficult to use
for so many people: so much of our stuff is the result of geeks working in a
vacuum solve their own problems, rather than the problems of others that the
techies themselves sometimes create. And the cycle goes on, and on, and on...
Side note: I worry a bit that this is happening even now in the Web standards
arena, particularly in the XML space; I wonder if there isn't a serious gap
between the technology that's being created and its utility (even to other
developers!) in the marketplace. 80/20, you know? Hmmm...
I thought I'd forward a copy of this little mini-essay I wrote to my friend this
evening, see if anybody around here has comments. FoRK's been unnervingly calm
lately; maybe this'll stir the pot a little, maybe even in a useful fashion.
There's one thing that you and I can agree on: usability. It is or should be
the chief concern of all software development. Failure to design with the users
in mind is just engineering masturbation. Usability is good, it's necessary,
So here's where you and I differ: you think usability is all about UI. In
fact, you think it's mostly about aesthetics. I don't think it has much to do
with UI at all. In my mind, there are four primary drivers of usability:
(1) Release. If you don't release it, it can't be used by anybody at all.
(2) Relevance. If people don't really need it, it's irrelevant and doesn't
(3) Compatibility. If it's isolated from the other things people use, they
won't use it.
(4) Survivability. If you can't keep it going, it's not going to be used for
People don't buy / download / whatever software products; they develop
relationships with bundles of features that do something useful for them. The
four qualities above are necessary requirements for an application to be
"usable" in any lastingly meaningful way, and they generally have little to do
with technical decisions. Our chronic arguments are about just this; I believe
that even if you've got the prettiest UI, the fastest IO, the perfect API,
whatever --- even if you've got these things, your effort is meaningless (or
worse, a net negative to forward progress) unless people actually *use* your
stuff. If you're not improving peoples' lives significantly, you're wasting
resources (talent, time, money, mental bandwidth of other people, etc.) that
could better be used elsewhere.
Lots of companies fail on the "release" front. Further, it's not enough to just
get it out there; you've got to beat the other folks to the punch. Even if
you're delivering 100% and they're delivering only 80%, if they beat you to
market you've lost.
A few companies --- usually driven by egomaniacal, introspective, vain techies
--- fail on the relevance front. I've come close to failing on that front
myself, before. That was Be's biggest problem: they weren't relevant. They
didn't mean enough to enough people, they didn't solve a problem that our
industry recognized that it had. It's Apple's problem, too: by being to
inwardly focused, they've pissed away their position bit by bit. At one point
they were the most relevant company in the world. Now they're entirely
irrelevant. iMacs with flowers on them?
Similarly compatibility. The list is endless, but the fact is that if you don't
plug-and-play right from the start with the other things that people think are
relevant, you lose. Game over. This is why there's only one consumer OS that
is of interest, this is why XML --- aside from its technical merits --- trumps
frames, [nb: cf. NewtonScript, the ne plus ultra of programming languages in my
friend's view] and this is why HTTP is the universal transport or whatever it
Finally, there's survivability. It's not enough to nail the first three. You
have to compete, and continue to compete, indefinitely in order to maintain your
relevance. Our industry is a kind of ecology of software and services, and
there *is* a fitness function. From empirical evidence, it's reasonable to
speculate that this fitness function values these first three kinds of relevance
more than aesthetics or ergonomics. And if you can't survive, your not going to
be "usable" in any useful sense of the word.
Usable: Windows, IE, Office, Apache, Linux for servers, ICQ, Palm, C, Perl
Questionable: Netscape, IIS, Windows NT, Napster, Linux for desktops, Java
Unusable: BeOS, Newton, Objective C, Smalltalk... Macintosh?
Note that in many of these cases, the "usable" products fail on *any* but the
intangibles mentioned above. Windows is uglier than the Mac and maybe Linux,
Apache is complete crap from an administrative standpoint, ICQ is ungodly
baroque, Palm is ugly, Perl is ghastly. OTOH, BeOS is pretty and fast, Newton
was 20 years ahead of its time, the Mac has always been more user-friendly from
an immediate perspective. Both Objective C and Smalltalk were beautiful
languages. OTOH, because they "failed" to some degree on the other critical
fronts, I can't use them today to accomplish what I want, which is to help move
things forward for our industry. Therefore: unusable.