Page MenuHomePhabricator

Fix the Watchlist visual layout
Open, Needs TriagePublic

Description

Problem: the hopelessly inefficient use of space in the Watchlist (below is relative to enwp, but the issue is general to Mediawiki across projects).

On a brand spanking new high-end laptop with a high-res 15" screen, the usable space of the Watchlist is as follows:

That's a hell of a lot of wasted space that could have been used for the content I actually care about with a few simple changes (bonus points for hiding/minimizing the left sidebar, but politics will shoot that down even as a user preference off by default):

The effect on usable space would be pretty dramatic (especially if you could move the article title, "Watchlist", up above the tab bar, "Special", or where "Read"/"Edit"/etc. are for mainspace articles):

Event Timeline

Xover created this task.Apr 17 2017, 6:20 AM
Xover renamed this task from Feature request: fix the Watchlist to Fix the Watchlist visual layout.Apr 17 2017, 6:23 AM

This is an interesting problem. Generally skins don't touch this stuff - the content itself (everything under the firstHeading) is rendered and styled by MediaWiki core - but special pages are predictable, unlike user-created content, and there is some precedent for this already: Special:Preferences is styled only by the skins, and to my knowledge doesn't even have any default core styles (unless this has since been fixed). It could well be worth implementing different handling in different skins for others, too, given reason.

What you describe here, though, sounds more like it is simply a core problem - the layout of the watchlist needs work. All skins would benefit from an improved version, and thus it should not be limited to a single one.

Specifics:

  • View/edit/etc would likely make more sense as tabs (cactions menu). CentralNotice is an another example of a special page with extra tabs on, so there is precedent, and this would be a use that would be very clear to users.
  • I'm less certain that 'mark all...' would make sense as a tab - tabs are different views/modes, from which other actions can be taken, whereas this is a simple action directly. A button makes more sense, but it is possible there's a better place for it (maybe to the right of the firstHeading, like where the slideshow/filtering buttons appear on commons).
  • Also not certain about putting the number of pages on the same level as the firstHeading (if that's what you're suggesting) - it's just not that important. It's basically just part of the general intro text, providing context.
  • Making the options a right float, while a good idea in principle, probably wouldn't work well in practice. It's too wide. The watchlist content below it is also too wide. You can't side-by-side two wide things very well. Also the legend is already floated right within it, so then you'd wind up with a right float containing a right float. That'd be a bit weird looking. I agree it's not good, especially at smaller screen widths, but then the too wide problem only becomes worse. Collapsing is probably a good idea, though, since if people never use it there's no reason they should always have it taking up the full space.
  • There's also an issue with watchlist notices, as used on some projects: where should those go?

I'll see if there's tasks for some of these.

I'ma go ahead and change this to a general interface task, but I would like to note:

bonus points for hiding/minimizing the left sidebar, but politics will shoot that down even as a user preference off by default

If and when I ever get around to making a proper mobile version of Vector (sadly this requires basically reimplementing the entire skin from scratch, hence why its current mobile support is a bit... weird, and not even enabled by default), totally doing this. MonoBook too, since it's pretty much the same.

Don't discount what's possible due to politics - the politics across the projects vary considerably, and Wikisource actually has this already: https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2015-07#New_Gadget. That may be a gadget, but there's definitely demand for this being properly implemented in the skins themselves.

Isarra updated the task description. (Show Details)
Xover added a comment.Apr 18 2017, 7:02 PM
  • View/edit/etc would likely make more sense as tabs (cactions menu). CentralNotice is an another example of a special page with extra tabs on, so there is precedent, and this would be a use that would be very clear to users.

I was thinking more in terms of the dropdown menus you can get for various things, probably by way of a Gadget (might be Twinkle, but I'm not sure), on enwiki. If the page runs out of horizontal space, that even includes the "Page history". Which distinction is relevant because…

  • I'm less certain that 'mark all...' would make sense as a tab - tabs are different views/modes, from which other actions can be taken, whereas this is a simple action directly.

…I was thinking of putting this "command" / "verb" into a dropdown menu with the other "verbs" above ("Edit", "Clear", "View"). In any case, I'm not picky, if I can get rid of these taking up space for actual watchlist contents, I don't care all that much where they're put.

  • Also not certain about putting the number of pages on the same level as the firstHeading (if that's what you're suggesting) - it's just not that important. It's basically just part of the general intro text, providing context.

Yes, but it's mostly unimportant information that really doesn't need to take up that much precious screen space. The number of times I have felt a need to know how many pages are on my watchlist (answer: too many. always.) is effectively zero.

  • Making the options a right float, while a good idea in principle, probably wouldn't work well in practice. It's too wide.

Yes, in the current layout. Is there any particular reason this can't be re-laid out as a vertical toolbox (think enwiki article infoboxes)? Or have the filtering option pop up when I press something, but be completely hidden by default? I don't think i've ever touched those check boxes or dropdowns on my main watclist, so all that space is utterly wasted. I'm sure some people use them, and on other special pages and logs (which, I believe, reuse that code) they make sense; but here they're just wasting space.

  • There's also an issue with watchlist notices, as used on some projects: where should those go?

Globalnotice, Geonotice, and friends? Why can't they just intrude above the watchlist as they do today? These only pop up intermittently and can be dismissed, so that's not a big deal (unless you're the kind of person that takes Geonotice as a personal affront). It's the 80% space wasted 100% of the time I object to, not the niggling details that together pop up much less than 20% of the time.

Xover added a comment.Apr 18 2017, 7:08 PM

Don't discount what's possible due to politics - the politics across the projects vary considerably, and Wikisource actually has this already: https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2015-07#New_Gadget. That may be a gadget, but there's definitely demand for this being properly implemented in the skins themselves.

Neat, I'd somehow missed that, but will go try it forthwith. Who do I bribe to get that gadget on enwiki?

But anyway, I wasn't even thinking of project politics: I'm guessing any universal and official way to hide the left sidebar will never make it through Wikimedia politics. Just imagine getting it through Legal, sanctioning hiding the trademarked project logos… :-)

Xover added a comment.May 20 2017, 8:25 AM

Ok, getting sufficiently annoyed with the status quo, and inspired by the Wikisource gadget, I hacked up a user script for enwiki to illustrate the point.

importScript( 'User:Xover/focus.js' );

(warning: quick hack, toy, for demo purposes only, may cause disorientation and nausea)

It will add a dingus in the top left corner of the viewport that acts as a toggle, showing or hiding "extraneous" page elements (vs. content).

Tested on an article ([[:w:Hamlet]]), it's Talk page, its page history, and on my watchlist; and, obviously, with Vector and a bunch of gadgets active. The effect on the watchlist is particularly telling. Imagine what an actually well designed and implemented version of this could be!

In any case, I strongly urge everyone involved with UI and visual design to take a look and reflect on the use of screen space for content vs. non-content. The current status quo is pretty ridiculous.

PS. If I get a round tuit I may switch the default for the script to hide extraneous elements, or implement some global (not per page) state or preference.