Pagination

[iuloshi]

cf-pagination issue #11

[iuloshi]

• CF pagination bug fix for coded example
• Layout examples?

[iuloshi]

@Scotchester Think we should hide the Pagination page for now and bump this issue's milestone to Release 2? Or do you think you guys will have time to resolve this issue in your upcoming sprints before R1?

[Scotchester]

We'll definitely have it fixed by then. Shouldn't be a major issue.

[iuloshi]

Awesome possum!

[iuloshi]

Hey @Scotchester, I was just talking to @benguhin and because the content isn't fully fleshed out for this page yet, we're going to backlog to R2. So no need to rush incorporating this bug fix into your sprint schedule.

[Scotchester]

For future discussion when we come back around to this issue: we need to codify our specs for:

• font size
• button color

In our Flapjack designs, we've determined that it feels better for pagination to be a bit bigger, so we're going ahead and updating the cf-pagination component to use our super button sizes. I think that whether the buttons should be standard (pacific blue) or secondary (gray) is still an open question. They're currently blue in cf-pagination.

[Dnpizarro]

@Scotchester do you know the current standard for flapjack?

[sonnakim]

Here is an example of pagination from the OaH team that doesn't follow the typical model: http://www.consumerfinance.gov/owning-a-home/loan-estimate/

To access different pages of the form, the user can either press the previous and next buttons that appear as an overlay over the form image, or they can click on the page numbers on top of the form image.

[ohsk]

Here's a first stab on updating pagination that focuses on the ability to navigate:

• "left and right" with the caret bookends
• jump between adjacent pages
• jump to first or last pages regardless of your current position

cc: @benguhin @ielerol

[benguhin]

@ohsk I like this direction a lot.

[ielerol]

I like it too! My one question, and I think this applies to our current pagination visuals as well, is whether the "previous" and "next" text is accessible on that gray background.

Also, is that text interactive at all? Or are they just labels for the carats that will be shown at wider widths?

[ohsk]

True true. To be honest, I'm not super up-to-speed on all our accessible combinations. But it could easily be changed to @black or @darkgray text. Would we also want a disabled state? Perhaps for "Previous" when you're on the first page, or "Next" when you're on the last page?

I think both the label and caret could function as the actionable area, and maybe there's still room for the labels on tablet-scale.

[Scotchester]

• Yes, as is the case now, Previous should be disabled on the first page, and Next disabled on the last page.
• Yes, I think both the word and caret should be actionable.
• Any particular reason you propose dropping the ability to jump to a specific page? (I'm not necessarily advocating for keeping it; just curious to hear your thoughts.)
• Channeling my inner @nataliafitzgerald: We've got a loosely-defined standard of using Pacific for highlighting actionable UI elements. What's the reason for taking this all-grayscale?

[schaferjh]

Definitely appealing, but how many pages could really be shown at the smallest viewport? With the current v1 pagination, we actually break out the buttons -- would you imagine doing the same?

[ielerol]

@Scotchester I don't have data backing this up, but my gut feeling about pagination is that there are few cases where our users are likely to know exactly which page they need to jump to, and without that, the ability to type in a page number is not too useful. Showing links to several page numbers is a common pagination pattern and would at least be familiar.

[schaferjh]

@ielerol I think you're right that users don't have a specific page number in mind, but I think the actual behavior (again with the lack of data) is jumping back/forward in large steps -- a third of the way through or half way through etc.

Providing the ability to jump to a specific page satisfies a wider variety of navigation behaviors -- for people who want to jump by just a page or two, jump by larger increments, or jump to the end.

[mistergone]

Hello! I just wanted to poke my head in with a concern about how the pagination discussion affects tables (#153). Pagination is included in the tables specification, so I wanted to talk to someone about whether pagination code will work on tables, or if tables need their own code, and how decisions here might affect my work on cf-tables. So uh... someone get in touch with me. 😄 💃 🐙

[schaferjh]

I'd be interested to know as well @mistergone -- Currently on V1 the same pagination is used on the Activity Log (which is being counted as a table) and on something like the Blog. I think it would be best if we keep this consistency.

[ielerol]

@schaferjh yeah, it's hard to say for sure without data, or specific use cases, but I tend to think that in cases where there are really large numbers of pages, offering good search/sorting/filtering options is a better way to help users find what they're looking for. People can narrow down the content to a relatively small number of pages (or sort it so everything relevant is at the top), which they can then go through one page at a time. And once you're to a point where you want to look through pages one at a time, clicking a link is simpler than putting in a number and clicking on "go". Obviously you can still use the next and previous buttons, but the list of page number links is just such a common pattern across the web that I'd want a really strong case for deviating from it.

I'd also like to know if any testing has been done of that stepper control. It's a nice idea but it seems like there's a lot of potential for confusion, especially on a touchscreen.

[marteki]

I hear that the FEWD devs in general agreed last week that code for this should only be written once, and should work with any needed use cases (tables, the blog, etc.)

The code for tables is being buttoned up this week. Whoever will be developing this, please reach out personally to @mistergone to make sure that our different teams' assumptions about how pagination works with tables are the same.

[ascott1]

@ohsk is the MVP of this your design? Or should it be based on the work of the V1 team?

[stephanieosan]

Status:

• We have a standard for pagination, that is not currently documented in the design manual
• Stephen proposed a usecase that it doesn't work for, and suggested design changes.

Recommendation:

• Document the current standard in the design manual.
• If additional use case issues are raised by folks who still work here, we can re-visit then.

[ielerol]

@jrubin555 and I would like to plan some usability testing of the pagination control for possible future updates, but for now we are going to document the existing standard.

[ielerol]

The google document draft with our current standards here: https://docs.google.com/a/cfpb.gov/document/d/1i1Tdgvg0PQaG-InpvlVLc0eEogy2RQSfPBw9N1QxMxA/edit?usp=sharing

[ielerol]

One question that has come up in documenting the standards is the question of what to label the buttons. Right now the pagination of filterable lists in Wagtail only allows "older" and "newer," but we have paginated lists of content that aren't date-based, and need the ability to label them as "previous" and "next."

The UX team discussed the question of labels, and generally agreed that we like having the ability to use "older" and "newer" for time-based content, but need the flexibility of previous and next for other content.