@Pginer-WMF, I think we should put pagination navigation at the bottom of pages as well, since getting to the bottom and then wanting to go to the next page is a common pattern. Roan says we can't have fancy controls, like the Google bottom navigation, that let you skip 4,5,6 etc. pages ahead or back. So, we're limited to one page at at time plus "oldest" and "newest" links. Do you want to use the nav we already have, e.g, at the bottom of History page? Or would you like to repeat the Older and Newer buttons and add to them Oldest and Newest links... What do you think?

@jmatazzoni my initial thoughts were about making the header to become sticky presenting some of the controls easier to reach at hand. This was part of the description before being edited:

The mockup below illustrate how navigation controls can be provided as part of a sticky header along other entry points to quickly access filtering functionality:

• The search button provides a quick access to jump into the filters on top
• Access to quick links can be provided to facilitate the switching between review activities.

Note that some of the controls (such as the "advanced settings") are outdated, but this approach allows users to move around and jump between saved filters not only at the beginning/end of the list. With the current controls, it could be more close to this:

@Pginer-WMF, two things in answer to why I specified that the search tools just stay at top: 1) it's useful for users to be able to see what their filter selections were as they page back, and 2) Roan says that his plan for implementing pagination is that as you press the Older and Newer buttons, it's really just another search. So the Results area updates, just as though you'd changed your search parameters. Given this, both technically and from a UX perspective, the simplest thing is just to leave all the tools at top, I think.

What I didn't think about is what happens if you change your parameters. E.g., if you just change blue highlighting to green, do you return to the top of the queue? I think you do...

@jmatazzoni I updated the description based on our latest conversation. I included a video to illustrate the idea of the sticky header.

There is one aspect that is not completely clear to me form the description:

The "Newer X" and "Older X" pagination buttons continue to do what their names suggest. However, this means the perceived "direction" of navigation they facilitate is reversed. I.e., "Newer" takes users "back" away from the top RC Page and toward what's now the bottom of the queue (where results are newest), while the "Older" takes users toward the top of the queue and the first RC Page (where results are oldest).

I'd expect the newer and older buttons to keep the same functionality but be ordered in reverse order based on the sorting direction. That is, moving forward (i.e., to the right*) means to advance through the most recent changes (to the oldest) or advance through the backlog (to the most recent) depending on the sorting order. I captured this in the mockups below:

Newest fist (review the most recent changes)	Oldest first (review a backlog)

*On left-to-right languages the order of the buttons will be the reverse for internationalisation reasons, but that is a different story.

Many gadgets hook into RC and watchlists, and these cannot handle them changing dynamically. Especially for watchlists, that might become an issue when this reaches the phase where such changes leave Beta mode.

We should have mw.hooks, providing the new content of a page, so that JS tools can hook into those instead of document.ready, as we have wikipage.content, wikipage.diff, wikipage.editform, mmv, map hooks etc.

In T163429#3565502, @TheDJ wrote:

Many gadgets hook into RC and watchlists, and these cannot handle them changing dynamically. Especially for watchlists, that might become an issue when this reaches the phase where such changes leave Beta mode.

That's absolutely right. We know about "Navigation popups" (tracked in T172957) but there's probably many others. We hoped the beta period would bring some of them to light but it's been pretty quiet on that front.

Please let us know if you encounter any weirdness (visual or functional) on RC or WL with gadgets.

We should have mw.hooks, providing the new content of a page, so that JS tools can hook into those instead of document.ready, as we have wikipage.content, wikipage.diff, wikipage.editform, mmv, map hooks etc.

wikipage.content is fired once on load on the current pages and we fire it whenever there's new changes for any reason (filter update, live update, etc) with the beta feature. Gadgets can migrate to use it today to stay compatible with or without the beta feature.

@SBisson wikipage.content is however intended for content of wiki pages, not special pages.... I guess that could work, but... not really what the original intent of that hook was (You might be triggering other scripts that will now encounter content that they are not expecting).

This sounds like something that should be discussed by Front-end-Standards-Group or something.

If/when this gets done, let's make sure that the changes in T172031: Small language tweak in 'Changes to show' menu are incorporated.

I updated the title of this to include Watchlist, where pagination features are more useful and arguably even required.

This task covers the same ground but is much older: T20228: Add pagination (offset, prev/next, until/from/to) to watchlist and recent changes in the old (non-JS) UI