pagination of userpage (and future listpages) about homebrewery HOT 7 OPEN

For the record, the screenshot above reinforces my assumption that you are German.

from homebrewery.

The main problem with a long page is that it takes a long time to deliver all that data from the server to the browser (including extra time for multiple API requests to marshal that data).

A progressive loading pattern (e.g. infinite scrolling) has that time broken into chunks, providing the user with an interactable experience earlier.

If the browser were to somehow have on hand a large collection of brew doc data, then presenting that in one long page is not a problem. Especially since we do provide on-page tools for sorting and filtering that collection (making the browser page visually shorter in the process, since many brews get "filtered out").

The main problems that "pagination" here is solving for are a) coping with API response size limits, and b) server to browser transmission time before first viewport painting. A very long but scrollable UI is not a problem (especially with our filter/sort tools).

Referring to this issue as a "pagination" problem might have been a misstep. The traditional solution for this problem is commonly called "pagination", but we don't need to hew to tradition.

from homebrewery.

about UI design, i would do something simmilar to userpage, or a grid of vertical cards with image and title below.

however if we wanted to move away from that, i have some ideas that i could try

from homebrewery.

The UI for the main content of listpages is one thing (card UI, columns, tag cloud, MS Bob virtual desktop, etc) ..

.. but I'm specifically asking about the UI and UX design for the pagination experience controls, and what controls will be included for it.

Like this:

.. or « 1–200 201–400 401–432 »

.. modulo including page-sizing controls

.. modulo including a status line of "showing page <n> of <m> pages, items <start>–<end> of <total> items"

.. or even sillier bits of over-engineering:

Additionally, will subsequent pages be presented by replacing the current page, or added to the current page (a la infinite scroll, but with a click).

My preference would be "none" (if fewer than some-large-number brews all on one page) and "minimal" (for the few use cases with more than that some-large-number).

from homebrewery.

This looks hideous, doesn't it?

from homebrewery.

This looks hideous, doesn't it?

The < before and after > widgets are a bit much visually.

Also, those < >widgets imply that only the results from the currently selected page are visible — it would be nicer, more useful, and more usable to add the requested page of results to the current view of results. This way the sorts and filter widgets can be useful, and it won't feel like exploring a library through a keyhole.

from homebrewery.

it would be nicer, more useful, and more usable to add the requested page of results to the current view of results.

wouldn't that make an incredibly long page? don't we want to avoid that?

The < before and after > widgets are a bit much visually.

i guess a simple < > would work better

from homebrewery.