Discussion:
any sightings of tear-off menus at MacWorld?
(too old to reply)
Eric Marshall
2001-01-12 08:44:42 UTC
Permalink
I'd hate to think they're gone forever...

Thanks in advance.
Scott Stevenson
2001-01-12 18:11:13 UTC
Permalink
On Friday, January 12, 2001, at 08:44 AM, Eric Marshall wrote:

> any sightings of tear-off menus at MacWorld?

Not that I saw.

- Scott


--
Scott Stevenson
http://wildtofu.com/
http://maxify.com
Miller, Mark D
2001-01-16 12:01:33 UTC
Permalink
I would like to speak up in favor of this feature in Mac OS X, too.

Tear-off menus are a brilliant GUI feature which saves me a lot of time
mousing around and/or switching between the mouse and keyboard to perform
repetitive tasks.

This is one of the last GUI features that would make the Mac OS X experience
perfect for me. (Hooray for the Task Bar and relocatable Dock!)

--
Mark Miller
***@boeing.com
The Object Is The Advantage



-----Original Message-----
From: Eric Marshall [mailto:***@emieng.com]
Sent: Friday, January 12, 2001 8:45 AM
To: macosx-***@omnigroup.com
Subject: any sightings of tear-off menus at MacWorld?


I'd hate to think they're gone forever...

Thanks in advance.
Jim Wilkinson
2001-01-16 13:18:18 UTC
Permalink
On Tuesday, January 16, 2001, at 08:00 PM, Miller, Mark D wrote:

> I would like to speak up in favor of this feature in Mac OS X, too.
>
> Tear-off menus are a brilliant GUI feature which saves me a lot of time
> mousing around and/or switching between the mouse and keyboard to perform
> repetitive tasks.

It's one of those things you don't miss until you have the opportunity to try. Then you find out how much more efficient it is - especially with the many useful sub-menus such as in Word2001.

Definitely on my wish list.

Jim
Bill Coleman
2001-01-16 14:19:15 UTC
Permalink
On 1/16/01 3:00 PM, Miller, Mark D at ***@West.Boeing.com wrote:

>I would like to speak up in favor of this feature in Mac OS X, too.
>
>Tear-off menus are a brilliant GUI feature which saves me a lot of time
>mousing around and/or switching between the mouse and keyboard to perform
>repetitive tasks.

TOM were innovative on NeXTstep because the menus were so small and the
screen so large. Given that it is hard to hit a small target from a long
distance away, moving selected menus closer to a work location was a
human interface win.

Even in the case of the right-button menu, TOM are a win, since the
invisible top level menu had to be navigated first, then the second level
menu. By tearing off a menu and keeping it visible, you can move closer
to your destination in one step.

But, with the adoption of the Mac-like menu bar, TOM make less sense. The
top-level menu is always visible. Since it is at a screen edge, it
becomes infinitely tall and much easier to hit with accuracy. The visible
first-level menus provide a large target to move to, even across a large
screen.

Radius also copied the TOM concept with their larger screen displays, as
a system extension. The need for TOM diminished when Apple improved the
mouse acceleration algorithms.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Jeff Biggus
2001-01-16 15:28:41 UTC
Permalink
On Tuesday, January 16, 2001, at 03:17 PM, Bill Coleman wrote:

> But, with the adoption of the Mac-like menu bar, TOM make less sense. The
> top-level menu is always visible. Since it is at a screen edge, it
> becomes infinitely tall and much easier to hit with accuracy. The visible
> first-level menus provide a large target to move to, even across a large
> screen. ... The need for TOM diminished when Apple improved the
> mouse acceleration algorithms.

I have to disagree with this. TOMs allow for the user to graphically place menus and submenus at places which are convenient for a given task. They can function like all the other tool palettes which people find so handy. It's all about the geometry of accessing your controls, which can vastly improve the efficiency of the user. Having to always go up to the menu bar, even a "good" menu bar, is a very awkward exercise, especially for oft repeated tasks. It wastes time and hand movement. It's better ergonomic design, even in Aqua, to make available TOMs. This should be up to the user if nothing else.

To the Mac user, the GUI experience has toggled on this issue many times. OS 7 could do it with various 3rd-party extensions, then on OS 8 I couldn't anymore for some reason. Then OS X Server allowed it, which was a blessing. Now OS X doesn't. NeXT had it. Clearly there is a demand for it by a certain segment. Most OSXS people I know lament TOMs being gone in Aqua. Why doesn't Apple allow for it, even as an advanced feature? I wish they would at least give a reason.

I've been using Aqua for almost a year now and there is still a very clear benefit to be had by using TOMs. Aqua has done nothing notable to alleviate this. Especially since the menu bar doesn't follow you from monitor to monitor in multi-headed systems (a gigantic pain in the rump).

Question: Does Aqua allow for 3rd partys to inherit and extend the behavior of menus?

TOMs and a sophisticated contextual menu system are two GUI features that Aqua sorely lacks. Allowing access to menu items via the contextual menus would be a welcomed feature as well.

My thoughts on a snowy Tuesday...
-Jeff
John Fieber
2001-01-16 20:01:26 UTC
Permalink
On Tue, 16 Jan 2001, Bill Coleman wrote:

> But, with the adoption of the Mac-like menu bar, TOM make less sense. The
> top-level menu is always visible. Since it is at a screen edge, it
> becomes infinitely tall and much easier to hit with accuracy. The visible
> first-level menus provide a large target to move to, even across a large
> screen.

But when the menu bar is an entire screen or two away, it is just
isn't quite as nifty of a situation as you make it out to be. I
don't care at all for the top-of-the-screen menu in a
multi-monitor setup but as long as we are more or less stuck with
it, tear-off menus can go a LONG way toward making it a more
tolerable situation.

-john
Ashley Aitken
2001-01-16 23:58:12 UTC
Permalink
Sorry Bill,

I don't agree!

Tear Off Menus are a real plus for power users who don't want to navigate two or three menus. Remember, it's not just the top level menus that tear off - any menu should.

Steve et al's push for a simple user for the novice user is fine but why restrict the power user. Perhaps they are worried that newbies will tear off a menu by mistake and worry :-)

For me, they are a great way of making a simple user interface POWERFUL (at least whilst Apple doesn't have a generic system-wide application toolbar system that is fully customisable).

Cheers,
Ashley.



>>> Bill Coleman <***@mac.com> 01/17/01 06:22 AM >>>
On 1/16/01 3:00 PM, Miller, Mark D at ***@West.Boeing.com wrote:

>I would like to speak up in favor of this feature in Mac OS X, too.
>
>Tear-off menus are a brilliant GUI feature which saves me a lot of time
>mousing around and/or switching between the mouse and keyboard to perform
>repetitive tasks.

TOM were innovative on NeXTstep because the menus were so small and the
screen so large. Given that it is hard to hit a small target from a long
distance away, moving selected menus closer to a work location was a
human interface win.

Even in the case of the right-button menu, TOM are a win, since the
invisible top level menu had to be navigated first, then the second level
menu. By tearing off a menu and keeping it visible, you can move closer
to your destination in one step.

But, with the adoption of the Mac-like menu bar, TOM make less sense. The
top-level menu is always visible. Since it is at a screen edge, it
becomes infinitely tall and much easier to hit with accuracy. The visible
first-level menus provide a large target to move to, even across a large
scree.

Radius also copied the TOM concept with their larger screen displays, as
a system extension. The need for TOM diminished when Apple improved the
mouse acceleration algorithms.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
CLOUT
2001-01-17 09:19:57 UTC
Permalink
The great thing about having tear off menus is that you don't have to tear
them off! They take away nothing from the experience even if you hate them.
It's just added functionality. If you don't like tear offs just navigate
the menus the way you like if you do like them tear them off to your hearts
content. This is really a no brainer, they should be added back into the
interface.

-----Original Message-----
From: macosx-talk-***@omnigroup.com
[mailto:macosx-talk-***@omnigroup.com]On Behalf Of John Fieber
Sent: Tuesday, January 16, 2001 11:00 PM
To: macosx-***@omnigroup.com
Subject: RE: any sightings of tear-off menus at MacWorld?


On Tue, 16 Jan 2001, Bill Coleman wrote:

> But, with the adoption of the Mac-like menu bar, TOM make less sense. The
> top-level menu is always visible. Since it is at a screen edge, it
> becomes infinitely tall and much easier to hit with accuracy. The visible
> first-level menus provide a large target to move to, even across a large
> screen.

But when the menu bar is an entire screen or two away, it is just
isn't quite as nifty of a situation as you make it out to be. I
don't care at all for the top-of-the-screen menu in a
multi-monitor setup but as long as we are more or less stuck with
it, tear-off menus can go a LONG way toward making it a more
tolerable situation.

-john
Karl Hsu
2001-01-17 23:04:17 UTC
Permalink
Well, I've seen several people (on MacOSX Server) tear them off by
accident, and not figure out how to "un" tear them...

Or just the annoyance of tearing them off by accident...

Karl


At 12:20 PM 1/17/01 -0500, CLOUT wrote:
>The great thing about having tear off menus is that you don't have to tear
>them off! They take away nothing from the experience even if you hate them.
>It's just added functionality. If you don't like tear offs just navigate
>the menus the way you like if you do like them tear them off to your hearts
>content. This is really a no brainer, they should be added back into the
>interface.
Andrew Weiss
2001-01-18 06:44:03 UTC
Permalink
On Wed, 17 Jan 2001, Karl Hsu wrote:

> Well, I've seen several people (on MacOSX Server) tear them off by
> accident, and not figure out how to "un" tear them...
>
> Or just the annoyance of tearing them off by accident...
>
> Karl

Yes I agree with this one... it is easy to tear off menus by accident and
it is also easy to open the wrong spring loaded folder by accident while
I'm trying to figure out in my head wear to place the file, or just
delaying too long before I drop it on an icon. I personally
hate both features... but that doesn't mean we shouldn't have them.

Andrew
Bill Coleman
2001-01-18 12:34:02 UTC
Permalink
On 1/16/01 18:28, Jeff Biggus at ***@frii.com wrote:

>On Tuesday, January 16, 2001, at 03:17 PM, Bill Coleman wrote:
>
>> But, with the adoption of the Mac-like menu bar, TOM make less sense. The
>> top-level menu is always visible. Since it is at a screen edge, it
>> becomes infinitely tall and much easier to hit with accuracy. The visible
>> first-level menus provide a large target to move to, even across a large
>> screen. ... The need for TOM diminished when Apple improved the
>> mouse acceleration algorithms.
>
>I have to disagree with this. TOMs allow for the user to graphically place
>menus and submenus at places which are convenient for a given task.

Well, there are two factors here that fight against each other.

* A TOM, since it is removed from the menu bar, has a rather small target
to hit. It's advantage is you can move it close to you work. But compared
to the menu bar, which is infinitely tall, it's still too small.

* A nested submenu isn't visible, and requires several steps to navigate
to. By tearing off such a submenu and creating a TOM, the number of steps
required is reduced.

All this has to do with Fitt's law. A TOM can't compare to the a
top-level menu, since it presents too small a target compared to the
menu. But, if the menu involved is nested deeply, a TOM is a better
solution, since it short-circuits several selection steps.

The advantage of a TOM depends on your menu organization. If you have
lots of submenus, a TOM appears to be a win. If you don't have submenus,
a TOM has no advantage over a menu bar menu.

>They
>can function like all the other tool palettes which people find so handy.
>It's all about the geometry of accessing your controls, which can vastly
>improve the efficiency of the user. Having to always go up to the menu
>bar, even a "good" menu bar, is a very awkward exercise, especially for
>oft repeated tasks. It wastes time and hand movement.

It may seem afurther distance if you measure it with a ruler, but you'd
actually have to set up user testing to prove it wastes time. The
distance involved is immaterial, since the speed of mouse movement is
different.

>It's better
>ergonomic design, even in Aqua, to make available TOMs. This should be up
>to the user if nothing else.

There's a lot of interesting UI selections for which one could make this
argument. But having lots of "choices" makes the UI more complex. Apple
has always had the phylosophy of picking the best choices and limiting
the user choices. This is both a benefit and a curse. The benefit is that
user's aren't tasked with making difficult design choices. The curse is
that some users have to adapt to the behavior, regardless if they think
it is "better" or "worse."

>To the Mac user, the GUI experience has toggled on this issue many times.
>OS 7 could do it with various 3rd-party extensions, then on OS 8 I
>couldn't anymore for some reason. Then OS X Server allowed it, which was a
>blessing. Now OS X doesn't. NeXT had it. Clearly there is a demand for it
>by a certain segment. Most OSXS people I know lament TOMs being gone in
>Aqua. Why doesn't Apple allow for it, even as an advanced feature? I wish
>they would at least give a reason.

Perhaps Apple has done the usability testing that shows it isn't as great
as you think it is.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Bill Coleman
2001-01-18 12:35:18 UTC
Permalink
On 1/16/01 23:00, John Fieber at ***@indiana.edu wrote:

>But when the menu bar is an entire screen or two away, it is just
>isn't quite as nifty of a situation as you make it out to be. I
>don't care at all for the top-of-the-screen menu in a
>multi-monitor setup but as long as we are more or less stuck with
>it, tear-off menus can go a LONG way toward making it a more
>tolerable situation.

Good point about multi-monitor scenarios. But I think that multi-monitor
setups are becoming increasingly rare. When the Mac used to have
relatively small displays, they were more common. But today, with the
availability of larger displays, many users opt for a single large
display, than to purchase several smaller ones.

I used a two-monitor Mac for 5 years. I don't miss it.

Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Nicholas Renter
2001-01-18 12:47:26 UTC
Permalink
2 15" flatscreen monitors and 1 graphics card is much cheaper than 1 cinema
display.

> Good point about multi-monitor scenarios. But I think that multi-monitor
> setups are becoming increasingly rare. When the Mac used to have
> relatively small displays, they were more common. But today, with the
> availability of larger displays, many users opt for a single large
> display, than to purchase several smaller ones.
>
> I used a two-monitor Mac for 5 years. I don't miss it.
Eugene Lee
2001-01-18 14:15:08 UTC
Permalink
On Thu, Jan 18, 2001 at 03:34:48PM -0500, Bill Coleman wrote:
: On 1/16/01 23:00, John Fieber at ***@indiana.edu wrote:
:
: >But when the menu bar is an entire screen or two away, it is just
: >isn't quite as nifty of a situation as you make it out to be. I
: >don't care at all for the top-of-the-screen menu in a
: >multi-monitor setup but as long as we are more or less stuck with
: >it, tear-off menus can go a LONG way toward making it a more
: >tolerable situation.
:
: Good point about multi-monitor scenarios. But I think that multi-monitor
: setups are becoming increasingly rare. When the Mac used to have
: relatively small displays, they were more common. But today, with the
: availability of larger displays, many users opt for a single large
: display, than to purchase several smaller ones.

I think the multi-monitor setup is common for people with notebooks and
other portable computers. And it's a pain to move your mouse pointer
back to the primary display to access your menu bar, your Dock and other
launchers, control strips, hard drives and file servers, and other stuff.


--
Eugene Lee
***@anime.net
John Fieber
2001-01-18 15:54:25 UTC
Permalink
On Thu, 18 Jan 2001, Eugene Lee wrote:

> On Thu, Jan 18, 2001 at 03:34:48PM -0500, Bill Coleman wrote:
>
> : Good point about multi-monitor scenarios. But I think that multi-monitor
> : setups are becoming increasingly rare. When the Mac used to have
> : relatively small displays, they were more common. But today, with the
> : availability of larger displays, many users opt for a single large
> : display, than to purchase several smaller ones.
>
> I think the multi-monitor setup is common for people with notebooks and
> other portable computers.

Also, as monitor prices fall and people (like me) buy spiffy new
monitors, why replace your old monitor when you can have both?
Two heads ARE better than one.

-john
Tim Bissell
2001-01-18 17:17:16 UTC
Permalink
> * A TOM, since it is removed from the menu bar, has a rather small target
> to hit. It's advantage is you can move it close to you work. But compared
> to the menu bar, which is infinitely tall, it's still too small.
...
> All this has to do with Fitt's law. A TOM can't compare to the a
> top-level menu
...

Don't forget that you can drag the torn-off menu to the LHS or RHS of the screen, to get infinite width for each menu item.

Tear-off menus weren't hard to understand in NextStep, once torn off, the title bar of the menu became the titlebar of a window with a close button - everyone knows what a window close button does, so even our room-temperature IQ bond salesmen could use them quite happily...

Regards,

Tim
--
home: ***@bissells.org | +44 1480 451022
work: ***@drkw.com | +44 207 4758789
Simon White
2001-01-18 18:03:49 UTC
Permalink
Apple's displays are one per box because the displays don't have their own
power supplies, and the box only has power for one display. I would say that
this implies that multi-monitors is not a huge priority for Apple right now.
I'm sure if you pressed someone at Apple about it, they'd say "get a Cinema
Display". That's actually what I did, so maybe that's a good strategy.

It also seems like Apple has an idea to reduce the number of windows and
other elements on the display as much as possible. Maybe they have research
that this is much easier for the majority of users. Also, the fewer features
they offer in Mac OS X, the smaller all the manuals and books can be, the
easier the OS appears to the new user.

I like tear-off menus, myself, though. Leave them off by default, just like
title-bar double-clicking window-shading is left off by default in Mac OS 9,
and you won't confuse users who don't know about the feature.

Simon White

> From: John Fieber <***@indiana.edu>
> Date: Thu, 18 Jan 2001 18:54:13 -0500 (EST)
> To: Eugene Lee <***@anime.net>
> Cc: MacOSX-Talk <macosx-***@omnigroup.com>
> Subject: Re: any sightings of tear-off menus at MacWorld?
>
> On Thu, 18 Jan 2001, Eugene Lee wrote:
>
>> On Thu, Jan 18, 2001 at 03:34:48PM -0500, Bill Coleman wrote:
>>
>> : Good point about multi-monitor scenarios. But I think that multi-monitor
>> : setups are becoming increasingly rare. When the Mac used to have
>> : relatively small displays, they were more common. But today, with the
>> : availability of larger displays, many users opt for a single large
>> : display, than to purchase several smaller ones.
>>
>> I think the multi-monitor setup is common for people with notebooks and
>> other portable computers.
>
> Also, as monitor prices fall and people (like me) buy spiffy new
> monitors, why replace your old monitor when you can have both?
> Two heads ARE better than one.
>
> -john
>
> _______________________________________________
> MacOSX-talk mailing list
> MacOSX-***@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-talk
>
steve harley
2001-01-21 21:54:00 UTC
Permalink
At 3:34 PM -0500 1/18/01, Bill Coleman wrote:
>[...] But I think that multi-monitor
>setups are becoming increasingly rare.

from other discussions i participate in, i think interest
in multiple monitors is steady or increasing.

At 5:53 PM -0800 1/18/01, Simon White wrote:
>Apple's displays are one per box because the displays don't have their own
>power supplies, and the box only has power for one display. I would say that
>this implies that multi-monitors is not a huge priority for Apple right now.

only the very latest (slightly stupid, IMHO) Apple displays
are not self-powered. take a look at the Apple store: the
G4 configurator has an entry for "Multiple Display
Suppport". PowerBooks also have multiple monitor support
built in. it's not clear that Apple is deprioritizing this
feature. again, the key is scalable complexity. make a
very simple configuration the default, but keep the
door open for complex setups.

steve harley ***@paper-ape.com
David P. Henderson
2001-01-18 21:55:13 UTC
Permalink
I think that there are already 2 existing methods which obviate the need for
tear off menus. Keyboard Equivalents and Contextual Menus, judicious use by
developers can offset the lack of TOMs. My suggestion would be to encourage
the developer of your software to make use of these items. I realize that
neither of these completely replicates TOMs but used complimentarily with
one another you get similar functionality.

Dave
--
Chaos Assembly Werks
"Beautiful bodies and beautiful personalities rarely go together."
- Carl Jung
mmalcolm crawford
2001-01-18 22:32:51 UTC
Permalink
David P. Henderson wrote:
> I think that there are already 2 existing methods which obviate the need for
> tear off menus. Keyboard Equivalents
>
It would be wonderful if every menu cell could have a key equivalent, but
having to learn them all would be silly. Further, TOMs are frequently used
while engaged in mouse-intensive tasks, so requiring the user to relinquish
the mouse to type in key-strokes is counter-productive. And I thought
everyone wanted a graphical interface anyway?

> and Contextual Menus,
>
Contextual menus are *contextual* menus. They serve a different function to
main menus.

> I realize that neither of these completely replicates TOMs but used
> complimentarily with one another you get similar functionality.
>
Not at all.


Going back earlier in the debate: Bill Coleman's wittering on about Fitt's
law misses the point completely. If this were such a big issue would there
ever be tool bars or palettes? What are they other than graphical tear-off
menus? having the ability to place a menu, especially a submenu, close to
your current focus of attention simply Makes Sense. If you don't want to
use it, or can't understand it, ignore it.

mmalc.
Chris Hanson
2001-01-22 21:44:28 UTC
Permalink
At 6:33 AM +0000 1/19/01, mmalcolm crawford wrote:
>Going back earlier in the debate: Bill Coleman's wittering on about Fitt's
>law misses the point completely. If this were such a big issue would there
>ever be tool bars or palettes?

Yes, unfortunately. Not everyone does usability testing on their
software, and not everyone does usability testing on their new
interface ideas to determine whether they're good or bad.

Toolbars and palettes are with us now, probably for good, *despite*
the fact that they're relatively bad interfaces.

-- Chris

PS - The toolbar is a corruption of the palette. The original
Lisa/Macintosh interface had strict rules about when to use icons and
when to use text; icons were always supposed to represent nouns like
files, folders, and tools. Toolbars, however, represent *verbs* with
icons and thus break down the consistency of the metaphor. (Kevin
Killion posted a great rant about this to semper.fi way back when...
I believe the salient quote is "Toolbars are further evidence that
Windows really is a cargo cult.")

--
Chris Hanson <***@bDistributed.com>
bDistributed.com: Making Business Distributed
Scott Stevenson
2001-01-18 23:47:26 UTC
Permalink
I have a theory as to why the tear-off menus are missing. One of Mac OS X's stated design goals are less floating windows, and less clutter in general. Tear-off menus would certainly qualify as another floating window.

- Scott

--
Scott Stevenson
http://wildtofu.com/
http://maxify.com
steve harley
2001-01-21 21:53:15 UTC
Permalink
At 11:47 PM -0800 1/18/01, Scott Stevenson wrote:
>I have a theory as to why the tear-off menus are missing. One of Mac
>OS X's stated design goals are less floating windows, and less
>clutter in general. Tear-off menus would certainly qualify as
>another floating window.

is there a specific source for this? i just looked through
most of the recently mentioned Aqua Human Interface
Guidelines and i don't see that stated.

<http://developer.apple.com/techpubs/macosx/SystemOverview/AquaGuidelines.pdf>

i do however see drawers and utility windows described at
length. it seems as if Apple would rather have you use
these instead of tear-offs. the key difference is the
developer has to intelligently design a set of drawers or
utility windows, rather than just expect a menu to be torn
off.

a menu or submenu itself is not always organized ideally
for being torn off; the groupings in the menus are usually
categorical, and you may need commands from several
categories kept handy. so a palette (utility window) may be
more work for the developer, and may be left out of rushed
or poorly designed applications, but is may better for the
user if well-designed.

further, it seems like configurable palettes offer some
distinct advantages, and we do see evidence of Apple
encouraging this in the form of user-modifiable toolbars.
this paradigm has worked well for me (after some initial
resistance) in configuring Microsoft Office.

suppose the system went all the way and supported palettes
which could contain any menu command (in Office and
Explorer, these can be iconic, textual, or both). if this
were universal, you could get a quick palette going by
tearing off a menu, then you could customize it at will and
save the configuration.

steve harley ***@paper-ape.com
Mike Elston
2001-01-22 06:29:22 UTC
Permalink
One thing struck me about this debate. It seems to be mostly between
1) folk who would like tear-off menus implemented because they've
used them before and have found a use for them, and
2) folk who are wondering whether tear-off menus would be useful, or
misleading to some users, or whether they're akin to toolbars, or are
made unnecessary by the existence of keyboard equivalents and
contextual menus.

Correct me if I'm wrong, but I believe classic Mac OS has never had
tear-off menus (with the exception of the Application menu, which
tears off to become a palette, but that's unique, I think). I've only
seen them on NeXTStep and Mac OS X Server.

So it seems to me that many in the second group may not have had the
opportunity to work with tear-off menus as a general feature of an OS.

Like so many other such features, once you've used them and found
them useful, you tend to argue for them. For example, I often tear
off the Windows menu when I'm working on a number of different windows
in the same app at the same time -- I can just glance at the menu to
see which ones I have open at any time. If you haven't used tear-off
menus, the discussion is more theoretical.

So I'd argue that, unless someone can come up with an *equivalent*
alternative, tear-off menus certainly qualify for consideration, and
just to say you don't think they'd be useful isn't an argument which
carries any weight with those who'd like to have their functionality.

Then there's the question of the implementation. On NeXTStep,
they're easy to use and intuitive, because all menus have title bars
which can be dragged to tear them off, and, as Tim Bissell
<***@bissells.org> pointed out:
> ... once torn off, the title bar of the menu became the titlebar
> of a window with a close button - everyone knows what a window
> close button does...
On Mac OS X Server, the menus acquire a title bar when they're torn
off, and this too has a close button on it. Presumably this is how it
would work in Mac OS X, so getting rid of them wouldn't be a problem
for even the most naive user.

However when menus have no title bar (as in Mac OS), tearing menus
off requires a different UI (eg dragging on the menu itself, as in OS
X Server). I think that worked quite well -- it's not possible to
tear a menu off easily by accident just by slipping off the end,
because you have to drag a significant distance below the menu before
it tears off (further than you do to instantiate the Applications
palette in OS 9).

So what's the real problem?

/mike
David P. Henderson
2001-01-19 08:57:56 UTC
Permalink
on 01/19/2001 01:33, mmalcolm crawford at mmalc-***@mmalc.com wrote:

> It would be wonderful if every menu cell could have a key equivalent, but
> having to learn them all would be silly. Further, TOMs are frequently used
> while engaged in mouse-intensive tasks, so requiring the user to relinquish
> the mouse to type in key-strokes is counter-productive.
>
Where did I state that every menu command should have a Keyboard Equivalent
(KE)? I said "judicious". KEs have, to the best of my memory, all ways been
a part of the Mac OS. KEs should be reserved only for those menu commands
which are repetitive in or common to all applications. I never argued
otherwise. Even in "mouse-intensive" tasks, one hand is on the mouse (or
other pointing input), and one is free. I understand that this is not an
optimal solution for those who do not have the full use of both hands, but
then GUIs are not optimal solutions in that case. Which argues for voice
access to menu commands rather than more GUI access.

> And I thought everyone wanted a graphical interface anyway?
>
How exactly does a KE preclude the GUI? In any event, I have not argued such
an extreme position. The more graphical your solution the more complexity
you add to the system. The more complexity, the more likely is failure.

> Contextual menus are *contextual* menus. They serve a different function to
> main menus.
>
What exactly is a Contextual Menu (CM) then? As I understand CMs, they are
commands pertinent to the current context. This does not preclude CMs from
containing access to functionality also provided by the Menu Bar menus i.e.,
main menus. It makes perfect sense to me to have per object contexts which
provide direct access, via the CM mechanism, to menu commands which apply to
those objects which would have the benefit of reducing the need for KEs.
They also have the advantage over TOMs in that the user doesn't need to go
to the menu bar, tear off menus, and move them to the working screen area.

>> I realize that neither of these completely replicates TOMs but used
>> complimentarily with one another you get similar functionality.
>>
> Not at all.
>
I disagree. KEs and CMs, independently, do not replace TOMs, but they
provide a usable solution with similar functionality when used in a
complimentary fashion with one another i.e., do not provide duplicate access
to functionality.

>
> Going back earlier in the debate: Bill Coleman's wittering on about Fitt's
> law misses the point completely. If this were such a big issue would there
> ever be tool bars or palettes? What are they other than graphical tear-off
> menus? having the ability to place a menu, especially a submenu, close to
> your current focus of attention simply Makes Sense. If you don't want to
> use it, or can't understand it, ignore it.
>
Which misses another point. Palettes and TOMs are poor solutions to the
access issue. Why not use voice access to menu commands? Then you not need
to alter the position of your hands relative to your work.

As far as I can tell, the objection to my solution is that it must be
provided by each application developer independently whereas TOMs would be
provided for free by the system. Developers are damn lazy ;) So my suggest
to those who want TOMs, push the developers of your favorite software to
provide sensible KE and CM access to menu commands. ;)

Dave
--
Chaos Assembly Werks
"Beautiful bodies and beautiful personalities rarely go together."
- Carl Jung
Bill Coleman
2001-01-21 13:36:50 UTC
Permalink
On 1/18/01 18:54, John Fieber at ***@indiana.edu wrote:

>Also, as monitor prices fall and people (like me) buy spiffy new
>monitors, why replace your old monitor when you can have both?

I think the real problem is people don't have ROOM for two monitors.
Especially big 17" or 20" CRT displays. Yow.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Bill Coleman
2001-01-21 13:39:45 UTC
Permalink
On 1/19/01 1:33, mmalcolm crawford at mmalc-***@mmalc.com wrote:

>It would be wonderful if every menu cell could have a key equivalent, but
>having to learn them all would be silly.

If you have too many to memorize, then you lose any benefit.

Common keyboard shortcuts may have some benefit over pull-down menus, but
Apple did some landmark usability testing in the 80's that showed
keyboard shortcuts were actually SLOWER than using the menus, even though
virtually all users PERCEIVED them as faster. The difference between the
measured and perceived results can be explained through the cognitive
differences in the use of each.

"Tog on Interface" has an excellent chapter on this topic alone.

>Further, TOMs are frequently used
>while engaged in mouse-intensive tasks, so requiring the user to relinquish
>the mouse to type in key-strokes is counter-productive. And I thought
>everyone wanted a graphical interface anyway?

It's interesting to note that the common shortcuts for cut/copy/paste are
not so much mnemonic, but they fit nicely in the left hand, leaving the
right hand free to stay on the mouse. (If you happen to be right handed)
Microsoft thought so much of these shortcuts that they copied them
verbatum for Windows 3.1 (after Apple had retired the HP/MS suit).

>Going back earlier in the debate: Bill Coleman's wittering on about Fitt's ...

Malcolm, I see you are back to your old tricks: when you cannot assault
the facts of the arguments presented, you denegrate the person. Please
refrain from trying to build yourself up by tearing others down.

>law misses the point completely. If this were such a big issue would there
>ever be tool bars or palettes?

Fitt's law still rules the mechanics of clicking with the mouse, but
there are other processes involved. A toolbar gives a visible locale for
an operation. It's a simple matter to direct attention to the appropriate
tool and click on it. For operations hidden in a menu bar, one must
remember the operations relative location -- much in the same way a
keyboard shortcut is remembered.

>What are they other than graphical tear-off menus?

Yes, in a way, they are.

>having the ability to place a menu, especially a submenu, close to
>your current focus of attention simply Makes Sense.

TOMs probably have more value from their visibility (a la Toolbar), than
they do from their locale.

> If you don't want to use it, or can't understand it, ignore it.

(Ignoring the obvious slight) I understand TOMs perfectly. And I'd
probably even use them, if they were available.
steve harley
2001-01-21 21:51:48 UTC
Permalink
at 1/21/01, 4:37 PM -0500, they whom i call Bill Coleman wrote:
>[...] A toolbar gives a visible locale for
>an operation. It's a simple matter to direct attention to the appropriate
>tool and click on it. For operations hidden in a menu bar, one must
>remember the operations relative location -- much in the same way a
>keyboard shortcut is remembered.

not really. menus are menus, literally; such as at a
restaurant. if you're not familiar with a menu, you can
scan through it. it provides a very accessible way of
learning unfamiliar parts of an application. you can't do
that at all with keyboard shortcuts.

there is also a categorical organization, so even if you
don't know the particular item, you can work your way
toward it. so you have some clues, just as "Entrees" &
"Appetizers". if you do get very familiar, you can memorize
where to go, get the keyboard shortcut, or add a macro such
as with QuickKeys. but that's just one part of a menu's
(including a TOM's) usefulness.

steve harley ***@paper-ape.com
Bill Coleman
2001-01-21 13:41:13 UTC
Permalink
On 1/19/01 2:47, Scott Stevenson at ***@maxify.com wrote:

>I have a theory as to why the tear-off menus are missing. One of Mac OS
>X's stated design goals are less floating windows, and less clutter in
>general. Tear-off menus would certainly qualify as another floating window.

This is one thing that I don't understand about the Mac OS X application
phylosophy: rampant window elimination. One thing the MacOS (classic or
X) does EXTREMELY well is to give users quick access to many windows.
With MacOS X's elimination of the layer manager, even moreso.

One thing I hate-hate-hate about Windows is the insistance that all
documents have to be in panes within the application window. This means
that it is extremely difficult to work with more than one application at
a time -- next to impossible to work with two documents in two different
applications similtaneously.

Paned window areas are also a nuisance. Instead of allowing me to
position overlapping windows where they show relevant information and
don't get in the way, a paned interface doesn't let me see what I want to
see without even more shuffling.

Since the Macintosh UI handles multiple windows so well -- why the
campaign to eliminate all extraneous windows?

I suppose all that window clutter confuses beginners, but like the CLI,
some power users find benefit in the feature.

Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
William Ehrich
2001-01-21 14:19:38 UTC
Permalink
>> key equivalent, but having to learn them all would be silly.

> If you have too many to memorize, then you lose any benefit.

I memorize a few which I use a lot, you probably use a different set.
It's nice to have both.

> Apple did some landmark usability testing in the 80's that showed
> keyboard shortcuts were actually SLOWER than using the menus,

When reading mail or news I keep my thumb on Cmd and three fingers on
D, W, and Q. R isn't very far away, and my right hand is near the up
and down arrows. (This style may be easier for a non touch-typist like me.)



> A toolbar gives a visible locale

One of my pet hates is a toolbar which takes a lot of space for little
pictures whose meaning I can't remember. In Windos I always have to wait
for the description to come up. It's like reading kanji.

I would like an optional view with only the labels of icons (or small
rectangular icons into which I could put clearly readable text).



> One thing I hate-hate-hate about Windows is the insistance that all
> documents have to be in panes within the application window.

Me too! Outlook Express would drive me crazy compared to my Eudora 3.1
and NewsHopper.


-- Bill Ehrich
William Ehrich
2001-01-21 20:51:20 UTC
Permalink
>> I would like an optional view with only the labels of icons (or small
>> rectangular icons into which I could put clearly readable text).

> This is already there in the build shown at Macworld SF. When you customize
> the toolbar, there is a pop-up menu at the bottom of the window from which
> you can select Text, Icons, or Text and Icons.

Sorry, I was unclear. I would like to be able to have only the label of
each icon, without pictures, on the desktop, etc.

-- Bill Ehrich
Simon White
2001-01-21 16:39:40 UTC
Permalink
> One of my pet hates is a toolbar which takes a lot of space for little
> pictures whose meaning I can't remember. In Windos I always have to wait
> for the description to come up. It's like reading kanji.
>
> I would like an optional view with only the labels of icons (or small
> rectangular icons into which I could put clearly readable text).

This is already there in the build shown at Macworld SF. When you customize
the toolbar, there is a pop-up menu at the bottom of the window from which
you can select Text, Icons, or Text and Icons. When the Finder button is
showing text only, it shrinks down to short and wide. You can put a folder
on the toolbar and see just the name of the folder. Lots of room there. I
wonder what would happen if you have more buttons than will go along the
width of the window? Are they clipped, or do they wrap? If they wrap, then
you could put 20 or 30 text buttons on there with every folder you ever use
and it wouldn't take up too much space.

Also, you can show a status bar like the one in classic Mac OS, that tells
you how many items in the current folder, and how much free disk space. As
someone who has said bad things about the Public Beta Finder, I was really
blown away by some of the elegant solutions in the newer build. Toggling the
toolbar open or closed with the right-hand window widget is great, and the
fact that that also changes the window's performance from browser to
multiple folders is very cool.

Simon White
David J Richardson
2001-01-21 17:35:13 UTC
Permalink
On Monday, January 22, 2001, at 11:39 AM, Simon White wrote:

>Toggling the toolbar open or closed with the right-hand window widget is
>great, and the fact that that also changes the window's performance
>from browser to multiple folders is very cool.

Can you still use the option key to alter whether a new window is opened?
Andrew Elliston
2001-01-21 18:07:47 UTC
Permalink
> This is already there in the build shown at Macworld SF. When you customize
> the toolbar, there is a pop-up menu at the bottom of the window from which
> you can select Text, Icons, or Text and Icons. When the Finder button is
> showing text only, it shrinks down to short and wide. You can put a folder
> on the toolbar and see just the name of the folder. Lots of room there. I
> wonder what would happen if you have more buttons than will go along the
> width of the window? Are they clipped, or do they wrap? If they wrap, then
> you could put 20 or 30 text buttons on there with every folder you ever use
> and it wouldn't take up too much space.

If you have more buttons than will fit in the width of the window, you get a pull-down menu on the right that lists the buttons that could not be displayed. It would be similar to IE5's approach to showing you more Toolbar Favorites than will fit in the window.
As you said - the newer builds are a vast improvement over the Public Beta.

At the same time - I played with the build a bit at the Expo. Window resizing is fast, almost smooth. Opening windows is lightning fast - just like we'd want. Along the same lines, opening up the System Preferences is quick (unlike the huge delay we have now).

I can't wait until March 24...just in time for my birthday.

Andrew Elliston
------------------------------------------------
Mac Digital Audio
-- news and info for your ears
<http://www.macdigitalaudio.com>
------------------------------------------------
Guy English
2001-01-22 06:45:37 UTC
Permalink
Hi,

> So what's the real problem?
> /mike

Not Invented Here.
( Like left hand scroll bars, the dock ( at first ), etc )

Guy
Scott Stevenson
2001-01-22 10:54:17 UTC
Permalink
On Sunday, January 21, 2001, at 07:25 PM, steve harley wrote:

> >I have a theory as to why the tear-off menus are missing. One of Mac
> >OS X's stated design goals are less floating windows, and less
> >clutter in general. Tear-off menus would certainly qualify as
> >another floating window.
>
> is there a specific source for this? i just looked through
> most of the recently mentioned Aqua Human Interface
> Guidelines and i don't see that stated.

Which part? The philosophy itself or the fact that tear-offs are against it? The latter is just a guess on my part, but I believe I did read the former in a doc somewhere. It would take me a while to dig it up. You can see evidence of the "less floating windows" philosophy throughout the system. Witness the single-window mode that was pulled before beta.

I'm not arguing against tear-offs. I'm sort of indifferent about them. I'm just putting forth a hypothesis as to why they disappeared.

- Scott

--
Scott Stevenson
http://wildtofu.com/
http://maxify.com
Bill Coleman
2001-01-23 06:11:47 UTC
Permalink
On 1/22/01 8:26, Mike Elston at ***@caisys.co.uk wrote:

>Correct me if I'm wrong, but I believe classic Mac OS has never had
>tear-off menus (with the exception of the Application menu, which
>tears off to become a palette, but that's unique, I think). I've only
>seen them on NeXTStep and Mac OS X Server.

Not true. When Radius came out with their full-page display, they
included an INIT which modified the Menu Manager to produce tear-off
menus. This was before Apple improved the mouse acceleration algorithm to
better handle large screens.

Remember that the NeXTStep environment is very different from the MacOS.
The MacOS menu organization places it at a screen edge with fairly large
menu targets. NeXTStep placed menus in a small floating window with
relatively small targets. Moving across a large screen to select a
NeXTStep menu is a slow process. The same isn't true of a MacOS-style
menu.

>So I'd argue that, unless someone can come up with an *equivalent*
>alternative, tear-off menus certainly qualify for consideration, and
>just to say you don't think they'd be useful isn't an argument which
>carries any weight with those who'd like to have their functionality.

I believe that MacOS X Server had TOMs largely because Apple didn't
bother to remove them. Obviously, someone decided that TOMs detractions
outweighed its benefits.


Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Mike Elston
2001-01-23 09:14:07 UTC
Permalink
Bill Coleman <***@mac.com> wrote:
> On 1/22/01 8:26, Mike Elston at ***@caisys.co.uk wrote:
>
> >Correct me if I'm wrong, but I believe classic Mac OS has never had
> >tear-off menus (with the exception of the Application menu, which
> >tears off to become a palette, but that's unique, I think). I've
> >only seen them on NeXTStep and Mac OS X Server.
>
> Not true. When Radius came out with their full-page display, they
> included an INIT which modified the Menu Manager to produce tear-off
> menus. This was before Apple improved the mouse acceleration
> algorithm to better handle large screens.

I guessed there might have been a third-party add-on. Most desired
features that aren't in the Mac OS proper seem to have been provided
by someone sometime :-)

> Remember that the NeXTStep environment is very different from the
> MacOS. The MacOS menu organization places it at a screen edge with
> fairly large menu targets. NeXTStep placed menus in a small floating
> window with relatively small targets. Moving across a large screen to
> select a NeXTStep menu is a slow process. The same isn't true of a
> MacOS-style menu.

'Very different'? I'd disagree. Agreed the main menu is vertical
rather than horizontal, but it's usually kept at the edge of the
screen, so the width is 'infinite'. And selecting a second-level menu
(from a vertical menu, on either OS) isn't much faster on MacOS and
on NS.

But the argument isn't just that the target size may be different.
TOM's can be placed next to where you're working so that mouse
movement is minimal anyway. The final target, not just the menu
title, can be aimed at directly, meaning one mouse movement instead of
two. And they are always visible, which has its own special
advantages.

> I believe that MacOS X Server had TOMs largely because Apple didn't
> bother to remove them. Obviously, someone decided that TOMs
> detractions outweighed its benefits.

I still haven't seen any convincing descriptions of their 'detractions'.

I suspect TOMs weren't removed, just not implemented in Carbon
(yet?). It's more likely that, because TOMs aren't available by
default in Carbon apps, the AppKit methods for tearing off menus were
disabled to keep the UI consistent. Tear-off menus are still referred
to in the AppKit (Cocoa) documentation - NSMenus have 'isAttached'
and 'isTornOff' methods. (Don't forget OS X Server is 100% Cocoa.)

/mike (still hoping)
Bill Coleman
2001-01-23 06:20:12 UTC
Permalink
On 1/22/01 21:46, Chris Hanson at ***@bDistributed.com wrote:

>Toolbars and palettes are with us now, probably for good, *despite*
>the fact that they're relatively bad interfaces.

I was one of the co-developers of Smartcom II, which first shipped in
March of 1985. We used a "toolbar" like metaphor because it solved
certain problems.

In our case, the icons served a dual purpose of acting like indicators as
well as controls. The telephone icon was dark while you were connected.
You could also initiate a connection / disconnection by clicking on the
indicator.

It also placed the most common operations in a very visible position,
where they could be easily found.

The problem with modern toolbars is they are too unrestrained. Programs
like Word have three levels of toolbars, all containing tiny, poorly
distinguished icons. Rather than bring common functionality to the
forefront, where it is visible, this results in functions being buried in
a mass of detail.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
steve harley
2001-01-23 12:49:41 UTC
Permalink
at 1/23/01, 9:22 AM -0500, they whom i call Bill Coleman wrote:
>The problem with modern toolbars is they are too unrestrained. Programs
>like Word have three levels of toolbars, all containing tiny, poorly
>distinguished icons. Rather than bring common functionality to the
>forefront, where it is visible, this results in functions being buried in
>a mass of detail.

Word is such an easy target that we tend to skip its
virtues.

in Word, the toolbar is completely configurable. granted
the standard toolbars are a mess, and there is reasonable
doubt that a set of tiny icons is a good approach to begin
with, though you also have text and tooltips alternatives.
but if you use Word enough (and are curious enough to find
the feature, i guess), you can completely replace the
standard toolbars with ones that fit your purpose. you can
build menus on these toolbars, and the standard menus are
an inspectable resource, meaning you could probably write a
macro to simulate tear off menus... you can even take these
toolbars with you and install them on whatever (Mac or
Windows) machine you use.

this idea, if not it's implementation, is something i'd
like Apple to make system-wide. then the challenge becomes
how do you manage scalable complexity - is there some way
we (Apple, actually) can make toolbars/palettes/shelves
have a "natural order", yet adapt to the needs of the user?

steve harley ***@paper-ape.com
John Fieber
2001-01-23 07:40:11 UTC
Permalink
On Tue, 23 Jan 2001, Bill Coleman wrote:

> Moving across a large screen to select a NeXTStep menu is a
> slow process.

Yes, but the argument for TOMs in this thread is that you can
place the menu CLOSE to where you are working.

> I believe that MacOS X Server had TOMs largely because Apple didn't
> bother to remove them. Obviously, someone decided that TOMs detractions
> outweighed its benefits.

If this thread is any evidence, the last point is more opinion
than science. Given that use of TOMs is optional, the only
compelling detraction I see is the possibility of accidently
tearing off a menu.

Isn't one hallmark of good interface design the minimization of
user errors? If so, it isn't so much the tear-off menu itself
that is flawed, but the interface that promotes accidental
activation.

-john
Bill Coleman
2001-01-23 11:55:08 UTC
Permalink
On 1/23/01 10:42, John Fieber at ***@indiana.edu wrote:

>On Tue, 23 Jan 2001, Bill Coleman wrote:
>
>> Moving across a large screen to select a NeXTStep menu is a
>> slow process.
>
>Yes, but the argument for TOMs in this thread is that you can
>place the menu CLOSE to where you are working.

Exactly! That's what I was saying -- TOMs were important to NeXTStep
because of this difficulty in selecting menus from across a large screen.

>> I believe that MacOS X Server had TOMs largely because Apple didn't
>> bother to remove them. Obviously, someone decided that TOMs detractions
>> outweighed its benefits.
>
>If this thread is any evidence, the last point is more opinion
>than science. Given that use of TOMs is optional, the only
>compelling detraction I see is the possibility of accidently
>tearing off a menu.
>
>Isn't one hallmark of good interface design the minimization of
>user errors? If so, it isn't so much the tear-off menu itself
>that is flawed, but the interface that promotes accidental
>activation.

Agreed.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@mac.com
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
mmalcolm crawford
2001-01-23 13:33:19 UTC
Permalink
Bill Coleman wrote:
>> Yes, but the argument for TOMs in this thread is that you can
>> place the menu CLOSE to where you are working.
>
> Exactly! That's what I was saying -- TOMs were important to NeXTStep
> because of this difficulty in selecting menus from across a large screen.
>
This has gone on long enough -- absolute poppycock!

There was no problem in accessing "distant" menus on NeXTstep, precisely
because of the Fitt's law you laud for MacOS -- menus were by default placed
on the far left, so infinitely wide. And NeXT got mouse acceleration right
first time round. TOMs were important because they were useful. Especially
for multi-level menus.

Rejoinders to other crass assertions when I get a time.

mmalc.
John Hörnkvist
2001-01-23 13:51:46 UTC
Permalink
> Remember that the NeXTStep environment is very different from the MacOS.
> The MacOS menu organization places it at a screen edge with fairly large
> menu targets. NeXTStep placed menus in a small floating window with
> relatively small targets. Moving across a large screen to select a
> NeXTStep menu is a slow process. The same isn't true of a MacOS-style
> menu.

NEXTSTEP menus start out in the upper left corner of the screen, and are very quick to find because of that. But that has little to do with why tear off menus are good; finding the top level menu with the mouse pointer is only a small step in the process of using a menu.

Changing the eyes to focus on the menu bar is more straining than shifting focus to a near target. How important this is is determined by the size of the screen. Fitt's law doesn't help your eyes. Thus, the ability to move menus is good.

Reading a horizontal menu bar is likely to be slower than reading a vertical menu. (Horizontal separation is more difficult to recognize than vertical separation, and you can't focus on as many words at a time.) Experienced users will not notice this, because they don't have to read the menu titles. (Notice that only the top level menu is horizontal in Mac OS.) Because of how Western languages are written, menus are best placed at the top left; that's where users of Western languages are trained to start reading. Closely related items are best placed horizontally, loosely related items are best placed vertically, unless separation is very strong, in which case orientation does not matter.

There is a cognitive process (you have to decide what to do and how to do it) which is likely to be the dominating time factor for some users. Part of that process can be helped by tear of menus since they provide a memory aid. (Placed within or close to your field of focus, they make a huge difference. Iconic information works even better, once the meaning of the symbols is known.) Experienced users don't need that memory aid, but it is a great learning aid and a support for using a less familiar interface. The ability to leave a menu level open while you go on working also supports the cognitive process.



User interface design is very difficult; what the expert wants is rarely what the novice needs. Even worse, if you take the trouble to do studies, efficiency does not necessarily coincide with popularity. As a user interface developer, you should probably make a popular interface the default, even if another interface is more efficient.

In the case of Mac OS X, popular is likely to coincide with "pretty", "cool" or "like Mac OS 9", so that's where Apple has to aim. Efficiency makes its way in only when users scream loud enough.

Having the dock centered at the bottom is likely a good example of pretty winning over efficient; visual identification and association is fastest in the (top) right part of the visual field, but having the dock to the right doesn't look cool enough. (Also, it wouldn't be new, since that's where NeXT put it.)

The version of the Finder in the Public Beta is another example. Quite pretty but almost useless as a tool. Before writing MarshmallowMode, I found myself using the Terminal instead (I still do that to some degree; habits are hard to break...) and that is a terrible mark; I've loved iconic interfaces since I first started using them, soon after the Amiga came out (I'm Swedish; the Mac wasn't competitive here, and the Amiga's hardware was much cooler).

Regards,
John Hornkvist

--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com
John Siracusa
2001-01-23 14:02:38 UTC
Permalink
On 1/23/01 4:53 PM, John Hörnkvist wrote:
> Reading a horizontal menu bar is likely to be slower than reading a vertical
> menu. (Horizontal separation is more difficult to recognize than vertical
> separation, and you can't focus on as many words at a time.)

Do you think that human factors were the driving force behind the NeXT menu
system? I've read that legal concerns were a big factor...

-John
Continue reading on narkive:
Loading...