From: mike_steiner@qm.claris.com (Mike Steiner)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 14 Oct 92 20:55:39 GMT
Followup-To: comp.sys.mac.advocacy

In article <1992Oct13.222051.29320@nwnexus.WA.COM>, kanefsky@halcyon.com
(Steve Kanefsky) wrote:

> >> Note that anyone can press a key on a keyboard with no practice, but it 
> >> takes some practice to use a mouse.  
> >
> >This completely fallacious. What are you measuring here? You can teach someone
> >to meaninglessly press a key, versus using a mouse proficiently? 
> 
> If I teach someone that "C" stands for copy, then reaching out and
> pressing C is certainly meaningful.  On the other hand, a menu
> choice isn't always meaningful.  Sometimes it isn't obvious which
> menu a command belongs in or what the command should be called.  My
> point is that a certain number of common commands can be assigned
> keyboard shortcuts, and those shortcuts can have a meaningful
> association with the command itself. Pressing a key (or even two) on
> the keyboard is almost always faster than using a mouse to select a
> menu item. 

If Copy is always "Copy," and is always in the same position of the Edit
menu, then it is always more meaningful than remembering "Copy, oh that's
the 'C' key."  You are saying that a keyboard shortcut to a command can be
more meaningful than the command itself.  That is patently nonsense. 
*Perhaps* Command Q, W, A, S, Z, X, C, and V, keyboard shortcuts are faster
than using the mouse--but if they are, they are so only because they have
been standardized for their equivalent menu commands.  However, people had
to memorize them--after memorizing the functions themselves.  That means
you have to dereference, mentally, twice to get to the function, instead of
only once.  Sure, you can get a handle on keyboard shortcuts, but pointing
with the mouse takes less mental effort.
 
> >> In addition to the extra cognitive effort of manipulating the mouse 
> >
> >The cognitive effort is not different than that required to reach out and
> >grab a coffee cup. You can do this without thinking. It is a low-level 
> >operation that takes place with little mental effort.
> >
> >> you have to remember what menu the command is in 
> >
> >No you don't. You don't have to remember at all. All you have to do is
> >RECOGNISE. Humans are terrible at remembering things. They are excellent at
> >recognising things. 
> 
> OK, so if I give you a page full of phone numbers -- one of which is
> yours -- you'll be able to recognize it faster than you could
> remember it? 

That's not the same thing.  The format is different and what you're
remembering is a different category.  There is a difference between
remembering a fact and remembering a process.  I can recognize a pattern
more easily than I can remember how to draw one.

> >> and you may have to scan all the items in the menu carefully for the 
> >> command you want 
> >
> >This is true only for the first few times you use a new product. We're 
> >speaking of reasonably proficient users, who are familiar with the product
> >(or similar products). 
> >
> >The beauty of the Macintosh is that you DON'T have to root around to find
> >the "Copy" menu item, because it is ALWAYS under the Edit menu. And the
> >Edit menus is ALWAYS in the same place. Consistancy.
> 
> But many programs add other commands to the edit menu (though the
> edit menu is more static than other menus), so the position of the
> copy command could change because of other menu items being added
> and deleted dynamically.

Nope.  The added items are at the end of the menu.  Apple's HIG dictates
(one of the few places where dictation is appropriate) what the first five
items on the Edit menu should be:  Undo; seperator line; Cut; Copy; Paste.

> And of course there are still plenty of
> inconsistencies.  What is called "place" in one program might be
> "import" in another or just "open" in another.  So the graphical
> interface doesn't guarantee consistency.  In fact, the amount of
> consistency is completely independent of the type of interface.  You
> can have a completely consistent CLI (where -o always specifies an
> output file, for example) or completely inconsistent GUI's (Windows
> -- need I say more?)
> 
> 
> >> (especially in programs that change the menu structure according to context).
> >
> >I have yet to see a Macintosh program that changes the location of Copy or
> >the position of the Edit and File menus. If you can find one, I submit that
> >the authors of these programs should be shot.
> 
> The cut, copy, and paste commands in the edit menu are pretty stable
> because new commands tend to get added *below* those commands.  But
> there are plenty of other commands in other menus which appear and
> disappear, which effectively changes the position of other commands.

I haven't seen any applications written in the past four or five years in
which menu items are inserted into the menu--a few append items to the end
of the menu, though.

+---------------------------------------------------------------------+
|Now that I have a reader that can do .sigs, I can't think of a witty |
|one to put here, so I won't.  All normal disclaimers apply.          |
+---------------------------------------------------------------------+
Newsgroups: comp.sys.mac.advocacy