Move links at top of Recent Changes to a Quick Links menu
Closed, ResolvedPublic20 Story Points

Description

Currently, most Recent Changes pages display multiple rows of links at the top of the page, right below the page name and above the filtering tools. These links are defined by community members and vary considerably from wiki to wiki. As part of the New filters for edit review redesign of Recent Changes, this task proposes a way to manage these links so as to preserve and even improve their utility while displaying them in a manner that's more in keeping with their function on this page.

The problem

  • On many wikis, this bank of links has grown quite large. On Czech Wikipedia, for example, there are almost 90 links up there.
  • A substantial portion of the links are completely unrelated to the Recent Changes page or even to patrolling. Many collections have become bulletin boards or alternate navigation bars that promote destinations as disparate as Signpost, Wkivoyage, and the general Wikipedia FAQ.
  • And yet the links are right under the page title—arguably the most significant spot on a Web page—where they create confusion about what the page is and how it's used. At a minimum, they add noise and visual complexity to a page that's already complex and slated to gain a lot more new tools as we merge functions in from other review pages (like Watchlist).

Goals for a proposed solution

  • The links will continue to be readily available to users who find them useful.
  • They should be moved to a position that is easily accessible but appropriate to their secondary functionality on this page.
  • The selection and wording of links should continue to be editable and under the control of community members.
  • Given the large number of links, and the fact that most of those who do use them probably use only a small subset of those available, we can improve these users' experience by letting them promote their favorite links so that they become more easily accessible.

Proposed solutions

Solution #1: Quick links menu

  • The links will be moved to a "Quick links" menu, prominently placed at top-right of the page. In this way, the links will be readily available for use, but the page will be significantly de-cluttered.
  • The menu will be linear, with sub-groupings for the different categories. .
  • Contents of this menu will continue to be edited by the community, though possibly via a somewhat different mechanism from now.
  • A "favoriting" function will enable users to promote their favorites to a section near the top of the menu.
  • In addition to the community-defined links, the Quick Links menu will also display filter presets saved by individual users. In this way, users will have one location for all their most useful links.
  • Note: to adapt the current links for presentation in a linear menu may require the community to re-create them using a new methodology, as yet undefined. This could be an advantage, in that it will be an opportunity to evaluate whether it's desirable to bring all the links over.
  • The screenshots below show the elements of this solution. You can also experience it in this prototype. (Note that the prototype is a mockup only; some things work and some don't, and not all functions are fully developed.)

Solution #2: Quick links dropdown panel

  • This solution is the same as #1 with one exception: instead of being rearranged in a linear menu, the links are displayed inside a dropdown panel that preserves their current structure.
  • Contents of this menu will continue to be edited by the community, in the same manner as now.
  • This solution may be easier than #1 to implement, since it may be able to simply ingest the current HTML.
  • There are some, however, who will see this as a disadvantage, since communities will not have an incentive to slim down their link collections.
  • Obviously, there will also be no opportunity to create Favorites.
  • User defined filter presets will still be presented in a "Created by you" section (now displayed in two columns).
  • See illustrations below.

Solution #3: Collapsible panel

  • Related links would be placed within a collapsible panel, so that users could choose whether to view it or not.
  • The default would be collapsed, with a header reading something like "Useful Links."
  • User-defined filter presets will be in a separate Quick Links menu (which may be renamed "Saved settings").
  • This is the simplest solution to achieve technically and for communities.
  • The screenshots below show the collapsible panel (without the Quick links menu) currently in use on the Arabic Wikipedia

Related Objects

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 4 2017, 11:54 PM
Quiddity edited subscribers, added: Trizek-WMF; removed: Quiddity, Trizek.May 5 2017, 12:04 AM
jmatazzoni updated the task description. (Show Details)May 5 2017, 1:34 AM
jmatazzoni updated the task description. (Show Details)May 5 2017, 1:37 AM
jmatazzoni updated the task description. (Show Details)May 5 2017, 1:49 AM

The links will be moved to a "Quick links" menu, prominently placed at top-right of the page. In this way, the links will be readily available for use, but the page will be significantly de-cluttered.

I'm currently working on T164001: Explore the different quick links chosen by communities and displayed on Recentchangestext to see how they are set. Now, the menu is defined on Mediawiki:Recentchangestext, in where all the links are different from one wiki to another. Plus the links are formatted very differently on all wikis,using tables, lists or simple text with <br>s. "Move" them is almost impossible, unless if done manually.

I would advice to start a list from scratch in a new space, with the most expected links from the communities and put it in the Beta feature.

Contents of this menu will continue to be edited by the community, in the same manner as now.

We will have to advice communities to add only useful links, through a community consensus process.

As an intermediary step, we can consider adding the current template as part of the drop-down. The menu can include a few links that are usually part of the community tools, and show the whole template when the user clicks in "view all". Eventually, more links will be added as a proper part of the list and displaying the template may not be needed.

As mentioned above, this is just a temporary option in case we want to reduce the initial set of links shown by default in the page (and the potential confusion with the purpose of "quick links" menu) before going through a process of integrating each link properly in the menu.

It may be very strange if you have this template (or this one) used in the dropdown. :)

We can ask the communities what they prefer between having a menu with some links missing (but they can add them) and the whole list they have defined. I think it is possible to convince them to convert their local list to the new format. We can have a page on MediaWikiwiki to ask them for feedback.

Side note: a possible inspiration how to format the new page/template is MediaWiki:Sidebar. It is a way to have main titles and sub items, easy editable by users.

jmatazzoni updated the task description. (Show Details)May 5 2017, 9:29 PM

It may be very strange if you have this template (or this one) used in the dropdown. :)

Thanks for pointing to these examples @Trizek-WMF.
Czech Wikipedia case has a big volume of links. At 1024x768 resolution, the list of links is almost all you see when reaching Recent Changes.

@jmatazzoni asked how would those look in the menu, and I illustrated this in a couple of mockups:

Making the menu 2x wide still looks very crowded and scroll is needed:

Making the drop-down ~4x wide, it looks similar to what you get in the current situation but avoiding the links to push the filters and the list of recent changes down the page:

In T164548, @jmatazzoni wrote:

Solution #3: Collapsible panel

I explored a couple of possible executions for the "collapsible panel" option, as suggested by @jmatazzoni:

One option is to collapse the panel into a button and present it next to the "quick links" menu:

Another option is to show part of the content (crop the links at the height of 2 text lines) and provide an option to view the whole panel:

jmatazzoni updated the task description. (Show Details)May 8 2017, 9:32 PM
jmatazzoni updated the task description. (Show Details)May 9 2017, 8:51 PM
jmatazzoni updated the task description. (Show Details)May 9 2017, 8:53 PM

When presenting both user-defined and community-defined links int a single menu, they have different possible actions associated. This results into having a difference in appearance and operation. However, I tried to explore a way to make their behaviour more aligned, keeping their actions to the right side regardless of the type of element: elements with one action (community-defined links you can favourite/unfavorite) will show the action directly and those with more (user-defined items you can rename, delete and make default) will include the "more" ("...") menu in the same place. I illustrated the idea in a mockup below, showing items of all types with the menu collapsed and expanded:

@jmatazzoni, thoughts?

Trizek-WMF added a comment.EditedJun 7 2017, 8:49 AM

My recommandations after solving T164617: Get stats on how frequently RC Page related links (at page top) are clicked and T164001: Explore the different quick links chosen by communities and displayed on Recentchangestext:

  • We can ask the communities to remove the top-links based on our observations.
  • To compensate, we should create most wanted shortcuts as default bookmarks ("From the community"):
    • IP contributions
    • newcomers contributions
    • new pages
    • mobile contributions
    • FlaggedRevision / pending pages
  • Move links to other projects to the sidebar (like this)
  • All other links belong to other existing or to-be-created products:
    • community board (request for sysop role, last news from the community...)
    • user dashboards (link to last updates on VP, to AfD...)
jmatazzoni closed this task as Resolved.Jul 12 2017, 9:18 PM