Simplify and improve consistency in curation toolbar display logic
Closed, ResolvedPublic

Description

Current status

  1. Curation toolbar code is loaded in the user's browser (not yet visible in the user interface) if the following are all true:
    1. User is logged in
    2. User has patrol right
    3. User is viewing an article *not* in the Draft namespace
    4. User did not come from Special:NewPages
    5. Article needs triage
    6. User is not viewing their own article (unless they have autopatrol right)
  1. Once the code is loaded, we then evaluate two things to determine if we should show the toolbar to the user.
      1. The ?showcurationtoolbar=1 query parameter is present, indicating that the user came from clicking "Review" on "Special:NewPagesFeed", or that they clicked "Next" from a page where they had the toolbar open. If this parameter is present we show the toolbar in maximized format.
        1. The above was the result of two business rules changes in October: one was to assume that users clicking from NewPagesFeed would want to always have the toolbar code loaded (hence the query parameter). The other was that we could show the toolbar maximized by default in this situation rather than read the user's preferences.
    1. If the showcurationtoolbar=1 parameter is not present, then check if the user accessed Special:NewPagesFeed in the last 24 hours.
      1. If we don't see any indication that the user visited Special:NewPagesFeed in the last 24 hours, do not show the toolbar. The user can click on "Curate this article" on the left in "Tools" to see the toolbar.
        1. If we see that they accessed within the last 24 hours, then read their preferences for whether to show the toolbar maximized, minimized, or hidden (in which case "Curate this article" link text in the Tools menu). The preferences are always set based on what the user's last interaction with the toolbar was.

Possible changes

  1. None. Let users override this with Gadget CSS if they really don't want to see the toolbar ever, or let them manually remove showcurationtoolbar=1 from the URL.
  1. Don't assume maximized display when showcurationtoolbar=1 is in the URL. Instead, read from their preferences about how they last had the toolbar displayed (hidden, minimized, maximized)
  1. Remove showcurationtoolbar query parameter and keep the 24 hour last use check. Not recommended. The way we check to see if the user visited Special:NewPagesFeed requires getting a value from the server. Because of how MediaWiki's caching layer works, we may not always have 100% certainty that this value is present on the page, unless the user does a hard refresh (Ctrl+Shift+R). If we remove it, we might end up with users saying that the minimized or maximized toolbar doesn't show up for them as they expected.
  1. Implement a gadget preference and forget the whole concept of tracking last 24 hour use., as suggested in T207482
  1. Forget about the 24 hour last use concept, remove the showcurationtoolbar=1 param, and always show what the last display state was. In this version we'd always read the user preferences to see how they last interacted with the toolbar, and display it the same way (minimized, maximized, hidden). We could remove the code on the server side that tracks last use of PageTriage too.
kostajh created this task.Oct 25 2018, 7:06 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 25 2018, 7:06 PM

The Growth team discussed the current status with the curation toolbar and possible changes. We decided we would like to implement option 5 from the above list of possible changes. To summarize, the changes will be as follows:

  1. Remove the ApiPageTriageLastUse module. Stop storing data about PageTriage last use on the server side entirely, and remove logic around calculating last 24 hour use of PageTriage.
  2. We will not change the rules around when the toolbar code might load (see "Current status" item 1).
  3. Once the user is on a page where the toolbar can be loaded, we will check their preferences to see how the toolbar was last viewed (hidden, minimized, maximized). Whatever the previous state was, is what the current state will be.
  4. We will update the documentation page to make sure that users know they can click "Curate this article" to have the toolbar appear again if they've hidden it in a previous page view.

What about making the 'curate this article' link available on any article so that the Page Curation tools are not relegated to only pages in the New Page feed? T207485

@Insertcleverphrasehere that's a possibility (I left a comment on that task). I'd prefer to handle the display inconsistency issues mentioned here before addressing that task, though.

@kostajh -- after the community discussion, we've decided to go with our plan of Option 5. This is ready for development.

There is also a request to change the link text from "Curate this page" to "Open Page Curation"

Change 471282 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/PageTriage@master] Make curation toolbar sticky

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

Change 471282 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Make curation toolbar sticky

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

Checked in betalabs the implementation of

  1. Forget about the 24 hour last use concept, remove the showcurationtoolbar=1 param, and always show what the last display state was. [...]

It seems to work as expected - the last state (maximized, minimized, closed) of the curation toolbar is remembered across different user sessions and browsers.

The link 'Curate the page' was changed to 'Open Page Curation'.

Fix seems to work. Been testing for the last few days and haven't had any cases of not getting the toolbar.

MMiller_WMF closed this task as Resolved.Wed, Nov 28, 6:08 PM
MMiller_WMF moved this task from Needs PM Review to Done on the Growth-Team (Current Sprint) board.

Thanks for testing. This is resolved.