How can I manage a large dropdown list (1000 + items)

[Karen Grube]

Hi!

I have a server control dropdown list on an asp.net page that may contain
as many as 1,200 items. The list is databound to a SQL Server stored
procedure which actually retrieves the data in a couple of seconds. However,
the dropdown list itself takes 20 or more seconds to populate.

On this page, the user selects an item from the dropdown list and then
moves down the page to enter additional information. As much as I mind how
long it takes to poulate the list initially, what's worse is this: I have
some amount fields on the page. When the user enters an amount, all of the
amount fields are totaled and the total is displayed in a label. Each of the
amount fields is set with autopostback so that the total can be recalculated
when the amount changes and the total redisplayed. What's happening is that
when you enter an amount on a page where the dropdown list is very large, it
takes forever for the page to redisplay, even though nothing is happening to
the dropdown list. I'm not sure what's going on behind the scenes, but I
really need to cut down on the time it takes to simply redisplay the page.
I'm not sure I really understand why this takes so long once the dropdown
list is populated. It's not changing. When the list is a short list (under
100 items) the screen redisplays quickly, so I know it's the dropdown that's
causing the delay.

Could someone please explain what's going on with the dropdown list while
the screen is redisplaying on autopostback for another item on the page. The
page load event is set to read "If not ispostback," so nothing's being
executed there. I can't see where anything at all is being executed except
the redisplay of that total label. Do I need to set some sort of memory
cache or something? Any suggestions would be greatly appreciated.

Thanks
Karen Grube
([email protected])

 

[Scott Mitchell [MVP]]

Hi Karen. What's happening is the DropDownList is storing it's items in
ViewState (that hidden __VIEWSTATE field filled with goobledygook you'll
see when you do a View/Source). So when the form posts back, the user's
browser must upload *all* of the <input> fields, including that
painfully large hidden form field. Furthermore, chances are the
DropDownList's rendered HTML is large, adding to the download time
again. Your user's are suffering on both the postback time and on
waiting for the HTML response to be sent back.

One option might be to turn off ViewState for the DropDownList, that
will save you on the upload time, although you will have to likely add a
bit of tricky code to compensate for the loss of the view state.

There are a host of other tricky ways you might solve this, but the
bottom line is Web apps aren't designed to have DropDownLists that huge.
Plus, how useable is such a form? Is the user really expected to
search through 1,000+ DropDownList entries?

Don't get me wrong, I understand this can be a clinet requirement - I
had such a project which ended up in a page size of over 2.5 MB! (See
http://scottonwriting.net/sowblog/posts/1579.aspx) But if you can, try
talking to your boss/client and see if this data entry form /
DropDownList can't be broken up in a more sensible manner.

Best of luck.

Hi!

I have a server control dropdown list on an asp.net page that may contain
as many as 1,200 items. The list is databound to a SQL Server stored
procedure which actually retrieves the data in a couple of seconds. However,
the dropdown list itself takes 20 or more seconds to populate.

On this page, the user selects an item from the dropdown list and then
moves down the page to enter additional information. As much as I mind how
long it takes to poulate the list initially, what's worse is this: I have
some amount fields on the page. When the user enters an amount, all of the
amount fields are totaled and the total is displayed in a label. Each of the
amount fields is set with autopostback so that the total can be recalculated
when the amount changes and the total redisplayed. What's happening is that
when you enter an amount on a page where the dropdown list is very large, it
takes forever for the page to redisplay, even though nothing is happening to
the dropdown list. I'm not sure what's going on behind the scenes, but I
really need to cut down on the time it takes to simply redisplay the page.
I'm not sure I really understand why this takes so long once the dropdown
list is populated. It's not changing. When the list is a short list (under
100 items) the screen redisplays quickly, so I know it's the dropdown that's
causing the delay.

Could someone please explain what's going on with the dropdown list while
the screen is redisplaying on autopostback for another item on the page. The
page load event is set to read "If not ispostback," so nothing's being
executed there. I can't see where anything at all is being executed except
the redisplay of that total label. Do I need to set some sort of memory
cache or something? Any suggestions would be greatly appreciated.

Thanks
Karen Grube
([email protected])

--

Scott Mitchell
(e-mail address removed)
http://www.4GuysFromRolla.com

* When you think ASP.NET, think 4GuysFromRolla.com!

 

[Karen Grube]

Hi Scott!

The dropdown's can't be separated or broken up. We have that many
members at several of our company's resorts, and I need to show all current
members in a dropdown for the user to select the correct one. The list is
alphabetical, so it's not that tough to get through.

My thought was, once the user has selected a single item from the list,
clear the dataset and re-populate it with just that one item, so only that
item will display in the dropdown and remain selected. But I'm not sure what
will happen if the user tries to re-select. Perhaps I can capture the user's
having clicked on the dropdown, even though the selected item can't have
changed - cause there's only one item. Hey, I just had a good idea. Do what
I just said about having only that one item in the dataset. Sort of. I
could add an item to the list that said 'reselect' and then repopulate when
the user selects that item from the dropdown. The word 'reselect' would be
the 'zero' selectedindex value; the real item they had selected before would
be the '1' selectedindex item. so if they hit they dropdown, they'll see the
word 'reselect' and know they can regenerate the list. Sorry if that sounds
a little weird, but it's the best I can come up with. Any other ideas? Of
course, I'd only use this technique if the list were over, say, 300 items.

I think your idea of turning off view state or something like that might
work better, but I'm not sure of the tricky code you mentioned that would
help me compensate for that. Where might I look for a sample of that
technique?

Thanks!
Karen

 

[J.W.]

We have encountered exactly same problem of some of our projects. I agree
with Scott that I think best practice for this kind of problem is to get rid
of dropdown and redesign it, using table with paging or others. Despite of
alphabetical sorted, it still not elegant in terms of web usibility,
especially you have maybe 500 A-started memebrs.....

Only my 2 cents.

 

[Scott Mitchell [MVP]]

Karen, one project I worked on had several screens where the user needed
to pick one client from potentially thousands. What I did was break it
up into two screens. On screen 1, they were given a textbox and asked
to enter all or part of the client's name. Once they did this, it would
show a DataGrid with the matching clients, with a "Select" button in
each row.

Clicking on the "Select" button for a particular client whisked the user
to the second page, where they were shown the information for that
specific client, and they could add/edit/delete the data.

Perhaps this UI concept would work for your project?

Hi Scott!

The dropdown's can't be separated or broken up. We have that many
members at several of our company's resorts, and I need to show all current
members in a dropdown for the user to select the correct one. The list is
alphabetical, so it's not that tough to get through.

My thought was, once the user has selected a single item from the list,
clear the dataset and re-populate it with just that one item, so only that
item will display in the dropdown and remain selected. But I'm not sure what
will happen if the user tries to re-select. Perhaps I can capture the user's
having clicked on the dropdown, even though the selected item can't have
changed - cause there's only one item. Hey, I just had a good idea. Do what
I just said about having only that one item in the dataset. Sort of. I
could add an item to the list that said 'reselect' and then repopulate when
the user selects that item from the dropdown. The word 'reselect' would be
the 'zero' selectedindex value; the real item they had selected before would
be the '1' selectedindex item. so if they hit they dropdown, they'll see the
word 'reselect' and know they can regenerate the list. Sorry if that sounds
a little weird, but it's the best I can come up with. Any other ideas? Of
course, I'd only use this technique if the list were over, say, 300 items.

I think your idea of turning off view state or something like that might
work better, but I'm not sure of the tricky code you mentioned that would
help me compensate for that. Where might I look for a sample of that
technique?

Thanks!
Karen

--

Scott Mitchell
(e-mail address removed)
http://www.4GuysFromRolla.com

* When you think ASP.NET, think 4GuysFromRolla.com!

 

[Karen Grube]

Hi Guys!

Thanks for the feedback! Yeah, you're right. Such a huge dropdown
really is unwieldy. I'll be following your suggestions and adding a text box
for a client number or partial name and then filling in the dropdown from
that. Often, there will be only one item, but perhaps more if the user types
in a common last name. Still, it'll be a very small, filtered list.

Thanks again! I really do appreciate your help.

Karen

 

[Robert Koritnik]

I had a simmilar problem but it didn't require dropdown in any way. But the
approach is the problem. From the user point of view, searching (may be
ordered in any way) in a list of 1000+ items is really BAD user experience.
What we did was to make a list with paging, but with custom paging that was
searched by individual initial letters rather than page numbers. It was
easier to serch for a certain item.

But most of the time we take a "search-select" approach with a textbox so a
user can enter a part of the item name or some other descriptor and select
from the results. View state remains small and time to select an item is
normally just as fast as having all items on the client side at once
eventhough this approach requires one postback...