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

List:       kde-core-devel
Subject:    Re: While were making controversial suggestions... ;)
From:       Kurt Granroth <granroth () kde ! org>
Date:       2000-04-28 21:20:14
[Download RAW message or body]

Michael Matz wrote:
[fitt's law]
> Not if it gets applied to each and every thing as
> "Totschlagargument" (I don't know the equivalent english phrase), an
> argument which nobody can object against, because either they don't
> know everything behind it well enough, or because it's so general,
> that you can't say anything against it. Esp. Fitts law was applied
> in the past in this list to each and every thing even remotely
> touching HCI, without making clear _how_ that should apply. (In the
> sense of "I think this is best... you know... Fitts law." and
> everyone answers: "???... Ahhh yes of course. Fitts laaaw. What
> else.")  ;-)

Okay, I see your argument.. but I try to be careful not to throw it
around where it is not applicable.

Let's digress just a bit and talk about exactly how Fitt's Law applies
here.  Fitt's Law (very simplified) basically says the the time to
aquire a target (e.g., click or select something) is a factor of the
distance you are from the target and the size of the target.  This is
common-sense, if you think about it.  The closer you are to the target
and the bigger the target, the easier it is to select it.

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.

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.

> Hmm. I think it's not the worst style. But anyway, I have a proposal how
> we can reduce all these threads about making this or that default to
> /dev/zero.
> 
> _Don't provide any defaults at all_
> 
> I'm serious. In the beginning wizard, the user can choose some things, and
> we provide _no_ default, so he has to make a decision at least one time in
> 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.
-- 
Kurt Granroth            | http://www.granroth.org
KDE Developer/Evangelist | SuSE Labs Open Source Developer
granroth@kde.org         | granroth@suse.com
           KDE -- Putting a Friendly Face on Unix

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