Page MenuHomePhabricator

Changes from T50615 to Special:Watchlist remove necessary options and decrease usability
Closed, ResolvedPublic

Subscribers
Tokens
"Dislike" token, awarded by Florian."Dislike" token, awarded by matej_suchanek."Dislike" token, awarded by He7d3r."Like" token, awarded by MGChecker."Like" token, awarded by Thgoiter.
Assigned To
Authored By
Millbart, Nov 22 2015

Description

The changes made to the options form decrease usability for numerous standard tasks, ie. increased number of clicks (for single option searches) and removal of options (number of entries) as described in the discussion following its rollout on T50615. No evidence for users' demand was given and enhanced functionality is not proven. Given that Special:RecentChanges and Special:NewPages are mentioned in the task, which are important tools in the projects' maintenance and will likely be affected in the future, a reevaluation of the situation seems appropriate.

Possible solutions would be to revert to the old behaviour or a preference option that allows users to chose between the old and new form. A combined form where the option text is a hyper link would also work, but might be confusing on touch screen interfaces.

Event Timeline

Millbart raised the priority of this task from to Needs Triage.
Millbart updated the task description. (Show Details)
Millbart added a project: MediaWiki-Watchlist.
Millbart added a subscriber: Millbart.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptNov 22 2015, 10:08 AM
Umherirrender set Security to None.
Ltrlg added a subscriber: Ltrlg.Nov 22 2015, 1:03 PM
He7d3r added a subscriber: He7d3r.Nov 22 2015, 3:54 PM
MGChecker added a subscriber: Luke081515.
MGChecker added a subscriber: MGChecker.
Fae added a subscriber: Fae.Nov 23 2015, 8:41 AM

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.

Arilou added a subscriber: Arilou.Nov 24 2015, 7:30 AM

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

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?

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.

Aklapper added a subscriber: Qgil.Dec 4 2015, 6:40 PM
Nemo_bis closed this task as Resolved.Dec 4 2015, 7:52 PM
Nemo_bis claimed this task.
Nemo_bis reassigned this task from Nemo_bis to Florian.

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.