Given that, I would think that the bookmarking/Saved Filters, and the ability to save one filter set as a Default that loads every time, would work well for you. What about that system that is a problem?
Well, as a feature set it more or less solves my case, although it forces me to jump through more hoops. The problem I have is with the interaction techniques used in the beta interface, which make my most frequent interactions much more cumbersome and less desirable than with the old interface. I've already explained my pain points in the previous posts, so I'll put them here in bullet points for reference:
- The saved filters/bookmarks are hidden behind a drop down control, so they require an extra click and scanning through a vertical list to find the filter I want to use. In the old interface, I can see all the common filters laid out in a horizontal table from the beginning, and I can activate any of them with just one click.
- The saved filters/bookmarks are hidden behind a drop down, so when the page finishes loading I can't see what filters are available; I need to start an interaction before the list of filters is shown. And there are three places where my desired filter may be hiding (Saved filters if it's a common one, search filters if it's not saved, "advanced" if it's a namespace), so I'm forced to remember which was the proper place to go and look for my common filter. In the old interface, I can instantly see whether my desired filter is there or not, without initiating any interaction.
- The Default filter is not enough. I want to change between four or five configurations quickly, not just one.
- The saved filters could work as long as I can force them to pile-up, combining two or more saved filters on the fly to create one configuration, just as I do now. In the beta, loading a saved filter replaces completely whatevdr filters are loaded in the current configuration, they can't be combined.
All these small paper cuts are mentally taxing and add up to an unpleasant experience for my most commonly used feature. This may be acceptable if you activate a filter or two every other day, but is too much grinding when activating a dozen or so of filter combinations in fast succession, several times a day, like I do.
An example of my routine could be, in a single session over the Watchlist:
-show only articles,
-show articles and their talk pages,
-show only Wikipedia pages,
-show Wikipedia pages and Wikipedia talk,
-show only Wikipedia talk,
-show Draft and Draft talk.
(If you couldn't follow all the above, I could record a short video of the routine for you).
But every day I may try them in any order, or create different combinations of these and other filters (at any step in the above routine, I could apply over the current filter: hide bots, hide minor edits, reverse the value of any filter...) I can do all the above in the current interface very fast, only with the mouse, with just one to three clicks per step, never reaching for the keyboard.
Every step might either add the new filter to the previous one - e.g. adding the "associated namespace", or remove the previous filter - first clearing all filters by re-entering the Watchlist.
Re. the interface, one thing you might not be factoring in is that a lot of new functionality has been added. This is the same interface (and toolset) as is being used on Recent Changes, for which it was primarily designed. But in time I think users will find a lot of it useful on Watchlist.
Oh, I don't doubt that, and of course I've been taking into account all the new functions (filters for problematic edits, applying color highlights, etc.). I'm not denying the utility of any of them; as I said above its great that you expand the possibilities of the tool, and I could put many of those features to good use. But the Recent changes doesn't include so many different namespaces, and it shows that the design was created for a simpler case.
Note that I'm not requesting that you remove any of the features in the new tool, so no need to be defensive; just make sure to also support what was possible in the old tool and it is still not included in the beta.
The old interface simply could not accommodate all the new functionality; it wouldn't scale. So a new paradigm was needed.
You're right about such need. But what I don't want in any way is that you take away the features and interactions that I use every day, dozens of times in a row, or that you make them slower and more cumbersome. A tool doing that could never be an improvement, no matter how many new features it provides.
More so when I HAVE SUGGESTED A POSSIBLE ADDITION THAT WOULD SUPPORT MY USE CASE IN THE NEW PARADIGM, and which is actually using the FEATURES THAT YOU HAVE ALREADY DEVELOPED, just adding a few new interactions to them. Just allow users to pin any filter to the screen, adding it to a quick launch pane ("Fast filters"?), where it can be activated with one click. This will go miles to help us, power users, to tweak the interface to our real needs. User-defined quick launchers are a true and tested classic interaction technique for adding flexibility to a tool.
After thinking about the problem a bit more, it wouldn't be enough to be able to pin the saved filters; I'd also need to pin any entry in the drop down list of filters and convert them into always-visible buttons. Pressing a pinned button should launch exactly the same command as selecting it from the drop down list; the fast filter would just remove the need to search for it in the drop downs every single time.