UI to allow 700+ multiple choices

Question

In my desktop .NET application I have written(for internal use) where I need to allow my users to apply diagnosis's to a Member Plan. There are currently 700 in the system and growing. I need to allow them to add multiple diapnosis's at once. I currently am allowing this through a combo check list box. This works but is INSANELY unweildly for both myself and the users.

What I am looking for is a how I could go about displaying these to the users. Ideally I would need to show two criteria for each each as well. Diagnosis Name and Diagnosis Code

Ideas? How would you tackle this?

I am using .Net 3.5sp1 and SQL 2005 for the backend. I don't care if the solution is WPF or Winforms.

Answer 1

You could either have some sort of method for limiting the amount of users displayed at one time...ie categorize them somehow (then you could 'drill-down' into smaller and smaller groups).

You could also implement a search that auto-suggests names as you type them to aid in limiting the amount shown at once.

Answer 2

I'd use 2 listviews, 2 buttons and textbox.

One listview to hold the possible values, one listview to hold the selected values. The textbox can be used to filter the possible values (if the user enter MyValue only show the values that contains MyValue etc) and then the buttons would be standard button arrows to move the selected rows between the listviews.

And expanding on espais answer about drilling down, if that's possible maybe it would be better to have one or both of the listviews be treeviews instead, that way you could combine drilling down with filtering and be able to tell which ones are where etc.

Answer 3

I think a simple text-entry field, with an auto-complete dropdown. when a selection is made, add another field to the page for the next entry.

Answer 4

You need to flip your thinking. It's not about presenting them with data, its about recording the users' intent.

When a user sits down to diagnose a Member Plan they are not thinking in terms of "which of 700 options should I select, oh let's just click some for the heck of it". The said truth is that people rarely sit down at a computer because business apps are fun - they're usually using them to get some specific bit of work done. In your case this sounds like they're trying to do a specific kind of analysis. Each type of analysis can have several uses, you should capture that too.

All these concepts should be explicit. For example (making up your domain somewhat), if there is an option to show all users that have a meal plan and an option to filter by users whose kids also have a membership it is probably unlikely that those options are ever used in conjunction. Instead you could ask your user what they would like to do: Analyze costs, or Analyze spread of membership. Something like that. Your users probably only use your application to issue at most several dozen types of queries.

Once you know what kind of work they're doing and what they're doing it for, I'm willing to bet the option set is cut down dramatically.

I've linked this a dozen times but this herding code podcast with Greg Young is a must listen for every developer.

Answer 5

I would implement something like:

Available              Assigned
+-----------------+    +-------------------+
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
+-----------------+    +-------------------+

Filter: -----------

Where each box is a list view, the filter text box allows the user to filter the available diagnosis', and items are drag/droppable between boxes.

Once an item has been assigned, mousing over would show an inline delete button to allow the user to remove previously assigned values.

Answer 6

The problem is that there simply isn't a control that isn't unwieldy with 700+ items in it. Trees, listviews, comboboxes, datagridviews... they are all a pain (for different reasons) when you've got that many items.

I'd suggest providing either A) some categorization of the data to limit the choices and have a combobox to switch between those categories, or B) text entry that has auto-completion to reduce down the size of the items from which to pick.

For B, I'd use the (fairly standard) two list view, text entry and two button mode. Hook up the text change event to "filter" the left list view, use the "Add" button to add the selected rows to the right list view. Use the "Remove" button to take them out of the right text view.

You could get clever and reduce down the items by their name or by their identifying code - some people remember that a 012345 means something since it is commonly picked, for instance - or you could devise a different scheme for reduction.

I use B) in several products and it works great.

Answer 7

In addition to George's suggestion, I'd just like to add that if your options need to be discoverable, grouping the options into categories can quickly get people to where they need to look.

However, be careful with this, because how a developer would categorize options vs. a user are often different.

Another option is creating a work flow and rethinking the interface. I know you mentioned they need to enter them simultaneously, but if there's an opportunity to create a multiple-page entry (similar to a wizard), it's far less overwhelming. "Choose options from category 1..." on page 1... and then next. Careful again here to let your users know where they are in the scope of your application. Step 2 of 8.

There are many factors, including, how often the application is used, what skill level do your users have, what are you trying to accomplish in the end?

HTH

Answer 8

From a historical use of data mining against a claims adjudication system and having to deal with diagnosis / procedure codes, you might want to switch to a combination of controls. First, I would have a grid (allows more than 1 or 2 diagnosis, so your not stuck there and having to redesign a form if more are ever needed) of Entered Diagnosis Codes. Above it (or below), have a textbox.

If the users have some documentation they are entering from and have the codes right there, allow them to free-entry into the textbox. During the validation of the textbox, query your table of valid codes and get the code and description to populate in your grid above if only 1 entry found. If more than 1, display a popup window with a grid of the choices that matched your query and allow them to pick from THAT. Any such chosen would be added to your primary grid display. If NO Entries are found, that could be from a type-o, or a code that just doesn't exist. I would then strip back the string until you queried and DID receive some result. Then, like previously stated, call the secondary form to pick from available diagnosis codes. Ex: if Diag code "12345" can't be found, look for "1234", "123", "12", "1" until SOMETHING comes back with a result.

Additionally, for the querying, if the text is determined to be numeric, query based on the code. If alpha, query on the description... Either way, a result set could be displayed of what IS found instead of stumbling through a list of non-applicable items.