🚀 go-pugleaf

In article <ZPo4aB15w164w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes:

   > > Really?  You don't expect clicking and dragging to select something?  Or
   > > Command-C/X/V to Copy/Cut/Paste the item selected?  You don't expect a
   > > search to be brought up with the same sequence, or the edit menu to be
   > > in the same place?  You don't expect the buttons to be similar in 
   > > appearanc
   > > and their placement in dialogs to be the same?  You don't expect the
   > > same mechanisms for getting help on the product, or finding out who
   > > wrote it, or quiting out of it?
   > 
   > Simply put, no.

   Why not?  What's the advantage in having such basic functions performed
   differently in different packages?  There are obvious disadvantages, so 
   what's the advantage which makes you say that you don't see any reason for 
   standardization across applications?

   > The right tool for the right job. Macs are good for some things, less 
   > good for others. The somewhat standard (everyone breaks the rules) user 
   > interface can sometimes be useful and can sometimes really get in the way.

   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 fair set of questions. In theory, a Mac program with its standardized GUI
can do no more and no less computationaly than a text only version of this
program. It is simply a matter of convenience. If we can agree on this simple
point, I can move on to my principal argument.

A Mac program's command input can be divided into three parts:

	1) Menu. (Also buttons.)
	2) Text.
	3) Geometric Data.

Clearly the last two are the most powerful means of input. Text can be
used to do Formal Language related processing and Geometric Data can
be used to do Computational Geometry related processing (kind of redundant :-).

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.

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

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.

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.

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. Many of the same
things can be said about *nix, since button type programs are the easiest
things to write.

--

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