From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 15 Oct 92 18:37:17 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct14.214506.1596@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
> In article <CKD.92Oct14155012@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>>
>>Then the program is broken.  The HIG (and the requirements of DAs) put
>>Undo, separator, Cut, Copy, Paste, Clear at the top of the Edit menu.  I
>>believe the HIG also puts New and Open as the first two items on the
>>File menu, where applicable.
> 
> Don't get too tied down to a specific example.  Just because Cut, Copy,
> Paste, and Clear are an exception doesn't mean there isn't a problem for
> other commands.

True. But these are the common, standard commands. They are most likely to
appear in other applications.

> Nevertheless, there's no way to know in general what a program will call
> a function, or what menu it will go in.  Sure, there are conventions for
> really common things, but for many functions which are specific to a
> certain type of program (page layout, or 3-d modelling, or whatever)
> there are no such conventions.  

The point is there is an established convention for the common elements,
and that convention is nearly universially followed (on the Mac).

For unique program features (or at least non-standard ones), new ways of
accessing these features must necessarily be invented. 

Of course, these new features won't be familiar to a user, either, since
no other program has them.

> Searching through all the menus, trying things out, playing around with 
> the dialog boxes, etc. isn't that much different from reading a manual 
> or using a good on-line help system for a CLI.  

I disagree.

By establishing a common set of interface elements, and a document paradigm,
the user is on familiar ground. Each application follows this common set 
and paradigm, so you at least know where to start. This becomes the
starting point for learning the unique facilities of a particular application.

CLIs attempt to do this, too. There are certain conventions for the name and
use of parameters to commands. But the conventions are quite limited and
not universially followed. An excellent example of this is Unix, where several
common commands have a built-in, unique macro language. This makes life 
impossibly difficult for the user, who must learn a unique set of macro
commands for each program. Yuck.

> The difference is that the CLI is faster once you've familiarized yourself 
> with the command and its options.

1) We have never established that a CLI was faster. I still don't think it
   is.

2) "Familiarization" is not enough. Immersion is required. You are grossly
   understating the learning cliff involved with CLIs.

> I agree.  Being a fan of CLI's as well as GUI's, that's why I'd like to
> see a Mac CLI.  It would really bring out the full potential of a CLI.

It exists. Buy MPW. Buy A/UX.

> I still like UNIX a lot, however, because it offers enourmous power in
> return for its lack of consistency.

Perhaps there's a fundamental tradeoff here. Perhaps it is possible (with
more extensive design) to avoid losing power and maintaining consistancy.
Perhaps this has been achieved in the MacOS.

>>One company seems to have a fetish for having commands appear
>>and disappear though.  They're run by someone whose initials are "BG" :)
> 
> In an application I helped develop (running under X/Motif on top of an
> object-oriented database) we decided that there were cases where each
> made sense.  The user would graphically browse objects, moving from
> object-to-object across its relationships to other objects, then apply
> tools to the object (such as edit, view, check-in, check-out, delete,
> etc.)  Different tools applied to different classes of objects, plus
> there were access controls which determined whether or not you could
> apply a tool to an object.  We decided that inapplicable tools shouldn't
> appear in the menu at all, and inaccessible tools should appear
> greyed-out.  Not only was it confusing to see tools which made no sense
> for a particular object, but there were so many tools overall that it
> would have made for a very cluttered menu.  

There are two things involved here. 

One is the problem of hidden modes. If you grey out an item, it should be
clear why it is greyed out. Just having a grey item isn't always helpful
if the user can't understand and remember why it is grey. 

Second is the problem of simplification. If you have too many tools to
clutter up the screen, you have to take strides to design them out. There
are several methods to this. One is to eliminate tools whose function is
unnecessary (or that can be taken care of automatically). Another is to
combine the function of several actions into common items. Still another
is to create a visual (rather than verbal -- command or menu oriented)
model for the action.

Of course, the last technique is simply to punt. Jam the menus in there,
take them out, and let the user sort it out. Eventually, all software
ends up in this stage -- the later the better -- but sometimes you just
have to ship it.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Xref: sparky comp.sys.mac.advocacy:1468 comp.os.os2.advocacy:7413