views:

413

answers:

6

I'm looking to build a "quick link" directory access widget. e.g. (option 1)

0-9 | A-F | G-K | L-P | Q-U | V-Z

Where each would be a link into sub-chunks of a directory starting with that character. The widget itself would be used in multiple places for looking up contacts, companies, projects, etc.

Now, for the programming part... I want to know if I should split as above...

0-9 | A-F | G-K | L-P | Q-U | V-Z
10+   6      5     5     5     5

This split is fairly even and logically grouped, but what I'm interested to know is if there is a more optimal split based on the quantity of typical results starting with each letter. (option 2)

e.g. very few items will start with "Q".

(Note: this is currently for a "North American/English" deployment.)

Does anyone have any stats that would backup reasons to split differently?

Likewise, for usability how do users like/dislike this type of thing? I know mentally if I am looking for say: "S" it takes me a second to recall it falls in the Q-U section.

Would it be better to do a big list like this? (option 3)

#|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z
+1  A: 

Well, one of the primary usability considerations is evenly-distributed groups, so either your current idea (0-9, A-F, etc.) would work well, or the list with each individual letter. Having inconsistently-sized groups is a definite no-no for a user interface.

James Burgess
+3  A: 

As a user I would most definitely prefer one link per letter.

But better (for me as a user) would be a search box.

PEZ
especially a search box that updates in real time and/or autocompletes
rmeador
Yes, that's the kind of search box I meant. Sites sporting these in an intelligent way gain my deep love.
PEZ
I think I'm going to use option 3 (every letter), graying out the letters with no results and providing an autocomplete type search box to go with it.
scunliffe
Why graying those letters out? If there are no results just don't display these letters.
Paul
A: 

I almost always use the last option since it is by far the easier to navigate for a user. Use that if you have enough room for it and the other one if you have a limited amount of screen estate.

willcodejavaforfood
+1  A: 

You probably definitely don't want to split across a number - that is, something like

0-4 | 5-B | ...

Besides that, I'd say just see where your data lies. Write a program to do groupings of two, three, four, five, etc... and see what the most even split for each grouping is. Pick the one that seems nicest. If you have sparse data, then having one link per letter might be annoying if there are only 1 or 2 directories with that name.

Then again, it depends what a typical user will be looking for. I can't tell what that might be just from your description - are they just navigating a directory tree?

Claudiu
The user would be navigating a directory... it could be contacts, projects, pretty much anything. There would definately be a search option as well, I was just hoping to "clean up the interface" rather than spell out the entire alphabet ;-)
scunliffe
+4  A: 

I would suggest one link per letter and hide the letters that don't have any results (if that doesn't asks for too much processing power).

Stormenet
+3  A: 

I think you're splitting the wrong things. You shouldn't evenly split letters, you should evenly split the results (as best as you can).

If you want 20 results per page, and A has 28, while B-C have 15 you'll want to have

A

B-C

and so on.

Additionally, you might have to consider why you are using alphabet chunking instead of something a bit more contextual. The problem with alphabet chunking is that users have to know the name of what they are looking for, and that name has to be the same as yours.

EDIT: We've tested this in lab conditions, and users locate information in chunk by results vs chunk by number of letters in pretty much the same way.

EDIT_2: Chunking by letters almost always tests poorly. Think if there are any better ways to do this.

AdamC