As promised, here are the responses received for my posting regarding
"Long lists vs reponse time".
Thanks to all who replied!
--- Original message ---
We are having a discussion on how to adress very long lists in our web
application (e.g. 1000 items/records called from a database).
The items are not sorted by relevance. We cannot add color or graphics
in the list to differenciate the groups of items. The list is
automaticaly generated. Response time is really an issue here, having
to get large chunks of info from the database takes time! Our users
need to go fast, so they want to scan a large lists fast!
We now have two possibilities in front of us :
1) Show 20 items at a time. Get the next items with "Next" and
"Previous" buttons (e.g. Results in Google). But we think the user will
not appreciate having to click 10-20 times (or more) to get to the
information he needs.
2) Use the scroll bar. But we think we cannot refresh the list fast
enough for the usual scroll bar, so the user will drag down the scroll
bar but the info will not refresh automatically. Only when he releases
the mouse button, will the items refresh in the list. We think that it
is not optimal when you are scanning a big list, plus, you never know
where you will land when you release the mouse button. We would prefer
the scroll we're used to in Excel (refreshes the data instantly).
We couldn't find any examples of large lists on the web, except search
results. They are sorted by relevance, so it's not our situation at all.
Any suggestions are more than welcome (interface or programming).
All responses should be sent directly to me and I will summarize all
responses back to the list.
Thanks in advance,
[log in to unmask]
--- Responses received ----
The way I've solved this problem in the past is with a combination of
paging and caching. But, as always in our field, it depends on context.
The most recent context I encountered this problem in was in designing a
physician directory. Users could make searches that would generate a
list of up to 300 doctors, but would really only look at the first 30 at
the most (results were sorted by distance from zip code by default). So
what we did was to return the first 10 results to the screen
immediately, then cache the remaining results on the server.
This way, when users paged to the second, third, etc. pages of results,
there would be no call to the database... only to the server for what is
essentially a regular HTML page. I'm not technical so I can't tell you
exactly *how* to do this, but if you tell your IT folks to "cache
subsequent pages of results on the server" they should know what that
As to your paging problem, this is what largely depends on the task.
In the task I was designing for, users would not compare large result
sets. Will your users really scroll through all 1,000 results to
accomplish their task? If so, I'd still recommend paging, but maybe
increase the results per page to 100. Another strategy here would be to
add dynamic filtering or sorting, again depending on the context that
you're working with. These techniques will help experienced users get to
the results they're looking for, but novice users may not understand how
to use them to manipulate the results set.
I hope that helps!
If they are links, that's harder (although RTF, PDF, Excel do all
support clickable links within a document, I think). I can say, as a
data point, that whenever I'm offered an option of how many results to
view at a time (10, 20, 50, 100), I always choose the largest (usually
100). Maybe there's a happy medium between having few enough items on a
page that it loads all at once (so the scrolling is immediate) but many
enough items that you only have to click a few times.
Lastly, you can use an AJAX-style solution to implement an "endless"
scroll that updates as you scroll (even if you don't release the
button). See the search results on Windows Live (www.live.com
<outbind://73/www.live.com> ) for an example.
Hope this helps!
I would go for option 1, but slightly modified.
show 20 items at a time. Get the next items with "Next" and
"Previous" buttons. In addition, have a button named "View All" (or
something similar). This button will be disabled initially when the full
list is getting loaded. In the mean time, the users can use the next
button to move to the next 20 items in the list. Once the full list has
been retrieved from the database, yenable the "View All" button.
This serves 2 purposes. you are not really making the user wait till the
list is loaded but temporaryily showing them the first few hundred
records/pages but at the same time retrieving the full list in the
background. By seeing the disabled "Full View" button, the user will
have an idea that there is an option to see the full list.
hope this helps.
How about a mix?
Have the interface default to 50 results per page, but have a link (with
a warning) that lets the user show all responses on one page.
If you have a CMS-style login for the website for users, they could even
customize the number of results per page.
I don't know what you mean about having to refresh the list? What would
happen if you loaded 1000 items into an HTML table and then let the user
use the browser's scroll bar to move through that list. The browser
would handle refresh, no?
Anne, this is what we do in our web-based app:
By default, the list displays 10 records at a time. Users can use arrow
keys on a navigation bar to go to the next set of records, the last
record in the list of results, etc. In this way, we only have to
actually load 10 records at a time.
However, we have mass update capabilities, so there is a very real
probability that users will need to review a large amount of records at
one time. Users can then click a button to expand the list to show all
the results. I believe the system must cache the records somehow,
because while there can be a delay in load time, once the search results
are loaded, the scoll moves quite quickly.
When the users are presented with a list of 1000 items, they are going
to have to use some criterion to decide which of those 1000 items are
the relevant ones and then (presumably) perform some further action on a
subset of those items.
You need to find out what criteria the users will use to select a
subset, and what further actions the users will perform with that
subset. I.e. you need to do a task analysis.
Once you know what the users' criteria are, you can then attempt to
provide an interface to allow them to filter the results according to
In other words, you need to find a way to make the list ordered by
Hi there Anne!
I see two other solutions that you may or may not have already
If you were looking for something different could you let me know? Your
situation seems very interesting. :) 1. Cache the query every 5 minutes.
(This keeps a fresh version of the query on the server's memory for
quick output.) Here's how MySQL 4 takes care of
2. Use AJAX to insert 10-20 results at a time into a page without
needing to refresh.
the server and display them on the page immediately (or as quickly as
your database will return them). Then, the browser continues to query
the database in the background (each time getting an additional 20-30
records) and as more results come in on each iteration of the query, you
just display them on the page without refreshing. The only down side is
work. It's a pretty neat technique though, and definitely worth learning
IBM has a very accessible series of articles on AJAX (Asynchronous
Hope this helps!
Tip of the Day: Forward out-of-office replies to
mailto:[log in to unmask]
CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html