This looks good .Thanks @Pginer-WMF! I'll rework the ticket, adding this info to the Description, and move to RFP.

@jmatazzoni I have 2 questions about Related Changes, not about this task specifically but the answers will influence how I approach this work.

1. Do we expect Related Changes to graduate out of beta together with Recent Changes or do we want it to happen independently?
2. Are we supposed to show "Saved Queries" for Related Changes? If so, are they shared with Recent Changes or are they independent (like Watchlist)?

In T172161#3581096, @SBisson wrote:

1. Do we expect Related Changes to graduate out of beta together with Recent Changes or do we want it to happen independently?

In general we are seeing Related Changes as a flavor of RC page, so I'd expect it to graduate at the same time unless there is some blocker. We put the present task in Release Group 5, because it isn't a blocker for graduation, but we'd like to get it done pretty quickly after at latest.

2. Are we supposed to show "Saved Queries" for Related Changes? If so, are they shared with Recent Changes or are they independent (like Watchlist)?

As I say, we're seeing this as a flavor of RC page. With regard to "Saved filters," I'm content to go either way—either the same as RC page or distinct from it. Whichever is easier.

In T172161#3581349, @jmatazzoni wrote:

In general we are seeing Related Changes as a flavor of RC page, ...

That's very much like that in the code. So unless explicitly specified, what we do to Recent Changes affects Related Changes.

Do we want the 2 new filters (page name, to vs. from) to be included in the saved queries? Do we want them to be cleared by the trashcan button?

In T172161#3586348, @SBisson wrote:

Do we want the 2 new filters (page name, to vs. from) to be included in the saved queries? Do we want them to be cleared by the trashcan button?

Yes and yes. Thanks for asking.

Change 378103 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] [WIP] RCLFilters: convert related changes tool to new UX

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

Please see also T178870: Excessive white space in Related Changes

Change 378103 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: convert related changes tool to new UX

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

I had to compromise with the TitleSearch component that already exist so the image and description are not shown for the selected page (first screenshot below). They can be easily enabled for the suggestions (second screenshot below).

Change 378103 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: convert related changes tool to new UX

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

Change 395528 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: Show images and descriptions with page suggestions

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

Change 395528 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: Show images and descriptions with page suggestions

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

@jmatazzoni Besides the exclamation points markers on the ticket (they are indicators of what is not done), below are my comments on what may be improved on Related Changes

(1) The UI differs from mockup - the label "Show changes on pages linked from" is not bold (and has a colon at the end) , the down arrow button is placed far from the label, and there is some extra space underneath the label and the search box.

(2) Preferences-Recent Changes do not mention Related changes in "Hide the improved version of Recent Changes".

(3) The search/suggestion box (adopted from VE) has two defects that are fixed in the search/suggestion boxes used in Content Translation:

• enter search criteria and enter a white space - you'll see a fake duplicate suggestion, fixed in T178126
• enter search criteria that starts with a low case letter and you'll see the fake duplicate suggestion as it was described above. It does not happen with wikipedia search box (and not in Content Translation).

(4) If filters discarded via the trash bin icon, the selected page will be discarded. It's not a current behavior in wmf.10 - so, it's a regression? The selected page stays if the filters are discarded via 'X' icon.

(5) minor Related changes page does not have a link to the page to which related changes are displayed.

Previously it was displayed:

@SBisson, I'll summarize those of Elena's notes from above that I'd like to see addressed if they can be. if they can't be, please explain briefly and we'll decide which can be skipped.

The red exclamation point items:

1. New wording for the text at page top.
2. The page-entry box instruction text (when the box has no pagename in it)
3. The no-results message specific to Related Changes

Elena's other observations:

1. The UI differs from mockup - the label "Show changes on pages linked from" is not bold and has a colon at the end, the down arrow button is too far from the label, and the space between the label and the search box is too big.
2. If filters discarded via the trash bin icon, the selected page will be discarded. [And the converse is true: if a Saved Filter is selected, that also wipes out the pagename from the selector]

Meanwhile...
I assume this is what you are referring to above when you say you had to compromise on the title search element? If so, the solution you implemented is acceptable.

• Selecting a page replaces the selector with an element representing the article. This makes the selection more explicit. In this way, recent changes only need to be loaded when the user makes the selection and not as the user types in the previous step.
  • An "X" icon allows to undo the selection and go back to the previous step. See illustration below.

Change 395778 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: UI tweaks

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

In T172161#3814521, @jmatazzoni wrote:

@SBisson, I'll summarize those of Elena's notes from above that I'd like to see addressed if they can be. if they can't be, please explain briefly and we'll decide which can be skipped.

The red exclamation point items:

1. New wording for the text at page top.

Fixed in https://gerrit.wikimedia.org/r/395778 BUT this message can be customized per-wiki and is indeed customized on en.wp so changing it there would require someone with the right access (like @Catrope)

1. The page-entry box instruction text (when the box has no pagename in it)

Fixed in https://gerrit.wikimedia.org/r/395778

1. The no-results message specific to Related Changes

Fixed in https://gerrit.wikimedia.org/r/395778

Elena's other observations:

1. The UI differs from mockup - the label "Show changes on pages linked from" is not bold

Fixed in https://gerrit.wikimedia.org/r/395778

and has a colon at the end,

I thought the colon was part of the spec in this task description but I've removed it in https://gerrit.wikimedia.org/r/395778

the down arrow button is too far from the label, and the space between the label and the search box is too big.

I can't really comment on too big. This control is not a label but a dropdown without a border, that's what we have to work with in ooui. In the screenshot below, I've added a border to it to help understand its size and positioning. I'm happy to change it but making it a simple label with an independent popup menu is more work than reusing a dropdown widget.

1. If filters discarded via the trash bin icon, the selected page will be discarded. [And the converse is true: if a Saved Filter is selected, that also wipes out the pagename from the selector]

Both to/from and target page parameters are part of the Saved Queries and are therefore affected by the empty and restore defaults buttons. Per T172161#3586489

Meanwhile...
I assume this is what you are referring to above when you say you had to compromise on the title search element? If so, the solution you implemented is acceptable.

• Selecting a page replaces the selector with an element representing the article. This makes the selection more explicit. In this way, recent changes only need to be loaded when the user makes the selection and not as the user types in the previous step.
  • An "X" icon allows to undo the selection and go back to the previous step. See illustration below.

Yes, that's the main trade off. The existing TitleInputWidget with autocomplete shows only the text of the selected page. I think I've made the interaction easy to use by responding to the user clicking a result or tabbing or clicking out of the box but I agree it is not as nice visually. We can prioritize a follow up to make it nicer if needed.

Change 395778 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: UI tweaks

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

Change 395861 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: Make 'target' and 'to/from' sticky

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

In T172161#3816645, re. chaning the text at the top of the page, @SBisson wrote:

Fixed in https://gerrit.wikimedia.org/r/395778 BUT this message can be customized per-wiki and is indeed customized on en.wp so changing it there would require someone with the right access (like @Catrope)

Arghhh. I hate all these modifications! But we have to change the text, since it I'm pretty sure that saying Watchlisted items will be marked with a green bullet is incorrect. Right @Etonkovidova? They're marked with boldface, like everywhere else.

So what do we have to do here? Is it just a matter of overriding en.wiki? (@Catrope, can you help with that?). Or do we have to track down all the wikis where this type of modification was made? The desired text is:

• Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). Changes to pages on your Watchlist are in bold.

Change 395861 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: Make 'target' and 'to/from' sticky

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

In T172161#3818328, @jmatazzoni wrote:

In T172161#3816645, re. chaning the text at the top of the page, @SBisson wrote:

Fixed in https://gerrit.wikimedia.org/r/395778 BUT this message can be customized per-wiki and is indeed customized on en.wp so changing it there would require someone with the right access (like @Catrope)

Arghhh. I hate all these modifications! But we have to change the text, since it I'm pretty sure that saying Watchlisted items will be marked with a green bullet is incorrect. Right @Etonkovidova? They're marked with boldface, like everywhere else.

So what do we have to do here? Is it just a matter of overriding en.wiki? (@Catrope, can you help with that?). Or do we have to track down all the wikis where this type of modification was made? The desired text is:

I've fixed the mention of green bullets by updating enwiki's customized message. It now only shows that part if the green bullets thing is actually enabled (the message already tried to do this, but the way it did it was broken).

I then decided to just keep going and fully update the message. I've now put the new wording in and made the detection work for both the bolding thing and the green bullet thing. It now reads one of:

• "Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category)."
• "Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). Changes to pages on your Watchlist are shown in bold."
• "Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). Changes to pages on your Watchlist are shown with a green bullet."
• "Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). Changes to pages on your Watchlist are shown in bold with a green bullet."

Change 395899 had a related patch set uploaded (by Catrope; owner: Sbisson):
[mediawiki/core@wmf/1.31.0-wmf.11] RCLFilters: Make 'target' and 'to/from' sticky

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

Change 395899 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.11] RCLFilters: Make 'target' and 'to/from' sticky

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

Some comments about the "Show changes on pages linked from/to". I guess that the original proposal (F9140533) was modified to add more precision ("show changes in pages" as opposed to just "). I'm ok with that, but I think there is no need to apply that approach to both the selector and also the options. Links are bidirectional concepts, so just changing to and from may not help much users to intuitively understand what we actually mean, even if capital letters are used.

I'd propose to shorten the options and write them in a more natural way.

My proposal would be to have:

On the selector: Show changes on pages linked from / Show changes on pages linking to
On the options:

• Pages linked from the selected page
• Pages linking to the selected page

Notice how:

• Capital letters that are associated with shouting are not used.
• The "selected page" is used instead of "a page" to clarify which page we refer to with the options.
• "linking to" is preferred to "linked to" in order to clarify the directionality of such link.

I like Pau's proposal above. @jmatazzoni, thoughts ?

It's possible to normalize the name of the page in this box?

In the example should be "Categoria:Unità di misura SI di base".

In T172161#3836806, @Beta16 wrote:

It's possible to normalize the name of the page in this box?

In the example should be "Categoria:Unità di misura SI di base".

It's been reported (T182164) and fixed. It should be deployed to all wikis in 3 hours or so. Sorry about that.

In T172161#3823323, @SBisson wrote:

I like Pau's proposal above. @jmatazzoni, thoughts ?

Yes, thanks @Pginer-WMF . I like these suggestions as well—and will call our attention to the subtle refinement he's made in terms of differentiating between "linking to" and "linked from." I also like his clever use of bold to highlight the difference in options (without resulting to the overbearing all caps).

So, to be clear, it's like this:

[on the page--all boldface]
Show changes on pages linked from
Show changes on pages linking to

[in the menu--boldface as shown]
Pages linking to the selected page
Pages linked from the selected page

Change 398471 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: change working of 'to-and-from' selector

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

In T172161#3838801, @jmatazzoni wrote:

[on the page--all boldface]
Show changes on pages linked from
Show changes on pages linking to

[in the menu--boldface as shown]
Pages linking to the selected page
Pages linked from the selected page

Done in https://gerrit.wikimedia.org/r/398471 pending code review

Change 398471 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: change working of 'to-and-from' selector

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

Hi @SBisson. We're very close, but the new entry box is an new element for us. And it still looks a little hinky. So, two questions about small tweaks:

1. I know that the space between the button text (on the page level) and the entry field is set to an extent by the height of the button. But it looks like there are about 7px between the bottom of the invisible button and the top of the entry field. Any chance you could the button right down on top of the entry field? Here's the reason I'm being finicky: currently the space between different items on this page is about 13px. When you combine the 7px of air between items with the space between the edge of the button and the button text, it looks like it's more than that 13px. Which makes it look as though the button text is a completely different item from the entry field—when in effect they are two parts of the "same" tool. So it would be more logical if they were grouped more closely together. Possible?
2. My second question is (and forgive me if we've already been through this), would it be possible to move the downward-facing carat to the left, closer to the button text?

If these can't be done, just say so and we'll just move on...

Thanks!
Joe

@jmatazzoni Many specs have been done and the marks (the green checkmark) have been updated.
The present look includes many changes - the title is bold and the wording is updated;

What's needs some additional consideration (the items that were already on my list)
(1) Right now on enwiki (wmf.12) we have a discrepancy in how RelatedChanges page display items on a Watchlist if the new filters are enabled or not.
Without enabling new filters the text mentions "green bullets" and the green bullets(along with the bolded titles) are, indeed, displayed.

With the new filters, the green bullets are gone:

Is this solution final? Are we going to keep that discrepancy, or we will remove the green bullets entirely? It's the same discrepancy situation for Watchlist with new filters and without. (On much smaller scale there is even a difference in naming those green filled dots: Wtachlist calls them a green marker and RelatedChanges call them a bullet. )

From my old comments:

(2) Preferences-Recent Changes do not mention Related changes in "Hide the improved version of Recent Changes".

It may be confusing for users to have the option for new filters on Recent Changes automatically enables new filters on RelatedChanges.

(4) If filters discarded via the trash bin icon, the selected page will be discarded. It's not a current behavior in wmf.10 - so, it's a regression? The selected page stays if the filters are discarded via 'X' icon.

I'd like to have an explicit approval from @Pginer-WMF on that. In Without new filters, the selected page won't be discarded with any selection of filters.

(5) (minor) Related changes page does not have a link to the page to which related changes are displayed.

I think it's important to retain as much functionality as possible from the previous working page, unless we have a good reason to discard it.

I'll take Elena's points above in turn.

Green bullets

I want to make sure I understand what's going on. (I tried to test, but the database is locked right now so I couldn't use Watchlist). Anyway, if I understand your remarks, then this is the status quo:

• Green bullets appear only if the user does not have the New Filters.
• Green bullets are mentioned only if the user does not have the New Filters.
• New Filters users get boldface and the text mentions boldface.

Is that correct? If so, that seems acceptable.

Related changes

It may be confusing for users to have the option for new filters on Recent Changes automatically enables new filters on RelatedChanges.

We have in general treated Related Changes as a different flavor of Recent Changes. There's some ambiguity there, but I think we should be consistent and just leave it out here as well.

Trashcan erases related page from field

If filters discarded via the trash bin icon, the selected page will be discarded.

The Trashcan should, IMHO, erase everything except # of days and # to search. If you'd like to consult @Pginer-WMF on that, I am happy to hear from him.

Link to related page

Related changes page does not have a link to the page to which related changes are displayed.

OK, I see the link now. I'm fine with including a link. I don't want to put it where it was before, since it will just push the content down again. @Pginer-WMF should find a place for a link that, in the past, looked like this: ← Category:Living people (The space to the right of the entry box seems very related--and empty.)

In T172161#3846695, @jmatazzoni wrote:

Hi @SBisson. We're very close, but the new entry box is an new element for us. And it still looks a little hinky. So, two questions about small tweaks:

1. I know that the space between the button text (on the page level) and the entry field is set to an extent by the height of the button. But it looks like there are about 7px between the bottom of the invisible button and the top of the entry field. Any chance you could the button right down on top of the entry field? Here's the reason I'm being finicky: currently the space between different items on this page is about 13px. When you combine the 7px of air between items with the space between the edge of the button and the button text, it looks like it's more than that 13px. Which makes it look as though the button text is a completely different item from the entry field—when in effect they are two parts of the "same" tool. So it would be more logical if they were grouped more closely together. Possible?

This control is actually a dropdown that we have made borderless but it still shows a border when selected (for accessibility purposes, I think). See screenshot below.

When the border is there, I think size and position look right.

1. My second question is (and forgive me if we've already been through this), would it be possible to move the downward-facing carat to the left, closer to the button text?

Probably a bug in OOUI: If I don't make it explicitly wider, the dropdown is too narrow and doesn't adjust to the size of its content.

If these can't be done, just say so and we'll just move on...

My suggestion is to remove the border and background customization and let it look like a dropdown.

Thanks!
Joe

In T172161#3847690, @SBisson wrote:

My suggestion is to remove the border and background customization and let it look like a dropdown.

I agree. I would also advice to have the field with the page name on the right, floated with the dropdown. That would permit something like

Show changes on pages linked from : v [page name]

In T172161#3847945, @Trizek-WMF wrote:

In T172161#3847690, @SBisson wrote:

My suggestion is to remove the border and background customization and let it look like a dropdown.

I agree. I would also advice to have the field with the page name on the right, floated with the dropdown. That would permit something like

Show changes on pages linked from : v [page name]

I think there are two valid metaphors that we can follow:

• a) Make the dropdown act as an actionable label for the input field. The dropdown appears on top of the input field describing it. No borders are used to make it align with the label appearance, but the chevron is preserved to communicate that you can adjust it.
• b) Make a combined selection, where the user picks one option in the drop-down that affects the effect of the input field.

I was originally proposing (a), but I'm ok to go with (b) if it is preferred considering the technical effort. In case we go with (b), I'd recommend to place the selector and the input next to each other as @Trizek-WMF suggested.

In T172161#3846767, @jmatazzoni wrote:

Trashcan erases related page from field

If filters discarded via the trash bin icon, the selected page will be discarded.

The Trashcan should, IMHO, erase everything except # of days and # to search. If you'd like to consult @Pginer-WMF on that, I am happy to hear from him.

The trash can is inside the Active filters area and that is the scope of the items it should clean up. That is, filters and highlights. The selected page here should not be affected by the trash can. Users selecting one page, should be able to explore by adjusting the filters, clearing them and applying saved filters without the page of interest to go away. Those interested in changing the page of interest, they have a clear path to do so.

In T172161#3848001, @Pginer-WMF wrote:

• b) Make a combined selection, where the user picks one option in the drop-down that affects the effect of the input field.

I was originally proposing (a), but I'm ok to go with (b) if it is preferred considering the technical effort. In case we go with (b), I'd recommend to place the selector and the input next to each other as @Trizek-WMF suggested.

I illustrated how the approach (b) could work below:

If we follow that route I'd recommend the following adjustments:

• Make both components (drop-down and input) to be connected to better communicate that they work together.
• Shorten the drop-down label from "Show changes on pages..." to just "Changes on pages...". The "Sow" part seems implicit and it is also not being fulfilled by the drop-down when presented as a component since acting on it does not show results immediately.

Although I applaud the impulse to save a vertical line, I see a number of issues with the side-by-side solution suggested above.

• Recall that we recently changed the width of the pagename entry box to 400 px. At that width, this solution won't fit on the iPad-size screen of the screenshots shown.
• I've never been fully happy with the discoverability of the from/to controls for this design, even before. But at least when the downward arrow faced down towards the entry box, it created a kind of connection between the two. Now I worry that users who don't know about the option to select "to" will see no reason to click on that button. (Some users are explorers and click on everything just to see what happens, others are not.)

Overall, I think we're working too hard here. Now that we're no longer doing some of the fancier functions that were originally specified for the page selector, I wonder if we couldn't return to an improved version of what was more or less here before. Radio buttons are the most common way to offer two mutually exclusive options. They fully expose the choices/functionality on offer. And the new standard widget brings a splash of color to the page's distinguishing feature. E.g., something like my rough design below. It feels to me like a clear and simple solution. @Pginer-WMF?

Also, while we're at it, I'd like to change the entry box text from "Select a page" to "Enter a page name (or category)"

In T172161#3858461, @jmatazzoni wrote:

Overall, I think we're working too hard here. Now that we're no longer doing some of the fancier functions that were originally specified for the page selector, I wonder if we couldn't return to an improved version of what was more or less here before. Radio buttons are the most common way to offer two mutually exclusive options. They fully expose the choices/functionality on offer. And the new standard widget brings a splash of color to the page's distinguishing feature. E.g., something like my rough design below. It feels to me like a clear and simple solution. @Pginer-WMF?

"From" and "to", unlike other contexts like giving directions or translation, are not intuitive concepts when talking about links. Users may want to use the "list of sovereign states" as a way to filter the changes that affect countries ("linked from" the list of states) or use "Saffron" to filter articles on recipes/history that mention it ("linking to" saffron). The main intention in the proposals (either a or b) is to make the concepts to read more intuitively.
Using a simple switch (e.g., a radio button) between to/from requires more thinking from the user to understand what is actually being selected.
In addition, embedding controls in the middle of a sentence is likely to create internationalisation issues since different languages place their words in a different order.

Also, while we're at it, I'd like to change the entry box text from "Select a page" to "Enter a page name (or category)"

Makes sense. Especially if this works for categories, it would be good to hint they can be used as a way of filtering.

In T172161#3860816, @Pginer-WMF wrote:

Using a simple switch (e.g., a radio button) between to/from requires more thinking from the user to understand what is actually being selected.
In addition, embedding controls in the middle of a sentence is likely to create internationalisation issues since different languages place their words in a different order.

I have the same analysis.

@jmatazzoni aside from a discussion on the ticket, the only thing that is missing is that the entry box still does not have the text you've suggested:

I'd like to change the entry box text from "Select a page" to "Enter a page name (or category)"

The text states: "Enter a page name"

Should we address it before closing the ticket?

Change 402326 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: reword target placeholder

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

Label now adjusted.

Change 402326 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: reword target placeholder

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

Checked the fix in betalabs - the text is corrected to "Enter a page name (or category)"

@jmatazzoni is the following is still part of this task?

An "X" icon allows to undo the selection and go back to the previous step.

In T172161#3879043, @Etonkovidova wrote:

@jmatazzoni is the following is still part of this task?

An "X" icon allows to undo the selection and go back to the previous step.

No. I assume this is no longer relevant due to the various changes Stephane had to make in the selection tool. So I crossed that requirement out in the Description.