HI tradeoffs (was Type/Creator Codes)
HI tradeoffs (was Type/Creator Codes)
- Subject: HI tradeoffs (was Type/Creator Codes)
- From: Fritz Anderson <email@hidden>
- Date: Tue, 15 May 2001 13:03:26 -0500
Just comments, not arguments (except to the extent that all opinions
are arguments).
At 10:31 AM -0500 5/15/2001, Michael Dagate wrote:
...
I was working on a children's drawing program with a main tool tray
on the side. As you click a main tool, the related sub-tools
appeared at the bottom. We discovered that children didn't associate
(conceptually) the main tool with it's sub-tools. So, we added an
animation sequence to show the kids that clicking a main tool
created the sub-tools. It was a subtle, but very effective, change.
Yes! There are three things Cocoa developers can take from this:
(1) User observation is crucial. (2) If the rest of the world
doesn't understand your program, the productive solution is to
understand the rest of the world better. (3) Animations are not
necessarily just eye-candy and demo-food.
Aqua is a very *attractive* user interface, but Windows is still
more user-friendly. This may be shocking to you, but I have very
specific reasons, all of which can be fixed in Aqua:
Many of the points you make are matters of custom, or of differing
priorities. It seems to me that the Microsoft environment was never
as serious about the windowing metaphor as the Apple environment was
-- ultimately, it was assumed that the proper extent of a single
program's human interface was the whole screen, not a window. The
Visual development tools' HI was an exercise in tiling one rectangle.
The result was that the actual files the user was editing could never
be bigger than a third of the screen, because it had to be tiled with
the munificent features of the MS Visual tools. Similar thoughts
have been exchanged on the Project Builder list.
The priority in Mac HI design has always been that the actual work
the user does should have first claim on resources. This is the
ghost of Jef Raskin, radical minimalist. It is a difficult priority
to enforce, because the people divvying up the screen are developers
and marketers, not users. From this priority follows a high
tolerance for overlapping windows, and a low tolerance for on-screen
features. The marketers and developers can only divvy up single
windows -- but the user gets the final say, by sizing, and
overlapping, those windows.
2. Windows should be sizable from all sides. I find myself
frequently needing to move a window up and left so that I can (in a
separate step) make it bigger. This can and should be a single step
operation.
It _can_. It would be convenient for some people for a few seconds a
day. It's eight pixels (at least) off of each side of the user's
work (or of the visibility of other windows). The cost is 14 kPixels
per typical window, with zero added information, plus 12 kP for the
title bar, which is about a third information. Aqua reduces the
visual overhead of window management to (eyeballing) 30 pixels across
the top, and 15 at the bottom right; 12+ kP, about a third
informative, and mostly out of the visual field. Everything else is
business. Aces.
You miss edge resizing because it is part of your mental model for
windows, and you place windows initially to take advantage of it. I
find I _very_ rarely place windows so they need drag-and-resize,
because I never developed the habit. That's why your point about
user observation is so brilliant -- no developer can see around the
skills and habits he has come to assume are obvious.
So this may not be the choice a Windows veteran would have made for
the windowing system, but it was a rational choice. As Cocoa
programmers, we ought to think more about tradeoffs between work and
features, and between area and information.
3. OS X should make more use of cursors to provide visual feedback.
For example, Windows uses a plus sign during drag and drop
operations to indicate when a drop target can accept a drop object.
I know you can highlight a control with a border to indicate this,
but the cursor thing really helps.
I like it that Cocoa gives you the + cursor automatically to indicate
copying, in addition to target highlighting for acceptance. Again, I
think part of your problem is in being used to one cue, and not
accepting another. As a programmer, I often find it tempting to
skimp on drop-acceptance highlighting, but what you say reminds me
that I ought to make acceptance as clear as possible. One problem
with cursors, though -- especially with dragging opaque or
translucent objects -- is that changes in the cursor can be missed
easily. Not every user has a pixel-perfect eye, and not every user's
mental model of moving objects accommodates their hands' changing
shape as they move their arms. The Macintosh should not be an
(unintentionally) psychedelic experience.
Contextual menus have been part of Mac OS for about five years now.
I agree everybody should use them more. I'm happy that Cocoa makes
use of a second mouse button and a scroll wheel free to developers.
But I do think developers should design their applications to work,
work well, and work fully, with a single-button mouse. Again: The
mouse, to many users, is not an instrument -- it _is_ the user's
hand. A single-button mouse presses/grasps, and releases/ungrasps.
That's not a bad or stupid way of dealing with the world. Most
people do most things without instruments, and it would be a shame to
present them with an instrument by default.
Note to self: Make things somatic. A human interface should have
unsurprising physics.
-- F