tags:

views:

75

answers:

1

I have this situation where I have a listbox which is being populated from a background thread (it's an address book and the data is coming from AD).

The problem is that since the list is sorted (using CollectionViewSource) and also available to the user while more data is being retrieved, it's bouncing all over the place as new items are being inserted at various places in the list. So it's available to the user, but mostly unusable since the user's selections keep going out of view.

Is there a way to keep focus to the item selected, and preserve the selection, even if items are being inserted above and below the selection from the background thread? I would prefer not to sort on the server, which I understand can be a bad thing when it comes to AD.

A: 

I'm going to respond to this from a UI design perspective rather then a technical code perspective. (I'm sure someone else will have a way to have the list box keep the selected item in view)

I would argue that the use of a list box while large ammounts of data is being added to it is fairly impossible to do nicely. Lets just say you do get it to keep the selection in view, what about while the user is still searching for their required item, you wouldn't be able to keep it still then.

Firstly if the expected total load time is under 10 seconds you could just disable the list box until loading is finished. (Obviously grey it out with a spinning animation or something so the user can see it's doing something.) I'm assuming you have already dismissed this option otherwise you probably wouldn't be asking here. But I do think this is worth considering. If the load time is farily small consider if your users will really gain anything by being able to browse the list while it is still being loaded.

Secondly, I would propose that you find a way to restrict the contents of the list box so that only small quantities are every displayed at one time. You could do this by only displaying names starting with a single letter of the alphabet (along with a letter selection control). Or you could provide a filter entry text box at the top where the user could type the first few letters and the list box would only display the names starting with those letters. This would allow the user to type say "sa" and the list box would display "sam", "samantha", "sacha", etc. Now you only have a small number of items in the list so you don't have to worry about it jumping around. If the number of items in the list grows too large (because of the loading on the background thread) and the list goes beyond the height of the box the user can simply type an extra letter to futher filter the list.

Sorry if this isn't really what you wanted, but I thought it would be worth bringing alternative design up incase you'd overlooked it.

Simon P Stevens
Thank you. I do agree with what you are saying, but how would you personally implement an address book (think of an Exchange address book, although in this case it's coming from AD) with hundreds of thousands of entries? An Outlook-like address book would make sense. It would be really annoying for people to have to select an letter to find the name, normally from UI design perspective, the less clicks the better. And when it comes to localization, do you really want to select a japanese or chinese character out of 40,000+?
Will I Am
To continue, i do have a filter implemented, but I want it to filter the display data. It mitigates but not eliminates the issue. I do not want it to go back the server and cause a new dataset to be transfered.Also, load times vary anywhere from 15 seconds up, depending on how the AD server feels that moment.
Will I Am