Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsb!jeffries
From: jeffries@hplabsb.UUCP (Robin Jeffries)
Newsgroups: comp.cog-eng
Subject: Re: consistency
Message-ID: <52000003@hplabsb.UUCP>
Date: 8 Feb 89 04:53:00 GMT
References: <714@cogsci.ucsd.EDU>
Organization: Hewlett-Packard Laboratories - Palo Alto, CA
Lines: 42

Nick Flor says:

> Anyways, I view the whole consistency/efficiency issue as follows:
>
> If we can believe that users when  presented  with a task  involving the
> use  of  a  software  tool,  use  the  problem  solving   techniques  of
> abstraction and  decomposition to break up the task into more manageable
> pieces, we can  envision a mental task tree -- where all  subtrees  of a
> node must be satisfied before the task the node represents is satisfied,
> [yeah, I know damn  those CS  metaphors].  At the top of the tree is the
> root  node  which  represents  the  overall  task, at the  bottom  - the
> physical  actions  necessary to accomplish the overall task.  We can use
> this task tree as the basis for discussing efficiency and consistency.
> 
> If the task trees for two separate  software  applications  are similar,
> then the two  applications  are said to be totally  consistent with each
> other.  If they differ in just the leaf  nodes, then the user  interface
> is inconsistent.  

That's an interesting definition of inconsistency, but if its the "right" one,
then Jonathon Grudin is exactly right -- consistency doesn't matter.  Some 
recent research (don't ask me to look up the references, but some of it was
done by John Anderson and other by Peter Polson (that stuff may not be
published) very strongly indicates that if the only differences are in what
you call the leaf nodes, then it is very easy to learn the second application,
and, in particular, there is no negative cost of having learned the first one
when you go to learn the second one -- the advantage of having learned all
those intermediate nodes in the tree overwhelms the small negative cost
of having to learn a new set of leaf nodes.  This work was done with text
editors in both cases, so its hard to argue that their stuff doesn't
apply to what you are talking about. 

The costs of inconsistency seem to be at much different levels.  For example,
there is some research that suggests that having multiple ways to do a task
(perhaps within an application, perhaps because you know two applications
and each one does it differently) can be very costly -- presumably because of
the mental cost of having to decide which one to use each time.  My interpretation
of the research I mentioned above is that if that cost is paid late in the
tree it is relatively cheap, but if it has to be paid higher up in the tree,
then it can screw you up.  I doubt that is the only reason that certain
forms of inconsistency are bad, but I believe it is one of them, and it seems
consistent with what Grudin says.