Xref: utzoo comp.unix.wizards:12196 comp.graphics:3558
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!ucbvax!decwrl!labrea!rutgers!att!whuts!homxb!mhuxu!m10ux!mnc
From: mnc@m10ux.UUCP (Michael Condict)
Newsgroups: comp.unix.wizards,comp.graphics
Subject: Re: Look and Feel... a red herring (Re: UNIX Expo in NYC)
Message-ID: <744@m10ux.UUCP>
Date: 7 Nov 88 18:04:56 GMT
References: <10794@ulysses.homer.nj.att.com> <2113@ficc.uu.net> <742@m10ux.UUCP> <2153@ficc.uu.net>
Organization: AT&T Bell Labs, Murray Hill
Lines: 48

In article <2153@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
>In article <742@m10ux.UUCP>, mnc@m10ux.UUCP (Michael Condict) writes:
>> Clearly, one was thinking about easing the programmer's burden and
>> the other about easing the user's burden.  I see no reason not to do both.
>
>Standardising the programmer's interface does this. It allows the Mac user,
>used to the way the Mac works, to purchase software that operates under the
>Mac paradigm.

Standardizing the programmer's interface does not guarantee that any particular
user interface will be implemented by the programmer.  If the programmer has
a powerful enough interface, s/he can make the windows and windowing operations
look arbitrarily different from any user interface in use today.  The fact that
some programmer interfaces may be too limited to accomplish this does not make
me wrong.  As someone pointed out to me, this is or was a problem on Mac's, i.e.
you had to restrict your use of the programming interface to just those
operations that would lead to the standard Mac user interface, at least
assuming that you wanted anyone to buy your software.

As for your second second statement, I don't understand the point.  Of course
a standard programmer interface means that you can buy software the uses the
interface and it is guaranteed to compile, link and execute successfully on
your machine.  It is NOT guaranteed to operate under the Mac paradigm, however,
if part of this paradigm is defined to be a particular user interface.  That
is, not unless the programmer interface is so restrictive and abstract as to
permit only operations that have a reasonable implementation within the bounds
of the Mac user interface.

As an example, suppose the programmer interface has operations to deal with
scroll bars, whereas the target user interface does not have any concept of
scroll bars.  It is very nice (for the programmer) that the programmer can do
these scroll-bar operations at a high level and not worry about the details of
their implementation, but what about the poor user who has never seen a scroll
bar and doesn't know what it is used for?  What about a programmer interface
that allows 5-sided windows, with each of the 5-borders having a different,
special purpose when clicked with a mouse?  And so on.

Summary: It is simply not true that the potential set of operations and rules
for a windowing system are so well agreed upon that every thing in one such
system has a clear analogue in another.  Although maybe we should move in that
direction.

Michael Condict		{att|allegra}!m10ux!mnc
AT&T Bell Labs		(201)582-5911    MH 3B-416
Murray Hill, NJ
-- 
Michael Condict		{att|allegra}!m10ux!mnc
AT&T Bell Labs		(201)582-5911    MH 3B-416
Murray Hill, NJ