[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 20:56:42
[Download RAW message or body]
I have a 21 inch monitor and run my display at 1280x1024. I very much
doubt you have a much larger display than I ;-) It requires less time
for users (including me!) to flick the mouse to the top than to target
it at an arbitary position on the desktop.
Richard Moore wrote:
>
> mosfet wrote:
> >
> > 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 ;-)
>
> I have read lots of these documents and books. Many of them seem to
> be very arbitrary and without a great deal of actual evidence to
> back them up. I understand the arguments, and I agree it is very nice
> in theory, but I personally detest it in practice (yes I have tried
> it!). My main problem is that on a large screen the distance you need
> to move the mouse makes it slower in practice, this is something which
> depends heavily on how high you like to have your mouse acceleration
> set. To actually do a proper model of this you need to integrate
> over the mouse acceleration function rather than making the assumption
> that the mouse movement is directly proportional to the hand movement,
> I have never seen anyone actually use such a model. To me this means
> their results are pretty worthless.
>
> I think we are both in agreement that users should have the choice.
> Putting it in kdewizrd means that even a Mac user will be able to
> find the option. ;-)
>
> Rich.
>
> >
> > 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
>
> --
> 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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic