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

List:       kde-core-devel
Subject:    Re: While were making controversial suggestions... ;)
From:       mosfet <mosfet () mandrakesoft ! com>
Date:       2000-04-29 0:02:08
[Download RAW message or body]

Okay, Michael. We are now all aware that you don't believe in fitt's
law. Nonetheless many of us do and Kurt's complaint is a valid one.

Michael Matz wrote:
> 
> Hi,
> 
> On Fri, 28 Apr 2000, Kurt Granroth wrote:
> > [... desc. of fitts law ...]
> I fully understand that.
> 
> > As a quick example, the mac menubar does a terrible job of being close
> > to the cursor BUT does a phenomenal job of being big.  In fact,
> > because it is anchored on the top of the screen, it has INFINITE
> > height.
> 
> Yes, virtual infinite because it not taking more space on screen as it
> should (read below). But note, that one doesn't need this infinite height,
> as the larger the normal menus are in height, the better they are also to
> select. So there exists a height (for each user different) over which it
> make no difference if I add another millimeter. Whereas for the distance:
> the larger it gets the worse.
> 
> This can be clearly seen in the hypotetical case of an 100" screen, with
> normal mouse and menu on top. You can say what you want, the height is
> infinite, but neverthelesse the distance is far too much as that fitts law
> would hold. I guess in my experiment I was exactly getting this break even
> point as I have measured the same time for using the according to fitts
> law better to target macmenubar and the theoretically worse normal
> menubar.
> 
> So my conclusion is that fitts law only holds in some circumstances (of
> course), and that menubars are not necessarily one of them, or at least
> they are a border case.
> 
> > But back to the the B II titlebar.   B II does a terrible job of
> > Fitt's Law in *both* areas.  In the example I gave, the cursor will
> > necessarily be on the right of the window to give it focus while the
> > titlebar will be on the left making sure that the cursor isn't
> > anywhere near the titlebar.  Furthermore, unless you have a very large
> > title, the bar will be quite small, making it harder to select.
> >
> > A full toolbar fits both criteria by being larger and right under the
> > cursor.
> 
> This is all true, and yes B2 title bars break fitts law, as you presented
> it. But my point was here also that fitts law is not really
> useful. For that to see, one should ask, when I want to apply fitts
> law. I think for UI elements which are used often, and under the premise
> that I have space. I count title bars as not often used, so for me fitts
> law is not useful, and consequently I don't care if these title bars break
> fitts law or not. You obviously do care, and about that we can do nothing.
> (then again even with normal title bar, to make them better fit fitts law
> we should make them at least 50 pixel high. Now this is clearly wrong, but
> with only fitts law in hand we would have to do that.)
> 
> But only for another example why fitts law is not in every case usefull:
> If we would apply it to each UI element very rigorous, we would have to
> make them very big and close together, for that we would use an hexagon
> pattern for the active UI elements as they have the best space partition
> without any space between. Obviously that can't be the solution. For once
> without space between we can accidently select the wrong thing, second we
> might be resticted in space to share, so we can't make them as big as we
> wish, and third, all items have the same size, which is plausible but may
> be we have checkboxes and buttons, and they should have different size.
> 
> It can be seen, that to make fitts law usefull, one also has to take into
> account space to share, importance of the item, astethic issues and so on
> (not to speak about the wrong infinity above), not everything of it can be
> measured and pressed into figures. Then we would have to apply this law to
> _each_ and _every_ UI element, buttons, icons, checkboxes, whatever, and
> globally minimize (or maximize if you will) this function.
> 
> I don't doubt that fitts law has its use, as long as it's not slavish
> applied, but it's definetly not the medicine to heal every HIC issue. It
> has so many flaws that one should think two or three times before doing
> something with it. Sometimes normal human sense is enough to reach the
> same, where fitts law would apply, and at the same time also does the
> right thing where fitts law would break horrible.
> 
> All that said, I admit that B2 breaks fitts law, but I think the users can
> cope with that, like they can cope with it in Be, which is really used by
> 'users' (mainly multimedia artists).
> 
> > > his life. We could even explain why users might want to choose this or
> > > that (talking about pros and cons).
> >
> > That's not an option.  If we FORCE the user to choose one, then the
> > initial startup would just be a pain in the ass for the majority of
> > users.  If we don't force them, then *something* needs to be the
> > default.
> 
> Hmm, I think mosfet (or?) said a twm/athena look is in order. That could
> be the default, as it is so ugly, that every user would choose something
> else. So effectively we force them to choose something, while at the same
> time nobody can object, as we really have a default ;-)
> 
> Just kidding.
> 
> 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

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