pagination of userpage (and future listpages)

[ericscheid]

The idea:

Google's API imposes certain limits on how many results to return when queried, and this can affect the userpage.

We don't have any similar hindrance for mongo stored brews (IIRC).

Most authors don't have thousands of brews, so this hasn't presented as an issue. Yet.

If we want to provide a Search Published Brews facility then this will certainly present as an issue. There could be thousands of brews matching certain simple keywords.

To do:

• decide hard pagination or soft pagination (i.e. actually fetch all serverside, but present in paginated form?)
• inifinite scrolling? or user-requested loading of additional results into the current view?
• implications for filter/sort widgets?
• UI/UX design
• URL design
• update fetch code on server
• add code on client side to display pagination (when needed, not otherwise)

[5e-Cleric]

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

[ericscheid]

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).

[Gazook89]

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

[5e-Cleric]

This looks hideous, doesn't it?

[ericscheid]

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.

[5e-Cleric]

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

[ericscheid]

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.

[dbolack-ab]

Could we slightly up the locally stored data so it's not necessary to query GD until the file is loaded?