[comp.cog-eng] Task Trees and consistency, was Re: consistency

nick@hp-sdd.hp.com (Nick Flor) (02/13/89)

In article <83@sundown.ACA.MCC.COM> grudin@sundown.ACA.MCC.COM (Jonathan Grudin) writes:

> When examined carefully, his [Ralph Hill's]
>position reduces to "consistently do the best thing in every situation"
>-- we can all agree on that but it isn't useful.
...
>But if you are determined to defend "consistency," here is one possibility:
>"Consistently maximize user efficiency and satisfaction." Because in order
>to do that, you will have to focus your attention on the users' work, which is
>where your attention is most usefully focused.

Well... but what is maximum "user efficiency and satisfaction"?

I  assume  when you say  maximize  user  efficiency  you mean  that  the
software tool together with its user  interface  must be efficient  with
respect  to  the  time  required  to  mentally  specify  AND  physically
accomplish a goal.

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.  Given two different users and the same application, if
the root node and the leaf  nodes are the same for both  users,  but the
depth  differs, then the user with the smaller  depth is the more expert
of the two.

So, the  morphology of the task tree is important.  To be efficient  you
want to minimize  both breadth and depth.  Minimizing  depth  amounts to
creating  a  software  tool  that  is easy  to use.  Minimizing  breadth
amounts to cutting down the amount of actions  necessary  to carry out a
task.

As a user  becomes  more  expert, the level of the tree  decreases.  The
expert  user goes  from root  node to leaf  nodes.  The time it takes to
decrease  the levels in the task tree, i.e.  transitioning  from user to
expert user, is the learning period.

If you try to cheat on the the number of action nodes, at the expense of
depth  then you are not being  more  efficient.  If you try to make your
application  ultra-friendly,  you  decrease the depth of the tree at the
expense of breadth -- also not very  efficient.  So  clearly,  or not so
clearly, there is this breadth/depth tradeoff to consider when designing
a software tool.

Now the  consistency  issue  boils down to this:  given a software  tool
that is similar in function to another  software tool, to what degree is
it's  task  tree  smaller  than the  other  tool.  You  then can  assign
consistency thresholds, so if the consistency threshold is, say 1/2, and
your  tree is 1/2 the  size of the  other  tool  then why  bother  being
consistent,  since  the  efficiency  gained  outweighs  the  need  to be
consistent.

One last thing before I shut up, it's  important to not just look at the
user interface  because this amounts to examining just the action nodes.
Minimizing  depth, i.e.  learning time, can be critical,  especially for
beginners.

I'd like to say more, and cover all holes (like how to you get this task
tree  from  a  user  onto  paper,  how  is  the  consistency   threshold
determined, and so on and so forth), but it's five minutes until the NBA
all star game, and after that INCOME  TAX!!!.  I can't think after doing
income tax.  But, I'm sure the net will correct me if I'm wrong.


Nick
-- 
+ Disclaimer: The above opinions are my own, not necessarily my employer's.   +
+ Oh, sure. Sure. I'm going. But I got  | Nick V. Flor           * * o * *    +
+ your number, see? And one of these    | Hewlett Packard SDD   * * /I\ * *   +
+ days, the joke's gonna be on you.     | ..hplabs!hp-sdd!nick  * * / \ * *   +