Page MenuHomePhabricator

Design interface for displaying and filtering ORES Good-Faith and Damaging scores as well as New Users flag
Closed, ResolvedPublic

Description

Create a design that provides effective filtering and data display for the following capabilities, which will be added as beta features on the Recent Changes page: ORES good-faith and damaging tests, the new user flag. This task requires us to:

  • Research and devise a conceptual scheme that breaks raw ORES scores into a certain number of discrete, useful steps that help communicate predictive data to users in a way that is simple to understand and corresponds with users goals.
  • Design a visual system for clearly signifying all three new types of data singly and in combination with one another—and in combination with everything else that already exists on the RC page.
  • Design an interface that enables users to surface the data they’re interested in effectively and conveniently. This new filtering interface will apply in this first phase only to the new features above, but may well provide a new interaction pattern that we eventually extend to the rest of the RC page filters.

An important goal to explore in these designs is the ability to surface edits that meet specific criteria, either by means of sorting or filtering. When combined with other features, such as the Patrol flag, this will, among other things, enable users to generate on-the-fly backlogs.

Related Objects

StatusAssignedTask
Duplicate Qgil
Resolved Qgil
Resolved Qgil
OpenNone
ResolvedJohan
ResolvedTrizek-WMF
Resolved jmatazzoni
ResolvedDannyH
ResolvedDannyH
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedSBisson
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedSBisson
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedSBisson
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedPginer-WMF
Resolved jmatazzoni
Resolved jmatazzoni
OpenNone
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
DeclinedNone
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
Resolved Mattflaschen-WMF
Resolved jmatazzoni
ResolvedNone
InvalidNone
ResolvedSBisson
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedSBisson
ResolvedCatrope
Resolved jmatazzoni
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
Resolved jmatazzoni
ResolvedCatrope
ResolvedCatrope
ResolvedSBisson
ResolvedHalfak
ResolvedTrizek-WMF
Resolved jmatazzoni
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedPginer-WMF
Resolved jmatazzoni
DuplicateNone
ResolvedPginer-WMF
Resolved jmatazzoni
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
OpenPginer-WMF
ResolvedPginer-WMF
OpenPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedCatrope
ResolvedSBisson
ResolvedNone
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedCatrope
DuplicateNone
OpenNone
ResolvedTrizek-WMF
ResolvedTrizek-WMF

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 11 2016, 11:56 PM
This comment was removed by Pginer-WMF.

I captured some ideas to improve the filtering mechanism on Recent changes in the mockup below:

  • Looks good. What do you think the "Add filter" interaction should look like?

    One concern I have is that this will shake up a lot of people who have been using Special:RecentChanges. Do you think it would be crazy to allow a user to toggle between the filtering UIs?

    Looks good. What do you think the "Add filter" interaction should look like?

    The mockup includes several images to illustrate that (but Phabricator UI does not make that very clear). You can check this slide deck with a more detailed step-by-step walkthrough.

    I'll provide a more detailed spec in Phabricator if this seems a promising direction to go.

    One concern I have is that this will shake up a lot of people who have been using Special:RecentChanges. Do you think it would be crazy to allow a user to toggle between the filtering UIs?

    Given that Recent Changes is as popular as Batman, I'd consider exposing the changes as a beta feature so that users can gradually get used to it (and surface the cases where it does not work as expected).

    I also tried to restrict the changes only to the filtering system, avoiding changes in the list that users optimised their eyes to process. I really think that the current filtering model based on explicit "show X, hide Y" is not scalable and requires effort to even understand what is being filtered: you need to infer the status ("Wikidata itms hidden by default") from the action ("Show Wikidata"). So, I see no reason to keep the current approach as an alternative in the long term (especially if new kinds of filters are made available), but I'm open to hear reasons to do so during the beta stage.

    Thinking about it, the beta feature strategy seems good. We already do have "Enhanced RecentChanges", so there's already a toggle in preferences that substantially changes the UI. I'm not sure we should add a third mode there. I do like the Transition-From-Beta-Feature plan.

    hey @Pginer-WMF, we're working on an even more basic integration of "good-faith" into recent changes for MediaWiki-extensions-ORES. See T137966. Would you be able to spare some cycles to help us imagine a good way to signal good-faith and damaging independently? We're hoping to find something that would be easy to implement since we don't have much engineering time to dedicate to fixing the filters (as you have proposed here) on the Scoring-platform-team team.

    hey @Pginer-WMF, we're working on an even more basic integration of "good-faith" into recent changes for MediaWiki-extensions-ORES. See T137966. Would you be able to spare some cycles to help us imagine a good way to signal good-faith and damaging independently? We're hoping to find something that would be easy to implement since we don't have much engineering time to dedicate to fixing the filters (as you have proposed here) on the Scoring-platform-team team.

    I'd be happy to help. Even if we aim for a long-term integration of filters, it makes sense to define simpler initial steps. I'll share some possible directions below, but first wanted to share some of my assumptions during the exploration:

    • Filter vs. highlight. I think it makes sense to support both, (a) the ability for users to focus on a specific sub-set of contributions (e.g., supported by filtering), and (b) the ability of users to add an extra signal when processing a more general list of contributions (e.g., supported by highlighting some contributions without hiding the rest). While I think it makes sense to support both, I'm not sure on which of them should we prioritise, and a better understanding on how users process the list of contributions and use these layers of information would be helpful.
    • Support multiple criteria. Even if we want to start by supporting ORES-based criteria, our solution should be able to integrate additional criteria. This avoids one-off solutions that clutter the interface as more criteria will be added and encourages users to combine multiple criteria in a simple way to focus on the changes of their interest (e.g., damaging by newcomers made in good-faith by newcomers on rock music articles).
    • Changing significantly the way contributions are displayed is out of scope. Users are used to scanning the list of contributions. Experimenting on that area may require focused research on the different usecases supported by those listings. In the current exploration we are considering enhancing the information without deviating from the current text-based patterns used for the list.

    Considering the above I captured two different directions below. Let me know if they seem to work well for the scenarios you had in mind.

    Quality filter
    as an initial step towards the idea of unifying the different filters, we can start by providing a simpler quality filter.

    The selector can be a simple list and may provide aids to select options easily (auto-completion, adding multiple results as capsules/tags with options to remove them) or start as a simpler selector.

    This will support the filtering case, and further steps could add support for highlighting the selected criteria as well as integrating more filter options through the same entry point.

    Highlight controls
    An alternative is to start with highlighting. We can provide a control for users to indicate how the items in the list can be highlighted. The idea is to allow users to indicate which criteria to use for each of the possible features of list items that can be highlighted.


    In the example, users can decide how to highlight the whole row, the bullet next to it and the username of the author of the contribution. For each of these, users can select a criteria. Each criteria can highlight matching items in one or more colors (if the criteria requires highlighting different levels).
    For example, the user can decide to highlight rows for good-faith edits (shown as green rows in the example) and use the bullets to highlight the damaging ones (showing the most likely damaging edits in red and those probably damaging in orange, while the rest of bullets are de-emphasised in grey).

    jmatazzoni renamed this task from Create design for adding ORES good-faith data to Recent Changes to Design interface for displaying and filtering ORES Good-Faith and Damaging scores as well as New Users flag.Aug 30 2016, 5:00 PM
    jmatazzoni updated the task description. (Show Details)
    jmatazzoni updated the task description. (Show Details)

    @Pginer-WMF and @Halfak, I wanted to make sure you spotted that I'd collapsed a number of tickets that addressed this issue (listed immediately above) and rewritten the Description. I merged these partly because I made one dupe by accident and partly because this task got a little simpler when we decided to postpone contemplation, for the moment, of the special page we'd been talking about.

    So now this task is both broader and narrower: broader because it's about three features instead of just one. But narrower because we're just focusing on Special:Recent Changes.

    Also, we now have a better sense of the way forward for the RC page. Which is, from Monday's ERI meeting notes:

    Update filter design: adopt Pau’s proposal for improving RC Page filtering tools generally, but in an incremental way. Incremental, meaning we provide improved tools only for the ERI filters at first. Lots of advantages:

    • Because RC Page is a central tool and needs to be managed carefully, revamping the entire filtering system at once would require extensive design work and research.
    • By going incrementally we get good feedback to make a transition to an all-new system like the one Pau proposes.

    @Pginer-WMF, in meeting the other day we talked about the desirability of adding these changes to the Watchlist page and, probably, the Contributions page as well. There are two aspects to this:

    • Add the ORES data display
    • Add the filter panel.

    Does it make sense to make these pages part of your design process? Or should that be a separate task do you think? And possibly in a later phase?

    @Pginer-WMF, in meeting the other day we talked about the desirability of adding these changes to the Watchlist page and, probably, the Contributions page as well. There are two aspects to this:

    • Add the ORES data display
    • Add the filter panel.

    Does it make sense to make these pages part of your design process? Or should that be a separate task do you think? And possibly in a later phase?

    In general, I'd go one at a time. Although all these pages use asimilar filtering mechanisms and technically it may be easy to propagate the changes everywhere, they also support different usecases and they are used by different groups of people. Making sure we solve well the case of the recent Changes page first, and then move to the next place seems the right way to go in my opinion. The more focused and specific the ticket, the better.

    In terms of design, it is ok to move some steps ahead and explore how the system would work in those pages. But I'd consider having separate tickets to be able to decide when to focus on what.

    This prototype illustrates the idea of providing better filtering on the Recent Changes page. It is still in progress (notice pieces missing compared to the designs for the reference scenarios.

    jmatazzoni closed this task as Resolved.Nov 9 2016, 12:09 AM