[comp.sys.mac] Poor Mac Design Philosophy

norman@sdics.ucsd.EDU (Donald A. Norman) (10/09/87)

Every N months someone posts a note saying, help, my apple menu icon
blinks and I can't shut it off.

Others patiently explain that this means the alarm clock is ringing:
find it and shut it off.  Everyone feels stupid (but they shouldn't --
it is a sign of poor design).

This is yet another example of how Macintosh design fails to follow
its own guidelines.  How should anyone ever know this is an alarm? Yes
it is in the manual, but buried. And manuals are unread.  And even if
it is read, who remembers 6 months afterwards when the alarm first
goes off?.  The proper design is self-explaining.  Example: when the
alarm goes off, the Apple icon should change to the phrase ALARM ON
and then it can blink.  (Not perfect: some will think this means that
the power supply will explode unless they immediately turn off the
machine and clear the building -- a not unreasonable interpretation).
If the menu line or screen space were not so limited the better idea
is to put a new icon on the desk that explained things and provided a
place to click it off (without the clock DA).

The same madness is responsible for the proliferation of "power keys."
shift control option command double-click. The mouse is simplified
with only 1 button, but because this is really inadequate, we must
memorize undocumented secret keys.  An alternative would be to add a
few LABELLED keys to the keyboard. Or to make reminders readily
available, perhaps a context sensitive pop-up menu.  Suppose
shift-option-command-? always brought up a context sensitive listing
of what power keys were available at the moment. Make learning easier.
And if you liked, you could use the menu and bypass the contortions.

Donald A. Norman
Institute for Cognitive Science C-015
University of California, San Diego
La Jolla, California 92093
norman@nprdc.arpa    	{decvax,ucbvax,ihnp4}!sdcsvax!ics!norman
norman@sdics.ucsd.edu	norman%sdics.ucsd.edu@RELAY.CS.NET

blh@vlsi.cs.cmu.edu (Bruce Horn) (10/10/87)

Although I mostly agree with Don Norman's view, I feel that he in
particular, and people in general, tends to forget the circumstances behind
the design of the Macintosh.  Limited ROM, RAM and *time* made us choose
what we felt were the most important things to work on.  Of course, many of
us in the Mac group were aware of these problems, but the time/memory wasn't
there to allow us to fix them.  The blinking Apple was one of those things.
Certainly now that Apple has time to take care of problems like these, they
will;  but again, there will be some things with higher priority than
others.  Completely user-centered design takes lots of time, money, and
memory (but I would agree that it is worth it.)

Also, Don Norman suggests several alternatives to hidden power keys,
including context sensitive help, menus and so on.  These are valid
*alternatives*, but as people get more used to the system, having to go
through these different contexts can be a waste of time.  Power keys are
just part of the context/expression tradeoff:  you can have complicated
expressions (command-option-shift click on the xyz icon) or context shift
(new window or dialog), followed by a simple expression (just a click on the
option you want).  My "perfect system" would allow both options.

Apple needs to continue to ensure that extensions to the user interface are
consistent, *including* the power keys.  For example, option-drag should
mean "copy" in all contexts where this makes sense.

I don't agree with his implication that the one-button mouse is the reason
that there are unmemorizable "power keys."  Yes, people tend to want to
classify clicks more specifically to add functionality, but there are other
ways to do this (see paragraph above).  Also, have you ever used a three
button mouse with the X window system?  "Power clicks" with multiple-button
mice are just as horrible as "power keys" are on the Mac.

His example of "alarm on" being threatening to some people reminded me of
our first naive-user reaction to the system error bomb:  she thought her Mac
was going to blow up!  Somebody suggested that we replace the bomb with a
flat tire, but we never got around to it.

To paraphrase Alan Kay, "The Mac is the first computer worth bashing".  Go
ahead and bash constructively--that's one way that the machine will be
improved.  I wouldn't say globally that the Mac was poorly designed...but
I'm biased.



-- 
Bruce Horn, Carnegie Mellon CSD
uucp: ...!seismo!cmucspt!cmu-cs-vlsi!blh
ARPA: blh@vlsi.cs.cmu.edu

isle@dartvax.UUCP (Ken Hancock) (10/10/87)

In article <400@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A. Norman) writes:
>Others patiently explain that this means the alarm clock is ringing:
>find it and shut it off.  Everyone feels stupid (but they shouldn't --
>it is a sign of poor design).
>
>This is yet another example of how Macintosh design fails to follow
>its own guidelines.  How should anyone ever know this is an alarm? Yes
>it is in the manual, but buried. And manuals are unread.

Good grief...what do you want it to do?  If people don't want to read
manuals, fine...but then don't complain every time you find something
that you don't know right off the back.  Sheez...I can just see the
dialog boxes.

      __________________________________________________
      |  Excuse me, Mr. User...your alarm clock is on. |
      |________________________________________________|

And then of course the users would complain that the System file
is 500K.... Just goes to show you can't win.

Ken

-- 
Ken Hancock      UUCP: isle@dartvax
               BITNET: isle@u2.dartmouth.edu

DISCLAIMER: If people weren't so sue-happy, I wouldn't need one!

straka@ihlpf.ATT.COM (Straka) (10/12/87)

In article <400@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A. Norman) writes:
>available, perhaps a context sensitive pop-up menu.  Suppose
>shift-option-command-? always brought up a context sensitive listing
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
>of what power keys were available at the moment. Make learning easier.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>And if you liked, you could use the menu and bypass the contortions.

It appears that the above (although perhaps a bit difficult to implement at this
point in time) is a lucid and clear way of handling the problem.
However, the user interface could become rather clumbsy when forced to make
additional menu choices *all* the time.

Perhaps instead of "always", however, a standard menu item under the "apple"
menu (like "About ...") could be used to detail the options (a separate menu
pick would be necessary to tell the application what action would be
requested).

Another alternative would be to have a single key (like "option") or
combination always (perhaps under the users pre-selected control) bring up
the list when the function is executed.  This might be more practical.

Come on, all you human-factors types at Apple.  A bit of polishing of this
aspect of the Human-Machine interface would be appreciated!
-- 
Rich Straka     ihnp4!ihlpf!straka

Advice for the day: "MSDOS - just say no."

avjewe@cvl.umd.edu (Andrew V Jewell) (10/13/87)

The finder has a SPECIAL menu right?
So, why doesn't it include items like
   REBUILD DESKTOP
and
   RESET PARAMETER RAM

It seems this would be amazingly easy to implement,
easier to document
and N times more mac-like


                                 Andy Jewell



           Am I missing something obvious here or what?

singer@endor.harvard.edu (Richard Siegel) (10/14/87)

In article <2514@cvl.umd.edu> avjewe@cvl.UUCP (Andrew V Jewell) writes:
>
>The finder has a SPECIAL menu right?
>So, why doesn't it include items like
>   REBUILD DESKTOP
>and
>   RESET PARAMETER RAM

	Because special system-level functions like that are functions
that are only needed in specific conditions, i.e. when the Desktop file
gets trashed or when the Parameter RAM gets corrupted -- these are both
things that in general aren't supposed to happen.

	I realize that for a Mac Hacker these functions are handy, but for
a novice user they would be only confusing and somewhat threatening.

>It seems this would be amazingly easy to implement,

	This is true, but see above.

>easier to document
	
	Easier to document than WHAT? It's equally trivial to document either
type of function.

>and N times more mac-like

	Again, more Mac-Like than what? The Finder is a program that
has no analog anywhere in the personal computer industry. True, there are
Mac-alike "desktop" things like Windows and GEM, but note what I just said:
the Finder is the prototype for graphical operating-system interfaces.

>
>                                 Andy Jewell

		--Rich


**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies, Inc).

* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer    *
* Customer Support  | singer@endor.harvard.edu			    *
* THINK Technologies, Inc.  (No snappy quote)                       *

avjewe@cvl.umd.edu (Andrew V Jewell) (10/14/87)

In article <2991@husc6.UUCP> singer@endor.UUCP (Richard Siegel) writes:
>In article <2514@cvl.umd.edu> avjewe@cvl.UUCP (Andrew V Jewell) writes:
>>
>>The finder has a SPECIAL menu right?
>>So, why doesn't it include items like
>>   REBUILD DESKTOP
>>and
>>   RESET PARAMETER RAM
and the many other functions currently accessed in non-intuitive ways.
>
>	Because special system-level functions like that are functions
>that are only needed in specific conditions, i.e. when the Desktop file
>gets trashed or when the Parameter RAM gets corrupted 

Empty folppies with 15K in them need the desktop rebuilt to recover 8K
Sometimes (esp. on a hard disk) the Finder fails to import a file's icon, or 
doesn't add an application to the list (for double-clicking a document)
Rebuilding the DeskTop fixes this too.


>	I realize that for a Mac Hacker these functions are handy, but for
>a novice user they would be only confusing and somewhat threatening.

I thought the point of menus was to include just about everything that the
application can do, so that a novice user can see whats available without
acting on it.


      
>>easier to document
>	Easier to document than WHAT?
There is always a section for a description of each menu item, the author
knows where to put it and the user knows where to look.
Arcane key-combinations are often hidden within descriptions of other things.



>>and N times more mac-like
>	Again, more Mac-Like than what?
A simple interface, where all operations can be accessed in a consistent
fashion (eg menus).


>>   Andy Jewell
>	--Ric qn whabelievblemsthis aB

dtw@F.GP.CS.CMU.EDU (Duane Williams) (10/16/87)

| 	Again, more Mac-Like than what? The Finder is a program that
| has no analog anywhere in the personal computer industry. True, there are
| Mac-alike "desktop" things like Windows and GEM, but note what I just said:
| the Finder is the prototype for graphical operating-system interfaces.

A prototypical Mac program is defined by Apple's User Interface Guidelines.
Sadly, the Finder is not prototypical, because it deviates from the
Guidelines in some respects.  There were no instances of the prototype among
the early Mac programs (Finder, MacWrite, MacPaint).  Of course, any day now
the Finder may become prototypical, because the rules (which Apple
criticizes developers for breaking) are constantly changing.

Duane.Williams@cs.cmu.edu

kdmoen@watcgl.waterloo.edu (Doug Moen) (10/16/87)

In article <400@sdics.ucsd.EDU> norman@sdics.UUCP (Donald A. Norman) writes:
>>Others patiently explain that this means the alarm clock is ringing:
>>find it and shut it off.  Everyone feels stupid (but they shouldn't --
>>it is a sign of poor design).
>>
>>This is yet another example of how Macintosh design fails to follow
>>its own guidelines.  How should anyone ever know this is an alarm? Yes
>>it is in the manual, but buried. And manuals are unread.

In article <7342@dartvax.UUCP> isle@dartvax.UUCP (Ken Hancock) writes:
)Good grief...what do you want it to do?  If people don't want to read
)manuals, fine...but then don't complain every time you find something
)that you don't know right off the back.  Sheez...I can just see the
)dialog boxes.
)
)      __________________________________________________
)      |  Excuse me, Mr. User...your alarm clock is on. |
)      |________________________________________________|

This sounds like a perfectly reasonable idea.  When the alarm clock
goes off, a small, non-preemptive window pops up in the upper right
corner of the screen saying "It's x o'clock and your alarm is ringing".
Closing the window turns off the alarm clock.
I really don't understand your sarcastic tone.

I hope Apple will consider putting something like this into System 4.2.
It's probably easy to implement in a MultiFinder environment: the
alarm window could be put into the DA Handler layer.
-- 
Doug Moen
University of Waterloo Computer Graphics Lab
UUCP:     {ihnp4,watmath}!watcgl!kdmoen
INTERNET: kdmoen@cgl.waterloo.edu

lriggins@afit-ab.arpa (L. Maurice Riggins) (10/17/87)

An ideal replacement for the alarm clock was recently released to the public
domain by Jam Software.  It's a one-alarm demo of their Smart Alarms software.
While it doesn't activate the advance warning or recurring interval buttons, it
does allow the user to post a dialogue note that displays when the alarm sounds.Granted this is far less powerful than the full Smart Alarms but a heck of a lotmore capable than the Apple alarm at the same price ... FREE!


-- 

Maurice                lriggins@afit-ab.ARPA