unity-design team mailing list archive

[David Regev <david.regev@xxxxxxxxx>]

On Mon, May 23, 2011 at 08:05, Ed Lin <edlin280@xxxxxxxxx> wrote:

>  W in this context depends on acceleration curve and distance, it's not
> fixed! That's the reason one may be tempted to start calculating with
> infinity and mathematically speaking its use is absolutely correct. "You are
> not supposed to" doesn't count.
>

*W* is the width of the target. Perhaps you’re thinking about *D*. As I
explained, for any particular display, in practice, you can figure out a
specific value for that based on how far users typically travel past the
edge. That’s exactly what Jef Raskin did. If you think this is inaccurate,
you need to do your own studies and measurements. (I wish someone would
actually do that on Ubuntu.) In any case, the point stands: Fitts’ Law
doesn't break down at screen edges.

I doubt these results. The mouse doesn't accelerate perfectly an
> indefinitely. There is a typical maximal speed people move their hands. Ever
> noticed how moving the pointer in a diagonal (bottom left <-> top right for
> right hander) or horizontal line is easier to do fast than moving
> vertically? The menubar usually has to be accessed with a vertical movement,
> squarely to the top left. _Again_ something Fitts's law does not take into
> account. Apart from requiring more "work" from the user to access targets
> which are further away, no matter the size,  it also adds to the RSI risk.
>

It does take this into account—*a* and *b* depends on he context, and must
be determined through testing. I suspect that you’re right that the angle
changes things (though *very* slightly). This is why Tog (question
3)<http://www.asktog.com/columns/022DesignedToGiveFitts.html>was able
to list the corners in order of difficulty to access.

Sadly he doesn't share his calculations with us but I also think his math is
> flawed because it's based on Raskin's who uses the same average distance
> both for the global and the in-window menus. It also looks like he didn't
> correct for mouse acceleration.
>

The average distance is not the same. That wouldn’t make any
sense.Windows-style menus and Macintosh-style menus obviously have
different
distances. And that’s the point: you can compensate for a larger distance
with a larger width, which the edge will give you (and it’s not ∞).

Anyway, he gives you *a* and *b* and the distance and width for both styles
of menu. (He uses different letters for the variables, though.) You can do
the calculations yourself and verify. If you do, I hope you’ll post the
results.

Raskin was using whatever mouse acceleration existed on the Macintosh at the
time of his test. I have no idea how accurate it still is for modern
systems, but I am not aware of any more recent determinations of *a*
and *b*for such systems. In any case, better mouse acceleration would
actually make
the screen edge even *easier* to reach.

Overshooting the top menu usually results in lateral movement which can put
> the pointer above the wrong entry. The horizontal W becomes a pretty small
> number. As mentioned the simple formula used ignores that.
>

And as all researchers already know, and as I’ve seen pointed out in most
serious discussions of Fitts’ Law. The equation describes movement in a
straight line. Further movement in another direction is a separate
calculation, which is why the target’s horizontal width is also important,
and why the corners are even easier to reach (“infinite” width in two
directions). Similarly, movement of your hand from the keyboard to the mouse
is yet another time calculation (that calculation is described by a
GOMS<http://en.wikipedia.org/wiki/Keystroke-Level_Model>analysis)
.

These are all things UI designers should keep in mind. Fitts's Law is only
> one aspect and in many ways an oversimplification.
>

Exactly. And that’s why you shouldn’t claim that Fitts’ Law doesn’t take
things into account. It’s *people* who may neglect taking certain factors
into account, like the time added up outside that one linear movement that
the Fitts described.