Page MenuHomePhabricator

Update the look and feel of the edit history screen
Closed, ResolvedPublic

Description

Why are we doing this?

History and dif pages are used by editors and readers to understand how an article has changed over time. For editors, these pages are integral for gathering context around notifications and are key elements in a variety of common workflows.

For readers, History and dif pages can help to illuminate the ‘inner workings’ of Wikipedia and help to show the living structure of articles and the communities of volunteers who work on updating them.

Currently on iOS the History page does not allow for users to take additional actions on individual edits or to compare diffs.

User story

As a reader using the iOS app, I would like to be able to access history and dif pages in order to better understand how an article has changed over time and to learn more about who has been contributing to an article.

Mocks

History screenHistory screen scrolled
Zeplin: https://zpl.io/VQQ9wmmZeplin: https://zpl.io/bz7eoK8

Event Timeline

LGoto created this task.Jul 23 2019, 6:41 PM
JMinor renamed this task from Reskin to Update the look and feel of the edit history screen.Jul 23 2019, 9:09 PM
JMinor triaged this task as Medium priority.Jul 23 2019, 9:13 PM
cmadeo added a comment.EditedAug 26 2019, 8:38 PM

@NHarateh_WMF I've made some small-ish edits to this screen


https://zpl.io/VQQ9wmm

  • exchanged Reverts with user edits
  • Changed the subtitle from [n] edits from [n] editors to [n] edits since [year]
  • Updated time stamps and date headers for edits that occurred on the day that user is looking at to today and [n time] ago
cmadeo updated the task description. (Show Details)Aug 26 2019, 8:38 PM
Krinkle added a subscriber: Krinkle.EditedOct 11 2019, 4:22 AM

I'm responding here rather than on T231598, because my intent is not to discuss the implementation ("how") but rather to discuss the "what", and to ask what is ultimately desired/acceptable.

From task description

This includes a highlight of how many "bot edits" a page has received. This might be a problem, because whether an edit was "bot edit" is only reliably available for edits made in the last 30 days (part of the recent changes database).

This is contrary to the "minor edit" flag, which we do store historically in association with all edits in the page history. For bot edits, the information simply isn't there currently. An idea for recording this in association with all edits indefinitely was raised, and reported here (at the time using Bugzilla) at T19237 – 10 years ago.

Task coding task (T231598) mentions this can be approximated this based on current user status, however this has several problems that I think you should be aware of:

  1. This data will change backwards over time, as accounts can gain and expire their official bot status. As such, this can cause confusing numbers to be shown to users where what they see in the list does not match the count. It might also be confusing to see the number go down over time or shift from one to the other without actual changes having been made to the page.
  1. The definition of "bot edits" and "edits made by accounts that had bot status at the time" is not the same. Marking an edit as a bot edit is internally similar to the checkbox "Mark edit as minor".
    • Bot software can virtually check and uncheck this box on each edit. Official bots sometimes mark some of their edits as non-bot for various reasons, for example, if they directly proxied a human action, or want the edit to be subject to greater scrutiny. Being a "bot account" grants several abilities (including the allowance to make many more edits per minute). The allowance to mark their edits as "bot edits" is merely one of these abilities. Hence "edits by bot users" is not the same as "bot edits".
    • Bot status is sometimes granted to personal accounts as well, which should not be considered as bots. This is done when they wish to use automation software without the hassle of creating a new account. The software they use will recognise their official ability to mark edits as "bot edits" and will tick the virtual check box for "Mark as bot edit" when the user is operating this software. But, when the user is editing the wiki normally their edits are not be marked as bot edits (and shouldn't be). This is all working fine today in recent changes. But it is another reason for why we can't accurately determine this on page history.
  1. Determining whether a user account is (currently) considered a bot is not possible through a fixed database query in core. The designation of User::isBot has runtime hooks that may alter this in extensions. For example, on Wikipedia it is extended by CentralAuth to include "global" user groups, where there is a "Global bot" group distinct from the built-in bot group. For all intends and purposes, these accounts are bots (in fact, the most popular bots are likely not to be "Bots" but "Global bots"). This expense and per-use check is fine today as we only invoke it when an edit is saved. And in all places where we use it (only Recent changes) a copy of the outcome is saved. For page history, even if we accept that it will be wrong historically, to determine even their current status would require this PHP code to run for every user separately. This however does not scale for a general purpose API. We would likely need to devise a different internal system for User::isBot that is compatible with batch queries. However, given all the other problems listed here, this is an unlikely investment to be made. Rather, we might want to invest in storing it at the time the edit is saved instead (T19237) which avoids this class of problems.
  1. Even if we accept all the above (ignore global bots, ignore bot edits from humans with bot access, ignore older bots that no longer have their status), we would still be left with a rather expensive query that would span many different database tables. This is generally something we only do for research purposes (offline) or from a job. Not on-demand in an API. One way to resolve that would for the product to have a "waiting" and "unavailable" state which would (hopefully only rarely) appear while the data is being backfilled. GitHub have something like this, where repo status may be unavailable if you're the first one to open it in a long time:

This would initially return a "Unavailable" state to the app, at which point MediaWiki would start crunching the data in a JobQueue job, and the app can check back in a few seconds and either make it appear if available then, or fallback to a "Sorry, check back later" state.

Alternatively, if we really want to invest in this we could proactively compute this automatically after every edit that is saved to a page, and store it long-term in a new database. However, again, in such case the investment might pay off better if we punt it toward T19237.

@cmadeo Selection flow question

When user selects 2 revisions and then attempts to select another one (not currently selected):

Should we allow that? Or should the user have to deselect a selected revision to be able to select something else?

My initial feeling was that we shouldn't block actions and when they select another revision, one of the selections should move to that revision. But that leaves me with a question of which selection should be the one that moves. On the web, it looks like there're 2 columns which help determine which selection moves (https://en.wikipedia.org/w/index.php?title=Douglas_Albert_Munro&action=history)

Easy to change so not a blocker either way

@Krinkle, thanks so much for this breakdown of potential paths forward with Bot edit stats. For clarity, does the count on Page statistics (https://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Ching_Shih) only include bots on the page in the last 30 days?

Design-wise, I think we can find a way to move forward without this stat, although I do think that highlighting that bots make edits on Wikipedia is important to illustrate to users, but with these technical constraints I can move forward with developing a different way to do this. @JMinor what do you think?

@NHarateh_WMF Not a problem, here's what was designed: https://zpl.io/2jYPG4r
This would mean that the selection circles become greyed out after two revisions are selected and then if the user attempts to select a third they would see this warning.

ABorbaWMF added a subscriber: ABorbaWMF.

Looks good on 6.5.0 (1690)

Aklapper removed NHarateh_WMF as the assignee of this task.Nov 25 2019, 12:32 AM
Aklapper added a subscriber: NHarateh_WMF.

Resetting task assignee as the account @NHarateh_WMF is not active anymore.

JMinor added a comment.Dec 6 2019, 1:10 AM

@Krinkle you raise a number of interesting points about the accuracy of bot edit counts. However, I don't think any of them are so severe as to prevent initial development and release of this element of the new design. I'd like to reassure you that we have built the UI so that stats with longer return times load and appear smoothly when available.

That said, I would strongly encourage you to create a ticket against the API itself, as that would be where any actual iterative improvements and documentation of your specific concerns about this metric will be much more relevant than a closed ticket for the iOS app UI.

We often have a chicken/egg issue with our platform where we don't expose useful information because of very legitimate backend or performance concerns, and we don't solve our backend or data issues because things which have no active users are deprioritized. One side has to go first. Perhaps consider this a chance to push forward some of these decade old improvements for a now live API and UI.

JMinor closed this task as Resolved.Dec 6 2019, 1:11 AM
JMinor claimed this task.