Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!amdahl!nsc!csi!jwhitnel
From: jwhit...@csi.UUCP (Jerry Whitnell)
Newsgroups: comp.sys.mac
Subject: A Few Good Rumors...
Message-ID: <1406@csib.csi.UUCP>
Date: 10 Feb 88 21:54:42 GMT
Reply-To: jwhit...@csib.UUCP (Jerry Whitnell)
Organization: Communications Solutions Inc., San Jose, Ca
Lines: 41
Keywords: A/UX Unix FullWriter
References:
From Feb 88 issue of Micro-Mini Systems:
Apple Finally Gets its UNIX act together - All on a disk
Apple Computer Inc, Curpertino Calif., chose the Uniforum show in Dallas this
month to introduce A/UX, its version of AT&T Co.'s UNIX System V.2
operating system. A/UX is designed for Apple's high-end Macintosh II and
comes preconfigured on either an internal ($4,879) or an external ($5,549)
80M-byte rigid-disk drive upgrade packge for current users [Ouch! jdw]. ...
A/UX contains Berkeley UNIX extensions, Network File SYstem, Streams and the
Macintosh Toolbox, plus functions for automatic booting and recovery.
That leaves users with 10 M-bytes of free disk space [Ouch again! jdw].
By preconfiguring the disk, Apple hopes to spare users from hiring UNIX gurus.
From Feb 8, 1988 issue of MacintoshToday
Ashton-Tate reportedly buys Ann Arbor, hot WP program
Ashton-Tate of Torrance Calif. reportedly has acquired Ann Arbor Softworks, INc.
of Newbury Park, Calif. and will soon publish the company's FullWrite
Professional...
Sources said Ashton-Tate bought Ann Arbor and a number of its assets after
months of negotiations between the two firms. Ann Arbor's graphics program
FullPaint is included in the aggreement, but FullCalc, the company's unpublished
spreadsheet, is not.
Ann Arbor's deal with Ashton-Tate could be worth up to $30 million including
royalties, sources said. [Everyone who knows anything :-)] declined to comment.
For those who are interested in C Compilers, see also Dennis Cohen's article
comparing C compilers in MacintoshToday.
Jerry Whitnell Been through Hell?
Communication Solutions, Inc. What did you bring back for me?
- A. Brilliant
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!brl-adm!
umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsp!gillies
From: gill...@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.sys.mac
Subject: Re: A/UX cost
Message-ID: <76000127@uiucdcsp>
Date: 17 Feb 88 21:32:00 GMT
References: <8659@allegra.UUCP>
Lines: 11
Nf-ID: #R:allegra.UUCP:8659:uiucdcsp:76000127:000:503
Nf-From: uiucdcsp.cs.uiuc.edu!gillies Feb 17 15:32:00 1988
The appalling thing is that Apple told users to go out and buy an 80
megabyte disk so they could run A/UX. Now Apple turns around, says
"throw away your disk, purchase OUR disk instead". I'm suprised their
is no outcry at this bait & switch tactic.
It reminds me of the ticket scalper that charges $16.50 for the NFL
tickets, and $100 for the envelope. You don't buy the envelope, you
don't get the tickets......
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gill...@p.cs.uiuc.edu}
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!
pyramid!voder!apple!phil
From: p...@apple.UUCP (Phil Ronzone)
Newsgroups: comp.sys.mac
Subject: Re: A/UX cost (and tape backup)
Message-ID: <7447@apple.UUCP>
Date: 19 Feb 88 20:26:02 GMT
References: <8659@allegra.UUCP> <76000127@uiucdcsp>
Reply-To: p...@apple.UUCP (Phil Ronzone)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 59
In article <76000127@uiucdcsp> gill...@uiucdcsp.cs.uiuc.edu writes:
>
>The appalling thing is that Apple told users to go out and buy an 80
>megabyte disk so they could run A/UX. Now Apple turns around, says
>"throw away your disk, purchase OUR disk instead". I'm suprised their
>is no outcry at this bait & switch tactic.
Sigh. Well, let me apologize for the fact that we here at Apple do NOT
have the most perfect corporation in the world. (I do think we have a
corporate plan for implementing a perfect coporation in the next quarter
however.) :-) :-) :-)
The Apple Tape Backup Unit is a SCSI device. The A/UX SCSI manager is, by
design, exceptionally robust. To ensure that the SCSI manager meets the
design goals of being very very robust, the source code was frozen at a
certain point. The Apple Tape Backup Unit was not ready for the A/UX source
code freeze. So, voila, no A/UX native support for the tape unit, hence,
aaarrrggghhhhh (Apple Marketing & Sales dying screams into the sunset ...)
no A/UX distribution on tape.
We did go begging on our knees to the Mac OS guys doing the Mac tape unit
software, and the next (soon very very soon) of release of Mac OS software
for the tape unit WILL support dumping and restoring of A/UX partitions on
an Apple HD80. NO plans right now for A/UX distribution on tape however.
Why you ask (scream)? Well, to the Apple factory, A/UX is no simple product.
For example, in ONE fell swoop, the A/UX manuals (all 6000+ pages of 'em)
DOUBLED the entire amount of Apple documentation in print. More important
are the "bundles", or configurations that the factory must produce. I.e.,
full A/UX systems, A/UX on an internal hard disk without a PMMU, A/UX on
an internal hard disk WITH a PMMU, A/UX on an external hard disk with and
without a PMMU, with and without various extra DRAM upgrades, with and
without manuals ...
A tape distribution right now would almost DOUBLE some of the configurations.
And all of this on a factory which likes to think in terms of a few
floppies (System Disk, Utilities, etc.).
But, we are getting there. Believe me, we winced a lot when we realized
that the tape unit would not be supported in the first release.
And, as for cost, well, PLEASE make sure that you are comparing retail
to retail! I was "beat upon" by a University professor for being much
more expensive that his favorite workstation. I pointed out that he
was comparing our price for a purchase of 100 units .vs. the price for
brand-X for 1200 units. End result, our price for 1000 units was cheaper
than brand-X at 1200.
Anyway, A/UX is our hard work - we here in Engineering finally get our
turn to be on the receiving end of criticisms, suggestions, etc. - and
we DO listen hard. Just like a Mac .vs. a PC, try A/UX. You will like it.
Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox
and the Mac look and feel. Ain't nobody else got that ...
-------------------------------------------------------------------------------
Philip K. Ronzone, A/UX Technical Manager APPLELINK: RONZONE1
Apple Computer, Mail Stop 27AJ, 10500 N. DeAnza Blvd. Cupertino, CA 95014
UUCP: ...!{sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!unisoft!hoptoad!
gnu
From: g...@hoptoad.uucp (John Gilmore)
Newsgroups: comp.sys.mac
Subject: Re: A/UX tape backup
Message-ID: <4128@hoptoad.uucp>
Date: 26 Feb 88 21:01:31 GMT
References: <8659@allegra.UUCP> <76000127@uiucdcsp> <7447@apple.UUCP>
Organization: Grasshopper Group in San Francisco
Lines: 21
p...@apple.UUCP (Phil Ronzone) wrote:
> We did go begging on our knees to the Mac OS guys doing the Mac tape unit
> software, and the next (soon very very soon) of release of Mac OS software
> for the tape unit WILL support dumping and restoring of A/UX partitions on
> an Apple HD80.
I haven't seen one, but what I have heard is that the Apple 40MB tape
drive is slow, slow, slow. For "super reliability" it writes everything
three times on the tape, cutting the speed by a factor of three.
There is a slim chance that when the SCSI tape support is released, it
might work with third party tape drives that provide higher speed and
better price/performance than Apple's. But only if you, the customers,
demand it.
Our Mac-II is ethernetted to a Sun with both cartridge and 6520 BPI
magtape anyway. The more serious problem is that they left *dump* and
*restore* off the Unix distribution! We have to do backups with tar,
which doesn't support incremental backups.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
"Watch me change my world..." -- Liquid Theatre
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!unisoft!hoptoad!
gnu
From: g...@hoptoad.uucp (John Gilmore)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: A/UX window systems, Mac toolbox, etc
Message-ID: <4129@hoptoad.uucp>
Date: 26 Feb 88 22:11:39 GMT
References: <8659@allegra.UUCP> <76000127@uiucdcsp> <7447@apple.UUCP>
Organization: Grasshopper Group in San Francisco
Lines: 98
p...@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote:
> Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox
> and the Mac look and feel. Ain't nobody else got that ...
This claim requires some looking behind the hype.
Under the MacOS, you indeed get the Toolbox and the Mac look and feel.
Under A/UX, you can run a small subset of Mac applications -- the ones
that strictly follow the latest guidelines for cleanliness. However,
there is no convenient way to transfer a Mac application from its home
on Mac floppies or hard disk, into the Unix file system. There is a
program that will read 400K, non-HFS floppies and extract the files
therein. There is *no* way to read standard 800K MacOS floppies, or an
HFS floppy, or an HFS disk partition, from Unix. I suppose you could
get a second mac, and transfer the programs and all their data files
over with xmodem, but I doubt many people will bother. It's easier to
shutdown A/UX and reboot the MacOS.
Under A/UX, you have access to the Toolbox. It's a library in /lib.
If you have source for a Mac application, you can do some of the
Toolbox calls, compile it, link it with this library, and they work.
However, you can only run one such application at a time -- it takes
over the whole screen, and you can't get to Unix any more, except over
the serial ports or Ethernet. No control-Z. No multiple windows. You
are either in the application or you are talking to a Unix shell, not
both. There is no equivalent to "switcher" or "multifinder".
When you boot up A/UX, you get a "terminal emulator" on your screen.
This is just like the terminal emulator you get on a Sun before you
bring up the window system -- it looks like an ANSI terminal, with 35
lines and 89 columns, like a slightly bigger VT100. However, they have
cleverly painted a mac-looking box around the outside of the terminal
emulator. There's a menu bar at the top -- with all the words in
grey. You can't hit any of them. There's a box around the terminal
"window", with a title bar. You can't hit it. There isn't even a
mouse cursor. This is a cute trick, but that's all it is. It doesn't
do any kind of graphics, it's just a terminal.
So you say you want windows! Well, Apple has provided them. The
single Toolbox application, term, that comes with your A/UX port
provides multiple windows. However, this is just more VT100's on your
screen. You can have up to 4 ANSI terminal emulators in a variety of
sizes. They can even overlap. (They have to, unless you bought a
third party large monitor, or you like dinky VT100s.) There is no
graphics support, however, and you can't run any Mac applications
because you are already running a Toolbox program and you can only run
one at a time. I would not call this a window system, certainly not in
the sense of NeWS or X or SunView or Andrew or the Apollo window
system. It's more like "uw". Also, "term" is not a supported part of
A/UX. If you find bugs in it, it's your problem.
Don't burn up a lot of money buying color graphics boards for your
Mac-II yet; A/UX doesn't support them. If your color board supports
monochrome, A/UX can use it -- until you try a Toolbox application. It
seems that frame buffer manufacturers have to alter the configuration
ROMs on their boards before A/UX can put up a mouse cursor. Of course,
if your color board does not support a 1-bit mode, A/UX can't use it at
all. And it can only handle one screen right now, even if you have
several. They have promised to fix this Real Soon Now.
The Apple marketing effort here is a masterpiece of hype. I have the
brochure they distributed at UniForum. The outer folder ("There are
currently more than 50 types of UNIX in the world.") has four pictures
of Mac screens. Three of them are running MacOS applications (one from
MultiFinder; the others we can't tell), and are photographed from
straight above the Mac, so you can barely see the screen. The fourth
is running unavailable software from Brown University that brings up
pictures and text from British novels, using the Toolbox. (By the way,
they are calling the Brown stuff "hypertext" and taking Ted Nelson's
name in vain. It ain't hypertext, it's just hype.)
Contained in the folder is a short letter and three flyers. The "Apple
A/UX Operating System" flyer has a single large picture: the Brown U.
software again (which is, of course, *not* in A/UX and not commercially
available either). The "Macintosh II Personal Computer" flyer, for
once, is free of hype. The "A/UX Support Services" flyer is headed by
a big picture of a mailing envelope with an "A/UX Update" tape hanging
out of it. Of course, this tape is in the 40MB Apple SCSI tape format,
which is not supported by A/UX.
In their booth, Apple was demonstrating a version of X windows.
However, if pressed, they revealed that it was X.10, not X.11, that it
was not available for purchase, and would never be available; and that
they could not talk about possible release dates for X.11.
I'd hate to be totally negative in this article, so let me just say
that there *is* a window system for A/UX. You just can't buy it from
Apple. We sell it; it's called MacNews, and it's a straight port of
Sun's NeWS, with all of NeWS's problems and all of NeWS's virtues. The
first test copy went out last night, and it has a firm release date and
a firm price.
I'm a techie through and through and I hate to see people get away with
marketing bullshit. If you buy A/UX, buy it because you know what you are
getting, not because you believed an Apple snow job.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
"Watch me change my world..." -- Liquid Theatre
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!husc6!mit-eddie!uw-beaver!
ssc-vax!benoni
From: ben...@ssc-vax.UUCP (Charles L Ditzel)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac toolbox, etc
Message-ID: <1710@ssc-vax.UUCP>
Date: 28 Feb 88 22:45:39 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 20
In article <2...@rhesus.primate.wisc.edu>, b...@rhesus.primate.wisc.edu
(Brain in Neutral) writes:
> p...@apple.UUCP (Phil Ronzone, A/UX Technical Manager) wrote:
> > Remember - it is a Mac. Under A/UX or the Mac OS, you have the Toolbox
> > and the Mac look and feel. Ain't nobody else got that ...
The toolbox is hardly something to be touting ... the Mac Toolbox lacks the
sophistication of other systems that incorporate network window management
and extensible window servers. Three years ago this might have been an
appropriate point.
As for the look and feel ... the Mac certainly has made it's contribution
but since it is not licensable and others can't use it... it is being
by-passed by the remainder of the industry...e.g. SunTools, Presentation
Manager, Apollo's DM, etc. Rather it is Apple that is moving more toward
industry standards with NeWS and X sitting on their system. Writing
an A/UX application using the Mac Toolbox specifically precludes the
application migrating elsewhere (which in some cases makes sense, but in
most does not if you are interested in portability).
> Which is hardly to demonstrate that it would be impossible or difficult
> to put the Mac look and feel up under some other windowing system.
it's been done...why else did Apple sue DRI for GEM.
Path: utzoo!mnetor!uunet!steinmetz!vdsvax!barnett
From: barn...@vdsvax.steinmetz.ge.com (Bruce G. Barnett)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac toolbox, etc
Message-ID: <3996@vdsvax.steinmetz.ge.com>
Date: 1 Mar 88 04:45:38 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP>
Reply-To: barn...@steinmetz.ge.com (Bruce G. Barnett)
Organization: General Electric CRD, Schenectady, NY
Lines: 32
In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
|The toolbox is hardly something to be touting ... the Mac Toolbox lacks the
|sophistication of other systems that incorporate network window management
|and extensible window servers. Three years ago this might have been an
|appropriate point.
My naive impression of the Mac Windows was that is was a useful window
system given a single process and a small screen. But I don't
understand how Apple can provide the same interface in a multi
application environment. How would pull-down menus work with multiple
applications? They can't all grab the top of the screen.
Context-sensitive pop-up menus make much more sense to me. But then
you would need more than one button on the mouse.
Someone once made the point that it is easy to grow downward than to
grow upward. That is, it is easier to convert a multi-application,
multi-tasking, color window system into a single color, single user
system than vice versa.
I bet Apple is finding out that converting the Mac toolbox to Unix
is more complicated than they thought.
| Rather it is Apple that is moving more toward
|industry standards with NeWS and X sitting on their system.
Moving? I think "dragged kicking and screaming" is more appropriate :-)
NeWS for the Mac II is looking better and better. Too bad that
NeWS wouldn't be practical for a non-A/UX system.
--
Bruce G. Barnett <barn...@ge-crd.ARPA> <barn...@steinmetz.UUCP>
uunet!steinmetz!barnett
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!claris!apple!han
From: h...@Apple.COM (Byron Han, fire fighter)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac toolbox, etc
Message-ID: <7523@apple.Apple.Com>
Date: 1 Mar 88 20:12:28 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <3996@vdsvax.steinmetz.ge.com>
Reply-To: h...@apple.UUCP (Byron Han, fire fighter)
Organization: Communication Tools Group - Apple Computer, Inc.
Lines: 36
In article <3...@vdsvax.steinmetz.ge.com> barn...@steinmetz.ge.com
(Bruce G. Barnett) writes:
>In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
>|The toolbox is hardly something to be touting ...
>
>My naive impression of the Mac Windows was that is was a useful window
>system given a single process and a small screen. But I don't
>understand how Apple can provide the same interface in a multi
>application environment. How would pull-down menus work with multiple
>applications? They can't all grab the top of the screen.
>Context-sensitive pop-up menus make much more sense to me. But then
>you would need more than one button on the mouse.
Why don't you try out MultiFinder and see how well (in my unbiased :-) opinion)
it works? The menu bar reflects the menu appropriate to the topmost
application. All the windows that belong to an application reside in a
layer. When an application is brought to the front/foreground, all the windows
in its layer are brought forward and the menu bar is switched.
> Someone once made the point that it is easy to grow downward than to
> grow upward. That is, it is easier to convert a multi-application,
> multi-tasking, color window system into a single color, single user
> system than vice versa.
Incidentally, the Macintosh windowing user interface evolved from the Lisa
Office System which was a multitasking multiple window, multiple application
environment. I don't think that there is much difference between a
color and a monochrome windowing system.
Disclaimer:
This is NOT an official Apple position, just some comments by me.
I do work for Apple and happen to love it so take my comments with
a grain of NaCl.
--
------------------------ Byron Han, Communications Tool ----------------------
Apple Computer, Inc. 20525 Mariani Ave, MS 27Y Cupertino, CA 95014
ATTnet:408-973-6450 applelink:HAN1 domain:h...@apple.COM MacNET:HAN
GENIE:BYRONHAN COMPUSERVE:72167,1664 UUCP:{sun,voder,nsc,decwrl}!apple!han
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!amdahl!nsc!voder!apple!lsr
From: l...@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac toolbox, etc
Message-ID: <7531@apple.Apple.Com>
Date: 2 Mar 88 01:46:41 GMT
References: <8659@allegra.UUCP> <76000127@uiucdcsp> <7447@apple.UUCP>
<4129@hoptoad.uucp>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 15
In article <4...@hoptoad.uucp> g...@hoptoad.uucp (John Gilmore) writes:
>is running unavailable software from Brown University that brings up
>pictures and text from British novels, using the Toolbox. (By the way,
>they are calling the Brown stuff "hypertext" and taking Ted Nelson's
>name in vain. It ain't hypertext, it's just hype.)
The name of the system is Intermedia, and it has been described in several
papers. I would like to know why you say that Intermedia is not hypertext.
(The only thing I can think of is that Intermedia deals with graphics as
well as text, and might better be described as hypermedia.)
--
Larry Rosenstein, Object Specialist
Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014
AppleLink:Rosenstein1 domain:l...@Apple.COM
UUCP:{sun,voder,nsc,decwrl}!apple!lsr
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ll-xn!mit-eddie!
uw-beaver!ssc-vax!benoni
From: ben...@ssc-vax.UUCP (Charles L Ditzel)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac toolbox, etc
Message-ID: <1719@ssc-vax.UUCP>
Date: 2 Mar 88 07:18:22 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <7523@apple.Apple.Com>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 14
In article <7...@apple.Apple.Com>, h...@Apple.COM (Byron Han, fire fighter)
writes:
> Why don't you try out MultiFinder and see how well (in my unbiased :-) opinion)
> it works? The menu bar reflects the menu appropriate to the topmost
> application. All the windows that belong to an application reside in a
> layer. When an application is brought to the front/foreground, all the windows
> in its layer are brought forward and the menu bar is switched.
Still sounds awfully serial to me. What happens if you have two windows
at the top (i do this on a sun, usually two editting sessions) maybe
different editors side by side...? Your menu bar would be constantly
changing as you go back and forth (cutting and pasting)... (all that
wasted mouse travel time and a wasted mouse click )
I think context-sensitive menus make more sense (try SunView applications
and see how well they work) :-) (Seriously, I think a menu bar starts
making less sense in a multitasking environment were more than one
application is running at a time in a number of different windows )
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!eos!lyman
From: ly...@eos.UUCP (Lyman Taylor)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <241@eos.UUCP>
Date: 3 Mar 88 07:03:43 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <7523@apple.Apple.Com> <1719@ssc-vax.UUCP>
Reply-To: ly...@eos.UUCP (Lyman Taylor)
Organization: NASA Ames Research Center, Calif.
Lines: 91
Keywords: window human computer interface
Summary: Human limitations
Sender:ly...@ames-aurora.arpa or
In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
.... ( deleted comments Byron Han made about multifinder )
>Still sounds awfully serial to me. What happens if you have two windows
>at the top (i do this on a sun, usually two editting sessions) maybe
>different editors side by side...? Your menu bar would be constantly
>changing as you go back and forth (cutting and pasting)... (all that
>wasted mouse travel time and a wasted mouse click )
>I think context-sensitive menus make more sense (try SunView applications
>and see how well they work) :-) (Seriously, I think a menu bar starts
>making less sense in a multitasking environment were more than one
>application is running at a time in a number of different windows )
Multitasking saves the World! Come on, the only person I know of
the can actually use two applications at once is Mr. Spock of Star Trek due to
the unique features of his Vulcan mind ( i.e. he is not a human being ).
Unfortunately, us humans can only handle ONE high level cognitive task
at once. Therefore, we only need ONE menu at a time. Anything above that is
a nice HACK, but not all that useful for us mortals. Needless to say, it
ignores most of what about Human Computer Interaction.
[ Like people operate best in a CONSISTANT environment which is why the Mac is
so easy to learn and use. And UNIX is well UNIX ( a terrific puzzle, but not
as great a tool as it could be. And why NeWS and X applications are often
thought of as HACKS by people who did not 1) create, 2) pay for, or
3) forcibly made to use the application in the first place. ]
Think about it. When have you ever seen anyone, including yourself,
doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing
something into your favorite editor ). I give you a hint most computers I seen
have ONE keyboard per user. This applies to general human behavior also. For
example, people can only handle one conversation at a time. Some people can
easily and rapidly " task switch " from conversation to conversation ( doing
something remarkably similiar to a multitasking operating system ) but they
cannot do it in parallel.
This is not to say multitasking is not useful. Multitasking and
timesharing used to mean just about the same thing. Then came the single user
system. It is useful on a single user system to run a BACKGROUND task(s) that
needs NO iteraction with the user, like laser printing a 50 page document. The
important point is that menus and the mouse and all that WIMPy stuff are for
INTERACTION with the human. WIMPy stuff is used by the human to directly
controlthe program unlike the MS/DOS and UNIX environments with their prompts,
with which the program ask YOU the questions. The psychological types call this
User Directed Software. Humans do not need to control background tasks that
is why they are background tasks. If programs need to talk to other programs
THEY don't need the menu for hopefully they know what each are talking about
:-).
As for your example of having two editors going at once.
1) If this was two copies the SAME editor open on two different files
then I would same that this is a malfunction of the EDITOR.
Take a look at most Mac word processors; they have the
capability of having multiple windows open at once.
Even emacs has multiple buffers ( it user interface leaves
something to be desired though )
2) If you actually needed two DIFFERENT editors you hopefully were
looking at two DIFFERENT types of files. In this case you are
context switching between two different types of data who
hopefully have completely different menus. ( execpt for
the APPLE, FILE, and EDIT menus, there goes that CONSISANTCY
again, Mac Write and Mac Paint have for the most part different
menus and operation ( those probably aren't the best examples
but you get the idea :-).
To sum it all up multitasking means that can have more that one task
runnig at the same time ( more than one doing work FOR you ), but you can only
work WITH one application at a time. So it looks SERIAL because people THINK
serial. We can only do low level tasks like see, hear, taste, and smell in
parallel; I guess that's what separates the humans from the computers who think
SERIALLY just like we do, only they're better at faking it.
P.S. Apple I hope you keep this in mind while you are rewriting the MAC OS. We
need enhanced MultiF not UNIX. We already got UNIX. :-)
P.P.S. And yes the Mac interface isn't THE absolute best interface, but at
least its tries.
Lyman S. Taylor ly...@ames-aurora.arpa
NASA Ames Research Center or
more verbose
...{uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!lyman
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!fluke!ssc-vax!
benoni
From: ben...@ssc-vax.UUCP (Charles L Ditzel)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <1735@ssc-vax.UUCP>
Date: 5 Mar 88 03:37:02 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <241@eos.UUCP>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 40
Keywords: window human computer interface
In article <2...@eos.UUCP#, ly...@eos.UUCP (Lyman Taylor) writes:
# In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
#
# .... ( deleted comments Byron Han made about multifinder )
#
#
# >Still sounds awfully serial to me. What happens if you have two windows
# >at the top (i do this on a sun, usually two editting sessions) maybe
# >different editors side by side...? Your menu bar would be constantly
# >changing as you go back and forth (cutting and pasting)... (all that
# >wasted mouse travel time and a wasted mouse click )
# >I think context-sensitive menus make more sense (try SunView applications
# >and see how well they work) :-) (Seriously, I think a menu bar starts
# >making less sense in a multitasking environment were more than one
# >application is running at a time in a number of different windows )
#
# Multitasking saves the World! Come on, the only person I know of
Some how you picked up on the multi-tasking aspect rather than the more
important issue of the cumbersomeness (is-this-a-word?) of menu bar switching.
# 2) If you actually needed two DIFFERENT editors you hopefully were
# looking at two DIFFERENT types of files. In this case you are
# context switching between two different types of data who
# hopefully have completely different menus. ( execpt for
# the APPLE, FILE, and EDIT menus, there goes that CONSISANTCY
# again, Mac Write and Mac Paint have for the most part different
# menus and operation ( those probably aren't the best examples
# but you get the idea :-).
Again you missed the *main* point, even if you do not have multitasking.
The user interface you wind up with is one with constant mouse clicks and
constant menu bar switches :( . Further, you will be constantly looking
to see which application window is the active one (a further nuisance).
Finally (if you do have multitasking) It gets worse (as I percieve it) on
an abstract level...when two windows are on top (side by side) why should
you choose one over the other in putting a menu bar up for that one? Can
you really design a system which unnecessarily defines user activity in a
serial manner and *predict* the type of applications you will see in the
future.
You wind up limiting your user interface today and for the future.
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!tybalt.caltech.edu!sho
From: s...@tybalt.caltech.edu (Sho Kuwamoto)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <5674@cit-vax.Caltech.Edu>
Date: 7 Mar 88 02:55:42 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <241@eos.UUCP> <1735@ssc-vax.UUCP>
Sender: n...@cit-vax.Caltech.Edu
Reply-To: s...@tybalt.caltech.edu.UUCP (Sho Kuwamoto)
Organization: California Institute of Technology
Lines: 53
Keywords: window human computer interface
In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
>Finally (if you do have multitasking) It gets worse (as I percieve it) on
>an abstract level...when two windows are on top (side by side) why should
>you choose one over the other in putting a menu bar up for that one? Can
>you really design a system which unnecessarily defines user activity in a
>serial manner and *predict* the type of applications you will see in the
>future.
>You wind up limiting your user interface today and for the future.
Enlighten me. If you have two windows side by side on a Sun, what
happens when you type something from the keyboard? Why should you
choose one over the other in sending characters to it for that one?
Can you really design a system which unnecessarily defines user
activity in a serial manner and *predict* the type of applications you
will see in the future.
You wind up limiting your user interface today and for the future. :-)
In either case, it seems that certain events can only be posted to the
active window (whether or not it is topmost) and you are always going
to have this type of problem. In response to someone who said the
Amiga system was slightly better because it has a seperate button for
the mouse, Get REAL! The Amigas menu bar switches depending on the
active windows, it's just that you can't see it until you hit the
right button.
What happens with context-sensitive popup menus when the program has
no windows open? Say you're running a memory based word processor and
you have two enormous files to edit. You edit the first one, close
it, and edit the second one. Where do you click to get your popup
menus when there are no open windows?
Another thing that scares me. Customizable mice seem fine for a multi
user environment; if I get an account on a new Sun, I copy over my
setup files or whatever and everything is hunky dory, right? But for
a single user machine, I couldn't imagine what would happen if *my*
mac functioned differently from the one my friend has, which
functioned differently from the one the school has for public use.
There are definite problems with the Mac interface, such as the grow
box being in the right hand corner and all. However, these are all a
side effect of the way it was designed. Ease of use was built in
before Apple realized that power was important too. I think a three
button mouse would confuse the, uh, counfuse the... stuffing out of
beginners, especially if all three buttons were somehow necessary to
do the most basic, necessary tasks.
-Sho
SonicYouthREMBeatlesKateBushReplacementsResidentsHuskerDuSeveredHeadsArtOfNoise
ChrisAndCoseyJoyDivisionKillingJokeLaurieAndersonWireLouReedSkinnyPuppyBrianEno
(s...@tybalt.caltech.edu, s...@caltech.bitnet, ...!cit-vax!tybalt!sho)
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!phil
From: p...@Apple.COM (Phil Ronzone)
Newsgroups: comp.sys.mac
Subject: Re: A/UX tape backup
Message-ID: <7580@apple.Apple.Com>
Date: 7 Mar 88 19:58:44 GMT
References: <8659@allegra.UUCP> <76000127@uiucdcsp> <7447@apple.UUCP>
<4128@hoptoad.uucp>
Reply-To: p...@apple.UUCP (Phil Ronzone)
Organization: Ungermann-Bass Enterprises
Lines: 15
In article <4...@hoptoad.uucp> g...@hoptoad.uucp (John Gilmore) writes:
>Our Mac-II is ethernetted to a Sun with both cartridge and 6520 BPI
>magtape anyway. The more serious problem is that they left *dump* and
>*restore* off the Unix distribution! We have to do backups with tar,
>which doesn't support incremental backups.
Actually, we did have dump, restore, rdump and rrestore in there, but found a
really nasty set of bugs just before freezing the production master. So, we
yanked them. Almost, but not quite ... Sorry about that! :-)
For incrementals, we like find & cpio.
-------------------------------------------------------------------------------
Philip K. Ronzone, A/UX Technical Manager APPLELINK: RONZONE1
Apple Computer, Mail Stop 27AJ, 10500 N. DeAnza Blvd. Cupertino, CA 95014
UUCP: ...!{sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil
Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!alberta!ncc!uunet!husc6!
cmcl2!nrl-cmf!ames!pasteur!agate!eris!mwm
From: mwm@eris (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Keywords: window human computer interface
Message-ID: <7481@agate.BERKELEY.EDU>
Date: 8 Mar 88 05:04:40 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <241@eos.UUCP> <1735@ssc-vax.UUCP> <5674@cit-vax.Caltech.Edu>
Sender: use...@agate.BERKELEY.EDU
Reply-To: m...@eris.UUCP (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 90
In article <5...@cit-vax.Caltech.Edu> s...@tybalt.caltech.edu.UUCP
(Sho Kuwamoto) writes:
<In response to someone who said the
<Amiga system was slightly better because it has a seperate button for
<the mouse, Get REAL! The Amigas menu bar switches depending on the
<active windows, it's just that you can't see it until you hit the
<right button.
No, having a second mouse button _is_ a win. You don't gain any
confusion because there is an Interface Guideline which basically says
"thou shalt use the right mouse button for menus (and similar
things)." Very few programs use "similar things," and those that do do
it right. My experience is that people (artists, etc.) don't have
trouble with the second mouse button.
On the other hand, you _do_ lose some capabilities. Without doing any
customization, you lose the "mulitple select" capabilities of the
Amiga. I'm used to configuring programs (at least until I set up the
config files) by doing "mouse menu button; pull down config menu;
mouse select on all options; let up mouse menu button." On the Mac,
this turns into "mouse menu button; pull down config menu; select an
option and let up mouse button; repeat for all options." Much slower -
but still available on the Amiga for the inexperienced users.
<Another thing that scares me. Customizable mice seem fine for a multi
<user environment; if I get an account on a new Sun, I copy over my
<setup files or whatever and everything is hunky dory, right? But for
<a single user machine, I couldn't imagine what would happen if *my*
<mac functioned differently from the one my friend has, which
<functioned differently from the one the school has for public use.
You mean the Mac isn't customizable _at all_? You can't put in your
favorite desktop accessories, and can't load the function keys with
your favorite acceloraters? And what's this I heard about pop-up
menus on the Mac? They don't exist? Or don't count as customization?
Nah, having a customizable micro will work like it always has, and
like having a customizable shell or editor does on Unix - when you
need to work in a different environment, you either arrange to load
your favorite environment, or use the lcd version. The former means
booting your system disk on the Mac/Amiga/CPM-80/MSDOS/whatever, and
creating a login shell as you on a Unix system. No big deal.
And now you start getting to the _real_ wins with that second mouse
button. If you've got popup menus, how do you distinguish between a
click to go to an application and a menu click? I like having a
"follow-mouse" interface, instead of a "click-to-type" interface.
Consider the problem of getting the mouse from the application at the
bottom of the screen to the menu bar at the top. With two buttons,
it's easy - I just hold down the menu button as I go. With one button,
how do I prevent another window from activating while I move it?
As DRI demonstrated, the Mac menu interface can be put on an
two-button mouse with no problem. Until you demonstrate that a
two-button interface (pop up menus + followmouse, or some such) can be
adequately dealt with (by that, I mean that you don't have to drive
the window manager with two hands) on a one-button mouse, the
one-button mouse will have to be considered inferior. Of course, Apple
may have done it right, and left hooks in the software for more
buttons. I know Amiga did.
<What happens with context-sensitive popup menus when the program has
<no windows open? Say you're running a memory based word processor and
<you have two enormous files to edit. You edit the first one, close
<it, and edit the second one. Where do you click to get your popup
<menus when there are no open windows?
The same place you click to reactive it under multifinder :-).
Seriously, there are lots of answers, depending on how the rest of the
window manager works.
And from another source:
>> And don't forget the Mac was the first 'commercially available'
>> personal computer to feature a windowing interface and a secondary
>> input device known as a mouse.
Not hard to not forget - it's not true. Or don't you remember the
Lisa? If you define "personal computer" to be distinct from "home
computer," then you can also count the Star as a predecessor to the
Mac.
The Mac wasn't the first - it was just the first to not flop.
<mike
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, m...@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. m...@ucbjade.BITNET
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!lsr
From: l...@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: 2 button mouse
Message-ID: <7602@apple.Apple.Com>
Date: 9 Mar 88 03:00:08 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <241@eos.UUCP> <1735@ssc-vax.UUCP>
<5674@cit-vax.Caltech.Edu> <7481@agate.BERKELEY.EDU>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 37
Keywords: window human computer interface
In article <7...@agate.BERKELEY.EDU> m...@eris.UUCP (Mike
(My watch has windows) Meyer) writes:
>button. If you've got popup menus, how do you distinguish between a
>click to go to an application and a menu click? I like having a
>"follow-mouse" interface, instead of a "click-to-type" interface.
Clearly, if you have an interface in which you activate a window just by
moving over it, then you can't put mouse-sensitive areas anywhere on the
screen. In this case, using 2 buttons would make sense.
The Apple human interface guidelines say that moving the mouse with the
button up is not supposed to do anything (such as activating a window),
except possibly changing the cursor shape. It requires an explicit click on
the button to activate a window.
It seems to me that the mouse can get moved accidentally while typing, and
that would cause windows to be activated. For me (a long-time Mac user),
this would take some getting use to, but I can see how some people would
prefer in order to reduce the number of clicks.
>two-button mouse with no problem. Until you demonstrate that a
>two-button interface (pop up menus + followmouse, or some such) can be
>adequately dealt with (by that, I mean that you don't have to drive
>the window manager with two hands) on a one-button mouse, the
>one-button mouse will have to be considered inferior.
This doesn't make sense. There is no question that the interface you
describe would not work well on a machine with 1 mouse button. That doesn't
make a 2-button mouse or a 2-button interface better. You would have to do
an experiment with the Mac interface and the Amiga or Sun interface and see
how well people perform on the same tasks (ie, selecting a menu item,
copying data from 1 window to another, etc.).
--
Larry Rosenstein, Object Specialist
Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014
AppleLink:Rosenstein1 domain:l...@Apple.COM
UUCP:{sun,voder,nsc,decwrl}!apple!lsr
Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!mailrus!ames!
necntc!ima!think!barmar
From: bar...@think.COM (Barry Margolin)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: 2 button mouse
Message-ID: <17702@think.UUCP>
Date: 10 Mar 88 02:08:51 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <241@eos.UUCP> <1735@ssc-vax.UUCP>
<5674@cit-vax.Caltech.Edu> <7481@agate.BERKELEY.EDU> <7602@apple.Apple.Com>
Sender: use...@think.UUCP
Reply-To: bar...@fafnir.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 50
Keywords: window human computer interface
This whole argument about the number of buttons on the mouse is silly.
The Mac already has a virtual 16-button mouse. Where are all those
other buttons? One of them is on the mouse itself: you can
double-click (and some applications even make use of triple-clicking).
The rest of them are on the keyboard: you can hold down Shift,
Command, or Alt (and Control, on the new keyboards?) in order to
modify the meaning of a click. Thus there are eight combinations of
modifier keys and either click or double-click, making sixteen ways to
click the mouse.
I've used 3-button systems (Symbolics Lisp Machines and Sun
Workstations) and 1-button Macs; I find them all relatively easy to
use, but I have a good memory for arbitrary keystrokes (and Symbolics
machines have a line at the bottom of the screen that lists what all
the mouse clicks currently do). I also taught my parents, who are
completely computer illiterate, how to use the Mac. In this case, I
am very glad that it only has one button, as it was hard enough
teaching them how to use the menus, and double-clicking was a major
achievement. I can just imagine them calling me up at night to ask
whether they are supposed to push the left button or the right button
to use the menu.
The Mac user interface is designed not to tax the memory of extremely
unsophisticated users. This is the reason for the one button and the
constant menu bar. Unsophisticated users should be able to do
everything they want without ever having to double-click or click
while holding a modifier key. MacWrite is a good example of this
philosophy: double-click lets you select a word, but this is just a
shortcut for click/drag; shift-click lets you select a big region
without having to drag across the entire thing. MacPaint is a bad
example: you need to shift-click/drag in order get constrained motion.
A good analogy for all this is Emacs-style text editors compared to
dedicated word processors. Word processors generally use arrow keys
to move around and have lots of specialized function keys with
appropriate labels; they are easy for computer-illiterate secretaries
to learn. Emacs is based on memorizing only-somewhat-mnemonic control
sequences. We power users tend to find the word processors extremely
limiting; there's a dozen or two function keys, and that's all you can
do. But a computer neophyte would find Emacs completely overwhelming.
Everywhere I've been where Emacs is used, I've seen lots of Emacs
wallcharts pasted above terminals. Apple didn't want people to have
to post MacWrite wallcharts.
Barry Margolin
Thinking Machines Corp.
bar...@think.com
uunet!think!barmar
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mcb
From: m...@oddjob.UChicago.EDU (Not prince Hamlet . . .)
Newsgroups: comp.sys.mac
Subject: Re: 1 vs 3 button mice issue
Message-ID: <14485@oddjob.UChicago.EDU>
Date: 10 Mar 88 03:57:59 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <14458@oddjob.UChicago.EDU> <1739@ssc-vax.UUCP>
<4737@sdcsvax.UCSD.EDU>
Reply-To: m...@oddjob.uchicago.edu (Not prince Hamlet . . .)
Organization: U of Chicago- Golden Apple Corps
Lines: 35
I'm disinclined to go with a three-button mouse because, as I said, it's
been shown that for non-experts, a one-button mouse is easier and faster to
use (I don't just believe Apple, I happen to KNOW that they did this research).
The mouse should be as simple as possible: a tool for pointing and doing
something. What I would like to see instead of more buttons would be a row of
"modifier buttons" along the bottom edge of the keyboard. These would be used
in much the same way as as keys like shift and option are often used now. I
see two main advantages to this scheme as opposed to a multi-button mouse
scheme: you get better control (at least 4 buttons are feasible), and you
don't clutter up the mouse (and confuse novice users). Note that REAL MEN
could have special mice with the buttons on them, if they wanted to.
As I see it, there are a couple of issues / problems that would have to be
addressed first:
1) This would require a bigger keyboard (and maybe left/right handed models)
2) For the sake of the novice / casual user of an application, the modifier
buttons should only duplicate functionality which is available by "normal", if
cumbersome means.
3) The use of the buttons should be consistent across applications. This
is something that Sun and IBM are apparently incapable of understanding- the
single most important part of a user-interface is that it must ALWAYS behave
the same way. Offhand, I can think of a couple of "standard" modifier
buttons:
- Activate (same as double-clicking on an application's icon)
- Copy (same as option-dragging on a file's icon)
- Select Unit (same as double-clicking on a word)
Obviously, applications would be allowed to define their own meanings for
unused modifier keys, but the "secret code" approach to functionality
(as typified by such monsters as MS Word 3.0) would have to be discouraged.
-Matt
--
Matt Bamberger "And while you watch and wonder,
1005 E. 60th St., #346 I'll pull the world asunder
Chicago, IL 60637 And show you who I am."
312-753-2261 - Supertramp
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!ssc-vax!benoni
From: ben...@ssc-vax.UUCP (Charles L Ditzel)
Newsgroups: comp.sys.mac
Subject: Re: 1 vs 3 button mice issue
Message-ID: <1759@ssc-vax.UUCP>
Date: 11 Mar 88 04:32:24 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <14485@oddjob.UChicago.EDU>
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 29
In article <14...@oddjob.UChicago.EDU>, m...@oddjob.UChicago.EDU
(Not prince Hamlet . . .) writes:
> The mouse should be as simple as possible: a tool for pointing and doing
> something. What I would like to see instead of more buttons would be a row of
*it* should be as simple as possible for *NOVICES*! again why laden
experienced users (users that 10 minutes before where novices :->) with
weak tools.
> "modifier buttons" along the bottom edge of the keyboard. These would be used
oh no! The linking with of keys and mouse is not 1) egonomic and 2) a weak
replacement for mouse buttons. Why would anyone add keyboard keys rather than
have the simpler and more logical multiple mouse buttons. I think users would
be even MORE confused by having additional keys that ACT on the mouse...i can
understand a mouse/keyboard RESET button (which would reset the keyboard and
mouse configuration to it's default configuration). Tho' i see problems with
this too...
> 3) The use of the buttons should be consistent across applications. This
> is something that Sun and IBM are apparently incapable of understanding- the
Apple also doesn't understand this consistency either, note that
when you click (select) a file from you Mac hard disk window and drag it to
your floppy window you do a COPY. When you try to to the same only instead
make the destination directory a hard disk directory ... you MOVE. Note this
is an operating system inconsistency...it makes sense but is inconsistent.
Second Apple has a good standard but is not consistent across appliations
(even MacWrite and MacPaint as mentioned by the previous poster).
Also look at Interleaf on the Mac. Their is no enforced standard.
FYI. Sun also has a chapter in their SunView Programmer's book on Sun user
interface design.
Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!beta!hc!ames!claris!apple!lsr
From: l...@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: UI Consistency (was 1 vs 3 button mice issue)
Message-ID: <7751@apple.Apple.Com>
Date: 22 Mar 88 01:46:39 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu>
<1710@ssc-vax.UUCP> <14485@oddjob.UChicago.EDU> <1759@ssc-vax.UUCP>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 40
In article <1...@ssc-vax.UUCP> ben...@ssc-vax.UUCP (Charles L Ditzel) writes:
>
>Apple also doesn't understand this consistency either, note that
>when you click (select) a file from you Mac hard disk window and drag it to
>your floppy window you do a COPY. When you try to to the same only instead
>make the destination directory a hard disk directory ... you MOVE. Note this
>is an operating system inconsistency...it makes sense but is inconsistent.
The short answer is that sometimes it is necessary to break the rules, in the
name of common sense.
On the Lisa, moving an icon always moved the actual document. If you wanted
to copy the document to another disk you had to select the icon and
duplicate it. The duplicate command was modal; the duplicate icon flashed
until the user moved it somewhere. If you clicked outside the flashing
icon, you got a chance to cancel the operation.
On the Xerox Star (as I remember it), you would select an icon, hit the copy
or move button and select the destination. This was all nice and
consistent. Also on the Star you printed a document by dropping it on a
printer icon. The question that arises is what happens if the user moves a
document onto the printer -- does the document get printed and then deleted
from the disk?
>Also look at Interleaf on the Mac. Their is no enforced standard.
There has never been any enforced standard. Apple does not revoke a
company's certified developer status if their application doesn't follow the
guidelines. Interleaf is a case where the developer decided that their
target user was someone who was using Interleaf on another machine, and that
they should make the Mac version havethe same interface. (It also made
porting the S/W easier, because they could port more of the code.)
--
Larry Rosenstein, Object Specialist
Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014
AppleLink:Rosenstein1 domain:l...@Apple.COM
UUCP:{sun,voder,nsc,decwrl}!apple!lsr