🚀 go-pugleaf

In article <KAP1.91Nov8150320@icarus.spc.uchicago.edu> kap1@icarus.spc.uchicago.edu (Dietrich Kappe) writes:
>In article <ZPo4aB15w164w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes:
[Someone else asks whether you expect various Macintosh operations to have
the same results in different applications]
>   > Simply put, no.
...
>   OK.  So give us an example of an example where having an edit menu in the
>   standard place gets in the way.  A quick explanation of why cut/copy/paste
>   should have to be on different keys for a certain application. Why 
>   getting help should need to be different for two products.
...
>A Mac program's command input can be divided into three parts:
>
>	1) Menu. (Also buttons.)
>	2) Text.
>	3) Geometric Data.

>Most Mac programs neglect 2 and 3 for the reasons that
>
>	1) The standard interface discourages use of text as a means 
>	of command input.

Text is suggested for shortcuts.  Many menu items have keyboard
equivalents.  Arrow keys can be used to move around in text editors and
many other programs (e.g. the standard file dialogue, the Finder, some
graphic editors).  Files can be selected in the Finder and the standard
file dialogue by typing the first few characters of the name.

>	2) Geometric Algorithms are not very freindly critters and
>	require quite a bit of overhead and somewhat unfamiliar
>	data structures.

Maybe I don't understand what "geometric data input" is, but don't most
graphics and page layout programs use geometric input?  And what about
selecting icons in the Finder and Hypercard a form of geometric input?

>Thus many Mac programs are restricted to Menus and Buttons in their
>command input. Sure, you could make the menu/button system into
>a command parser, but this would amount to constructing a somewhat
>limited and counter intuitive keyboard. So we are often left
>with a rather limited command set in a typical Mac program.

How does this support your original point?  You were asked whether you
expected different applications to provide similar ways to execute common
operations, and you said no.  Your latest post explains why you don't like
the Mac interface in particular, but that doesn't explain why standard
interfaces are a bad idea in general.  In other words, if the Mac had a
standard user interface that you liked, wouldn't you expect most
applications to use it?

>To see an example of this, you need go no further than the finder. It
>is not the most useful directory/file manipulation tool I have ever used.

The primary goal of the Mac UI is to be easy to learn.  It's a well known
fact of UI design that it's very difficult to make a UI that's flexible,
powerful, and also easy for novices to use.

>Of course each UI has a limiting effect on its programs. I am not Mac bashing,
>just pointing out some of the drawbacks to a standardized UI. 

It seems more like you're pointing out the drawbacks of a particular
standardized UI.  I didn't see any general statements.

>							       Many of the same
>things can be said about *nix, since button type programs are the easiest
>things to write.

Huh?  Aren't most Unix UI's text based?
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar