Page MenuHomePhabricator

Summary of activity at the top of mobile history page
Closed, DeclinedPublic

Description

The mobile history page is ok nowadays, but it would benefit from a summary at the top that could provide interesting information to newcomers and regular editors alike, i.e.

This page was created on DD-MM-YYYY and has been edited N times by N registered volunteers and N anonymous users.
 
Improve it anonymously           Log in / Register

For logged in users we could simply show the summary followed by the edit pencil icon

Background: T94298: Rephrase "Last edited..." in mobile web UI and link only to page history, https://lists.wikimedia.org/pipermail/design/2015-March/002296.html and related posts.

Proposed design

Yeah something like this where we summarize the edits to page would be useful

pagehistory.png (1×750 px, 110 KB)

Developer notes

This will kick off the epic T169162 so bear in mind during implementation we are looking for a generic solution for ALL special pages.
Remember SpecialMobileHistory extends MobileSpecialPageFeed extends MobileSpecialPage

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added a project: Web-Team-Backlog.
Qgil subscribed.
Sn1per subscribed.

Not a duplicate?

Yeah something like this where we summarize the edits to page would be useful

pagehistory.png (1×750 px, 110 KB)

@Nirzar it would make sense to do this at the same time as T147722
Could you update the mock to show what it would look like for other namespaces and merge T147722 into this one?

Ping @kaldari can we use https://xtools.wmflabs.org to provide this information and more? Would that scale? I wonder if we could be more ambitious with this summary.

@Jdlrobson: XTools has a page API you could use to get this information: https://xtools.readthedocs.io/en/stable/api/page.html. For example: https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Albert_Einstein. Whether or not it would scale is another issue. @MusikAnimal knows more about the caching and scaling aspects of XTools.

My guess is that it would make more sense to just steal the code that XTools uses (https://github.com/x-tools/xtools) to get this info and copy it into MobileFrontend so that you can query against the production databases rather than the Labs replicas.

The XTools API can handle a decent amount of traffic, but I don't know about using it in MobileFrontend. Getting the data you're after could be done with a single query, something like:

SELECT
  COUNT(*) AS num_edits,
  COUNT(DISTINCT(rev_user_text)) AS num_editors,
  MAX(rev_timestamp) AS modified_at
FROM revision
WHERE rev_page = 1092923

This is how we do it using the replicas. On production it seems this goes really slow... I don't know why, but I'm sure you could use something similar.

This should either be folded into something we can do as part of AMC or declined.

LGoto subscribed.

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.