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.
Description
Description
Details
Details
Related Objects
Related Objects
- Mentioned In
- T153389: "mark all as visited" appears temporarily grayed/disabled after a refresh following a watchlist reset
T153462: Implement an undo manager in MediaWiki - Mentioned Here
- T153389: "mark all as visited" appears temporarily grayed/disabled after a refresh following a watchlist reset
T150045: Add a confirmation button to "Mark all pages as visited" on the Watchlist, and update via ajax
Event Timeline
Comment Actions
This is T150045. Related discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical).
Comment Actions
Thirdoned. There are also a lot of such requests on dewiki (plus more on other pages).
Comment Actions
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... :)
Comment Actions
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
Comment Actions
Change 327684 had a related patch set uploaded (by Fomafix):
Don't show dialog to confirm whether to reset watchlist
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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?
Comment Actions
It is surprising when the change is to make more complicated a core workflow which was not broken.
Comment Actions
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
Comment Actions
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.
Comment Actions
Change 327684 merged by jenkins-bot:
Don't show dialog to confirm whether to reset watchlist
Comment Actions
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.)
Comment Actions
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
Comment Actions
"destructive operation" is quite exaggerated. There is nothing destructive in marking a watchlist as read.
Comment Actions
@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)?
Comment Actions
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? :/
Comment Actions
@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.
Comment Actions
Change 327751 had a related patch set uploaded (by Florianschmidtwelzow):
Don't show dialog to confirm whether to reset watchlist
Comment Actions
@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.
Comment Actions
Change 327751 merged by jenkins-bot:
Don't show dialog to confirm whether to reset watchlist
Comment Actions
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)
Comment Actions
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)