Paging

18 Sep 2004 - 6:46pm
9 years ago
7 replies
319 reads
Alex Robinson
2004

I realise that there are numerous ways to skin this particular cat,
but assume that there exists a paging legend along these lines:

Showing from 261 to 270 out of 356 items 10 items per page
Pages: 1 .. 10 .. 20 .. 24 | 25 | 26 | 27 | 28 .. 30 .. 35 Next | Previous

Is there any evidence that giving several pages that flank the
current page or that fall at regularly spaced intervals between the
first and large page are beneficial to the user?

Would users be disserved by only having buttons to take them to the
next, previous, first and last pages?

Comments

18 Sep 2004 - 7:39pm
Lilly Irani
2004

In tackling this same problem for more than 10ish pages, I actually
designed a widget like this:
First Previous <drop down selector to access random page> Next Last

However, whether the random page access is beneficial completely
depends on the kinds of tasks you expect your users to complete with
the page you're designing. If you're designing a gigantic sorted list
and you expect people to randomly want to browse to the middle of the
alphabet, my drop down is useful.

On a Google search results page, they allow random access but I'm less
convinced of how beneficial that random access is since the pages on
the result page aren't in some order where someone might predict
they'd find what they want on a middle page. (Unless they've run the
query before and knew they found it on the third page.)

So, as always, the answer depends, imho.

On Sun, 19 Sep 2004 00:46:04 +0100, Alex Robinson
<sohobonobo at alex.cloudband.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I realise that there are numerous ways to skin this particular cat,
> but assume that there exists a paging legend along these lines:
>
> Showing from 261 to 270 out of 356 items 10 items per page
> Pages: 1 .. 10 .. 20 .. 24 | 25 | 26 | 27 | 28 .. 30 .. 35 Next | Previous
>
> Is there any evidence that giving several pages that flank the
> current page or that fall at regularly spaced intervals between the
> first and large page are beneficial to the user?
>
> Would users be disserved by only having buttons to take them to the
> next, previous, first and last pages?
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

19 Sep 2004 - 10:50am
Clay Newton
2004

> (Did you mean to post off-list?)

Uh, no... apologies to the list, my earlier reply is pasted below.

> The current scenario which led me to ask the question is indeed a
> "web application which is to be output in HTML". However, I don't
> think the method of output is relevant to the question. Do you think
> it is?

Well, I feel it is relevant in that I pagination makes working on many
items significantly more difficult than having all results at least
appear to be available at the same time. This is a difficult thing to
do when dealing with HTML, but with other types of output I can't
really conceive of a reason to use pagination.

My earlier reply:
>>This may seem like a particularly dumb question, but is this for a
>>hosted web application which is to be output in HTML?

19 Sep 2004 - 11:41am
Nathan Moody
2004

Clay Newton wrote:
>> ...pagination makes working on many
>> items significantly more difficult than having all results at least
>> appear to be available at the same time.

Of course, especially in the realm of Web applications, pagination
attempts to *improve* the user experience when a gigantic amount of
data will be requested; piping it all into a client UI or browser can
create quite a wait. I've had to design paginated results in Flash and
HTML UI's alike specifically to accommodate both server lag and
overwhelming numbers of returned results.

This is no judgement on whether or not the attempt to improve the user
experience is actually successful. ;-) However, I was just on a project
where, between the huge potential number of returned results and a
drastically overtaxed server, no pagination would have resulted in a
minutes-long wait for requested results. Ah, the pleasures of corporate
prototyping...

Has anyone experimented with using more meaningful result labels,
beyond just page number? Lilly's solution sounds like she's using an
alphabet, which would be a lot more intuitive than trying to navigate
through numbers that bear no contextual link with the results contained
therein. I wonder, though, how easy/hard it would be to construct this
dynamically (page 1 = "A-D," page 2 = "E-G") without reading the entire
returned set (which, of course, is what pagination specifically tries
to prevent)?

Awaiting a better paginator,
-Nathan

19 Sep 2004 - 10:07pm
Clay Newton
2004

> Of course, especially in the realm of Web applications, pagination
> attempts to *improve* the user experience when a gigantic amount of
> data will be requested; piping it all into a client UI or browser can
> create quite a wait.

One of my biggest issues with the idea of pagination is that it is a
quick and easy fix that can be implemented as a usability enhancer on
top of really under-developed query tools. In other words: a crutch
for developers who are not interested in investing the effort.

How often do you open your address book looking for everyone? Gmail's
(and now Yahoo Mail's) address book integration at the recipient
fields in an email is an example where something very sophisticated,
yet simple has been implemented that prevents me from having to pop
open my address book and deal with a really clunky paginated list of
contacts.

Implementing a tool such as this is not going to be reasonable for
many list interfaces, but that doesn't mean a query tool better suited
to the specific tasks of the list user wouldn't yield a much smaller
list, potentially obviating the use of pagination.

-Clay

20 Sep 2004 - 4:32am
Ben Hunt
2004

I've just defined a UI guideline on paging for the UK Government site
I'm working on.

Basically, for a list of non-indexed results, we show links for 10 pages
at a time, and previous/next where applicable.

The *crux* question was, when you get over page 10, do you show the
current page in the middle, or at the end of the list of 10?

Our answer was to show e.g. page 14 at the *end* of the list, i.e. show
<Previous 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 Next>.

The reasoning is, when there's no order to the results, other than
relevance, we couldn't think of why anyone would want to jump to page 18
from page 14! Page 20 is probably less likely to contain your desired
result than page 19, so there's no reason to link to 20 and skipping 19.

However, they've probably scanned through the results 1-13, and may have
noted some likely-looking links to content. If you've remembered that
the thing you're looking for may have been on page 5, showing pages 9
through 18 doesn't help you at all.

Regards,

Ben Hunt
Scratchmedia
www.webdesignfromscratch.com

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Alex Robinson
Sent: 19 September 2004 00:46
To: IxD
Subject: [ID Discuss] Paging

[Please voluntarily trim replies to include only relevant quoted
material.]

I realise that there are numerous ways to skin this particular cat,
but assume that there exists a paging legend along these lines:

Showing from 261 to 270 out of 356 items 10 items per
page
Pages: 1 .. 10 .. 20 .. 24 | 25 | 26 | 27 | 28 .. 30 .. 35 Next |
Previous

Is there any evidence that giving several pages that flank the
current page or that fall at regularly spaced intervals between the
first and large page are beneficial to the user?

Would users be disserved by only having buttons to take them to the
next, previous, first and last pages?
_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest):
http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements
already) http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

20 Sep 2004 - 8:51am
Coryndon Luxmoore
2004

Nathan,
I have actually seen this implemented on a discussion site. The challenge
that my coworker had when he had it implemented on a project is that the
dropdown had to change the range type based on the sort type of the list. So
they ended up displaying the first and last item on each page which allowed
the user to get a sense of each pages contents. This feature is incredibly
useful and tested well since it was an extension of behaviors the user
already understands.

The technical issue here is while all of the results are not returned to the
browser the server will have to get a full set of results in order to
extract this information which can be an additional burden on the server and
database which regular pagination systems do not impose. If you are only
displaying numbers of pages you only have to determine if there are more
than 1 pages of results and return only one plus the number of results pages
you are displaying.

--CML

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Nathan Moody
Sent: Sunday, September 19, 2004 12:41 PM
To: Interaction Designers
Subject: Re: [ID Discuss] Paging

[Please voluntarily trim replies to include only relevant quoted material.]

Clay Newton wrote:
>> ...pagination makes working on many
>> items significantly more difficult than having all results at least
>> appear to be available at the same time.

Of course, especially in the realm of Web applications, pagination attempts
to *improve* the user experience when a gigantic amount of data will be
requested; piping it all into a client UI or browser can create quite a
wait. I've had to design paginated results in Flash and HTML UI's alike
specifically to accommodate both server lag and overwhelming numbers of
returned results.

This is no judgement on whether or not the attempt to improve the user
experience is actually successful. ;-) However, I was just on a project
where, between the huge potential number of returned results and a
drastically overtaxed server, no pagination would have resulted in a
minutes-long wait for requested results. Ah, the pleasures of corporate
prototyping...

Has anyone experimented with using more meaningful result labels, beyond
just page number? Lilly's solution sounds like she's using an alphabet,
which would be a lot more intuitive than trying to navigate through numbers
that bear no contextual link with the results contained therein. I wonder,
though, how easy/hard it would be to construct this dynamically (page 1 =
"A-D," page 2 = "E-G") without reading the entire returned set (which, of
course, is what pagination specifically tries to prevent)?

Awaiting a better paginator,
-Nathan

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

20 Sep 2004 - 2:37pm
Cristian Cheran
2004

> The *crux* question was, when you get over page 10, do you show the
> current page in the middle, or at the end of the list of 10?

Here's a solution that it's rather shot from the hip (because I don't
know hence don't think about actual usage pattern)

For the 16th page, you display (on the same line):
<< First
< Previous
13
14
15
16 as a drop down with all the pages focused on page 6
17
18
19
Next >
Last >>

In this way, you can the best of both approaches but you need to
customize it according to scenarios you address.

For example, I expect that some applications won't need First and Last
and the users will have to access them from the clunky drop-down.
Also, some other applications won't need this gimmick at all (forums
threads for example). One applications that I can think about is
browsing a huge photo collection (or photo search result)

Syndicate content Get the feed