Page MenuHomePhabricator

Modernize the look and usability of page histories
Open, MediumPublic

Description

Original task:
The history page view contains too much cruft. I suggest following actions:

  • Hide the user tool links behind a popup that shows when the username is hovered (this should work anywhere in MediaWiki) (imho no non-js fallback is needed, the linked pages can be reached by few more clicks)
  • Hide the action links unless the given row is hovered (keep them visible in non-js fallback)
  • Now that there is less stuff to show, even a table based layout could work.

Merged duplicate task:
History pages are a key tool for article maintenance! Some possible improvements:

  • More reliable layout; clearer divide between rows, and/or better wraparound behaviour
  • Better separation of data from actions. "Data" includes revision links, timestamp, user info, edit summary, tags, et cetera. Actions include rollback, undo, thank, et cetera.
  • Fewer mildly-cryptic things that might be confusing to newbies. For example: "cur" and "prev" links aren't self-explanatory as "diff with current revision" and "diff with previous revision", respectively.
  • Visual representations of data. For example, graphical links between net-null revisions (usually between a revert edit and the revision to which it reverted). The key idea here is "information on history pages that doesn't require reading words or numbers", so that it's easier to understand a page's history at a glance.

I've played around with some of this already using JavaScript; interested parties can paste importScript("User:Nihiltres/nothingthree.js"); and then nothingthree.customRevs.testRun(); into the console of an English Wikipedia history page to see how my experiments ended up. For example, I make the byte-difference more self-explanatory by changing "(65,176 bytes) (+1,234)" into "+1,234 → 65,176 bytes".

I stopped messing around a) because it was tiring and b) because this is something that should be implemented in MediaWiki proper, rather than reimplementing the whole damn history page in JavaScript. Maybe something the Community Tech team would like to take a run at? {{Nihiltres|talk|edits}} 20:25, 17 July 2015 (UTC)

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 11 support votes, and was ranked #60 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Moderation_and_admin_tools#Better_history_pages


Examples:


See Also:

Details

Reference
bz28131

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:25 PM
bzimport set Reference to bz28131.
bzimport added a subscriber: Unknown Object (MLST).

IMHO with touch based interfaces growing now things that function on hover, especially non-obvious stuff aren't very nice things to add.

Omitting a non-js fallback also isn't very nice to the users without js. Who ARE more likely to be power users that do want those links.

Probably better to do this as part of the overhaul of ChangesLists in general (currently: Recent changes, History, Logs, Watchlist) that is to say, the overhaul to make it into a table.

The exact specifics of this are to be discussed in an RFC, and Recent changes might be an exception since there is going to be some other stuff around that with regards to wiki monitoring and patrolling etc.

bug 28446 - tabular changeslists

(In reply to comment #0)

The history page view contains too much cruft. I suggest following actions:

  • Hide the user tool links behind a popup that shows when the username is

hovered (this should work anywhere in MediaWiki) (imho no non-js fallback is
needed, the linked pages can be reached by few more clicks)

On bug 22516 you also suggested that as a viable approach.

(In reply to comment #2)

Probably better to do this as part of the overhaul of ChangesLists in general
(currently: Recent changes, History, Logs, Watchlist) that is to say, the
overhaul to make it into a table.

Indeed. I was looking for this bug in RC component.

Quiddity set Security to None.

(I'm assuming this task is for the general area of modernizing page histories, and not for a specific intended design.)

I've been working on a userscript for reworking the appearance of history pages, which contains several ideas that I think haven't been explored before: User:Yair rand/HistoryView.js. Might be useful.

I've been working on a userscript for reworking the appearance of history pages, which contains several ideas that I think haven't been explored before: User:Yair rand/HistoryView.js. Might be useful.

Verrrrry neat. I like it. A picture is clearer... so i made a quick silent screencast showing what it looks like with some quick mouseovers. I probably missed showing some features, so feel free to upload a better version on top. HTH. :) https://commons.wikimedia.org/wiki/File:YairRandHistoryView.ogg