Monday, April 23, 2007

What Would You Do?

Hi Friends! Today, I thought I'd take a little respite from writing my normally long-winded articles (translation: I'm wiped out from this weekend and I need a break! :-). Instead, I'm going to ask you to help me provide some ideas to another reader.

I got a great response from my post On Not Using Views and I really appreciate all of the feedback and e-mails. In that thread, Keith asked a very relevant question. I started writing a reply, but then I thought that this was important enough to get some discussion going. Here's what he had to say:

"I've started creating apps with fewer views and experimenting with displaying data differently. But my problem is customers are wanting drop down boxes that may contain 200 choices. Once they pick a category from the drop down the pertinent documents are displayed in an embedded, single category view. Is there a better way to choose the categories other than having a drop down with 200+ choices? I've made it where they can start typing the category and it'll move accordingly, but it's still kind-of extreme."

This is a sticky wicket for sure, since he has presented a scenario that makes it difficult to definitively select one construct over another. Keith, you may never be able to come up with the perfect solution in this case, but here are some thoughts:

Can you change the taxonomy somewhat so that it will easier to make the relevant selection? For example, maybe the 200 choices are logically grouped into a subset of 10 or 20. You could then have two drop downs, one to select the main category and the second to pick the sub category. In that way, both sets of drop downs are relatively small and easy to handle.

Another thought is that maybe there is some info you could gather before the user opens the form that can help narrow down the list of choices. For example, perhaps your embedded view shows a list of sales calls by branch. On document open, ask the user what state the report is for and use that to show just the relevant branches for that state in the drop-down.

Sorry I don't have a better answer for you. Sometimes you are just stuck having to present a big list. There's nothing inherently wrong in this, however. In my mind, the key is to weigh this against the alternative and see which one works best. (Hint: Although it's tempting, don't try to answer this question yourself. This is the perfect time to enlist the aid of your customers and do some usability testing. Trust me, they'll tell you exactly what you need to know! :-)

So...perhaps some other people out there have come up with alternate solutions that might benefit Keith (and everyone else here). If you have an approach that you'd like to share, please leave a comment. Thanks in advance! Oh...and Keith, let us know what you end up doing.


Rob McDonagh said...

What about something like a saved search, but with saved selections instead? Hardly anyone really needs 200 items in a drop-down, they need 10, but there are 300 of them and when you do an @Unique on their sets of 10 you get to 200. Or at least that's always been the case where I've worked. I wonder if you could let people identify the subset of items they most commonly need, store them in profiles, list just the preferred choices by default, and give the users access to the whole list via a checkbox or Other selection?

Nathan T. Freeman said...

Since Keith describes this as a "drop-down" I'm assuming he uses a combobox. Personally, I find 200 choices a lot easier to digest in either a dialog-style list, or in a listbox, which should give you limited type-ahead abilities. You don't have to consume a lot of screen real estate with the list box, though. Even if it's only 6 or 7 options long, the type-ahead will help you.

Anonymous said...

would you try (and share, via probably) following scenario...?

- combo, allow values not in list
- OnChange event reacting to typing in combo
- if combo is empty, it would suggest recently used categories only (stored in environment or profile)
- if you start typing (and pause for a moment), list of categories starting with typed text will be added to choices. it will probably result to dozens, not hundreds of choices. if prefetched, it will be fast
- if you type or choose anything matching category, view will be refreshed to show selected category

what you think?

Keil Wilson said...

Actually, Rob's comment reminded me of the new resource scheduling features in ND7. I work for a state government that has tons of resources listed when you want to schedule meeting. I've always dreaded having to scroll through the whole list to schedule a meeting. The ability to set your "preferred" rooms and resources is an awesome add. Unless your users have an equal chance at needing any of the 200 choices, then having a preferred list similar to the Rooms and Resources tab of the ND7 calendar preferences might be a good option.

Nathan T. Freeman said...

@Rob & Keil,

Actually, that could be a very powerful model, now that I think about it. You could have the system just LEARN for pretty easily.

The first time you go in, when you don't have a profile, there's a button: pick my favorites. User gets a multivalue listbox and selects those of the 200 that are important. (That interface also has a "no favorites" option that just skips the step and shows everything.)

The normal course of use shows the favorites list, plus an entry for "full list." That limits the choice, but gives the exception approach for full lists of choices. I'd bring up the full list in a dialog box, too, personally -- no reason to dedicate screen real estate to it. (Though maybe with a layer... :-) )

THEN, if the user selects out of the full list, you add that one-off selection to their favorites. Or if you present in a dialog, you provide a checkbox that says [ ] add to my favorites.

It's a lot of work, but all the good stuff usually is, right? and once you put the framework in place, the amount of stuff you DON'T need to build (ie: 200 views) really makes it pay off.

Patrick Kwinten said...

If you have such a long dropdown list why dont you group your options via the optgroup tag?

Definition and Usage
Defines an option group. This element allows you to group choices. When you have a long list of options, groups of related choices are easier to handle.

Anonymous said...

@nathan - "pick my favorites"
I think, "favorite" is something already and comonly used. you force user to choose from 200+ options again. think of profiling "history", rather than managing favorites (what is in my opinion unnatural to non-IT-affected users).

Keil Wilson said...

Nathan, you and I are on the same page there. Again, if the use is just as likely to pick ANY of the 200 choices, then the favorites approach doesn't really work, but I love it for the Room and Resource Reservations. I'll have to start using something like that in our current application :).

Nathan T. Freeman said...

@Anonymous - If I base it SOLELY on learning from history, then I have to present the user with all 200 options the first time for sure. If they select A the first time, and then come back and want to select B, they have to look at the list of 200 again.

My suggestion is to offer the list of all 200 the first time, and then let the user say "I typically want A, B, M, Q and R." Then retain that. If they go beyond that set in the future, you can add the selection in to their list, thus learning by history.

It's a preferences control for them. Giving the user a minimal amount of setup when using an application for the first time isn't obtrusive, as long as they can skip the set up if they're a one-off user. Hence my "skip selecting favorites."

As far as the language choice goes...

I'm kinda digging "druthers," but "top choices" also works well.

@Keil, I have a hard time envisioning a user having equal chance of picking ANY of 200 options.

Keith Strickland said...

Wow! Thanks for all the choices on how to attack this. Also, Thanks to Chris for making a full blown post out of my question :)

The applications that I've been working on lately are to manage government agencies, the agencies are identified by an agency code, the user picks the agency code from a combobox (populated with @dbcolumn) and then adds documents for that agency.

But I think that keeping track of favorites or recently accessed agency codes would be the way to go here. I've just presented the initial version of the app to the customer, and watching them use the app they tend to have just certain agency codes that they are responsible for.

Now I just have to decide to do it via an environment variable or via a profile document.

Thanks again everyone!


Thomas Bahn said...

I have described another approach, which I call "embedded picklist", in my blog:

Thomas Bahn

Anonymous said...

@nathan: I have to present the user with all 200 options the first time for sure

yes, that is true - put them into combo. I was just arguing, that opening different form with checkboxes "choose your favorites" is counterproductive.

good example is in MS Word font combo. you see all your fonts, but few recently used are on top.

my suggestion was about dynamic population of combo - similar to gmail's contact autocomplete (hard to achieve in LN client, though).

@keith: profile vs enviro
count with ~254 chars limitation of single line in notes.ini

Nathan T. Freeman said...

"good example is in MS Word font combo. you see all your fonts, but few recently used are on top."

Now there's an interesting possibility. I still would look to do this in a listbox rather than a combobox, but putting the personal frequent entries at the top is a nice way to go. Definitely minimizes click-count.