[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Mac-menu is _not_ faster
From:       mosfet <mosfet () mandrakesoft ! com>
Date:       2000-04-28 16:40:29
[Download RAW message or body]

Well, I can point out tons of reasons why it's good that has been
documented by UI experts (like no targeting time to move the mouse at an
arbitary position on the screen due to window positioning, it always
being on an edge so it only being a flick of the mouse, etc...), users
seem to prefer the Mac to Windows UI and it is one of it's most visible
features, and both UI designers and critics love it. Most of the
arguments against it here seem to be "I just don't like it", which is
rather unusual ;-)

Anyways, we are all just debating theory now. I'm the main advocate of
it here it seems and I agree it shouldn't be default due to
interoperability issues with other toolkits. But mac menus are easier to
use and cooler than sliced bread, so it must be very easy to select and
configure it :)

Richard Moore wrote:
> 
> mosfet wrote:
> >
> > Mac menu *is* faster, the reason why it was not faster for you is
> > because your window was always in the same place (smack in the middle of
> > the screen) and there was only one ;-) Mac vs. windows menus has been
> > timed on many occasions by people's whose entire job is studying UI's.
> > See "Fitts Law".
> 
> I have to say I think that most of the arguments I have seen about this
> have been extreme simplifications. I don't think it is true to say the
> Mac menubar is always faster, though it is in some circumstances. Fitts
> law is an approximation, but far too many people seem to think that you
> can provde things from it. It is like saying that because g is constant
> an object will always accelerate at the same rate when falling - this
> is not true because other things like air resistance get in the way.
> 
> Personally I think the Mac menubar position is terrible, but I know
> others disagree. I think making it the default would be a very bad
> move, the best idea I have heard so far is to make it a kdewizard
> setting.
> 
> Rich.
> 
> >
> > Michael Matz wrote:
> > >
> > > Hi,
> > >
> > > In his original proposal Kurt has claimed, that it is a proven fact, that
> > > mac menus on top of screen are faster than menus tied to its containing
> > > window. Not less than _five_ times faster. I would be very interested in
> > > that "prove", as I'm fairly sure it was done by people not even knowing
> > > what a prove is. Under what circumstances is it faster, for what
> > > use-pattern? What are the propositions?
> > >
> > > Then there were others saying that mac menus are technical superior or
> > > faster, and that it is an admitted fact in nearly the whole world besides
> > > the KDE lists, that this is really the case (without saying in what other
> > > lists).
> > >
> > > Anyway I gave it a try, and actually measured the time it takes for me
> > > with both menu styles, as I thought it is not the baddest thing to throw
> > > some facts between all these IMHO's and may be's:
> > >
> > > I have a 20" screen, created a konsole (80x24), placed it in the middle of
> > > the screen, and than repeated the following steps:
> > > * click into the "Konsole No 1" button at the bottom of konsole
> > > * select "size" submenu of "options" menu
> > > * deselect that by clicking  beside the open menu
> > >
> > > This I repeated 30 times. I actually repeated it twice (in the whole 60
> > > loops), the first 30 to get used to it, the second 30 for measuring time.
> > >
> > > This all I tested one time with Mac-menus one time with "normal" menus,
> > > and I needed 94 seconds for each. Before I tested I even thought I'm
> > > faster with normal menus, but that is not the case, and one good make that
> > > a point for Macmenus. But nonetheless for me Mac menus are _not_
> > > faster despite any "prove".
> > >
> > > Now, all Mac lovers, please explain to me why that would not be the case
> > > for an average user. I thought for myself about some reasons why it is not
> > > faster for me, but not one of them was specific for me. E.g. the way to
> > > the menu is larger in Macmode, but that is compensated by the fact, that
> > > one can't accidently move the mouse above the menu.
> > >
> > > I also have other reasons why macmode is not good, some of them were
> > > already given by Andreas Pour: a menu belongs logically to an application.
> > > Placing it in a common place (more often than not far away from the actual
> > > window) is counterintuitive, or at least not logical.
> > >
> > > Even worse is the fact that at any given time, there can be seen only one
> > > menu. Now imagine you work with two application simultanous. In normal
> > > menu mode:
> > > in app 1: select, do stuff, click into app2 directly selecting, do stuff.
> > > Now try this in Macmode:
> > > go to top of screen, select, go back to app 1, do stuff, click into app 2,
> > > go to top of screen, select, go to app 2, do stuff.
> > >
> > > To conclude, I doubt that Mac menus on today computers, with large
> > > screens and more than one app used simultanous, are of any use. In fact I
> > > think they are only pushed by apple to prove themself as not foolish. They
> > > may have had their right to exist in the past on macs with small screens
> > > and semi-singletasking, but today are only of nostalgic value. That is OK,
> > > and people happy with them should use them, but please don't make it the
> > > default only because someone has said he knows someone who might have
> > > heard of one who has seen a study proving it faster. Note also that the
> > > fastness of access to menus is not the only criteria for
> > > usefullness. There are also things like logical structure.
> > >
> > > Ciao,
> > > Michael.
> >
> > --
> > Daniel M. Duley - Unix developer & sys admin.
> > http://www.mosfet.org - The place for KDE development news.
> > mosfet@mandrakesoft.com
> > mosfet@kde.org
> 
> --
>      Richard Moore              rich@ipso-facto.freeserve.co.uk
> http://www.robocast.com/        richard@robocast.com
> http://developer.kde.org/       rich@kde.org

-- 
Daniel M. Duley - Unix developer & sys admin.
http://www.mosfet.org - The place for KDE development news.
mosfet@mandrakesoft.com
mosfet@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]