From: kanefsky@halcyon.com (Steve Kanefsky)
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Organization: The 23:00 News and Mail Service
Date: Wed, 14 Oct 1992 21:45:06 GMT

In article <CKD.92Oct14155012@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>Steve> == Steve Kanefsky <kanefsky@halcyon.com> 
>
> Steve> But many programs add other commands to the edit menu (though the
> Steve> edit menu is more static than other menus), so the position of the
> Steve> copy command could change because of other menu items being added
> Steve> and deleted dynamically.
>
>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.


> Steve> And of course there are still plenty of inconsistencies.  What
> Steve> is called "place" in one program might be "import" in another or
> Steve> just "open" in another.
>
>No, because "Open" is for opening a document, not for inserting another
>into this document (place).  "Import" could mean either, depending on
>your context; normally import of another file format (say, MacWrite
>format into Word) is handled in the Open... dialog box.

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.  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.  The difference is that the CLI is faster once you've
familiarized yourself with the command and its options.


> Steve> So the graphical interface doesn't guarantee consistency.  In
> Steve> fact, the amount of consistency is completely independent of the
> Steve> type of interface.  You can have a completely consistent CLI
> Steve> (where -o always specifies an output file, for example) or
> Steve> completely inconsistent GUI's (Windows -- need I say more?)
>
>Yes, but if we're talking about the Mac's UI vs. any CLI I've ever seen
>(this *is* c.s.MAC.advocacy, after all, though dumping on Windows is a
>major sport), the Mac's UI is far more consistent.

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.
I still like UNIX a lot, however, because it offers enourmous power in
return for its lack of consistency.


> Steve> The cut, copy, and paste commands in the edit menu are pretty
> Steve> stable because new commands tend to get added *below* those
> Steve> commands.  But there are plenty of other commands in other menus
> Steve> which appear and disappear, which effectively changes the
> Steve> position of other commands.
>
>The HIGs, if I recall correctly, advise application designers to use
>menus with *disabled* options rather than adding and subtracting
>options.  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.  

--
Steve Kanefsky
Newsgroups: comp.sys.mac.advocacy