Page MenuHomePhabricator

Keep pagination consistent when switching status filters on the Notification Page
Open, Needs TriagePublic

Description

Currently, every time you change the status filters (all, read, unread) from the NotificationPage, the pagination gets restarted going back to the initial page. This may be problematic when users explore older notifications and need to switch the filters applied.

Ideally, a user switching from "read" to unread" and back again to "read" should be in the same page she was before switching filters, even if it was not the initial page.

This consistency is challenging since the different filters result in lists of different lengths. One way to achieve this is to use the date as a reference and show the results for whichever page contains results from that date.

Event Timeline

Simply passing the same continue value should achieve the "date as a reference" thing, because the continue value is timestamp-based.

Simply passing the same continue value should achieve the "date as a reference" thing, because the continue value is timestamp-based.

Sure. But then the problem is going backwards to "previous page". We won't really have the correct continue value to use there.

We could try to do something with changing the pagination from "continue" to the dir/offset style pagination, but that, too, will be problematic in terms of pages.

To be honest, preserving pages in these cases sounds illogical to me, and it's not really the way other things work (like gmail filtering). Even in Gmail, if you look at page 10 of your inbox, the moment you filter, the results go back to page 1.

It's logical, because your filter just changed the entire result-set, including the number of pages that are available, and the position of whatever you are looking at in the set.

Beyond the fact that this is a technical challenge, I'm not entirely sure I see the benefit of this, honestly, it sounds like it will be more confusing than helpful.

Beyond the fact that this is a technical challenge, I'm not entirely sure I see the benefit of this, honestly, it sounds like it will be more confusing than helpful.

The current behaviour makes sense from the information hierarchy perspective. So I'm not claiming it to be broken, and I'm totally fine in keeping it for now and observe how this is used in practice.

What is being proposed is to better support the specific workflow of viewing a set of notifications through different lenses, reducing the friction when switching between them. For example, a user viewing the pending items (i.e., "unread" filter") that wants to keep the notification she just read as unread for follow-up actions is being forced to reposition herself when going to "read/all" (to find the notification) and back to "unread" (to continue with pending items).

The fact that unread items won't fill a whole page may make it even less of an issue in any case. However, I think it's an aspect worth keeping in mind when observing users that make use of the notification page in a realistic settings.

Restricted Application added a project: Growth-Team. · View Herald TranscriptFeb 26 2019, 8:48 AM