views:

201

answers:

4

I am building a Silverlight application where one of the tasks will involve the user selecting one item from a list of approximately 1300 items. What would be some of the best ways to present this list to the user? I think 1300 items in a ComboBox is too many. Is it? What are the best practices for this kind of situation? The items are inventory locations that have a pattern such as:

Row 1 - Aisle 1 - Level 1
Row 1 - Aisle 1 - Level 2
...
Row 1 - Aisle 2 - Level 1
...
Row 2 - Aisle 1 - Level 1
and so on.

There will also be some other locations such as: Shipping Dock, Staging Area etc...

I would like to possibly have a TextBox and ListBox where the ListBox would start be populated with matches to what the user enters into the TextBox. The data could be from a web service or stored in Isolated Storage?

+2  A: 

Yes, 1300 is too many for a combo box. Using a combo box to select my country on a website always seems borderline to me, and 1300 is more than that.

With your data structure I highly recommend choosing row, then aisle, then level as three separate things. Update the next box each time. Within each selection, list boxes are faster to use than combo boxes, but take up more screen space.

Peter
My first impulse would be to have three drop-downs or list boxes. The first one gives a list of rows. Once the user selects the second one fills in with a list of aisles in that row. Once that's selected, the third one fills in with a list of levels. Alternatively, let the user select a row, then display a new screen with the list of aisles, etc. Either way it's a round trip to the server for each selection.
Jay
Regarding the 3 dropdown lists, I would still need those other locations that are not part of the 'pattern'. How to break apart the master list into rows, aisles and levels? How to merge the 3 selections back into one once the user has made their selection? 3 service calls? One service call and then break apart on the client?
DaveB
+1  A: 

Use a list (or table if there's more info) with an edit box above that filters the list based on the text as the user types.

This is different from what's suggested in the question as by default it shows all the data and then filters it down.

Tom
+1  A: 

It sounds like your items are highly grouped. This means you can either use a tree-view to present the items, or you can even display an image (floorplan?) of the areas which can be selected.

Having a textbox with autocomplete (and a list of -say- 20 best guesses update in realtime next to the textbox) would be the old-skool way of solving this.

David Rutten
I agree with the treeview idea, but disagree that autocomplete is "old-skool". Autocomplete is very web 2.0 (Google suggest, Stack Overflow, etc.). Tree views on the other hand sound more old fashioned (Outlook, Windows, Winforms, etc.)
Jacob Adams
A: 

I agree with both @tom and @davidrutten. Either a treeview or autocomplete type controls sound the best. Look at the TreeView and AutoCompleteBox controls in the Silverlight toolkit

Jacob Adams
The AutoCompleteBox might work. Would I need to download all 1300 locations each time the page is rendered? Maybe store globally in the application? Does the AutoCompleteBox allow the use of a ASHX service to populate it(like SilverlightFX can)? Didn't look that way. Using a TextBox still doesn't constrain the selection. I'll look into the TreeView.
DaveB
You would probably want to filter it before it even got to the AutoCompleteBox. That being said though, you have pretty granular control with the Autocompletebox. It my last project, I handled the event of the text changing and each time, called my web service to get a list of 20 items. If needed, I also could have used done further filtering with the AutoCompleteBox. I'm not sure how much built in support there is for ashx, but you should be able to use it one way or another. If you try it, post your findings.
Jacob Adams