@Pginer-WMF, please add design illustrations and specify whatever functionality I haven't (e.g., say how users open the panel). Once you've done this, ping me and I'll review the design. Thanks.

In T166919#3311909, @jmatazzoni wrote:

@Pginer-WMF, please add design illustrations and specify whatever functionality I haven't (e.g., say how users open the panel). Once you've done this, ping me and I'll review the design. Thanks.

@jmatazzoni I added mockups to illustrate the idea. I tried to present the entry point as a continuation to the page description (to avoid making it too prominent but still closer to the previous location), and focus it on the main purpose of accessing other reviewing tools.

Collapsed	Expanded

This prototype shows the panel in action.

Based on @jmatazzoni feedback, I added more clear cues to communicate expanding and collapsing the links, updating the prototype and the mockups in the ticket description and below:

Collapsed	Expanded

Is it possible to keep the panel open by setting a cookie? I have a user asking to keep the panel open for users who have open it.

In T166919#3404880, @Trizek-WMF wrote:

Is it possible to keep the panel open by setting a cookie? I have a user asking to keep the panel open for users who have open it.

The idea is to keep the open/closed status persistent per user. So a user that wants to keep it open will find it open after opening it the first time every single time the user gets to Recent Changes. This is what the following part of the spec tries to capture:

The panel will, however, remember whatever state the user leaves it in. So, for example, if a user opens the panel and then closes the browser, when she returns to the page, the panel will be open.

Which technical mechanism is used to keep the status persistent (a cookie, browser local storge, user preferences, etc.) I don't know.
Feel free to add details about the problem if it were a different issue than the one described, and about the use of a cookie as the preferred solution.

Change 368358 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Make 'related links' collapsible

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

In T166919#3480596, @Mooeypoo wrote:

To make this work quickly, I've used the same library that collapses the legend on the related links. It's not quite the same as the design, but it works the same as the legend -- and remembers its position from the session.

I'm on in iterating fast and keep improving if necessary while in beta, but I'm not sure how much this will differ from the intended design.
Can you share a screenshot to illustrate the expanded and collapsed status? That would help to understand if it diverges in a very significant way.

In T166919#3480673, @Pginer-WMF wrote:

In T166919#3480596, @Mooeypoo wrote:

To make this work quickly, I've used the same library that collapses the legend on the related links. It's not quite the same as the design, but it works the same as the legend -- and remembers its position from the session.

I'm on in iterating fast and keep improving if necessary while in beta, but I'm not sure how much this will differ from the intended design.
Can you share a screenshot to illustrate the expanded and collapsed status? That would help to understand if it diverges in a very significant way.

Nevermind. Through nerd-sniping and a bit of manipulation of the jQuery.makeCollapsible library, I think we made it pretty close to the design (while keeping to the existing library).

It's available on Beta, but here are screenshots:

By the way -- it is next to the 'saved filters' button rather than above it following @jmatazzoni asking for that, to save more space.

Change 368358 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Make 'related links' collapsible

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

In T166919#3483399, @Mooeypoo wrote:

Nevermind. Through nerd-sniping and a bit of manipulation of the jQuery.makeCollapsible library, I think we made it pretty close to the design (while keeping to the existing library).

It's available on Beta, but here are screenshots:

Looks good. I'd suggest removing the colon (":") from the label to avoid it clashing with the drop-down indicator and looking more like an action.

In T166919#3483401, @Mooeypoo wrote:

By the way -- it is next to the 'saved filters' button rather than above it following @jmatazzoni asking for that, to save more space.

When the panel is collapsed, it was intended to be shown next to the saved filters anyway. When the panel is expanded, whether we save space or not will depend on the window size and number of links. If having the saved filters below avoids the panel content to wrap, you may be saving space when showing the saved filters below as illustrated:

In any case, the applied approach seems ok to me (people in look for better use of space can collapse the links anyway).

I imagine the command to show/hide the panel as a link, not a button. Do you think it is relevant to remove the blue border and have the link and the arrow in the "default" blue used on all links?

@Trizek-WMF the blue border appears in some other cases of UI elements (i.e. Legend expand link).

All functionality is in place including

The panel will, however, remember whatever state the user leaves it in. So, for example, if a user opens the panel and then closes the browser, when she returns to the page, the panel will be open.

The following is not implemented:

The tooltip for the link and the arrow now reads: "Collapse the links menu."

QA Recommendation: Product should weigh in

@Etonkovidova wrote:

The following is not implemented:

The tooltip for the link and the arrow now reads: "Collapse the links menu."

@Mooeypoo, is there a reason we can't get the tooltips? Elena's note is slightly ambiguous: it's not clear whether we have the tooltip in the closed state (I don't see it). If we can get it only in one state, then it's more important to show the tooltip for the default, closed state: "Expand the links menu."

However, if we have to have the same tooltip in BOTH states for some reason, then go with this: "Expand or collapse the links menu." Moving this back to In Dev to take care of this.

In T166919#3491046, @Etonkovidova wrote:

@Trizek-WMF the blue border appears in some other cases of UI elements (i.e. Legend expand link).

Well, it is still disturbing. :/

The arrow is misaligned this morning on Beta wiki:

In T166919#3492150, @Trizek-WMF wrote:

In T166919#3491046, @Etonkovidova wrote:

@Trizek-WMF the blue border appears in some other cases of UI elements (i.e. Legend expand link).

Well, it is still disturbing. :/

The arrow is misaligned this morning on Beta wiki:

<<mutter mutter>> OOjs-UI release <<mutter mutter>>

I'll add the tooltips and take a look at the issue with the indicator.

However, about the colon (of all things) that's actually going to be tricky; the message also appears in the no-JS version, where it does not have a collapsible behavior. It's similar to the legend -- which also has a colon, but no indicator (it has a 'expand' / 'collapse' text instead).

In short, if I remove the colon, it will not appear in the noJS version either. Is that okay?

In T166919#3485772, @Trizek-WMF wrote:

I imagine the command to show/hide the panel as a link, not a button. Do you think it is relevant to remove the blue border and have the link and the arrow in the "default" blue used on all links?

The link isn't a link, it's a toggle button (and the blue is the same shade as default blue in OOUI and the design schema. I'm also not entirely sure the blue border (focus) should be kept, but it is the way all frameless buttons behave, consistently, right now.

So... I'm tagging @Volker_E and @Pginer-WMF on that one, since it's a standardized design issue.

In T166919#3492212, @Mooeypoo wrote:

In short, if I remove the colon, it will not appear in the noJS version either. Is that okay?

I think the message without the colon should work well enough as a label for the no-js version.

In T166919#3485772, @Trizek-WMF wrote:

The link isn't a link, it's a toggle button (and the blue is the same shade as default blue in OOUI and the design schema. I'm also not entirely sure the blue border (focus) should be kept, but it is the way all frameless buttons behave, consistently, right now.

So... I'm tagging @Volker_E and @Pginer-WMF on that one, since it's a standardized design issue.

In this particular case, I wonder if it makes sense to move the focus to the expanded elements. That is, clicking to expand moves the focus to the first link there (and as a side effect removes it from the button). @Volker_E
may know better if this is a legitimate approach or goes against the accessibility guidelines.

FYI, I've created T172250: Reconsider the blue border for buttons themed like links on focus/click to think about this issue in a more general perspective.

In T166919#3492306, @Pginer-WMF wrote:

In this particular case, I wonder if it makes sense to move the focus to the expanded elements. That is, clicking to expand moves the focus to the first link there (and as a side effect removes it from the button). @Volker_E
may know better if this is a legitimate approach or goes against the accessibility guidelines.

I can probably do that in JS for our use, but it would mean that if a user is using the keyboard to traverse the page, then if they hit tab, land on the expand link, and hit enter, the focus will move - which means that if they want to toggle, they'll have to tab through the entire page again to go back up (or tab backwards). You won't be able to toggle the box on and off if you just want to see what's in it, is my point, and I don't think that's a great behavior for this?

One aspect that makes the outline jarring is the lack of margin around it as shown in the previous image. Making sure the button has a 8px distance from the box lines may help.

Change 369812 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Adjust styling of 'other review tools' button

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

Change 369812 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Adjust styling of 'other review tools' button

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

Checked in betalabs - looks better now (the border is a little bit tight though) :

Btw, when the keyboard navigation is used, the outline is different.

The tooltips are still not done.

A tooltip for the link and the arrow reads: "Expand the links menu."
The tooltip for the link and the arrow now reads: "Collapse the links menu."

QA Recommendation: Resolve

@Mooeypoo @Pginer-WMF Thanks for removing the :. I was on the way to reaching out about this as well.

In T166919#3494051, @Mooeypoo wrote:

In T166919#3492306, @Pginer-WMF wrote:

In this particular case, I wonder if it makes sense to move the focus to the expanded elements. That is, clicking to expand moves the focus to the first link there (and as a side effect removes it from the button). @Volker_E
may know better if this is a legitimate approach or goes against the accessibility guidelines.

I can probably do that in JS for our use, but it would mean that if a user is using the keyboard to traverse the page, then if they hit tab, land on the expand link, and hit enter, the focus will move - which means that if they want to toggle, they'll have to tab through the entire page again to go back up (or tab backwards). You won't be able to toggle the box on and off if you just want to see what's in it, is my point, and I don't think that's a great behavior for this?

One aspect that makes the outline jarring is the lack of margin around it as shown in the previous image. Making sure the button has a 8px distance from the box lines may help.

It would be disadvantageous to change the elsewhere learnt behaviour to include the whole area into the focus from my point of view.
But there's another idea, I've been carrying along since I saw the corresponding article, that might (repeat, might!) help us with this solution. A new approach for focus styles, that only triggers focus border on keyboard interaction. I've filed T172578 for it.

Another minor nitpick: I find it disturbing that the clicked link jumps by the non-existing and then switched on border of .mw-recentchanges-toplinks.