Unix programmers inherit a strong bias toward making interfaces
expressive and configurable. Like programmers from other traditions,
they think about how to match their interfaces to the target audience
— but they differ in how they deal with uncertainty about
that target audience. Software developers whose experience is
primarily with client operating systems default toward making
interfaces simple; they are willing to sacrifice expressiveness to
gain ease. Unix programmers default toward making interfaces
expressive and transparent, and are more willing to sacrifice ease to
get these qualities.
The results of this attitude have often been described as
interfaces written “by programmers, for programmers”.
But this oversimplifies the matter in an important way. When a Unix
programmer opts for configurability and expressiveness over ease, he
is not necessarily thinking of his audience as consisting solely of
other programmers; rather, he is often acting on a gut-level instinct
that in the absence of knowledge about end-users' intentions it is
best not to patronize or second-guess them.
|
The downside of this attitude (which is a close cousin to
“mechanism, not policy”) is a tendency to assume that
when the highly configurable and expressive interface is done, the job
is finished... even if the result is almost impossible for anyone else
to use without lengthy study. The flip side of configurability is an
urgent need for good defaults and an easy way to set everything to the
default. The flip side of expressivity is a need for guidance — be
it in the program or the documentation — on where to get started
and how to achieve the most commonly-desired results.
|
|
| --
Henry Spencer
|
|
The Rule of Transparency also has an influence. When a Unix
programmer is writing to meet an RFC or other standard that defines a
set of control options, he tends to assume that his job is to provide
a complete and transparent interface to all of those options; whether
or not he thinks any given one will actually be used is secondary.
His job is mechanism; policy belongs to the user.
This mindset leads to a much stricter attitude about what
constitutes standards conformance, one in which incomplete support is
much less tolerable. In cases where a Macintosh or Windows developer
would say “We don't need to support that feature of the
standard; most users won't care, and it's too complicated for
them”, a Unix developer is likely to say “We don't know
that nobody will ever want this feature or option, therefore we must
support it”.
These attitudes can lead to clashes when a Unix programmer is
working with others, who are likely to interpret his design choices as
a blithe willingness to burden users with technical details that are
obscure, pointless, and even frightening. Mac or Windows programmers
fear scaring away the many to serve the advanced needs of the
few.
The Unix programmer, on the other hand, is likely to see
defaulting away from expressiveness as a sort of cop-out or even
betrayal of future users, who will know their own requirements better
than the present implementer. Ironically, though the Unix attitude is
often construed as a sort of programmer arrogance, it is actually a
form of humility — one often acquired along with years of battle
scars.
Finally, a note about user-interface design for nontechnical
end-users. This is a demanding art, and Unix programmers don't have a
tradition of being very good at it. But with the ideas we've
developed from examining the Unix tradition, it is possible to make
one strong and useful statement about it. That is: when people say a
user interface is intuitive, what they mean is
that it (a) is discoverable, (b) is transparent in use, and (c) obeys
the Rule of Least Surprise.[107] Of these three rules, Least
Surprise is the least binding; initial surprises can be coped with
if discoverability and transparency make longer-term use rewarding.
The user interfaces of today's cellphones (for example) have
relatively high mnemonic load in that you have to maintain at least a
rough mental map of the interface menus to use them rapidly without
constantly having to spend attention on checking where you are in the
hierarchy. But the better-designed ones rapidly become
‘intuitive‘ for their users anyway, because they have
these three qualities.
Intuitiveness is not quite the same quality as ease, because (as
the cellphone example shows) people can develop what they think of as
‘intuitions‘ about transparent interfaces that have fairly
high mnemonic load, as long as simple operations are easy and there is
a discovery path that allows them to assimilate the interface's more
difficult corners one step at a time.
