Page MenuHomePhabricator

Enable the user to hide (or show) the timestamps on the left
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):

A setting to enable the user to hide (or show) the timestamps on the left

There could also be a setting to instead have one header per day but that would be a separate issue and slightly more difficult to implement than making the timestamps removable.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Here is a comparison between the Wikipedia Watchlist enhanced with a button, "since last seen", via a gadget and the Global Watchlist to illustrate the usefulness and how the problem was discovered:

GlobalWatchlistAdded button
globalwatchlist.png (1×861 px, 286 KB)
workingwatchlist.png (942×882 px, 216 KB)
globalwatchlist2.png (3×890 px, 768 KB)
< this screenshot makes it clearer (the panel being visible in the middle of the page was a bug of the Firefox screenshot-taker, it wasn't actually visible there. It shows the configured settings so it may be useful.)

Users may want to remove or be able to remove the timestamps to make the watchlist less cluttered, easier to glance over, clearer and more minimal. Always on the utmost left there would be the title of the page in an organized, well-looking way. Users may want to adjust the watchlist to look more like the Wikipedia Watchlist they're used to which doesn't have these timestamps but a header per day.

Benefits (why should this be implemented?):

The Watchlist displays lots of info and in the future even more info could be added to it. Some may want to keep it minimal and the timestamps can clutter the watchlist, often without any clear benefit. It would be useful if there was a setting to have the timestamps hidden.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

You could probably write a patch for https://phabricator.wikimedia.org/diffusion/EGLW/browse/master/modules/SiteDisplay.js$67 (see https://www.mediawiki.org/wiki/Gerrit/Tutorial ) which adds an HTML class parameter for all timestamp entries, and after that change has been merged and deployed, you could add custom CSS (like display: none in order to hide timestamps) to your on-wiki Special:MyPage/common.css page.

Very useful info but I would disagree if you're saying that custom common.css would be a solution to this:
it should be configurable on the GlobalWatchlist page. Meaning somewhere at the top of the page you have a small gear icon where you can find settings where there is a tab, e.g. "UI", to customize the UI with a few, clear options, including a checkbox for "show timestamps". This option could use this css class or just hide the div the timestamp is contained in. Wasn't it decided that VueJs will be used in the future? In that case it would be even simpler to toggle this.

@Prototyperspective: And I'd be quite reluctant to add more and more code complexity and maintenance costs for years to come ("options") until there are clear and common use cases. "Some people prefer green to yellow" (or "Some prefer minimal, some not") is not a use case. Software development comes with a cost.

It's a clear and common use case. It's so simple and quick to just hide a div which is why even a relatively small advantage of this would make it worth. Once they have been hidden one could show day-headers, just like on the English Wikipedia. I'm not sure why it wasn't built like this in the first place: why put timestamps on the left without any option to change that instead of having a header per day (which people are used to, makes a lot of sense, and is the well-tested approach)?

Costs are a valid concern but I didn't say I think that this task would be high-priority plus just hiding them could be done in 5 minutes, adding options could potentially be done in an hour, depending on various factors...and of course I've always advocated for more efforts / decisions to also facilitate volunteer development alongside cost-associated development.

It is not a clear and common use case as there is no use case provided at all so far...