Fitts Law fits

5 Oct 2007 - 4:22pm
7 years ago
9 replies
712 reads
DrWex
2006

I've been trying to figure out how to use Fitt's Law properly to
increase the targetability of a dense tree structure, as displayed on
a browser page.

The information in the hierarchy is three levels, call them Category,
Subcategory, and Items.

There are about 5 Categories, each of which has 3-10 Subcategories and
each subcategory has 1-15 Items.

Displaying these data in a conventional tree leads to a display that
is a grand pain to target on. The left side is nice and large and
clear, but the right column of Items is dense and packed so that
targeting becomes quite slow.

Ideally I'd replace the tree with something like a pie menu or other
progressive display, except that the users are infrequent visitors.
We cannot expect them to learn or remember the taxonomy. The display
needs to support scanning.

In addition, a significant fraction of the users know the NAME of the
thing they want, but again do not know or remember the categories.
Thus I want to support conventional "find" functionality (ctrl-F).

My initial attempt involved using Javascript tricks to expand the size
of the Items group when the user's mouse got nearby, but that seems to
confuse people as their target appears to "jump" and may not be where
they're tracking to. Expanding the font itself (by bolding or changing
size) also has bad effects in that it can cause word wrap, meaning the
target is suddenly very far away from where the person is tracking.

Can anyone suggest a way I can meet the two constraints (support
scanning; support find-ability by name) while improving the
time-to-target problem for people who are actually using the taxonomic
hierarchy?

--
--Alan Wexelblat

Comments

5 Oct 2007 - 6:17pm
Oleh Kovalchuke
2006

It sounds like you have a categorization problem, which cannot be solved by
improving target acquisition.
To go on with your pun: Fitts law does not fit here.

Oleh

On 10/5/07, Alan Wexelblat <awexelblat at gmail.com> wrote:
>
> I've been trying to figure out how to use Fitt's Law properly to
> increase the targetability of a dense tree structure, as displayed on
> a browser page.
>
> The information in the hierarchy is three levels, call them Category,
> Subcategory, and Items.
>
> There are about 5 Categories, each of which has 3-10 Subcategories and
> each subcategory has 1-15 Items.
>
> Displaying these data in a conventional tree leads to a display that
> is a grand pain to target on. The left side is nice and large and
> clear, but the right column of Items is dense and packed so that
> targeting becomes quite slow.
>
> Ideally I'd replace the tree with something like a pie menu or other
> progressive display, except that the users are infrequent visitors.
> We cannot expect them to learn or remember the taxonomy. The display
> needs to support scanning.
>
> In addition, a significant fraction of the users know the NAME of the
> thing they want, but again do not know or remember the categories.
> Thus I want to support conventional "find" functionality (ctrl-F).
>
> My initial attempt involved using Javascript tricks to expand the size
> of the Items group when the user's mouse got nearby, but that seems to
> confuse people as their target appears to "jump" and may not be where
> they're tracking to. Expanding the font itself (by bolding or changing
> size) also has bad effects in that it can cause word wrap, meaning the
> target is suddenly very far away from where the person is tracking.
>
> Can anyone suggest a way I can meet the two constraints (support
> scanning; support find-ability by name) while improving the
> time-to-target problem for people who are actually using the taxonomic
> hierarchy?
>
> --
> --Alan Wexelblat
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

5 Oct 2007 - 6:28pm
SemanticWill
2007

But - thata

will evans
user experience architect
wkevans4 at gmail.com
617.281.1281

On Oct 5, 2007, at 7:17 PM, "Oleh Kovalchuke" <tangospring at gmail.com>
wrote:

> It sounds like you have a categorization problem, which cannot be
> solved by
> improving target acquisition.
> To go on with your pun: Fitts law does not fit here.
>
> Oleh
>
>
>
> On 10/5/07, Alan Wexelblat <awexelblat at gmail.com> wrote:
>>
>> I've been trying to figure out how to use Fitt's Law properly to
>> increase the targetability of a dense tree structure, as displayed on
>> a browser page.
>>
>> The information in the hierarchy is three levels, call them Category,
>> Subcategory, and Items.
>>
>> There are about 5 Categories, each of which has 3-10 Subcategories
>> and
>> each subcategory has 1-15 Items.
>>
>> Displaying these data in a conventional tree leads to a display that
>> is a grand pain to target on. The left side is nice and large and
>> clear, but the right column of Items is dense and packed so that
>> targeting becomes quite slow.
>>
>> Ideally I'd replace the tree with something like a pie menu or other
>> progressive display, except that the users are infrequent visitors.
>> We cannot expect them to learn or remember the taxonomy. The display
>> needs to support scanning.
>>
>> In addition, a significant fraction of the users know the NAME of the
>> thing they want, but again do not know or remember the categories.
>> Thus I want to support conventional "find" functionality (ctrl-F).
>>
>> My initial attempt involved using Javascript tricks to expand the
>> size
>> of the Items group when the user's mouse got nearby, but that seems
>> to
>> confuse people as their target appears to "jump" and may not be where
>> they're tracking to. Expanding the font itself (by bolding or
>> changing
>> size) also has bad effects in that it can cause word wrap, meaning
>> the
>> target is suddenly very far away from where the person is tracking.
>>
>> Can anyone suggest a way I can meet the two constraints (support
>> scanning; support find-ability by name) while improving the
>> time-to-target problem for people who are actually using the
>> taxonomic
>> hierarchy?
>>
>> --
>> --Alan Wexelblat
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> List Guidelines ............ http://beta.ixda.org/guidelines
>> List Help .................. http://beta.ixda.org/help
>> Unsubscribe ................ http://beta.ixda.org/unsubscribe
>> Questions .................. list at ixda.org
>> Home ....................... http://beta.ixda.org
>>
>
>
>
> --
> Oleh Kovalchuke
> Interaction Design is the Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org

5 Oct 2007 - 7:09pm
SemanticWill
2007

sorry - i tend to be more eloquent than that -Oleh is right - but I am so
psyched that you were thinking about Fitt's Law that I am almost beside
myself - this is exactly why I like IxDA - practitioners dealing with real
problems while not forgetting all the good cog sci and HCI stuff that came
before us.

sorry - more later - dinner guests just arrived - I just didn't want to look
like a putz.

w

On 10/5/07, William Evans <wkevans4 at gmail.com> wrote:
>
> But - thata
>
> will evans
> user experience architect
> wkevans4 at gmail.com
> 617.281.1281
>
>
> On Oct 5, 2007, at 7:17 PM, "Oleh Kovalchuke" <tangospring at gmail.com>
> wrote:
>
> > It sounds like you have a categorization problem, which cannot be
> > solved by
> > improving target acquisition.
> > To go on with your pun: Fitts law does not fit here.
> >
> > Oleh
> >
> >
> >
> > On 10/5/07, Alan Wexelblat <awexelblat at gmail.com> wrote:
> >>
> >> I've been trying to figure out how to use Fitt's Law properly to
> >> increase the targetability of a dense tree structure, as displayed on
> >> a browser page.
> >>
> >> The information in the hierarchy is three levels, call them Category,
> >> Subcategory, and Items.
> >>
> >> There are about 5 Categories, each of which has 3-10 Subcategories
> >> and
> >> each subcategory has 1-15 Items.
> >>
> >> Displaying these data in a conventional tree leads to a display that
> >> is a grand pain to target on. The left side is nice and large and
> >> clear, but the right column of Items is dense and packed so that
> >> targeting becomes quite slow.
> >>
> >> Ideally I'd replace the tree with something like a pie menu or other
> >> progressive display, except that the users are infrequent visitors.
> >> We cannot expect them to learn or remember the taxonomy. The display
> >> needs to support scanning.
> >>
> >> In addition, a significant fraction of the users know the NAME of the
> >> thing they want, but again do not know or remember the categories.
> >> Thus I want to support conventional "find" functionality (ctrl-F).
> >>
> >> My initial attempt involved using Javascript tricks to expand the
> >> size
> >> of the Items group when the user's mouse got nearby, but that seems
> >> to
> >> confuse people as their target appears to "jump" and may not be where
> >> they're tracking to. Expanding the font itself (by bolding or
> >> changing
> >> size) also has bad effects in that it can cause word wrap, meaning
> >> the
> >> target is suddenly very far away from where the person is tracking.
> >>
> >> Can anyone suggest a way I can meet the two constraints (support
> >> scanning; support find-ability by name) while improving the
> >> time-to-target problem for people who are actually using the
> >> taxonomic
> >> hierarchy?
> >>
> >> --
> >> --Alan Wexelblat
> >> ________________________________________________________________
> >> Welcome to the Interaction Design Association (IxDA)!
> >> To post to this list ....... discuss at ixda.org
> >> List Guidelines ............ http://beta.ixda.org/guidelines
> >> List Help .................. http://beta.ixda.org/help
> >> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> >> Questions .................. list at ixda.org
> >> Home ....................... http://beta.ixda.org
> >>
> >
> >
> >
> > --
> > Oleh Kovalchuke
> > Interaction Design is the Design of Time
> > http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://beta.ixda.org/guidelines
> > List Help .................. http://beta.ixda.org/help
> > Unsubscribe ................ http://beta.ixda.org/unsubscribe
> > Questions .................. list at ixda.org
> > Home ....................... http://beta.ixda.org
>

--
~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"
-------------------------------------------------------
will evans
user experience architect
wkevans4 at gmail.com
-------------------------------------------------------

5 Oct 2007 - 7:20pm
bminihan
2007

One way we have resolved this in the past is to provide a page-level "jump to" box, into which you type the word you're looking for, JavaScript finds the name in a behind-the-scenes keyword list and takes you to what you want immediately. We have a portal full of hundreds of such tree-structures in the form of flyout menus - we made the target areas big enough, but no amount of taxonomy tweaking fits everyone's perspective. Sometimes, you just have to give them a targeted search. As long as people can easily distinguish it from your regular search it should work (we put the words "Jump to" in front of the box and folks seem to use it ok).

Another point to note: what's the percentage of people using the taxonomy vs your search? and related: is your search an effective alternative to the taxonomy, for those who prefer to search? I guess I'm asking if people are struggling with the taxonomy because they can't search for what they want...

Good luck =]

- Bryan
http://www.bryanminihan.com

---- Alan Wexelblat <awexelblat at gmail.com> wrote:
> I've been trying to figure out how to use Fitt's Law properly to
> increase the targetability of a dense tree structure, as displayed on
> a browser page.
>
> The information in the hierarchy is three levels, call them Category,
> Subcategory, and Items.
>
> There are about 5 Categories, each of which has 3-10 Subcategories and
> each subcategory has 1-15 Items.
>
> Displaying these data in a conventional tree leads to a display that
> is a grand pain to target on. The left side is nice and large and
> clear, but the right column of Items is dense and packed so that
> targeting becomes quite slow.
>
> Ideally I'd replace the tree with something like a pie menu or other
> progressive display, except that the users are infrequent visitors.
> We cannot expect them to learn or remember the taxonomy. The display
> needs to support scanning.
>
> In addition, a significant fraction of the users know the NAME of the
> thing they want, but again do not know or remember the categories.
> Thus I want to support conventional "find" functionality (ctrl-F).
>
> My initial attempt involved using Javascript tricks to expand the size
> of the Items group when the user's mouse got nearby, but that seems to
> confuse people as their target appears to "jump" and may not be where
> they're tracking to. Expanding the font itself (by bolding or changing
> size) also has bad effects in that it can cause word wrap, meaning the
> target is suddenly very far away from where the person is tracking.
>
> Can anyone suggest a way I can meet the two constraints (support
> scanning; support find-ability by name) while improving the
> time-to-target problem for people who are actually using the taxonomic
> hierarchy?
>
> --
> --Alan Wexelblat
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org

--

6 Oct 2007 - 12:11pm
Jennifer Berk
2007

It sounds as though your concerns are about vertical space, with your
Items ending up too close together but not wanting to make them taller
for fear of hurting scannability. A tree might not actually be the
most effective way of displaying the hierarchy of the information.

Are you able to use your horizontal space more effectively? For
instance, you could make each Category the heading of a column, with
the Subcategories and Items displayed in tree form within. Then it's
more possible to make the Items larger (taller) without feeling like
your page is ten feet long.

Jennifer Berk

On 10/5/07, Alan Wexelblat <awexelblat at gmail.com> wrote:
> I've been trying to figure out how to use Fitt's Law properly to
> increase the targetability of a dense tree structure, as displayed on
> a browser page.
>
> There are about 5 Categories, each of which has 3-10 Subcategories and
> each subcategory has 1-15 Items.
>
> Displaying these data in a conventional tree leads to a display that
> is a grand pain to target on. The left side is nice and large and
> clear, but the right column of Items is dense and packed so that
> targeting becomes quite slow.

8 Oct 2007 - 12:33pm
DrWex
2006

Thanks for all the suggestions and feedback. I will probably make use
of most of what was suggested.

Bryan can you send a link to an example of a "page-level "jump to"
box" such as you described? I'm not able to picture the behavior well
from text discussion.

To respond to a few of the points:
- I agree that this isn't really a categorization problem. The
introduction of categories of this sort will be a new feature with
this release. The old groupings were developer-driven; I've replaced
those with categories/subcategories that came from a combination of
user feedback and subject-matter expertise. One of my first goals will
be to test whether this was an improvement, but to do that I have to
have a display technology that doesn't confound things. Frankly, if
the tech makes finding what you want too hard it doesn't matter how
good your categories are. Since the present implementation (cascading
menus) doesn't permit any form of search/find I have no data on how
frequently people will use that mode versus scanning.

- we do have far fewer than 800 items at the leaf node level; it's
more like 200. In the previous version the number went from 50 to that
near-200 level and there was significant complaint from experienced
users that they could no longer find the items they wanted because of
the proliferation of new things. Even though this group is probably
only about 20-30% of our users I still want to support them in finding
the few familiar items quickly. (My proposal to let people customize
their lists to just the 10 or so they frequently use was not
implemented in the current release.)

Thanks again - I really appreciate the feedback.
--
--Alan Wexelblat

9 Oct 2007 - 9:43am
Pierre Abel
2004

Hi Alan,

Concerning the needs to find an item by its name, did you consider using
a "search as you type" field that filters the tree ? I mean like in
ITunes that allows to find quickly a song via its name/its artists/the
album name/... by hidding the songs which meta-data do not match the
search field. In your case, as soon as a node or leaf name and
meta-data (don't restrict to only the name of the tree nodes) matches
the search field, the tree branch must displayed and opened (and
possibly the node that match is displayed in bold)..others tree branch
are completely hidden. . I've seen this interaction in Eclipse: its is
used in its preferences window where there is a lot of things...I found
it well suited for the task of searching by name ( one problem in
Eclipse is that the filtering is restricted to the name of the nodes
and do not apply on the leaf content ...)

Concerning the scanning, did you consider using a "column view" instead
of a "tree view" such as in (Apple one more time!) in Mac OSX Finder
(check it out in
http://www.dummies.com/WileyCDA/DummiesArticle/id-1651.html) ?
Personnaly, I don't like it very in Finder because I always have some
resizing issues, but if you have a tree depth that is fixed, it can
perhaps do the trick . (note that in this case, "search as you type"
won't work!!)

Hope its helps !

Pierre

9 Oct 2007 - 10:33am
DrWex
2006

Pierre

Thanks for the comments.

On 10/9/07, Pierre Abel <abel at castify.net> wrote:
> Concerning the needs to find an item by its name, did you consider using
> a "search as you type" field that filters the tree ?

I don't have easy access to one of these in a Web page. Our desktop
client uses these a lot.

> Concerning the scanning, did you consider using a "column view" instead
> of a "tree view" such as in (Apple one more time!) in Mac OSX Finder

My problem with using something like this is that the lower level list
is only displayed once a selection is made at a higher level. This
makes the on-page Find functionality fail and makes people back up and
down the tree a lot. I find I do this myself a good deal with the
finder which I've sometimes called the "Wander" when i get frustrated
with it.

--Alan Wexelblat

9 Oct 2007 - 10:39am
Jack L. Moffett
2005

On Oct 9, 2007, at 11:33 AM, Alan Wexelblat wrote:

>> Concerning the scanning, did you consider using a "column view"
>> instead
>> of a "tree view" such as in (Apple one more time!) in Mac OSX Finder
>
> My problem with using something like this is that the lower level list
> is only displayed once a selection is made at a higher level. This
> makes the on-page Find functionality fail and makes people back up and
> down the tree a lot. I find I do this myself a good deal with the
> finder which I've sometimes called the "Wander" when i get frustrated
> with it.

I designed a UI using a column view that included a find feature.
After typing in a search term, a column of results is added at the
left. Clicking a result in the list opens the tree/columns to show
that result, leaving the result list column until explicitly closed.
In this fashion, you can quickly browse through the results without
having to "wander".

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

My goal is to build elegant products.
The products that don't make people think
when they should be doing,
make people think
when they should be learning,
compel them by relating to them,
and simply work.

- Robert Hoekman, Jr.

Syndicate content Get the feed