Page MenuHomePhabricator

Standardize system for indicating unseen/seen changes on Watchlist
Closed, ResolvedPublic

Description

On most wikis new, or "unseen", changes on Watchilist are indicated via boldfacing of the page title. But some wikis, notably English Wikipedia, have customized this system. The English Wikipedia community elected to institute a system that uses a blue dot in the left margin for seen changes and a bright green (3D) dot for unseen changes.

Now that Global Collaboration team is extending the New Filters for Edit Review UX to Watchlist, custom systems like the one on English Wikipedia pose a problem. Specifically, the New Filters UX displays colored dots in the left margin in combination with highlighting to help users understand what colors of highlighting have been applied to edits. Testing shows users find these dots very helpful, particularly when multiple colors have been applied to a particular edit.

After consulting with the community on the best way to resolve this inconsistency, we will be standardizing all wikis (including English) on the following system of indicators:

  • Boldfacing of the page title will be standard across all wikis for unseen changes.
  • A secondary indicator will be that the dots next to each result in the left margin will be, respectively, hollow or filled to indicate seen vs. unseen status. This has the advantage of being similar with the use of hollow/filled dots in Notifications to similarly indicate read vs. unread states. To be clear, filled dots = unseen; hollow = seen.
    • As on Recent Changes, when the "Highlight results" button is in the INACTIVE state: the bullets are displayed in the default (blue-green) color. (Unlike Recent Changes, the dots are hollow or filled to indicate seen/unseen.) See screenshot below.
    • When the "Highlight results" button is in the ACTIVE state: the filled/hollow dots are either shown in the highlight color or gray (See screenshot below):
      • 1) Dots for results that are highlighted are displayed in the relevant color (using the same set of dot colors as for Recent Changes).
      • 2) Dots for results that are not highlighted are shown in gray.

Using a secondary indicator of filled/hollow dots will enable wikis or individuals who dislike boldfacing to customize their display without sacrificing the useful distinction between unseen and seen changes. In addition, the new UX adds new seen/unseen filters, which will enable users to further make that distinction.

Highlight OffHighlighting on
WL-next-marked-no-high Copy 2.png (768×1 px, 236 KB)
WL-next-marked-high Copy 2.png (768×1 px, 239 KB)

Event Timeline

User testing and community feedback from English Wikipedia will give us the pulse for bold. If people are not happy, they can custom the interface.
I advice to move on and use bold. Bold is used on all wikis.

@Trizek-WMF, we have scheduled beta release for Sept. 5. Do you have any good feedback from en.wiki users about their preference? A couple of specific questions:

  1. Can we just go with Pau's proposal of filled/unfilled bullets and BF?
  2. I specified that the default settings for ALL wikis will be green highlighting for “unseen.” Good in that it teaches people about both highlighting and the new filter. Will it cause a problem?
  1. I specified that the default settings for ALL wikis will be green highlighting for “unseen.” Good in that it teaches people about both highlighting and the new filter. Will it cause a problem?

Given that bold was considered distracting in the past, I'd consider the use of highlight to be too prominent. Especially if the unread status is already signaled in other ways. For this kind of read/unread distinction (similar to the case of email clients and notifications) we want to make the users aware of the status if they want to but avoid create a sense of urgency to read everything by default.

@Trizek-WMF, we have scheduled beta release for Sept. 5. Do you have any good feedback from en.wiki users about their preference? A couple of specific questions:

  1. Can we just go with Pau's proposal of filled/unfilled bullets and BF?

Yes. Feedback received was in favor of consistency across wikis.

  1. I specified that the default settings for ALL wikis will be green highlighting for “unseen.” Good in that it teaches people about both highlighting and the new filter. Will it cause a problem?

I +1 Pau : let's have bold, that's enough for the moment. Add green will be like repaint the door of the bikeshed and will very probably raide up a lot of complaints.

jmatazzoni renamed this task from Make system for indicating 'seen changes' on en.wiki Watchlist compatible with New Filters highlighting to Standardize system for indicating seen/unseen changes on Watchlist.Aug 23 2017, 10:07 PM
jmatazzoni removed jmatazzoni as the assignee of this task.
jmatazzoni updated the task description. (Show Details)

@Pginer-WMF, in the illustration above, when no highlighting is applied, the default dot color appears to be a blue-green. This is probably the current color on WL for seen changes? In any case, I think this might be confusing when it's displayed in combination with blue and green highlight dots. Would it be a good idea, do you think, to spec out a more neutral color for the default dots? If you think so, please add the spec above where I've indicated, and update the graphics. Thanks

jmatazzoni renamed this task from Standardize system for indicating seen/unseen changes on Watchlist to Standardize system for indicating unseen/seen changes on Watchlist.Aug 23 2017, 10:15 PM
jmatazzoni updated the task description. (Show Details)
jmatazzoni updated the task description. (Show Details)
jmatazzoni added a subscriber: SBisson.

@Pginer-WMF, in the illustration above, when no highlighting is applied, the default dot color appears to be a blue-green. This is probably the current color on WL for seen changes? In any case, I think this might be confusing when it's displayed in combination with blue and green highlight dots. Would it be a good idea, do you think, to spec out a more neutral color for the default dots? If you think so, please add the spec above where I've indicated, and update the graphics. Thanks

The blue bullet points are the default in Mediawiki for lists in general and for lists of changes in particular (such as the Recent Changes page). Note that the default color for bullet points may be different on different skins.

The default color for bullet points can conflict with the highlight feature, but it is not a unique problem of the Watchlist. In Recent Changes what we did is to change the bullet point color when the highlight mode is enabled. That is:

  • With highlight mode off, all bullets are using the default blue.
  • With highlight mode on, bullets without a highlight use an empty circle in grey.

This allows to avoid the problem when it happens (in highlight mode) without having to make lists inconsistent with the rest or changing the style of all instances.

We can follow a similar approach in the Watchlist. We can keep the filled empty aspect to represent the visited/unvisited status, but show them in grey in any case when highlight mode is active. The image in the description does not seem to capture the idea properly It is better illustrated below:

Highlight OffHighlighting on
WL-next-marked-no-high Copy 2.png (768×1 px, 236 KB)
WL-next-marked-high Copy 2.png (768×1 px, 239 KB)

Change 373991 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Adjust highlight for seen/unseen states in Watchlist

https://gerrit.wikimedia.org/r/373991

Change 373991 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Adjust highlight for seen/unseen states in Watchlist

https://gerrit.wikimedia.org/r/373991

Checked in betalabs.

With new filters on Watchlist:

  • no Highlighting - the filled blue dot indicates the unseen change

Screen Shot 2017-08-28 at 12.52.26 PM.png (433×915 px, 100 KB)

  • no unseen changes

Screen Shot 2017-08-28 at 12.48.38 PM.png (378×860 px, 93 KB)

-Highlighting is applied - the UI shows it according to the spec

filled dots = unseen; hollow = seen.

Screen Shot 2017-08-28 at 12.47.09 PM.png (655×883 px, 179 KB)

Note: (minor) there is a "special" state on Recent changes page - when Highlighting is just clicked (no selection is made!). The click action makes all dots become empty. This is not happening on Watchlist with filters - clicking on Highlighting without making selection does not affect the state of the dots which is a correct behavior.

QA Recommendation: Resolve

@SBisson do we need to reopen this ticket?

Re-opening or creating a new and more specific ticket. I don't have a strong preference but there's definitely an aspect of this that has not been addressed: customization by the community to put the green dot instead of bold is still ON by default.

en.wp currently has all the watchlist features in dark more (?rcfilters=1) minus a few layout adjustments. You can see it in action already. Watchlist customization is controlled at "Preferences > Gadgets > Watchlist." The 2 last checkboxes control the green marker and bold respectively.

In T171235#3571873, @SBisson wrote:

You can see it in action already. Watchlist customization is controlled at "Preferences > Gadgets > Watchlist." The 2 last checkboxes control the green marker and bold respectively.

I investigated these gadgets and their current behavior. See my thoughts and questions about each in turn:

Green dot gadget

  • On en.wiki Watchlist today (with the Rcfilters=1), I do not see the green dots, with or without highlighting, with or without the gadget checked. Is that your understanding of what is going on now as well?
  • Assuming that is what is happening now, this is good. This is correct. What is the problem?
  • However, given that we have decided, with community consultation, to nullify the gadget, can we remove it from the Preferences list?

Boldfacing gadget

  • On en.wiki Watchlist today (with the Rcfilters=1), the boldfacing preference does work. Checking it adds boldfacing. Unchecking it takes away boldfacing.
  • As long as we've gotten rid of the green dots (as above) and instituted the hollow/filled dot system, then the BF is not an issue. People can still tell whether their pages are seen/unseen, with or without. (They can also use the seen/unseen filters, BTW.)
  • So, given that we've decided already, with community consultation, to reinstate boldfacing, it seems like the minimum intervention here is just to turn the gadget on for everyone by default (including people who've turned it off previously). That would add bf and have the added benefit of letting people who don't like bf to just use their preferences to opt out of it. Would that work?

@Trizek, @Mattflaschen-WMF, what do you think? Can we

  1. REMOVE the green dot preference (assuming I'm right that it has been nullified)?
  2. turn the bf preference ON by default?

Screen Shot 2017-08-31 at 5.05.49 PM.png (932×1 px, 298 KB)

I see the green dot when results are grouped by page. We seem to have nullified it for ungrouped. I guess we could try to do it for grouped as well.

Adding, removing or turning gadgets ON or OFF by default is done on https://en.wikipedia.org/wiki/MediaWiki:Gadgets-definition and seems to be based on requests and discussion on the talk page.

Our goal is to give the new design to users: bold and no dot. Can we change something in our work on watchlists to make them not compatible with the two gadgets? If so, will have to be sure not to have someone to make the gadgets "compatibles" and force green dots and normal font face to everyone. I'll include it to the deployment announcement.

Change gadgets default state or removing one of them without a community decision is not possible.

Can we change something in our work on watchlists to make them not compatible with the two gadgets?

We can, but we can't stop anyone from making it compatible again.

Also, don't forget that the gadgets control the appearance of the lines AND the message. So even if we prevent the line from showing the green dot, the text will still pretend unseen changes have a green dot.

Change gadgets default state or removing one of them without a community decision is not possible.

I see that there was a consultation as part of this ticket. Can it be used to change the default values of those gadgets?
Edit: I read the consultation at WPT and I'm confused. It's mostly trying to reconstruct the past or have a meta discussion about where rfcs should be (without a conclusion).
What do you make of it? Do we have the authority to change the defaults or not?

Can we change something in our work on watchlists to make them not compatible with the two gadgets?

We can, but we can't stop anyone from making it compatible again.

Sure. Keep the proposal we make as it is is a negotiation I'll have with the community.

Also, don't forget that the gadgets control the appearance of the lines AND the message. So even if we prevent the line from showing the green dot, the text will still pretend unseen changes have a green dot.

After a discussion with Stéphane about possible technical solutions, the only way to solve this is to have a conversation with the English community, to ask them to move the two gadgets from default to opt-in.
It is not a good idea to start this conversation with the community on a Friday, so I'll start it on Monday. It may postpone the Watchlist deployment on this wiki.

Change gadgets default state or removing one of them without a community decision is not possible.

I see that there was a consultation as part of this ticket. Can it be used to change the default values of those gadgets?
Edit: I read the consultation at WPT and I'm confused. It's mostly trying to reconstruct the past or have a meta discussion about where rfcs should be (without a conclusion).

Between the lines (that's the problem for most conversation that are apparently not decisions but are decisions - or vice-versa), the conversation allows us to make the proposal and implement a Beta feature with a new design. At that time I was not aware of the need to remove the gadgets.

What do you make of it? Do we have the authority to change the defaults or not?

Only after a consultation, unless if there is a security issue. We will be able to move if there is no feedback that develop a logically structured opposition.

Full list is at https://en.wikipedia.org/wiki/MediaWiki:Gadgets-definition#watchlist .

Also:

(There are also geonotice, geonotice-core, watchlist-notice, and watchlist-notice-core, all of which are de facto enabled by default, but I don't think they're relevant to seen).

To summarize the current state for future testing purposes:

Since there will be some adjustments to the indicating unseen/seen changes on Watchlist, I think that this task should be closed.