Page MenuHomePhabricator

Design: Determine approach to allow users to filter for events only on specific wikis
Closed, ResolvedPublic

Assigned To
Authored By
ifried
Mar 21 2025, 4:25 PM
Referenced Files
F58936480: image.png
Mar 28 2025, 5:35 PM
F58919498: image.png
Mar 25 2025, 7:16 PM
F58919544: image.png
Mar 25 2025, 7:16 PM
F58919398: image.png
Mar 25 2025, 7:16 PM
F58890758: Screenshot 2025-03-21 at 9.27.47 AM.png
Mar 21 2025, 4:30 PM

Description

User stories:

As a user of the Collaboration List on Special:AllEvents, I want to be able to find events that are only for specific wiki(s) (and not all wikis), so that I can find events that are most likely to be related to my wiki of interest.

As an editor who wants to add a transcluded version of the Collaboration List to a wiki page, I want to add events that are only for specific wiki(s) - rather than also 'all wikis' - since many events for 'all wikis' may not be of interest to the people who visit the page that I will be modifying, but they may be interested in events that are for the wiki that the page is on.

Background:

When an organizer configures registration for an event page, they have the option to state if the event is for all wikis, no wikis, or specific wikis. The 'all wikis' label is something we envisioned as a team, since some events do have a broad global call to action, and we imagined that organizers did want to signal that broad call to editors. This hunch turned out to be correct, and many organizers do indeed choose 'all wikis.' However, one problem with this is that, when someone goes on the Collaboration List and then looks for events for a specific wiki (such as 'English Wikipedia'), we show them events that are both specifically for English Wikipedia (because an organizer picked EN wiki as a target wiki) and for 'all wikis.' For some users, I think it is fun and useful to see the full extent of events that they can potentially participate in, as an English Wikipedian, even if some are not strictly for English Wikipedia. However, for other users, I think this is less helpful. They may just want to find events that specifically apply to a certain wiki. It may come down to personal preferences, interest in other wikis/communities, and experience level.

This is especially true for our current project in the works (T385347), which allows someone to transclude the Collaboration List onto a wiki page. The most common use cases we anticipate are people adding a version of the Collaboration List (perhaps filtered by specific topics and wikis) to: WikiProject pages, wiki homepages, affiliate pages, and event pages. In all of these cases, the person who transcludes the page may want to exclude the 'all wikis' events, since they may seem too broad-reaching to be applicable to a certain page or context.

For these reasons, we want to create an option to exclude 'all wikis' when someone is filtering for events by wiki on Special:AllEvents. In this way, the same search filter could be applied to the transcluded version of the Collaboration List on other pages.

Visual example of current state:

In this example, when the user searches for 'English Wikipedia,' an event comes up that is for 'All wikis.' For some users, they may be interested in the event. For others, they may wonder: Why am I seeing this event? It doesn't really seem like it is for strictly English Wikipedia. We should allow the first user to see the event, but we should allow the second user the option to filter out events such as these.

Screenshot 2025-03-21 at 9.27.47 AM.png (1×1 px, 184 KB)

Design

Design file

image.png (2×3 px, 776 KB)

Timeline:
  • First version shared in Design + Engineering meeting and 1:1 with Ilana on March 26
Acceptance Criteria:
  • Provide some design options/examples for how events for 'all wikis' can be excluded from 'Wikis' search results
  • Provide recommendation of which approach you think is best - and why

Event Timeline

ifried updated the task description. (Show Details)
ifried renamed this task from Design: Determine approach to allow users to filter for events only on target wikis to Design: Determine approach to allow users to filter for events only on specific wikis.Mar 21 2025, 4:35 PM
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
Idea 1: A selected by default checkbox labeled "Include events open to all wikis" below the Wikis filterIdea 1b: A selected by default toggle labeled "Include events open to all wikis" above the event listIdea 2: Add All events as option in the Wikis filter dropdown
image.png (872×1 px, 85 KB)
image.png (1×1 px, 138 KB)
image.png (1×1 px, 117 KB)

Idea 1A

  • A clear separation (but still shows the relationship) of the action of filtering by specific wikis from hiding or showing 'events open to all wikis'. Filtering out events open to all wikis is like a second level of filtering after you may have filtered by specific wikis.
  • Follows common UI pattern
  • Easy to find and understand

Idea 1B

  • Similar to 1A but too much emphasis is being placed on this control in this design
  • It is too separated from the Wikis filter

Idea 2

  • If this follows the same behaviour as other items in the dropdown then if checked by default, it would only show "open to all wikis" events. If unchecked, it would hide "open to all wikis" events. Neither matches the expected behavior of showing ALL events by default
  • It's confusing to have a filter for "open to all wikis" in the same place as wiki selection. The dropdown is for selecting specific wikis, adding a toggle for "open to all wikis" events mixes two different concepts/controls
  • This interaction will be confusing for users

Idea 1A seems to be the most straightforward and simplest solution for this cc @ifried @Daimona @MHorsey-WMF

Idea 1A seems to be the most straightforward and simplest solution for this cc @ifried @Daimona @MHorsey-WMF

I agree, it looks simple and easy to use. Also, I don't think we'd be able to implement 1b because the control is no part of the main form. Thanks for exploring these options!

This work is now done, since we have picked a solution (the first one) and created an implementation ticket based on it: T390621.