Page MenuHomePhabricator

Add a link: maintain task feed and position on reload/back button
Open, MediumPublic

Description

User story: As a user of suggested edits, when I open a task, I want to be able to use my browser back button to return to the task feed if I decide I want to see a different task instead, so that I don't lose my place and have a whole new feed to browse.

From @RHo's description in T269653#6959667:

Right now, on desktop *only* the first article in the queue is kept when navigating back on a task. And actually it's the same behaviour on Mobile as well (the first article is always maintained, second and subsequent always lost). Given that is the case, we want to be able to maintain the queue when the user returns. Two scenarios come to mind. First is when someone mistakenly goes back, which even from just personal experience that can happen especially when browsing on mobile where there is an OS swipe left gesture to go back that can accidentally be triggered.

The second is if someone is deciding between a few articles they browse in the feed. Say they browse from the first article "Cream" to a second article "Diamond" and then 3rd is the "Pearl" article. They open "Pearl" to check out what's involved and think they might go back to see what "Diamond" is about first before committing, but upon hitting back "Diamond" and "Pearl" are both no longer available to edit.

Event Timeline

If you accidentally go back, you can go forward again to recover the task. Granted, on mobile forward navigation tends to be less obvious than back navigation.
If you are deciding between various options, you can open them in new tabs. (Mobile Chrome just updated their UI for multiple tabs and it's quite pleasant.)

Most browsers sometimes recover the last seen state of the page when backnavigating ("bfcache") but the behavior depends on all kinds of obscure properties of the web page and details change from browser to browser so it's hard to build on.

The alternative would be to store a sort key in some navigation-proof way (e.g. in the URL fragment) and use that to randomise the sort. That would mean moving the sorting from the server side to the client side. But we render the first card on the client side, and that needs to be different on different home page visits, so I don't think that would work.

More fundamentally, we'd have to differentiate between backnavigating from a task (where we should preserve the sort order) and visiting the homepage in some other way (where we specifically want to randomize the sort order). So unless we reconsider randomization, the least fragile way to do this is probably stashing the order in session storage, since that can reliably identify backnavigation.

All in all, this seems to me as relatively complicated while only marginally useful.

Clarifying the specification -- I remember when we implemented suggested edits, we deliberately wanted to randomize the card shown on each visit the user made to Special:Homepage. Does this task override that, or is this task requesting to preserve the task only in the specific scenarios of swiping or clicking back from a suggested edit session, or doing a page reload while already on Special:Homepage?

@kostajh @Tgr -- thanks for adding these notes. @RHo and I will try to clarify the specification when we approach the point that we might work on this.

More fundamentally, we'd have to differentiate between backnavigating from a task (where we should preserve the sort order) and visiting the homepage in some other way (where we specifically want to randomize the sort order). So unless we reconsider randomization, the least fragile way to do this is probably stashing the order in session storage, since that can reliably identify backnavigation.

All in all, this seems to me as relatively complicated while only marginally useful.

Clarifying the specification -- I remember when we implemented suggested edits, we deliberately wanted to randomize the card shown on each visit the user made to Special:Homepage. Does this task override that, or is this task requesting to preserve the task only in the specific scenarios of swiping or clicking back from a suggested edit session, or doing a page reload while already on Special:Homepage?

Thanks both for your additional comments. I am realising now that I was not involved in the decision (or perhaps wasn't paying close heed) to the decision to randomize the article shown on each visit. I think that it would be fairly confusing and unexpected for for newcomers who do not realise randomisation is occurring so in thinking back I would have pushed for the default to not be random (and potentially include a "randomise order" instead). I do think it is more than merely a marginal improvement for people to have a sense of orientation and understanding of how these results are being sorted and shown to them, as better grasp of therse settings could increase engagement with finding an article they want to edit. But as @MMiller_WMF says we will discuss and clarify next steps on this task.

More fundamentally, we'd have to differentiate between backnavigating from a task (where we should preserve the sort order) and visiting the homepage in some other way (where we specifically want to randomize the sort order). So unless we reconsider randomization, the least fragile way to do this is probably stashing the order in session storage, since that can reliably identify backnavigation.

All in all, this seems to me as relatively complicated while only marginally useful.

Clarifying the specification -- I remember when we implemented suggested edits, we deliberately wanted to randomize the card shown on each visit the user made to Special:Homepage. Does this task override that, or is this task requesting to preserve the task only in the specific scenarios of swiping or clicking back from a suggested edit session, or doing a page reload while already on Special:Homepage?

Thanks both for your additional comments. I am realising now that I was not involved in the decision (or perhaps wasn't paying close heed) to the decision to randomize the article shown on each visit. I think that it would be fairly confusing and unexpected for for newcomers who do not realise randomisation is occurring so in thinking back I would have pushed for the default to not be random (and potentially include a "randomise order" instead). I do think it is more than merely a marginal improvement for people to have a sense of orientation and understanding of how these results are being sorted and shown to them, as better grasp of therse settings could increase engagement with finding an article they want to edit. But as @MMiller_WMF says we will discuss and clarify next steps on this task.

We currently cache a set of tasks for a user for one week. That is easy to show in a predictable order to the user. But when the cache expires, we need to refresh the set of tasks and prefer that the refreshed data contain all the current items (less any expired ones). I think it might be possible to use the page IDs from the existing cached task set while generating the new cached task set (@Tgr does that sound right), so that might be a solution.

I think it would be less confusing for users to keep the order of the tasks. When you browse a choice of articles, and visit some, you expect to find the list of articles the way you left it.

If we go this way, providing a link that would reshuffle the offer of tasks would indeed be nice. Roll the dice!

I think it might be possible to use the page IDs from the existing cached task set while generating the new cached task set (@Tgr does that sound right), so that might be a solution.

You mean, reuse all the existing tasks, and add new tasks to the end of the queue to fill it up to 200? That would work, but it would mean the user sees the same task list forever (unless they / someone else solves those tasks). For non-structured tasks, which do not get automatically removed, that seems less than ideal.

The minimal-effort change would be to just remove randomization, and accept that once a week the suggestions get completely replaced (as this is already the case, just not really noticeable due to the random ordering).

If we go this way, providing a link that would reshuffle the offer of tasks would indeed be nice. Roll the dice!

That already exists (although it was intended for debug purposes), just append a resetTaskCache query parameter.

If we go this way, providing a link that would reshuffle the offer of tasks would indeed be nice. Roll the dice!

That already exists (although it was intended for debug purposes), just append a resetTaskCache query parameter.

If it is not visible to end users, cas we say it exist? :)

If we go this way, providing a link that would reshuffle the offer of tasks would indeed be nice. Roll the dice!

That already exists (although it was intended for debug purposes), just append a resetTaskCache query parameter.

If it is not visible to end users, cas we say it exist? :)

:) no, but it does mean that implementing the feature for that wouldn't be a lot of extra effort since we already have infrastructure to handle it.

kostajh triaged this task as Medium priority.Apr 26 2021, 7:55 PM

CirrusSearch supports pseudorandom sort now (although AIUI it's not guaranteed to be stable for long, just a day or so) which would be an easy way forward.