As part of the new designs proposed for the Recent Changes page (T142785), users can highlight the results in the list of recent changes to better focus on specific aspects as they process the list (see the current prototype). It sometimes happens, however, that users want to highlight a quality that they don't necessarily want to filter for (especially because, when filters in different groups are selected, the system returns only the intersection of both) To get around this limitation, an "ignore filtering" button was added. This is a helpful option, but in early testing users experienced a number of difficulties, some of which are described below. This task will explore solutions to these issues.
The problem
We want users to combine filters and highlights in useful ways, understanding the possibilities and when to apply each. We have identified issues at different levels:
- Problem #1: Discovery of the ways to combine filters and highlights Users make their filtering choices inside the filtering dropdown. When getting to the list of results, even if they realise they do not meet their expectations, it is not clear where to go to change that.
- Problem #2: Understanding the need for controlling filter behaviour The concept of "ignore filtering and just highlight" is an unusual one which makes it hard for users to figure out that is what they need in the corresponding scenarios.
- Problem #3: Provide enough flexibility The interaction of filtering and highlighting can be complex, with numerous opportunities for users to get results that they weren't intending. In some cases users want highlights to be considered when filtering while it is not desirable for other contexts as illustrated in the scenarios below.
Example scenarios
- Scenario #1: Reviewing damaging contributions with special interest on newcomers A vandal fighter is interested in reviewing all potential edits that are "likely to have problems". She is interested in noticing which of those are from "newcomers" to review them with extra care (e.g., point them to the Teahouse). The expected result is to view only the "likely to have problems" but highlighting some of these in blue when they are contributed by "newcomers". Applying filters for both aspects would be problematic: it would lead to just the small set of damaging edits by newcomers (showing all of them highlighted in blue), which is not what the user is interested in.
- Scenario #2: Reviewing damaging contributions with special interest on new articles A vandal fighter is interested in reviewing edits that are "likely to have problems" of the default types: Content edits and New page creation (i.e., not including Wikidata or changes in page categories). She is interested in noticing new page creations (but still wants to go through regular edits). The expected result is to view only the "likely to have problems" edits that either change content or create new pages (showing the later highlighted in green). Ignoring the application of filters for highlight would be problematic: if "page creation" is not considered for filtering only "content edits" is shown, which is not what the user is interested in.
Design goals
- Clarity. Making more explicit the effects of user actions may help to reduce the gap between the actions and the intent.
- Simplicity. While providing support for more scenarios, we don't want to complicate the most simple ones where users may not even need highlighting at all.
Solution explored #1
This approach provides the highlight control for each item on the filter panel, once the user selects a highlight color. The first time the option is shown, an introductory tooltip provides additional details.
The new option will allow to "skip filtering", and the default value will depend on whether other filters are selected in the same group:
- If there are no other filters in the same group, the new highlight won't filter. In these cases, filtering always would lead to all items being highlighted.
- If there are other filters being applied, highlighting will keep the filter active.
The two example scenarios are illustrated below:
Scenario #1: Reviewing damaging contributions with special interest on newcomers
Scenario #2: Reviewing damaging contributions with special interest on new articles
Solution explored #2
This approach provides a separate entry point to control highlighting. Filtering is provided as the main entry point but users can access highlight options when needed. The separate highlight menu surfaces the selected filters to make it easy to act on them when both filtering and highlight are needed; but provides access to other criteria for the cases where users just want to highlight.
The two example scenarios are illustrated below:
Scenario #1: Reviewing damaging contributions with special interest on newcomers
Scenario #2: Reviewing damaging contributions with special interest on new articles
Solution explored #3
This approach integrates highlight into the list of filters (to avoid duplication), but still provides the highlight access less prominent than regular filtering. Users enable the highlight layer only if they are interested in it and they can apply it independently of filters. The "highlight results" button allows also to quickly switch between showing the results highlighted or remove all highlights.
