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.
>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
>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