Page MenuHomePhabricator

DE1.3.3: Diff design improvements
Open, Needs TriagePublic

Description

Hypothesis: If we produce designs for improvements to the onboarding and legibility of diffs, which connect reviewing a change to clear next steps, the Moderator Tools team will have a clear understanding of what to implement.

This is a Q1 design hypothesis, intended to queue up implementable work for Q2. It is relatively open-ended, and we may take this in a number of different directions based on what we learn and what feels achievable in a short time frame.

The goal of the Review Changes module in the Personal Dashboard is to engage newer editors in the practice of staying up to date with the edits that have been made to the pages they are interested in. We hypothesize that this feature can drive retention among newer editors. To make the feature as engaging as possible, we need to ensure that the full journey a user goes through with it is clear, actionable, and provides an obvious next step. So far, our efforts have focused on the entrypoint - assembling the right edits for a given user, and providing them with reasons to click on an edit. Once they land on a diff, however, they:

  • May find the interface confusing
  • May not be able to find the action that they want to take (e.g. Thanks, Undo)
  • Are not provided with a clear way to either navigate back to the list of Review Changes edits, or to navigate to the next edit in their feed.

We would like to make changes here so that there is a clear ‘loop’ from first seeing the Review Changes module, through reviewing a given edit, reviewing more edits, and either returning to the Dashboard or moving on to other activities. We don’t want looking at a Diff to be a dead end that results in the user closing the page.

The scope of our changes could be for all users, whenever they view a diff, or they could be limited to changes which only display for users engaging with their Review Changes feed. Additionally, we may decide to limit our efforts to either the desktop or mobile experiences.

Screenshot 2026-07-01 at 13.22.10.png (1,150×1,132 px, 390 KB)

Event Timeline

@Samwalton9-WMF This popped up on my Phab feed, so gonna leave some thoughts :)

  • Next edit and prev edit are probably gonna be the most used (or at least I use them the most), and those are the smallest
  • Browse history interactively is not usable on mobile AFAIK
  • I feel like the wikitext to visual is taking up unnecessary space and could potentially be moved below the fold? I've used it a few times, but not enough to warrant its prominent placement
  • Can we please have a native version of "restore this version" pls :) The current one-click one is provided by Twinkle, and the official way to do it is to go to the revision, click edit, and then save which won't be accessible to newbies.
  • I really liked the old version of this UI, which had a huge and prominently placed thank button and user stats in the sticky UI (they are now one more click away)
  • I wonder if we could present the user with two prominently placed buttons: undo or thank? I feel like that would make antivandalism into a Tinder/Tiktok-like game (that might be a bad thing or it might not?)

Thanks for sharing these thoughts @Soda!

Making actions (e.g. Undo, Thank) clearer & more obvious is definitely something we want to think about, though I'm in two minds about it at the moment. On the one hand, we should make it more obvious that users (I'm thinking about new users here) can share their opinions on a change via those actions. At the same time, Undo is a dramatic action to take, so do we want to make it too easy to do? What other actions might we consider surfacing? Like, what if the top-line actions to take when looking at a diff were "Undo, Thank, Discuss" where Discuss takes you to the article talk page with a pre-loaded ping for the editor who made the diff? Just trying to think of ways to go beyond that 'Thank or Revert' paradigm that we have at the moment.

Regarding the new tray, where the actions are below an additional click, I agree it's awkward that they're down there but it came as a result of us starting from a position of having them always visible but finding that it was taking way too much screen real estate. Definitely something we could revisit, though the outcome may be similar.