I have a database driven asp.net mvc3 web application. In it, a user can go to a page and enter data based on the completion of a task. I bolded the task because it is hugely weighted in this application. The selection of a task holds the referential link to a load of data. Currently (and under construction) the tasks are listed in a dropdown list.

For example, this might be what the user sees when they click the down arrow to expand the dropdown:

[ id number  |   name   |  description  |  date  ]
[    1       |   Car    |  Repaired     |  4/20  ]
[    2       |   Door   |  Lock changed |  4/21  ]
[    3       |   Fridge |  cleaned      |  4/22  ]

However, each of these have far more data linked to them such as who did the task, what type of tools were used, where the work was done, how long it took, and more. In total, there are four tables which need to be displayed with about 11 fields combined.

There is far too much data to properly display the whole task in the dropdown, and doing it as shown in the example gets really hard for the user to navigate once there is a lot of data.

I tried searching google and SE for a good way to display large amounts of data like this but was unable to find anything which fit this situation.

What is a good approach to take in order to show a collection of huge amounts of relational data while still allowing the user to distinguish the different sets of relational data?


The task is actually part of a larger data collection which will eventually be committed. In this sense, the task represents a large data set which has already been entered. There are only one-one relationships there.

4 Answers 4


Are you sure you're required to use the dropdown? What happens on the rest of the page? This is a classic case for master-detail layout. For example:


download bmml source – Wireframes created with Balsamiq Mockups

  • Nope, not required to use a dropdown that was just used as a simple example. This is a good suggestion and similar to what I had in mind as far as approach when I went searching for what others suggest. However, the real issue is the visual aspect hence the context of the "User Experience" - moreover, the specific nature of compactness in visual displays. In that sense, this is not really viable.
    – Travis J
    Apr 25, 2012 at 20:57
  • "the real issue is the visual aspect hence the context of the "User Experience"". If you think that user experience means that it's about the visual aspect of things, you really need to spend more time on this site... Apr 26, 2012 at 7:05
  • What a rather negative attitude you have, thank you for the implied insult I suppose. Either way, your comment really has no content to it at all - much like your answer.
    – Travis J
    Apr 26, 2012 at 19:23

There are 11 fields for each task... but do you need to show the user all 11 in the list? Instead, why don't you figure out which of the fields make it easiest for users to differentiate the tasks (for example, the date, customer, and employee), and then display the rest of the information after you choose an item, like so:


download bmml source – Wireframes created with Balsamiq Mockups

However, you indicated in a comment that the list of data contains tens of thousands of entries. This should not be in a drop-down control at all! If a user is browsing the data, it should be displayed in a grid control like a table or spreadsheet. If the user is selecting an item from that list, then this should be done via searching or filters on the table. You can make it so the row pointed at highlights, and clicking selects/activates that task, presumably taking them to a different related screen.


download bmml source

But a drop-down control is completely unsuitable for thousands of records.

  • Showing the information after the selection in this example is visually appealing, but not an issue for me. The issue is showing the information before the selection. What if there are collisions in the dropdown? For example: [ 04/24 for John Doe ][ 04/24 for John Doe ]. I don't want the user to have to wade through all those to find the right one so I am trying to display the rest of the information up front.
    – Travis J
    Apr 24, 2012 at 21:39
  • That's why you choose fields that will reduce collisions; only you know your data well enough for that. If collisions are rare, then occasionally having to choose twice is a very minor cost. Apr 24, 2012 at 21:41
  • John Doe is a simple example, but when there are large amounts of data a few fields aren't going to differentiate enough. The representations of are too complex for a dropdown. I am looking for alternatives. Consider also that there could be tens of thousands of records in the drop down.
    – Travis J
    Apr 24, 2012 at 21:43
  • Hold on... tens of thousands of records in a drop-down? You are using the wrong control. In fact, you are using the wrong interface completely. Users should never have to scroll through thousands of lines to select something. Apr 25, 2012 at 13:03
  • I never said I was using a dropdown as a control. That is the only thing you seem to be able to come up with lol. This question is posed as seeking alternatives. Stop thinking in the box!
    – Travis J
    Apr 25, 2012 at 20:53

Could you possibly use a drill-down approach here? Myrddin Emrys' example begins to get into this a little. You could offer the user a dropdown containing all your data points (ID number, name, description, etc.) to give the user a starting point, e.g.:

Find job by:
[date |v]

Then the user would be presented with a date selection to find all jobs completed on the selected date. The user could then continue to drill into the results, for example by selecting a "name" on the results of the date search, until she finds the exact job she is looking for.

You could even do some testing to determine the most usable option for starting a search like this, and default to that instead of offering the extra dropdown selection.

I hope I am understanding your problem correctly.

  • Thank you for the response. I must not have been explicit enough in my description so I apologize for that. The task is actually part of a larger data collection which will eventually be committed. In this sense, the task represents a large data set which has already been entered. There are only one-one relationships there so there wouldn't really be any "drilling".
    – Travis J
    Apr 24, 2012 at 21:55

everyone else got a stab at this, why not me right? :)

This answer will be subject to change as my solution evolves. I figured it would be nice to for others to see what direction I would be going in. Sorry if it was not stated or implied, but this is going to be a web application in asp.net.

I will be using a tandem of approaches here. Filtering, dropdown (non-classic!), grouping, and dashboard.


The records will be all loaded, and there will be a control at the top of the list of all records to filter based on criteria pertaining to relevance.


This functionality will be overloaded, in that it will classically look like a dropdown selection at first glance, but will be a fully dynamic experience to interact with. Picture a re-imagining of the dropdown.


Data will be grouped by relation in panels where the outermost panel is the parent-most relation. A single collection of these panels will constitute a record and have a select button to keep with the theme of a "dropdown" (re-imagined). These panels will populate the dashboard.


The dashboard will be a popout (think lightbox but more custom). At the top of the dashboard will be a section for filtering records. Records will be grouped, and each group will be in a panel. These panels will be displayed in a list fashion (keeping with the dropdown theme). The list will contain a set of records, roughly 50. The dashboard popout will be scrollable in place. This means it will scroll in its own area without the whole page scrolling. When the dashboard scroll has reached the current bottom of the list, another 50 records will be dynamically loaded and appended.


To get a visual idea, an overview if you will, picture a <div> which is 80% of the screen width, and about 40% of the height, indented down from the top of the page a little. This will be the dashboard area. The dashboard area will pop out and display based on user activation (I am re-inventing the wheel in a way, by overloading the functionality of the dropdown here). The activation control will look like this:

[ -- Select A Z -- ]

When the dropdown list gains focus the dashboard will be displayed. Clicking in the bottom right [close] of the dashboard, or at the top right [x] will close the dashboard. In addition, clicking anywhere outside of the dashboard will prompt a dialogue which asks if the user wishes to close the dashboard.

The user will then navigate through the panels, filtering as necessary, in order to come to the final choice and then marking it as selected with a button click.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.