I have a hunch (no data) that paginated content will seem larger only because it's that much more of a chore to slog through it all.
–
DA01Nov 8 '11 at 22:22

This would be very interesting to have some quantitative data on
–
Ben Brocka♦Nov 9 '11 at 14:01

Agree with @DA01: probably the more important thing to look at is the perception of work involved in going through the images. Click through 10 pages of 100 images each, or 100 pages of 10 images each? Google made a significant change to their image search results that seems to capture the best of both worlds, one long scroll broken up into "pages." While this doesn't answer your question, I think it may get at what you're really trying to figure out.
–
Taj MooreNov 11 '11 at 18:24

4 Answers
4

Just to clarify, the question that I think Philip is asking is: Which style of presentation makes the list of items feel longer: one page of all the items, or multiple pages with the items relatively equally divided?

I believe this will depend on:

the content; what type of items make up the list,

the scale of the total number of items, and

the pagination breakdown (number of pages, items per pages).

If the content takes a long time to process (either as a person, or computer), than it would likely skew the 1 page list to feel longer. If the total number of items is very large, than the 1 page list is would likely feel longer. Given a few number of pages (in the range of around 2-4), I think it would make the pagination technique seem longer.

For example, if there are 1,000 total images, I think viewing 1,000 images on one page would appear to be a much larger set than 4 pages of 250 images.

The contributing factors being:

images take time to load; hence, having many images on a single page slows the entire process

the scale of 1,000 items is fairly large and difficult to comprehend

4 pages is a understandable number divisions that can be easily consumed

I'm sure that there are other contributing factors, but these were the ones that immediately came to mind.

Thanks for you comment! So far you're answer is the closest to what I'm looking for, but I'd appreciate if anyone could point me to some research confirming everyone's gut feelings.
–
Philip SeyfiNov 16 '11 at 10:44

I think you're looking to the wrong mechanism to manage the perception of quantity. Instead of wrestling with pagination vs. scrolling, why not find a way to work in an expression of the quantity of data, like "Showing 60 Photos"?

The perception of scrolling vs. paginating has definitely changed. Users today are not opposed to scrolling if they believe that there is value to be had in doing so. At the same time, users sense of being overwhelmed with data has changed. The most successful interfaces that challenge users to wade through large data sets are provide some or both of the following:

1) As Todd says: An expression of quantity: a notion of how many results.
2) Mechanisms to understand and navigate dimensions within the total quantity. A good example of this is faceted navigation/filter sets. (See Getty Images result set left rail as an example).

The perception of volume has two sides:
If the data response is shallow, it can cheapen the value perception. “These guys don’t have anything”. Conversely, creating too many clicks will weaken the user’s motivation to move forward. Narrowing the set and localizing to relevant results usually changes the users perception on volume. If they believe you will give them the result they’re looking for, the tolerance to paginate and scroll is vastly increased.

The determining factors for pagination vs. full query set scrolling are context, end user goals and technical feasibility.

A note on pagination vs. single page scrolling: This interaction is typically a decision made due to technical limitations/feasibility. Depending on the data set, queries and data - retrieval can be seen as a performance risk in complex systems with massive data sets. Breaking up the query into well defined and finite RPC's basically breaking the data into chunks or in this case, pages, is a good way to mitigate that risk. The length of time users wait for data can make or the user acceptance and the brand and is more of a perception risk than the quantity of response data.

What we're seeing with AJAX and "lazy load" used by Twitter and Facebook among other sites, is the tendency to load a page or two of scrolling data initially, then "fetch" another set as the user hits the bottom of the screen.

In the case of Twitter, the audience can assume that the data set is too massive for pagination as a volume indicator to make any sense. And as the context-culture of Twitter is more topical and present tense, there's little value in archival functionality.

Facebook Timeline on the other-hand is sensitive to Life Experience context to their data, and have implemented a nice Annual/Monthly rollup archive on the right rail of what can be a seemingly endless set of life streaming posts.

I'm sure a one-page vs paginated will be perceived differently. But if that perception is good or bad is another discussion and depends on the type of pagination and the type of task that is performed.