Knowing some users, I anticipate the question " why don't you use infinite scroll?".

(I know: "Infinite scroll, infinite troll" :þ)

Since this is for the old notification page, maybe it should use ReverseChronologicalPager.php or one of the other pagers in core.

Then we can do this pagination mockup for the new JS-only one.

There's another issue to consider here. With the current augmented JS functionality, it just appends to the current page when you click the button. Do we want to keep that (not sure if that's compatible with the idea of using ReverseChronologicalPager or similar)?

This is now just about the future pagination for the new JS version of the special page.

The first round (which will apply to both JS and no-JS users) is T129169: Change current no-JS Special:Notifications to use core Pager.

In T129363#2104460, @Mattflaschen wrote:

Since this is for the old notification page

I'm not sure what do you mean. This was proposed as an one of the first iterative steps for the new Notification Page.

In T129363#2104526, @Mattflaschen wrote:

There's another issue to consider here. With the current augmented JS functionality, it just appends to the current page when you click the button. Do we want to keep that (not sure if that's compatible with the idea of using ReverseChronologicalPager or similar)?

In the proposed designs the idea is to replace one page with another as you move through the pages, not expand it as it currently happens. But I'm not sure where are you referring to when talking about "keeping that".

In T129363#2103747, @Trizek-WMF wrote:

Knowing some users, I anticipate the question " why don't you use infinite scroll?".

(I know: "Infinite scroll, infinite troll" :þ)

First, I'd ask which is the problem that we expect to solve by using "infinite scroll"?

"Infinite scroll" is just one of the possible solutions to navigate through a list of items. Infinite scroll is a technique that, when done well, provides the illusion of all items being in a single long list. It is equivalent to have a very long list (plus some technical optimisation to not load items that they are unlikely to be consumed, and keep loading as users scroll).

So the bigger question is whether we want to present a big continuous list or braking it into parts. Keeping a single list facilitates consuming the content sequentially (you just need to scroll) but provides less reference points (where I am? how many other results are left?) which you get by breaking it into smaller parts.

For the current context, if we expect users to focus on the tasks to be completed and move back and forth through several items, I think these reference points can be useful. If we find that clicking "next" adds too much friction, we can explore alternatives to improve that.

I want to avoid users to scroll for a while until they view two interesting notifications, click on one to read them and going back o the beginning of the list, having to scroll down again chasing the other notification. I'm sure that there are ways to solve that in an infinite-scroll scenario, but I'd prefer to start simple with a model that seems to fit our needs first.

In T129363#2106364, @Pginer-WMF wrote:

In T129363#2104460, @Mattflaschen wrote:

Since this is for the old notification page

I'm not sure what do you mean. This was proposed as an one of the first iterative steps for the new Notification Page.

When we talked about the "no-js" experience, we decided to keep the current notification page with a few tweaks just to make it usable (pagination, mark as read) as the no-js experience and build a new one from scratch for the js experience.

The iterative steps you are referring to are going to be on the new page T129176: Minimal JS version of Special:Notifications

From this point on, I propose we refer to those pages as "Special:Notifications (JS)" and "Special:Notifications (NO-JS)" or something like that to avoid more confusion.

From this point on, I propose we refer to those pages as "Special:Notifications (JS)" and "Special:Notifications (NO-JS)" or something like that to avoid more confusion.

Thanks for the clarifications.
When talking about products, I assumed the default to be the full experience (with JS, CSS, HTML), and expected limited versions to be clearly labelled. I'd recommend having all tickets about No-JS version under a single parent No-JS Notification Page ticket.
Outside of that we can try to explicitly state that the ticket refers to the full version, but we may safely assume it when missing.

Responding to Benoit's question:

Knowing some users, I anticipate the question " why don't you use infinite scroll?".

My feeling about that is this: Infinite scroll is an effective technique when the user is just browsing and the goal of the design is to show as many options as you can so that the user will eventually find one that appeals. This is why it's so popular on news and other content sites. The designers don't want you to get to the bottom of a page and bail because you hadn't yet found a story that attracted you. So an endless stream of stories is a good solution.

But when the user is in a more directed, hunting mode, then as Pau says, being in one infinite list can leave her without reference points. For example, if I'm looking to find something from about two months ago, I might try skipping about 5 pages. If I find I've overshot by a month, I'll back up by two pages. The pages become a rough measure of time.

Email may be the best model for this type of tool, and I don't think any of the main email programs use infinite scroll--likely for the same reason. So I think if someone asks, we can answer that we don't believe it's conducive to the type of activity we imagine is taking place on that page.

Another thing I'd mention is that we propose to increase the messages shown per page from the current20 to 50. I think this is a number that provides a nice balancing point in terms of breaking up the list but not being too granular about it.

I created a ticket to capture some aspects of the ticket which are not currently supported in beta: T136574: Hide pagination controls from the Notification Page when there is only one page

Other changes seem to be supported, but since I don't see the patchset attached maybe another ticket may have been used as reference.

Change 291851 had a related patch set uploaded (by Mooeypoo):
Display a message if there are no notifications in Special:Page

https://gerrit.wikimedia.org/r/291851

Change 291851 merged by jenkins-bot:
Display a message if there are no notifications in Special:Notifications

https://gerrit.wikimedia.org/r/291851

Checked along with other tickets related to Special: Notifications page layout/functionality.

The comments below are on specific requirements for that ticket.

1. A very minor deviation from the original prototype - http://pauginer.github.io/prototypes/notifications/notification-page/index.html:

Currently, the tabs and 'Mark as read' are bolded, but pagination labels are not.

In the original design, it's vice versa - and when I checked how it'd look like - it certainly looks more visually pleasing.

2. The following spec is not implemented:

The header (where the pagination controls are) will become sticky as the user >scrolls. That allows to keep the navigation controls at hand if needed:

In T129363#2345860, @Etonkovidova wrote:

1. A very minor deviation from the original prototype - http://pauginer.github.io/prototypes/notifications/notification-page/index.html:

Currently, the tabs and 'Mark as read' are bolded, but pagination labels are not.

In the original design, it's vice versa - and when I checked how it'd look like - it certainly looks more visually pleasing.

For the button and button groups we want to use the standard components which are currently using bold text.
We can revisit the standard components as part of UI-Standardization efforts if needed.

Sending back to Ready for Pickup for:

• Style changes by implementing standard components, as Pau suggests.
• Implementation of sticky header (for the all/read/unread filters and page navigation.

Change 292270 had a related patch set uploaded (by Catrope):
Display a message if there are no notifications in Special:Notifications

https://gerrit.wikimedia.org/r/292270

Change 292270 merged by jenkins-bot:
Display a message if there are no notifications in Special:Notifications

https://gerrit.wikimedia.org/r/292270

In T129363#2346043, @jmatazzoni wrote:

Sending back to Ready for Pickup for:

• Style changes by implementing standard components, as Pau suggests.
• Implementation of sticky header (for the all/read/unread filters and page navigation.

This is in "needs review" but I can't find anything to review here. I suggest to either:

1. Move back to RFP and update the description to clearly define what's left to be done (mentioned above), or,
2. Move to QA and create new tasks for the items above

If what's left to be done needs to be done NOW, I'd go for option 1. Otherwise, option 2 will allow for independent prioritization of those.

Any preference?

Going for option 2 since the major work is done - Special:Notifications page has working pagination functionality and the all major design elements are in - splitting off the minor issues that can be addressed later. They can be also marked as blocking tasks.

There is T139696: Special:Notifications not showing all my notifications in production reported by @Mattflaschen-WMF - confirmed in betalabs. The issue is of High priority and it's a regression of pagination functionality, so the issue is independent from this task.

Two of my comments above are two separate issues:

1. T140962: [minor] Notification page - usage of bold font
2. T140964: Special:Notifications - make the pagination controls sticky