Browse Prior Art Database

Improved pagination for web UIs

IP.com Disclosure Number: IPCOM000238127D
Publication Date: 2014-Aug-04
Document File: 3 page(s) / 44K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method is suggested for loading paginated web UIs where information about the structure of other pages is fetched as well as the full content for the current page, so provide a more intuitive user experience in a system with rapidly changing data.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 01 of 3

Improved pagination for web UIs

The most interesting application of this idea is in a fairly specific type of system. We will explain this later, but first we cover explain how it could be applied in a more ubiquitous example (online retail).

    When exposing a view of back-end data via a web UI, when there is a lot of data to display it is undesirable to show it all on one page. This is for reasons of usability and also performance. Instead, it is better to load *some* of the data, populate a page with that, and then paginate the rest of the data such that a user can browse to it.

    For example, consider Amazon. I search for headphones, and sort them by price: low to high...

Information is displayed about the total number of results, but only some are

loaded into the UI and displayed:
The rest of the results are paginated so that I can navigate to them:

    Say I'm looking for headphones that cost around £22. I can see that the first page of results range in price from £3.99 to £12.99. But I can't see the range of prices on page 2, or 3, or any of the other pages. I'm not sure which page I need to go to view headphones that cost around £22.

    This is worked around by sites like Amazon by including other UI design elements such as the ability to filter down to a price range. The drawback of this solution is that more widgets need to be displayed on the page, which in turn can lead to it becoming more cluttered, less usable, and increasing load times.

    There may also be situations in which you want to see your data in full context. For example you want to see headphones that cost £22, but then you also want to see at least 10 different lower and 10 different higher priced headphones on either side. You must guess at the correct range to enter into the filter to achieve this, but if you guess too large a range, you're again stuck with needing to use pagination, and if you enter too low a range you don't achieve what you wanted, and so you need to try again.

    An alternative solution would be one where the pagination itself is able to display additional information that helps the user decide which of the pages they want to go to.

Consider a general example:

    
There are N ordered results from the back end database to display, and these are to be displayed on pages with n items on each. Therefore there are ceil(N/n) pages required to display all of the data.

    When the page loads, we request the data for the first n pieces of data, but we also request the order-defining information (in the above example, price) about the first and last items on each of the subsequent pages.

    We can then supplement the page with this information, for example as a tooltip when the user mouses over the link to a page (or some other implementation), which tells them the range of results they will see on that page:


Page 02 of 3

    This solution will obviously increase the amount of data we need to get from the backend database, but by a small amount. Efficiency is improved...