Re: Guidelines for scrolling vs. paging, max. number of elementso n screen

There are at least 2 performance reasons to providing paging when you have
long lists.

1. Longer query sets take up server cycles
2. Longer quer sets are longer to download. (This latter one isn't as big a
problem anymore due to changes in how HTML parses tables.)

As for how it is done I recommend the following:
Give the ability to change the # of items on screen, this may even turn off
paging if your system can handle it. Provide robust multi-data filtering.
Sorting is good but not as good as filtering. Provide a "starts-with"
mechanism. It is a search on your name space but as a "starts with" query
instead of a "contains" query. allow paging next and previous and first and
last. If your items are thought of alphabetically have a jump mechanism to
where the list begins at X. Display the total # of results respective to
what range is on screen and tell people how many pages there are and what
page they are on.

I've done a bit of testing here and the problem areas arise when it is
unclear that there is a next page. Paging widgets need to be at the top and
the bottom to help in this.

One problem I've had is with the "starts with" component. It is often not
clear that this search is separate from my global search which is also on
screen. The area of influence of the "starts with" is thought to be global,
from the container the user is in and all its sub-folders, or the correct
interpretation of just the container's current list.

Oh! the other problem area is multi-object selection. What does select all
mean? Is it just the current page? Is it all items in the container? Does it
include all sub-containers?

As for the max # of elements. The rule is that it is up to the user. Every
user will balk if you try to dictate this to them.

Good luck!

-- dave

David Heller
Sr. User Interface Designer
Documentum: The Leader in Enterprise Content Management
925.600.5636

[email protected]
http://www.documentum.com/
AIM: bolinhanyc  //  Yahoo: dave_ux  //  MSN: [email protected]

--"If it isn't useful, it will never be usable."

    --------------------------------------------------------------
     POSTINGS (in plain text): [email protected]
           SUBSCRIPTION CHANGES:  http://lists.syntagm.co.uk
            (or send email to mailto:[email protected])
    --------------------------------------------------------------