Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

The dominant UI pattern for pagination involves a list of numbers.

<< First < Prev 1... 4 5 6 7 8 9 10 ...27 Next > Last >>

sometimes including a "+10" link, and/or a "jump to" numeric text field.

Some elements of this pattern seem "fishy" to me:

  1. The most common action (Next) is buried between two links, which both link to the same (last) page
  2. Previous and Next, which seem to be related by mode (exploring without a specific target) are far apart
  3. Similarly, First and Last are far apart, though they also seem related via the common prior act of resorting (e.g. I want the oldest record, so I'll sort chronologically, and then go to the first or last page, depending on whether ascending or descending is the default sort ordering)
  4. There is a strong affordance for jumping 2 or 3 pages in either direction, though I'd be surprised if this wasn't really an edge case. Is it really that much more common than jumping 5 or 10 forward or back, or jumping to a particular page?

My first question is:

Is there any user research supporting the dominant UI pattern? Are all the elements equally necessary for effective navigation of paginated tables?

The question becomes critical on a mobile browsing context, given that prevailing touch interface guidelines recommend a minimum of at least 26px (at 164ppi) - though Apple recommends at least 44px.

Getting that pagination pattern to conform to those interface guidelines takes up a lot of screen real estate.

So, the second question is:

Which part of this pattern can be safely jettisoned, in favour of bigger touch targets? Can, for example, we safely abandoned the list of numbers in favour of including a user-driven "Go to page" menu listing all page numbers?

The wireframe below is one possible alternative pattern which avoids the fishiness above, and has 40x40 px targets. Mobile browser-friendly table pagination pattern

share|improve this question
    
Put the wireframe online and provide a link and we'll insert it into the post, no worries. Saying "vote me up to see more" is... um... an unorthodox approach :). –  Vitaly Mijiritsky Jun 16 '12 at 15:38
    
Also, see if this question helps: ux.stackexchange.com/questions/22526/… –  Vitaly Mijiritsky Jun 16 '12 at 15:40
1  
@VitalyMijiritsky Apologies for the unorthodox / noob approach. I had a look at the other question. There are a few questions about pagination versus infinite scrolling. It seems to me that inifinite scrolling combines "next" and "previous" actions into one "more" action (disregarding whether it is driven by scrolling or by an explicit control). This is prima facie a good simplification, and supports the view that these are closely related actions. But there is no "jump" action, and no "resort and jump to first / last position" action. So the question is, how important is that? –  Justin Jun 17 '12 at 4:39
1  
I always wonder what's a use case for (unspecific) pagination with just page numbers where the user would want to jump to specific page numbers without knowing what content is behind them (I do understand specific pagination, e.g. year numbers) –  greenforest Jun 17 '12 at 7:51
    
Quite often you can safely drop the last button. In something like forums, I can see a use for the last button (e.g. latest posts). But for something like searches, latest news, recent tweets, people will rarely go there. –  Muz Jan 9 '13 at 6:18

3 Answers 3

First of all, on a mobile experience, don't give the user too many things to choose from. A grid sounds nice but, as someone who is new to the whole touch thingy - I'm going to be starring at it for a few minutes before i figure it out.

here's a simple pattern i use for pagination. its user friendly (in most cases) and my developers love me for not going overboard (with features) for a simple utility on a page.

  1. give first and last page jump option (indicate the last page number)
  2. provide a text field on which the user can enter a number
  3. provide a ui option to choose how this number should be treated i.e. goto or travel by +/- pages (my clients loved the jump by -5 pages tbh its better than next/prev)
  4. a button to start jumping (/shrug why not)

Simple page-navigation idea for mobile/touch interface (wireframe):

enter image description here

share|improve this answer
    
Thanks @severance. I like it a lot. Two possible improvements. Give the jump to / by drop down a default and put it before the text field. This would give you a natural reading order and require only two separate focuses to complete a jump. –  Justin Aug 14 '12 at 9:11
    
Wait... what happened to next and previous?,l Also, any backwards movement requires the user to enter -1 into a text field., which is pretty unintuitive for non-math types. –  Justin Aug 14 '12 at 9:15
    
well if you are expected to pass this off to the non math types then in the nav opts you can include options like "jump forward" "jump backward" so the user can just enter "5" and select "jump backward" to go back, which is the same as entering "-5". My design is not perfect, but there are a 100 ways tweak it :P –  Rayraegah Sep 4 '12 at 5:15
    
If the O/S allows it (and this can be quite a big if), you could allow the user to swipe left and right for next and previous page. –  Muz Jan 9 '13 at 5:24

I'd go for some kind of horizontal slider rather than the menu with all the page numbers. That would have the benefit of showing you visually how far through the results you are, and also let you skip forward and back by small or large amounts. Even better would be a vertical slider on the right of the page as that's the direction the page will likely be scrolling. A kind of scrollbar-paginator - but one that allows you to skip forwards/backwards by a large amount, rather than a lazy-loading infinite scroll idea.

While I agree with your issues about the commonly seen paginators, I don't know how intuitive your design would be.

<< >> < [grid] >
share|improve this answer
    
Thanks @alex, that raises an interesting point, and possibly another limitation of the std pattern. The +10 or -10 actions presume a certain scale (around 20-100 pages). A slider would be agnostic about the total number of pages, because it effectively represents a percentage. –  Justin Jun 17 '12 at 11:45
    
I'm not sure I can picture the scrollbar-paginator, though. –  Justin Jun 17 '12 at 11:47
    
I was trying to think where I'd seen something similar... Android 2.3 Phone Book has the alphabet up the right side that you can "page" straight to the part of the phone book you want. It works well and is intuitive. It's not exactly the same thing though... –  alex stacey Jun 17 '12 at 14:06
    
Yeah, i agree that it is a lovely pattern, but that's not really pagination, though, because all results are loaded at once. It's more like assisted scrolling. –  Justin Jun 20 '12 at 12:25

why paginate when you can accelerate and scroll fairly quickly to exact desired spot with a pattern like the contacts or music on iphone. pagination is mainly used on desktop because scrolling is far inferior than on touch interface.

share|improve this answer
    
You've not really answered the OPs question. The question isn't about alternatives to pagination, it's about improvements to pagination controls on mobiles. Also I disagree that pagination shouldn't exist on mobiles - You need to consider data usage on mobile sites. Loading up the whole entire set of results in one go would potentially be a huge hit to the data allowance. –  JonW Aug 7 '12 at 6:51
    
sorry but i'm reading it differently. that is because as the OP suspects that paging patterns are particularly ungraceful in mobile environ, there is a shift away from paging especially on mobile. to me it's like saying how can i build a house to withstand hurricanes but it has to be made of one ply paper. there's nowhere to take paging further but better constructs exist, such as smartly set up filtering or smart navigation. mobile pagination was a bad idea, a desktop paradigm that doesn't have much value on mobile. –  Chris Aug 7 '12 at 10:30
    
Would agree that pagination is not as suitable as scrolling. I know Android only loads things into memory when they're on screen, so it doesn't load the entire set in one go. It can be very efficiently designed; I've done a hundred items downloaded (with images) and no loss of performance. But pagination has its uses, like allowing the user to note that something was on "on page 3", as opposed to scrolling down 60 items. –  Muz Jan 8 '13 at 3:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.