peterr@utcsrgv.UUCP (Peter Rowley) (09/06/83)
Recent discussion leads one to believe that, as qualities of user
interfaces, "access-efficient" and "friendly" could be thought of as
rather independent, with the former referring to cognitive considerations
and the latter referring to emotional (affective) properties of the interface.
For example, I'd say vi is considerably more access-efficient than ed, but
only a little more friendly (the latter based on the tone of its error
messages). The emotional impression I get from both is fairly sterile,
though ed's leading-? errors are distinctly rude.
This might satisfy those who voiced concern about "friendly" being
applied to non-humans, as it restricts the word to the emotional aspects of
software.
"Friendly" seems useful as a separate term in this sense, as indicated by
the recent article which described improved performance from a compiler
with friendlier error messages with the same information content (equally
access-efficient, in some loose sense).
Friendliness, like access-efficiency, is a function of the particular
user (or has to be considered as an average across all the intended users
at all their stages of learning) so what is friendly to one may be
condescending or brusque to another. I think that this interface adaptation
is more than a question of verbosity vs. terseness, with a vocabulary change
required between different classes of users.
Of course, the two qualities ARE related. Frustration with an access-
inefficient interface would lead to a negative affect, no matter how helpful
sounding the error messages might be, though I'm at a loss to find a good
example of this.
Finally, it would be interesting to see the *magnitude* of the effect in
the compiler error message experiment given above. It would be my intuition
that access-efficiency is most important for performance, though friendliness
may be very important for purchase decisions and brand loyalty.
peter rowley, University of Toronto Department of C.S., Ontario Canada M5S 1A4
{cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr
{cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterr