Page MenuHomePhabricator

Put community-defined 'related links' into a collapsible panel
Closed, ResolvedPublic

Description

On many Recent Changes Pages, the community has defined a large number of links that display directly under the page name (e.g., Polish). Many of these links are unrelated or only peripherally related to Recent Changes. The bulk of them are used only rarely or never, research shows (T166623 and this document, which collects results from the ticket just cited). To reduce the informational complexity of the RC page and clarify its functionality — while recognizing that these links are useful to some users—we will put the links into a collapsible panel.

Functionality

  • The panel will continue to display the links and other functions more or less as they are laid out now (except inside a box).
  • Community members will continue to be able to create and manage links as they do now.
  • The default panel state will be closed.
  • 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.

Interface / UX

  • In the default, closed state, a link at the top of the reads: Other review tools [down arrow]
  • A tooltip for the link and the arrow reads: "Expand the links menu."
  • Clicking the link expands the panel; the link stays where it is, but the link arrow now points up.
  • The tooltip for the link and the arrow now reads: "Collapse the links menu."

Mockups

CollapsedExpanded

Event Timeline

@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.

Pginer-WMF updated the task description. (Show Details)Jun 7 2017, 3:16 PM
Pginer-WMF updated the task description. (Show Details)Jun 7 2017, 3:30 PM

@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.

CollapsedExpanded

This prototype shows the panel in action.

Pginer-WMF updated the task description. (Show Details)Jun 13 2017, 3:34 PM

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:

CollapsedExpanded
Pginer-WMF updated the task description. (Show Details)Jun 13 2017, 3:35 PM
Pginer-WMF updated the task description. (Show Details)Jun 16 2017, 7:58 AM

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.

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

Mooeypoo claimed this task.Jul 28 2017, 7:58 AM
Mooeypoo added a subscriber: Catrope.

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.
@Catrope, @Pginer-WMF, @jmatazzoni that works, or should I implement the exact design without the given library for ourselves?

Also, this will happen regardless of implementation -- we can't tell in advance if the legend is open or closed, so I made it invisible while we load. This makes it easier if it was collapsed, and doesn't matter if it wasn't (it just appears) but what it does do is that the content may "jump" a bit if there was a lot of content initially and it ended up being open. This would've happened too if we wouldn't have hidden it (it would've appeared, long, while we load) and then it collapsed. We can't really avoid it, but maybe we can think of ideas on how to make it less prominent?

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.

Mooeypoo added a comment.EditedJul 29 2017, 1:13 AM

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

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.

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.

@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:

@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?

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 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.

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.


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.

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 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.

Etonkovidova added a comment.EditedAug 4 2017, 9:15 PM

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

jmatazzoni closed this task as Resolved.Aug 4 2017, 9:41 PM

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

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.