Also, if we decide to fix it - renaming filters should not create dupe names.

I'm not interested in creating a lot of filter editing apparatus, as some have requested, but this seems like a reasonable request, if it's easy.

@Mooeypoo and @Pginer-WMF , how hard would it be to do? The point is not so much to make sure people don't dupe names but to let them edit their filters without having to create a new one then remove the old. They could just save over the old. We'd need to inform them that that's what they are doing...

In T167640#3689291, @jmatazzoni wrote:

I'm not interested in creating a lot of filter editing apparatus, as some have requested, but this seems like a reasonable request, if it's easy.

@Mooeypoo and @Pginer-WMF , how hard would it be to do? The point is not so much to make sure people don't dupe names but to let them edit their filters without having to create a new one then remove the old. They could just save over the old. We'd need to inform them that that's what they are doing...

As @jmatazzoni says the key part is to communicate what is going on. I think this should be done in a way that (a) is clear, (b) does not interrupt the user and (c) it is not alarming.

I'd propose to detect whether the filter name exists, surface it in the process of creation in a way that the user is aware but not surfacing it as a mistake/error, and provide clarity on the outcome of their actions.

• When the user types "Vandalism" (assuming there is a filter with the same name), the user is communicated that "A filter exists with this name"
• The action changes from "Create filter" to "Update existing filter". This communicates that a new filter won't be created and the current one will be updated instead.
  • Even if the "Make this the default" option is marked, the text label should be updated to be "Update existing filter".

This provides all the information to decide whether to replace the existing filter or adjust the mane to create a new one.

I've updated this task so the Description tracks Pau's designs above (with an added point or two). Roan and Matt say this should be possible and not that hard.

But in writing this up, I see now that the functionality has a flaw that makes the plan as described less useful than I'd hoped: namely, the user needs to remember exactly what the name was and type it in precisely. That's because the existing Saved Filters system is based around the idea that you can't save a filter set until it is a different filter set—an idea fundamentally antithetical to the idea of "updating."

I.e., right now, as soon as you alter a Saved Filter that you've loaded, the name of that filter disappears from the Active Filter area. Which means we can't prepopulate the name field when you save. This presents a number of problems, it seems to me:

1. The feature seems pretty hard to discover; I mean, why would you think to manually write in the old name? It's not a typical pattern.
2. Even if you wanted to try that, it's easy to make a typo or unwitting alteration.
3. Entering the name wrong is especially easy because once the user is in the Save dialog, she has no way to see what the old name was. She can't open the filter menu, and the old name is no longer displayed in the Active Filter area.
4. (And anyway, it's not possible to copy and paste the old name from the Active Filter Area even if you knew how this all worked.)

All of which leads me to suggest that the logical implication of our desire to let users "update" filter setting is this: We need to change the system so that once a user loads a Saved Filter, that filter is thought to be in effect until the user either hits Trashcan, loads a new filter or ends the session, no matter what alterations the user might make. I.e., if a user changes settings, we don't remove the current filter name from the Active Filter area.

With this change, the whole concept makes sense: I load a filter, make changes, and hit the bookmark. The filter name is prepopulated and I can update my settings. Without this change, I think what we have is a somewhat iffy, hidden feature.

So, two questions:

• Does anyone disagree that the suggested change is more logical?
• We agreed to do this feature because we judged it to be pretty easy. If we make the basic change I just suggested, does that make the whole feature a lot harder?

@Trizek-WMF? @Mooeypoo @Pginer-WMF? @Catrope?

In T167640#3728341, @jmatazzoni wrote:

So, two questions:

• Does anyone disagree that the suggested change is more logical?

I think both approaches are logical. They just came with their own set of benefits and complications. Overall I prefer the simplicity of the current approach compared to the new proposal.

The current model works like the bookmarks in the browser: once those are loaded, if you move away you are no longer affecting them in any way. This acts as a simple shortcut that leads you to your destination. Navigate away from that destination, and it is totally disconnected from the bookmark. The bookmark does not follow you.

The proposed approach requires to keep the state active after selecting a saved filter. That facilitates the update of filters, but it may lead to confusion (we need to distinguish the saved version from the temporarily modified one) which can lead users to override their filters accidentally. It also comes at the price of facilitating the update of existing filters over the creation of derived ones (e.g., I create "vandalism" and want to create a similar "vandalism by newcomers" that adds a couple of filters to the former but with the intention of keeping both), making it harder the process of creating a new similar filter.

I think we need to ask ourselves whether we want to provide a way to update existing filters or optimise for it. The main goal for the "saved filters" is to facilitate repeated use: users are going to spend more time using those filters than creating them. I don't think the update scenario is worth to be supported at the expense of making users to deal with the filter state as they manipulate the filters.

The original proposal in this ticket was not aimed at optimising for updating existing filters. It was intended to provide a more consistent result for those aiming to do so. Users can create new filters, an discard the old ones if those are no longer useful. For the case where it is obvious they want to create exactly the same filter, we provide a less surprising result than creating another filter with the same name.

• We agreed to do this feature because we judged it to be pretty easy. If we make the basic change I just suggested, does that make the whole feature a lot harder?

Engineers can evaluate the technical implications, but from the design perspective it changes the concept of what a saved filter is, and I'd be careful to make such a change in production for all users.

In T167640#3729119, @Pginer-WMF wrote:

...from the design perspective it changes the concept of what a saved filter is, and I'd be careful to make such a change in production for all users.

What i'd say about that is this: yes, precisely. In making the Saved Filters updatable, we are changing the concept. The current functionality is based on the premise that Saved Filters can't be updated. The thing you are viewing either is "My Filter X" or it is not. That's why we stop displaying the name when you change the settings. But if "My Filter X" is updatable, then something can still be "My Filter X" which isn't identical with the original definition. Just as "My Word Doc X" is still the same doc when I edit it. That's why I say the functionality I propose is more logical.

But logic isn't really the point. The real point is discoverability. To my mind, it's not worth the trouble to build a feature that can only be accessed if a user somehow intuits that if he enters manually the same exact name when saving (which he has to remember precisely, since it's not displayed anywhere), then it will be updated.

But actually, as we get into this, I'm starting to think the whole idea is not worth the trouble--even if we do make it more logical (by my definition). What percentage of RC or WL users do Saved Filters? Is it even 5%? And let's face it: it's not that hard to just save a new filter set and delete the old one. So we're talking about a feature that will make life a little bit easier for a small % of a small %...

In T167640#3729119, @Pginer-WMF wrote:

That facilitates the update of filters, but it may lead to confusion (we need to distinguish the saved version from the temporarily modified one) which can lead users to override their filters accidentally. It also comes at the price of facilitating the update of existing filters over the creation of derived ones (e.g., I create "vandalism" and want to create a similar "vandalism by newcomers" that adds a couple of filters to the former but with the intention of keeping both), making it harder the process of creating a new similar filter.

I didn't get into it, but the functionality I suggested requires that we create a flow more like the one you get with other programs when you try to save over a file. E.g., see the screenshot from Photoshop, below.

But as I say above, I'm getting disillusioned with this supposedly "easy" feature idea.

What about displaying already existing filters while typing?

We can assume that people already know the filters they have defined in the past. If a filter named "vandalism by newcomers" exists and the user wants to update it by typing "vandalism...", we can have a dropdown with:

New filter
Vandalism

Existing filters
Vandalism by newcomers

Was just burned by this today. At the very least, it would be nice to disable creation of two filters with the same name while we figure out what else the interface should do, because that's basically a bug.

We discussed in triage and we'd like to get to this in Q3. When we work on it, we'll first tackle the bug (prevent save with duplicate name) and then follow up with the feature (update existing filter).

We will work on this next quarter.