T50615 was not an improvement, has a doubtful use case and would have failed user testing had any been done.

I don't understand why another ticket has been raised when what is needed is to revert T50615 and then test alternatives if there is some sort of urgent need to change how watchlist pages function.

my previously descibed usecase,
pro old-style watchlist.

Change 255806 had a related patch set uploaded (by Florianschmidtwelzow):
SpecialWatchlist: Add an option to automatically reload the page when a filter was changed

https://gerrit.wikimedia.org/r/255806

The changes made to the options form decrease usability for numerous standard tasks, ie. increased number of clicks (for single option searches)

They also increase usability when changing multiple options, which now requires only a single page reload.

and removal of options (number of entries)

I don't understand this part. Care to elaborate?

No evidence for users' demand was given and enhanced functionality is not proven.

This is simply not true. Just look at the comments on T50615, both before and after the change.

That said, I accepted Florian's patch, which should be the best of both worlds. You could say that it's a tiny subset of T5658.

Change 255806 merged by jenkins-bot:
SpecialWatchlist: Add an option to automatically reload the page when a filter was changed

https://gerrit.wikimedia.org/r/255806

In T119322#1852483, @matmarex wrote:

The changes made to the options form decrease usability for numerous standard tasks, ie. increased number of clicks (for single option searches)

They also increase usability when changing multiple options, which now requires only a single page reload.

So to increase usability for one set of users you decrease it for another. Why?

and removal of options (number of entries)

I don't understand this part. Care to elaborate?

Compare Special:Watchlist and Special:RecentChanges, the latter has the follwoing format which allows one to choose the number of entries:
Show last 50 | 100 | 250 | 500 changes in last 1 | 3 | 7 | 14 | 30 days

I would argue, as have others, that this format is preferable to the one recently released for single option changes, useful especially to power users with large watchlists and often in RC patrol.

No evidence for users' demand was given and enhanced functionality is not proven.

This is simply not true. Just look at the comments on T50615, both before and after the change.

I have looked at the comments and see three users expressing vocal support to your proposed change in the two plus years since its creation and I see a number of users who have expressed doubts regarding the usefulness since inception who heavily rely on said features in the projects' maintenance. Where does that leave us? I realise that the software is not solely developed for power and maintenance users or WM projects for that matter, but these are the users who's input you should value most when deciding functionality in the content maintenance area.

---

That said, I accepted Florian's patch, which should be the best of both worlds. You could say that it's a tiny subset of T5658.

Does it get rid of the pull down menu(s) (I guess you plan on using it for RC and the options pointed out above) which unnecessarily increases number of clicks?

In T119322#1852745, @Millbart wrote:

No evidence for users' demand was given and enhanced functionality is not proven.

This is simply not true. Just look at the comments on T50615, both before and after the change.

I have looked at the comments and see three users expressing vocal support to your proposed change in the two plus years since its creation and I see a number of users who have expressed doubts regarding the usefulness since inception who heavily rely on said features in the projects' maintenance. Where does that leave us? I realise that the software is not solely developed for power and maintenance users or WM projects for that matter, but these are the users who's input you should value most when deciding functionality in the content maintenance area.

As far as I can see, there are users on both "sides", the positive and negative one. I don't judge, who is a "power" user, and who not, but I think, that all users uses the watchlist regulary, otherwise they wouldn't post there :)

That said, I accepted Florian's patch, which should be the best of both worlds. You could say that it's a tiny subset of T5658.

Does it get rid of the pull down menu(s) (I guess you plan on using it for RC and the options pointed out above) which unnecessarily increases number of clicks?

No, the (it's only one, not more, see the diff here, e.g. :)) dropdown is still there.

In T119322#1852745, @Millbart wrote:

In T119322#1852483, @matmarex wrote:

The changes made to the options form decrease usability for numerous standard tasks, ie. increased number of clicks (for single option searches)

They also increase usability when changing multiple options, which now requires only a single page reload.

So to increase usability for one set of users you decrease it for another. Why?

Because one of the two usability problems here is greater, and it's the one where you need to reload the page (potentially very large in case of power users) multiple times.

Compare Special:Watchlist and Special:RecentChanges, the latter has the follwoing format which allows one to choose the number of entries:
Show last 50 | 100 | 250 | 500 changes in last 1 | 3 | 7 | 14 | 30 days

I would argue, as have others, that this format is preferable to the one recently released for single option changes, useful especially to power users with large watchlists and often in RC patrol.

These options were never there for watchlist, only for recent changes. Here's how the two forms have always looked:

[...] pull down menu(s) [...] which unnecessarily increases number of clicks

Point taken, but even with the additional click, I believe dropdown menus offer a better user experience than multiple tiny links.

As an aside tip which you might find useful: depending on your browser and operating system, you might be able to choose an option from a dropdown menu with a single "click": click on the dropdown and hold the mouse button, move the mouse cursor over to the desired option, and then let go of the button. Firefox seems to support this on all operating systems, Chrome on Windows doesn't seem to; I don't know about other browser/OS combinations.