Page MenuHomePhabricator

Spike #2: Watchlist Expiry [12 hours]
Closed, ResolvedPublicSpike

Description

As a PM, I want to know which of the primary use cases and proposed elements of the feature can be reasonably implemented and supported, so that I can make decisions regarding the work that we do and its relative priority.

Important Links:

Acceptance Criteria:

Basic Functionality: Investigate how users can watch a page temporarily (highest priority)

  • Via the "watch" star: Can we add a drop-down menu (when user clicks the "watch" star) that enables them to select a timerange (for example, one day, one month, three months, six months, or permanently)? See the mockup link for examples.
    • What are the possible risks or issues associated with implementing this?
  • Via Special:EditWatchlist
    • Can we allow users to select one or multiple items on their watchlist, and then click a new button ("Watch Temporarily"), which will generate some sort of drop-down or datepicker to select when the watch period should expire?
    • Can we add lines for each item on the watchlist: make permanent/make temporary? This would open a drop-down with the options for the user to edit the watch period of the page.
      • What are the possible risks or issues associated with implementing this?
  • Via Edit Summary: Can we add an option to temporarily watch via edit summary with a drop-down?

Customization: Investigate ability to allow users to set custom time periods in the following ways:

  • Type in the number of days or weeks in a drop-down when watching the page
  • Select a custom and specific time period (either via datepicker or blank fields for days/weeks) when the user first chooses to watch the page temporarily
  • Set default time period via Preferences (see mockup example) that specifies by:
    • Default time period when using the star icon
    • Default time period when watching the Edit pages or Talk pages

Editing: Investigate how users can edit watchlist expiration dates in the following way:

  • By clicking on the watchlist star: Can the user edit the time period by unwatching the page and then re-watching it with a newly selected time period? Would this be the easiest to implement (in terms of editing)?
  • From Special:EditWatchlist: Can the user edit the watch period, based on either of the two processes explained in the "Basic Functionality" section above (specific to Special:EditWatchlist)?

Management: Investigate how we can support users who have temporarily watched pages by visually distinguishing between temporarily & permanently watched pages

  • Indicator on the page: Can we implement a half star (as per the mockup example)? If not (or if too technically difficult), what would be a more manageable solution?
  • Indicator on Special:EditWatchlist: Can temporarily watched pages have some sort of icon next to them? Can the date of expiration (or some info about the expiration period) be displayed? If not, what other behavior is possible?
  • Can we implement a filter on Special:EditWatchlist, so users can view all temporarily watched pages? Would this add a lot of work/effort?
  • Can we have per item links on EditWatchlist?

Notifications: Investigate our ability to notify users (in Echo) about changes to the watch status, including:

  • When a page is about to expire (for example, within one day of expiration)
  • When the page has expired (i.e. within one day after expiration)
  • If we cannot provide any notifications in Echo, why not? And are there any other alternative forms of notification/communication that may be manageable, from a technical perspective?

General Technical Considerations

  • What sort of changes will we need to make to the API?
  • Can we implement the basic functionality (i.e. allowing user to temporarily watch a page) in a way that looks/acts the same in both web and mobile versions?
  • How will the general usability of the tool be potentially impacted if someone has JavaScript disabled?

Additional Notes

  • We do not yet have mock-ups for mobile, but they have been requested in T235132.

Event Timeline

ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried renamed this task from Placeholder: Watchlist Expiry Spike #2 to Spike: Investigate Feasibility & Risks of Basic Proposal.Oct 9 2019, 9:10 PM
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried renamed this task from Spike: Investigate Feasibility & Risks of Basic Proposal to Spike #2: Watchlist Expiry.Oct 9 2019, 9:47 PM

Do any of these considerations change or have unique limitations in the mobile context?

@aezell They probably do, but we don't have any mobile mock-ups yet. I've created a ticket for @Prtksxna (T235132) to think through the mobile side of things, among other questions. The spike is already so large that I didn't know if it made sense to include mobile support within it, or if it was better to wait until we have mobile mock-ups. Thoughts?

@ifried That's fine. I wanted to scope the responses you're expecting.

@aezell Great, thanks. Yes, this ticket will focus on desktop view. If we plan to provide mobile support, we'll have a separate investigation that is paired with mobile-specific mock-ups.

ifried renamed this task from Spike #2: Watchlist Expiry to Spike #2: Watchlist Expiry [for Tuesday estimation -- pending].Oct 10 2019, 12:22 AM
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried renamed this task from Spike #2: Watchlist Expiry [for Tuesday estimation -- pending] to Spike #2: Watchlist Expiry.Oct 15 2019, 9:46 PM
ifried updated the task description. (Show Details)
MBinder_WMF changed the subtype of this task from "Task" to "Spike".Oct 15 2019, 11:22 PM
ifried renamed this task from Spike #2: Watchlist Expiry to Spike #2: Watchlist Expiry [12 hours].Oct 15 2019, 11:29 PM
ifried moved this task from To Be Estimated/Discussed to Estimated on the Community-Tech board.

@MBinder_WMF I've just created a request for a new component (Watchlist-Expiry). Once it's created, I'll add the component to all existing Watchlist Expiry tickets. Thanks!

ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)

By clicking on the watchlist star: Can the user edit the time period by unwatching the page and then re-watching it with a newly selected time period? Would this be the easiest to implement (in terms of editing)?

The smoothest way would be to let users first watchlist a page, then edit its expiry time in the post-watchlisting confirmation box.

Indicator on the page: Can we implement a half star (as per the mockup example)? If not (or if too technically difficult), what would be a more manageable solution?

It wouldn't be hard technically to implement this for one skin, but we have to support multiple skins, including MinervaNeue, which is very different from desktop skins; and Monobook that doesn't use a graphic watchlist button at all. We're talking about a visible change to our design language, especially since there's nothing like that in the widespread "star to like" design popularized by Google. Doing all this would be a significant work that would potentially involve dependencies on other teams, such as Design, Reading Web and Frontend Standards Group.

Investigate our ability to notify users (in Echo) about changes to the watch status

From a backend POV, this is all doable however it all takes time to implement, and then it will demand maintenance. Careful with scope!

What sort of changes will we need to make to the API?

Add timestamp to read APIs, add it to watchlisting API (problem: currently, the only place we're accepting expiry timestamps from the user are blocking/protecting which have higher precision and are quite different)

How will the general usability of the tool be potentially impacted if someone has JavaScript disabled?

There's no-JS fallback for this functionality, expiry selector can be added to it:

image.png (252×592 px, 16 KB)

Basic Functionality: Investigate how users can watch a page temporarily (highest priority)

  • Via the "watch" star: Can we add a drop-down menu (when user clicks the "watch" star) that enables them to select a timerange (for example, one day, one month, three months, six months, or permanently)? See the mockup link for examples.
    • What are the possible risks or issues associated with implementing this?

We can add an OOUI popup that attaches to the "watch" star or link in skins, with some fallback in skins where these don't exist or are hidden within a menu.

Since this is on a read-page (only for registered users) and on every page, OOUI will need to be lazy-loaded, which might mean a longer delay between the successful initial watch action and until the followup-expiry popup appears.

During TechConf, I've discussed the implication of a periodic purge of the Watchlist table with several people, and there seems to be consensus that the general approach is sound with regards to the new table and the periodic purge of the Watchlist based on indexed timestamps of the watchlist_expiry table (ticket upcoming for the creation of that table+consultation with DBAs)

The general plan:

  • Add a watchlist_expiry table that contains watchlist ID and expiry timestamp (both indexed)
  • Have a periodic purging of the Watchlist table (and the watchlist_expiry table) -- purging all items that have timestamp that is before the current time from both tables.
  • This purging will be done through the job queue.
  • The product requirement for the resolution of expiration is 1 day, which gives us leeway in how often we want to run the actual purging operation.

Initially, we were considering triggering the 'purge job' for the Watchlist on every edit of the watchlist; so, if a single user edits their Watchlist a purge job is created to purge all expired items from the Watchlist for all users. This will ensure the status of the unexpired items is as updated as possible without overwhelming the system.
For smaller wikis where Watchlist editing is less common, we were considering augmenting this process with a maintenance script (running every 6/12 hours) that will do the purge of the expired items.

During discussion and brainstorming, @daniel suggested we look into triggering the purge every X edits, similarly to what RecentChanges is doing now: https://github.com/wikimedia/mediawiki/blob/ea04a07b7d34dc9437ce5d1bfc16d46a1ace405f/includes/Storage/DerivedPageDataUpdater.php#L1481-L1483

The actual purge doesn't need to run that often; our product commitment takes into account that expiration has a resolution of a full day. In this case, we can do two things to not overuse this:

  • use a config variable to adjust the number of edits that trigger the purge between wikis (higher number for very active wikis, lower on slow activity wikis)
  • retain the timestamp of the last purge and only trigger it if x hours have passed from the last time the job has run.

We'll examine full implications of the actual implementation after approving the table structure and SQL purge queries with DBAs (ticket upcoming).

@daniel, I would like to make sure I've captured your suggestion correctly. Does this sound reasonable to you?

Mooeypoo claimed this task.

Investigation resolved. Next steps on followup tickets. Thank you for everyone's input!