vanilla-framework
vanilla-framework copied to clipboard
canonical
Pagination: add counter, specify position with respect to results
The pagination component does not specify where it should be positioned with respect to the results. From the discussion below, "always at bottom" seems the reasonable thing to do. We should consider adding a counter (e.g. “1 → 20 of 87 results”), which makes more sense at the top. Design TBD.
Transcript for some added context of a mattermost discussion with @matthewpaulthomas:
In Vanilla we have a pagination component https://vanillaframework.io/docs/patterns/pagination but it doesn’t say where to place it. Should it be above the batch? Below it? Both? Opinions? For a batch of search results, I mean. Maybe it depends partly on the batch length — for longer batches it’s useful to have pagination both above and below, while for short batches that looks redundant
I've only seen it used at the bottom, and, depending on context, sometimes left aligned, sometimes right aligned. Seems there's an implicit assumption that the need for further results arises the moment you've gotten to the bottom of the current page, not while you're at the top or the middle. If this assumption is correct, pagination at the top would require a scroll up, while a sticky one would be unnecesary until you get to the bottom.
I agree, bottom is definitely more useful for batch navigation. Meanwhile, though, top placement is more useful for batch count (e.g. “1 → 20 of 87 results”), because it guides you to whether you should refine your search. And putting batch count and batch navigation on the same line saves vertical space (e.g. “1 → 20 of 87 results • Prev • Next”). So I guess one of those three has to be sacrificed.
I'd vote for separate counter and prev / next. Combining them for the sake of economizing a few pixels seems like a dubious gain. It creates a problem that doesn't otherwise exist. And usually, there are more effective ways to shave off excess white space, especially when repeating elements are involved. For example, shaving even a few pixels on each of 20 results would save far more space than the pagination takes.
That’s reasonable, I’ll change my wireframes to separate them.
What is the suggestion here? Include documentation on recommended positioning?
Add positioning recomendation to the documentation, and add an example of a counter.
This can be achieved by some muted text floatd to the right, so seems to require some documentation and an example. I don't think we need to modify the component. especially given the fact this counter will be phisically detached (top of page) from the component (which is at the bottom of the page under the search results).
We need to specify UX behaviour for the documentation. Examples:
- https://ubuntu.com/certified?q=dell
- https://ubuntu.com/tutorials?q=ubuntu
- https://ubuntu.com/security/cve?q=&package=&priority=medium&version=groovy&status=needs-triage
- https://charmhub.io/?base=all&filter=big-data
Pagination Proposal document here:
https://docs.google.com/document/d/1MM4QtugMvNr5B5GcVzHhd2a22SK8Y8okM0Mw0BYAbBU/edit?usp=sharing
@amylily1011 @danielmutis if either of you get a chance at some point, would you mind taking a quick look and providing feedback in the document? I know both of you have looked a bit at this before. Would be interesting to get your feedback, and check it would work in instances where you've used it. Thanks.
@davegoddard42 Great work! Very clear structure and detailed content. Left some comments, please let me know if there is any questions.
@davegoddard42 I will leave the comments here:
I'm questioning the purpose of variant B's existence:
- if we change the Variant A example (168 items) to show 200 per page, does it switch to variant B?
- if so Then I cannot see the 'item to show' component anymore to change to show 20 per page back?
@Zihe Liu @.***>
I answered this in the document, but I resolved it and I don't think I tagged you, so you might have missed it. I wrote:
"That's a really good point. I envisaged it so that only when first shown if the number of items is below the 'show' value the second variant is used. In the case of changing the number of items to be shown, it would stay as variant A. I realise that isn't what I've written though (there's lots of room of ambiguity). Will update the copy." In short, variant A doesn't change to variant B if the item numbers to show. Happy to chat further if needs be!
On Thu, Jul 8, 2021 at 5:19 PM Zihe Liu @.***> wrote:
@davegoddard42 https://github.com/davegoddard42 I will leave the comments here:
I'm questioning the purpose of variant B's existence:
- if we change the Variant A example (168 items) to show 200 per page, does it switched to variant B?
- if so Then I cannot see the 'item to show' component anymore to change to show 20 per page back?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/vanilla-framework/issues/3208#issuecomment-876572733, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCGINE3ZMY4GSB6OXYZ7ODTWXF2PANCNFSM4QDJNCZA .
The pagination is being currently discussed as part of https://github.com/canonical/vanilla-framework/issues/4704, closing this one.
