🚀 go-pugleaf

In article <khmo26INN3mo@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

   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.

An example of text command input might be the C source code that you run
through Think C in order to produce CODE resources. Keyboard equivalents
need not apply.

   >	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?

Yes, these are good examples of 3. But move beyond these types of applications,
and you run into difficulty. You simply don't find applications in the 
amateur and low professional ranks that make use of this kind of input
for non-drawing purposes.

   >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?

My original argument was: the right tool for the job. I don't expect 
all the programs that I use to make use of the same user interface since
this may be clumsy in some circumstances, such as doing version
control (try doing that under the finder).

Actually, I like the Mac interface just fine for certain applications.
Heck, I even own a Mac.

   >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.

Yes, and it is easy to learn; very good. Its standardized user interface
does not have to, but does tend to lead programmers to write "button"
programs.

   >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.

OK, you can't do graphics processing easily in vanilla text *nix. Thus *nix
programs tend away from such programs. This is a standard feature of
*nix. It has a limiting effect on *nix programs.

   >							       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?

Suppose I write a program that allows you to type in 10 legal commands.
This is the same as taking away all but 10 of your keys. It is a button
program in that every operation in it is performed by entering a simple
command (pushing a "button").

--

---
Dietrich Kappe
kap1@icarus.spc.uchicago.edu
Center for Population Economics