Pagination

[govuk-design-system]

Use this issue to discuss the Pagination component in the GOV.UK Design System.

What

Help users navigate through multiple pages. Typically used for pages of search results.

Examples

Multi-page pagination examples:

• https://design-patterns.service.justice.gov.uk/components/pagination/
• http://hmcts-design-system.herokuapp.com/components/pagination
• https://design.homeoffice.gov.uk/components?name=Pagination
• https://cjscpp-design-patterns.herokuapp.com/design_patterns/pagination
• https://dvsa-front-end.herokuapp.com/library/mts/pagination

Previous / next only pagination examples:

• http://land-registry-elements.herokuapp.com/pagination-simple/demo
• https://digital-land-design.herokuapp.com/component/pagination
• https://nhsuk.github.io/nhsuk-frontend/components/pagination/index.html
• https://components.publishing.service.gov.uk/component-guide/previous_and_next_navigation

[joelanman]

Pagination in the US Web Design System

[36degrees]

There was a request for this in Elements.

[gazaston]

Pagination from blog.gov.uk:

[leekowalkowski-hmrc]

We need to make sure pagination links are big enough for touch screens, I think all the examples shared are not.

[glenjamin]

Are there scenarios where "jump to page N" is actually desirable to a user?

In practice I can see why next/previous is useful in a long list, but jumping to a numbered page is probably always going to be worse than providing the user a way to filter down the results to something manageable.

[36degrees]

One scenario I can think of is a user 'binary searching' a relatively small number of sorted results. For example, with an imagined alphabetical result set spanning 10 pages, if a user is looking for something beginning with 'N' they might jump to page 5 (guessing, based on the position of n in the alphabet) and then navigate from there to find the result they're looking for, which would arguably be a better experience than having to page through one page at a time.

I'd agree that providing a search or filtering interface would be preferred, but might not always be possible?

EDIT: Filtering and searching might be the sort of thing that would get dropped from an 'MVP', in which case providing the ability to quickly move through a result set as described above might be an easy short-term solution.

[mgilgar]

I think 90% of the times it should be enough to provide only the first X results without pagination and give the option to filter or seach. Less complicated for the user and for the developer.

Anyway, I can see the needs of the other options for some scenarios. I think it would be great if govuk can develop patterns for all of them.

Also, please specify what the url should look like.

[edwardhorsford]

Came here as my service uses / needs pagination.

One use case to consider:
Where the user isn't looking for a specific thing (so search / filtering isn't necessarily relevant), but wants to review all the things. For instance, my user might want to review all the things created by Ed. They may filter for Ed as creator, and then want to read down the entire list of things Ed created.

On a personal level (and very much subjective to how I work), having numbered pages may help if people are noting down things of interest - I can review several pages and know that my interested things are on pages 1 and 3.

Numbering potentially gives an idea of how many pages of results there are - but there are other ways this could be achieved.

[tomwrightgov]

Wow, there is a lot of different styles in use out there in .gov sites.

My personal preference is for the ‘blog.gov.uk’ style. Labelling the links ‘Previous page’ and ‘Next Page’ is a lot more obvious then ‘Prev’ and ‘Next’ especially for screen readers.
Listing links to the surrounding page numbers with additional links to the first and last page is also a nice touch.
My guess is that this component can straight from the blogging engine and so is widely used outside .gov.

The thing I am most uncertain of is the use of item counts and pages numbers.

Is it better to say:

Page 3

or

Showing 21 – 30 of 100 items

Does the user care how many items there are?

Is it enough to just show the number of pages, as that it the quantity that the user is actually dealing with.

DO we show both number of items and pages, like land-registry does.
Does that add any value?
Is it confusing to the user?

[leekowalkowski-hmrc]

Well, the word 'items' isn't a geat choice of content, so I don't know if the user would care. In the Government Gateway's group management, we have 'Showing 21-30 of 100 team members' and I think yes, a group administrator could care how many team members were in the group (or matched their search criteria).

[mtallamy]

I thought I'd offer some feedback we received during private beta for our service. Our page closely follows the first example given at the top of this page, i.e. https://home-office-digital-patterns.herokuapp.com/components/pagination. In addition to further filtering, we've been asked by some of our users to add 'first' and 'last' page links alongside the 'previous' and 'next' links to help traversing larger data sets.

[edwardhorsford]

We’ve just added pagination to our service - which is a modified form of the MOJ pagination. See our PR adding it.

What it looks like:

Changes from the MOJ one:

• Add aria-label to the nav, removing the paragraph.
• Include the page number (page x of y) in the page title if pagination is visible.

Some other implementation details:

• The pagination is all driven from the query string - so &page=4 will take you to page 4.
• If you attempt to load a page out of bounds, we redirect you to page 1.
• Any change to filters on the page will reset the pagination.
• We're starting with a page size of 100, but will evaluate this in the future and whether we need it configurable (I hope we don't).

[terrysimpson99]

See: https://gouvfr.atlassian.net/wiki/spaces/DB/pages/223051980/Pagination+-+Pagination

[hopebristow]

We have used pagination in 3 places in our service for check and pay for multiple vehicles as part of the "Drive in a Clean Air Zone" service https://www.gov.uk/clean-air-zones. We also adapted a version of the MoJ pagination https://moj-design-system.herokuapp.com/components/pagination. Originally, we used a simple “next” and “previous” in one of these designs but users found this confusing and weren’t sure where they were in their overall list of vehicles when asked to find and make payments from a list of number plates that spanned multiple pages, often resulting in them failing to complete the task. When we changed this to match the MoJ pattern we saw an increase in the usability for users and all were successful in completing the task. All 105 users we tested with had no issues when testing this page with page numbers added.

[calvin-lau-sig7]

GOV.UK Design System working group review

The Design System working group reviewed this contribution in November and December 2021. They’ve approved it to be usable, consistent and versatile.

To get it ready to publish, the working group made these recommendations.

On the scope of this component, they made recommendations to:

• focus on ‘numbered pagination’, which is the most useful implementation for service teams
• split out and possibly remove the ‘previous or next’ variant, as it’s not strictly about pagination
• include support for the user to navigate to any page (such as with a number input) — however, the working group agreed this was ”‘one for the future”

On the design of this component, they made recommendations to:

• consider if the component needs to include a top border
• consider if users need the guidance and example to ‘show the total number of results’
• consider if the mobile version should be centre aligned — we said that this made sense as the component is symmetrical and nearly the width of a mobile device screen, similar to how full-width buttons appear
• make arrows and chevrons more consistent — we said that ideally, arrows should represent movement and chevrons should represent dividers, which this component works towards
• make links a consistent colour, as some are blue and some are black — we said this was to be consistent with a visual hierarchy formed around the ‘back link’ and ‘breadcrumb’ components, though we do need to document these design principles
• consider if users need the guidance and example for ‘showing large numbers of pages’

On the guidance, they made recommendations to:

• explain why the previous and text links are stacked on top of each other — we’ll add guidance to explain that this makes the next link more visible, especially for users of screen magnifiers
• clarify if services should ever place this component before the pages — however, we do not know if there is a reasonable use case for this
• suggest services also look at using search filters to help improve navigation

On the coded examples, they made recommendations to:

• include an example of paginating specific parts of page, such as a table — however, this might not be practical, as this could only be done with JavaScript
• remove an extra border from the full page example — but this will depend on whether we decide to keep the top border
• set the arrow size in rems, so it scales properly
• consider using divider: true rather than type: ellipsis
• unquote the Nunjucks keys

[joelanman]

on using a javascript framework - we do have a requirement to use progressive enhancement:

https://www.gov.uk/service-manual/technology/using-progressive-enhancement

if you are updating the page using javascript you would have to make sure it is progressively enhanced, and that the javascript interaction is accessible for example to screen reader users. If that's the case, its possible you need gov uk secondary buttons: https://design-system.service.gov.uk/components/button/

We only use primary green buttons to highlight the main call to action on a page

[nasainsbury]

putting aside the PWA, and whether it's a button/link, the primary concern is around the styling of the "previous" and "next" link.

all examples I find online, the previous/next links are styled to look the same. in the example I've presented, we can assume it behaves in a non-framework style, and when you click next, it goes to website.com/search?page=3, and when clicking previous it goes to website.com/search?page=1.

we've followed the guidance on removing the button when you cannot go back or forward.

the main question is, would there be any reason to style the next/previous button differently? I can so no examples where this is the case, and in all the GDS examples they are styled the same. is there a specific reason for this?

apologies if I'm not explaining this well enough.

TLDR; Should the previous and next links be styled to look the same in all cases?

[joelanman]

We only use a different design (primary button) when it is a main call to action on the page (for example submitting a form). In all other cases the normal link or secondary button style is used, or the design of a specific component if it exists like pagination, tabs and so on. If you do user research and find another style works better you can feed that back in this thread.

[nasainsbury]

OK perfect. Thank you. I am also curious to see if we get any feedback about this, as the logic presented to me was that we want people to view more and thus wanted to give more attention to next than previous

appreciate the help!

[robertjmccarthy]

The MoJ Design System has a pagination component which we're currently reviewing. We think this is a candidate for archiving from the MoJ Design System and signposting to the GOV.UK Design System's pagination component instead.

But, as seen in this discussion thread, and in discussion with teams at MoJ, the GOV pagination component does not include a way to show the number of results alongside the pagination navigation.

The MoJ Design System team think there are 3 options that we could consider:

Option 1
The MoJ pagination component is archived and we contribute to this discussion for a need to show results on the GOV pagination component.

Option 2
As above in option 1, but instead of contributing to this discussion, the MoJ Design System team submits a PR for review. Once reviewed and merged, the MoJ pagination component would be archived.

Option 3
The MoJ Design System archives the pagination component, but creates a 'Show results' component (name firmly TBC) which references the GOV pagination component to be used as a complimentary and connected component.

The MoJ Design System teams preference would be for option 2. Option 1 leaves users with a choice of using an unsupported component from the MoJ Design System, or a component from the GOV.UK Design System that doesn't do all they need. Option 3 feels far from ideal due to the work required to implement it.

Could the GOV.UK Design System team let us know whether a 'show results' is on the table for the pagination component, and if not, would a PR be welcomed?

[querkmachine]

(Personal thoughts, not responding on behalf of the team.)

I personally don't see labels like "96 results" or "Showing results 1–10 of 96" to be necessary to include within a pagination component. It's related information, sure, but it's also not information I really expect to be in the same place as pagination — rather, I expect it to be nearer to the top of the page.

Maybe this is just an expectation created because that's where I tend to see it or notice it, but it doesn't seem to be uncommon to position it that way.

Bing shows the total number of results at the top of the page, below the search form and filters and above the first result. Google no longer shows this information at all, but when it did, it did so in a similar location.

GOV.UK search, likewise, shows the total number of results at the top.

---

Some other examples of major websites showing the total number of results separate from pagination and above the results themselves.

[Ciandelle]

Hi Rob,

The team had initially designed the pagination component with the total number of results in it, however when we reviewed it we decided to remove it for the following reasons:

• We felt that this guidance would be more at home in a ‘search results’ pattern
• By including it in the component, we’d be taking away the freedom to put this information wherever teams want to put it – it doesn’t necessarily make sense for it to be at the bottom of the page etc
• Even if we remove this, we should advise users not to have 100s pages of results unless they have good search and filters
• It’s dependent on the number of results you get back – you don’t need it if the total number is only a page

[robertjmccarthy]

Thanks @Ciandelle. Rationale all makes perfect sense. Any plans to make a 'search results' pattern? I think that covers the Option 3 that I mentioned which is the route we'd likely go down unless there's plans for your team to be working on one.

[Ciandelle]

@robertjmccarthy Just checked with the team and it's not on any roadmap so it doesn't look like we'd be looking into it any time soon. I'd love to see what you're going to do with it though!

[PatriciaSanchezHMRC]

Hello all!

Just jumping in to share a few insights from our recent user research with screen reader users, which touched on this variation of the pagination component (the one with the ellipsis) - see 'For navigating pages of items' on GOV.UK.

We use this pagination variation in cases with many transactions and pages, where showing all page numbers would be overwhelming.

The main issues we found were:

• When the user focused on the ..., their screen reader announced it as “horizontal ellipsis”. We were curious if that’s the expected behaviour, or should we be providing a more descriptive name using an aria-label.

• The user also raised a question about the missing pages between 3 and 17. They couldn’t tell if those pages existed.

• Finally, they expected to be able to jump to a specific page number manually, but since that wasn’t supported, they had to keep pressing ‘Next’ to get where they needed, which was pretty frustrating for them.

Hope the research offers helpful insights.

[querkmachine]

@PatriciaSanchezHMRC

• Finally, they expected to be able to jump to a specific page number manually, but since that wasn’t supported, they had to keep pressing ‘Next’ to get where they needed, which was pretty frustrating for them.

I find that piece of feedback interesting, because how would a user know which of a set of sequential pages the thing they're looking for is on? Even if the ability to jump to a specific page number were available, it would still require moving back and forth and making repeated lookups to find a specific result (unless they were lucky and got it right on the first guess)

It feels like solutionising without stating the actual problem: that they expect the results to be searchable, filterable, or grouped in a different way to how they currently are.

[PatriciaSanchezHMRC]

@querkmachine

Hey there!

That’s a great point. You’re right that that the request to jump to a specific page highlights a broader need for improved filtering and navigation of large result sets. It’s something we've picked up on in our research too.

I still thought it might be useful to share the user feedback we’ve seen around this. Thanks for your input!

[gavinthomas-valtech]

I notice in the example it has a bare # used in the href href="#" . Is this not bad practice? It's linking to the same page? should it not be a link since it's linked to itself?

How will a screenreader read this out? it will reload the same page they are on?

[36degrees]

@gavinthomas-valtech the links used in the examples are just placeholders, for two reasons:

1. We don't know what URL structure will be needed, as it'll be unique to the service.
2. If we used real links, clicking them would attempt to load the URL in the example iframe (likely resulting in a 404).

You can see we do the same thing with # for links elsewhere, for example with the examples for the breadcrumbs component.

[gavinthomas-valtech]

I guess what i'm asking is what is the pattern for a link that is the same page when used in a pagination component? It uses # as an example. I would have thought this should not be an actual link at all as it links to the same page? or do we actually use a link to eh same page as use aria-current to define its the current page?

@gavinthomas-valtech the links used in the examples are just placeholders, for two reasons:

1. We don't know what URL structure will be needed, as it'll be unique to the service.

2. If we used real links, clicking them would attempt to load the URL in the example iframe (likely resulting in a 404).

You can see we do the same thing with # for links elsewhere, for example with the examples for the breadcrumbs component.