Page MenuHomePhabricator

Marking Watchlist visited requires confirmation
Closed, ResolvedPublic

Description

I am quite surprised that 1. this change was introduced without community approval; 2. it requires a confirmation (I don't see the need for that); 3. there is no way to deactivate confirmation.

Event Timeline

Yann created this task.Dec 16 2016, 11:43 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 16 2016, 11:43 AM
Krd added a subscriber: Krd.Dec 16 2016, 11:55 AM

Please revert this change globally. Totally unusable, complaints on all major wikis.

Please revert this change globally. Totally unusable, complaints on all major wikis.

Seconded.

Please revert this change globally. Totally unusable, complaints on all major wikis.

Seconded.

Thirdoned. There are also a lot of such requests on dewiki (plus more on other pages).

I'm surprised that someone expects "community approval" for software changes and I wonder what exactly this expectation is based on.

Feel free to describe how the change negatively influences your workflow.
"totally unusable" is not feedback that helps understanding, and "me too" comments don't help much either... :)

Italian Wikipedia users seemingly perceived the new confirmation steps as a storm of system warnings/system errors.
https://it.wikipedia.org/wiki/Wikipedia:Bar/Discussioni/Avvisi_di_sistema_aumentati_a_dismisura

Change 327684 had a related patch set uploaded (by Fomafix):
Don't show dialog to confirm whether to reset watchlist

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

It takes additional action for something that should be as easy as possible. Perhaps someone accidently presses the button but how often will this happen, once in a year? And for this once no one wants to confirm all the other times. It disrupts the workflow, it steals time and even an accidently pressed button isn't a catastrophe, the watchlist is still there.

Krd added a comment.EditedDec 16 2016, 1:38 PM

The button worked directly, without confirmation. The confirmation popup breaks workflow, breaks display on small screens, costs time, is annoying, is not needed.
Time and dedication to the projects are the values we have in volunteers. A tool that costs time and is annoying, for no benefit at all, is the worst case scenario, and I wonder how one could not see that before deployment, and I'm speechless that this has to be explained.

Negatively influences workflow: requires extra clicks to perform a task. IMO risk of accidental clicking is small and doesn't really damage anything. Those who had a problem with this already had a user script available which inserted a confirmation window.

Moreover, when the watchlist used to completely reload, that updated my notifications. Not sure if that happens any more on marking the watchlist as read?

I'm surprised that someone expects "community approval" for software changes and I wonder what exactly this expectation is based on.

It is surprising when the change is to make more complicated a core workflow which was not broken.

Urbanecm added a subscriber: Urbanecm.

Some users complains at cs.wikipedia too.

Urbanecm moved this task from Backlog to Watching on the User-Urbanecm board.Dec 16 2016, 2:40 PM
Thibaut120094 added a subscriber: Thibaut120094.EditedDec 16 2016, 2:48 PM

Users complains on fr.wikipedia too (well, like usual, but still...)

https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/16_d%C3%A9cembre_2016#Confirmation

Yann added a comment.Dec 16 2016, 2:48 PM

Krd and BethNaught explained it very well. I have nothing to add.

Generally, in software usability, there is a tendency to directly acknowledge when possible the destructive operations, and allow an undo.

So yes, we can improve the UI with an undo feature instead.

Meanwhile, ask the confirmation allows to avoid any operation you can't cancel.

Change 327684 merged by jenkins-bot:
Don't show dialog to confirm whether to reset watchlist

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

Krd added a comment.Dec 16 2016, 3:02 PM

Dereckson: There is no "meanwhile", the button worked directly since it was introduced, and this is a breaking change now.
(Side effects of accidental use, if there are any at all, are irrelevant as no actual data is deleted.)

Florian closed this task as Resolved.Dec 16 2016, 3:03 PM
Florian assigned this task to Sn1per.
Florian added a subscriber: Florian.

First of all: I merged the change, which removes the confirmation box, so the task is resolved. However, some words to the task itself:

this change was introduced without community approval

Like @Aklapper already wrote: Where does this expectation come from? We usually have hundreds of changes between two deployments of MediaWiki, some are community requests, some are, let's call it, "general" development. This means: We develope something we think is useful (and I privately prefer a confirmation box, too, however, I usually doesn't care, if there's no one).

Ontop of this changes, we improve the implementation, e.g. by recognizing, that a confirmation box isn't really needed and that users don't want it (this is the basic request of this task, I think), so we remove it. However, this doesn't mean, that we need (but probably want? ;)) an approval of the community for each change. Community input is always welcome and we request it at any place, however, the users of MediaWiki usually aren't really active (unfortunately) when we ask for feedback for changes that aren't merged already. Doing this would slow us down a lot :( That's not the best situation, but the situation we need to deal with.

And as a consequence this means (as we're just humans, too :P), that we sometimes merge things, which isn't the best idea from the user perspective. But this doesn't mean, we can't improve on top of it :-) So, instead of "freaking out" (some comments at least feels like that the person who wrotes it is freakin gout), I would love to see constructive input about what do you think about something and what you would love to see instead of it. Furthermore, I would love to see, that developers (and some of them are also "just" volunteers) would be counted as part of the community and not some outside people who tries to slow the community down (sometimes, at least for me, it feels like some community members of the editing community thinks that developers are the heart of all bad :().

Ok, now I really lost the focus, however, I just wanted to write this somewhere :P

Secondly: All changes goes to our beta cluster mostly 15 minutes after they got merged. So you're invited to, from time to time, go to the beta cluster and test the latest version of MediaWiki. If you find something, that isn't goog from your point of view, feel free to open a task. The beta cluster is our way of saying: Hey, we've build something and would love to read/hear your feedback about it. So, feel free to use it :P

Yann added a comment.Dec 16 2016, 3:04 PM

Generally, in software usability, there is a tendency to directly acknowledge when possible the destructive operations, and allow an undo.

"destructive operation" is quite exaggerated. There is nothing destructive in marking a watchlist as read.

Dereckson added a comment.EditedDec 16 2016, 3:11 PM

@Florian next deployment week is in January, I'm not sure it was worthwhile to merge the change right now, as it won't reach fr.wikipedia and en.wikipedia through the train before Thursday 5th. Or do you plan to cherry-pick it for wmf6 and ask a deployment a Friday (which could be a good idea to avoid 2 weeks of bug reporting, and in January new bug reports from users used to the feature who want it back)?

Florian added a subscriber: greg.Dec 16 2016, 3:55 PM

Ah, damn, I thought we've a deployment next week, but it turns out, we haven't :P So, the next planned date would be the 3rd of January. This isn't really an urgent task, in my opinion, so I'm not sure, if this qualifies for an unplanned deployment, what do you think @greg? :/

@greg I'd be in favour of a deployment now rather than in January with the following rationale: if we don't deploy this, we'll create a situation where the users will adapt their worfklow to use the confirm button, and will have to rollback to their old workflow 3 weeks later.

So, the task could be correctly asserted as urgent if we examine the effect of not deploying it: there would then be an abrupt UI change for some users twice, requiring two periods of adaptation.

Change 327751 had a related patch set uploaded (by Florianschmidtwelzow):
Don't show dialog to confirm whether to reset watchlist

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

Nenntmichruhigip added a comment.EditedDec 16 2016, 4:10 PM

@Florian see T150045#2880700 and (in german:) WD:NEU on dewiki for the issues I'm having with the change. Though I understand the reasoning (in theory, but not seeing much practical use for) that there should be some protection against accidential use and would quite like the AJAX reloading if it's faster, this feature really isn't ready for production use yet. It seems like the changes so far won't fix those (more severe) issues.

Ok, thanks all for the feedback. I'll deploy the revert now.

Thank you Legoktm!

Change 327751 merged by jenkins-bot:
Don't show dialog to confirm whether to reset watchlist

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

Stashbot added a subscriber: Stashbot.

Mentioned in SAL (#wikimedia-operations) [2016-12-16T16:35:36Z] <legoktm@tin> Synchronized php-1.29.0-wmf.6/resources/src/mediawiki.special/mediawiki.special.watchlist.js: Revert confirmation button and apply other fixes - T153389 T153438 (duration: 00m 39s)

Mentioned in SAL (#wikimedia-operations) [2016-12-16T16:36:34Z] <legoktm@tin> Synchronized php-1.29.0-wmf.6/resources/Resources.php: Revert confirmation button and apply other fixes - T153389 T153438 (duration: 00m 39s)

Restricted Application added a project: Growth-Team. · View Herald TranscriptOct 18 2018, 11:49 AM