snakeeye45 wrote:

Well, making rollback a two-click process defeats its purpose and renders it redundant to undo. The problem, really is in the design of the watchlist. Since each entry is just a string of data of varying lengths, the rollback button can be anywhere on the horizontal axis, including right on top of article or other links, leading to the misclick.

Personally, I think a good solution would be to change the watchlist into a spreadsheet style and put the article, last editor, edit description and undo/rollback buttons in their own cells. Keep rollback right justified and away from the other links.

(In reply to comment #1)

Well, making rollback a two-click process defeats its purpose and renders it
redundant to undo. The problem, really is in the design of the watchlist.
Since each entry is just a string of data of varying lengths, the rollback
button can be anywhere on the horizontal axis, including right on top of
article or other links, leading to the misclick.

Well, it depends on the two-click implementation. Imagine a system where you click [rollback] and the link magically and instantly turns into [are you sure? click again to confirm] (i.e., no page reload). This workflow would be marginally more burdensome (requiring two clicks rather than one), but it wouldn't be as bad as undo.

Personally, I think a good solution would be to change the watchlist into a
spreadsheet style and put the article, last editor, edit description and
undo/rollback buttons in their own cells. Keep rollback right justified and
away from the other links.

Have you tried the "enhanced" watchlist (available via [[Special:Preferences#mw-prefsection-rc]] --> "Group changes by page in recent changes and watchlist (requires JavaScript)")? It may be a starting point for a redesign.

You can use user or site css to hide the link on the watchlist for you or all users of the wiki. Try:

.mw-special-Watchlist .mw-rollback-link {
display: none;
}

Please make the two clicks a option, because not all user will like. You can also write a easy javascript to reach this and make it as gadget.

Also the 2-click proposal may interfere with the ability to open the rollback link on a new tab with ctrl+click, or make it tedious when one needs to rollback a lot of edits (like more than 10 or so).

Another solution may be to "hide" them by default, and put a button to make them appear when clicked so they only appear when needed. This could be done as a gadget.

(In reply to comment #4)

Also the 2-click proposal may interfere with the ability to open the rollback
link on a new tab with ctrl+click, or make it tedious when one needs to
rollback a lot of edits (like more than 10 or so).

It won't if done right. It could still work as now for middle-clicking or for users using browser extensions to open multiple links at once.

I'm starting to like this idea; the ([rollback]) link expanding to (are you sure? [yes] [no]) should be pretty non-disruptive for power users while still preventing most of the accidental clicks. (And would be reasonably easy to implement – I think those links have a class one could hook to with JavaScript.)

(In reply to comment #4)

Also the 2-click proposal may interfere with the ability to open the rollback
link on a new tab with ctrl+click, or make it tedious when one needs to
rollback a lot of edits (like more than 10 or so).

Another solution may be to "hide" them by default, and put a button to make
them appear when clicked so they only appear when needed. This could be done
as a gadget.

(In reply to comment #5)

I'm starting to like this idea; the ([rollback]) link expanding to (are you
sure? [yes] [no]) should be pretty non-disruptive for power users while still
preventing most of the accidental clicks. (And would be reasonably easy to
implement – I think those links have a class one could hook to with
JavaScript.)

Someone could probably expand my solution on Bug 46412 and my new [[User:Technical 13/Scripts/NoThanks.js]] to make it so that [Rollback] (or any of the others) is grayed out until clicked on and then the second click would perform the action... I would be happy to work on that. I've been thinking of improving and modifying that code anyways and I could add multiple settings to allow for hiding/removal of rollback, block, thank, and undo links based on user settings...

Fresh discussion about this at Enwiki in this section, and 2 sections below:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=664746521#Yes.2FNo_toggle_for_Rollbacks

Note that Extension:Thanks now uses jquery.confirmable via https://gerrit.wikimedia.org/r/#/c/92315/ which specifically mentions "rollback" as a potential use.

One silly idea for rollback links might be requiring confirmation, but doing so with a short-term memory. Similar to thanks links, you would have a confirmation step for the first rollback link click, but for subsequent rollback link clicks within the next 10 minutes you would not need to re-confirm. (Maybe make this per-user/per-target?)

This approach has the potential to mitigate most accidental clicks of rollback links, but would still allow anti-vandalism patrollers to quickly use rollback.

In T49782#486689, @bzimport wrote:

snakeeye45 wrote:
Personally, I think a good solution would be to change the watchlist into a spreadsheet style and put the article, last editor, edit description and undo/rollback buttons in their own cells. Keep rollback right justified and away from the other links.

See also T121389: Should Special:Contributions be converted to a table (wasn't there a similar request for Watchlis and Recent Changes?).

The "Blocked By" tasks should be "blocked by this task" instead IMHO. We should think before attempting to fix anything, to not have to revert the fix as it happened with T88044

In T49782#486731, @Ciencia_Al_Poder wrote:

Another solution may be to "hide" them by default, and put a button to make them appear when clicked so they only appear when needed. This could be done as a gadget.

Not exactly that, but I have a similar user script: https://commons.wikimedia.org/wiki/User:Whym/lockrollback.js . It disables all rollback links when the page is loaded. When you clicks "Unlock rollbacks" in the side bar, the links will be enabled.

The rationale for the behavior is that, as an admin who deals with mass vandalisms less than once a week, I don't normally need rollback, but when I need it, I don't want to spend two clicks for each edit.

I absolutely need what @matmarex said.

To be known, now in it.wiki we are quite happy about this KISS gadget:
https://it.wikipedia.org/wiki/MediaWiki:Gadget-SureSureSure.js

I will describe what it does:

• first click: it asks for confirmations
• next click: it does the rollback
• next clicks in other rollback links in that page: they do the rollback

@MZMcBride Have you tried this simple solution? :) It disables the immediate rollback action but you have not to confirm every rollback action in the same page.

In T49782#3484023, @valerio.bozzolan wrote:

@MZMcBride Have you tried this solution? :)

I have not. Both T49782#2356029 and T49782#3174843 seem promising, though.

Change 90729 had a related patch set uploaded (by Martineznovo; owner: Bartosz Dziewoński):
[mediawiki/core@master] Inline confirmation for rollback links

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

I've gone ahead and merged the other 2 tasks that talk about requiring some sort of extra step in the rollback workflow as they all discuss the same problem and solution.

This wish is also currently on the German Community Technical Wishlist, although I can't find the correct phab ticket for the wish.

@Lea_WMDE @JStrodt_WMDE ?

Commenting so that this would not be lost: feedback round from WMDE proposal [1] shows that many rollbackers from different projects (although it wasn’t advertised everywhere, just on Meta) overwhelmingly reject having rollback confirmable by default.

Community consensus seems to be lacking for making a change like in a patch submitted above.

[1]: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Rollback/Feedback_round

In T49782#3799102, @Addshore wrote:

This wish is also currently on the German Community Technical Wishlist, although I can't find the correct phab ticket for the wish.

Yes, improving the rollback workflow is on the wishlist. However, we are still in the research phase (which is why there is no ticket for it yet). As @stjn pointed out, we did a feedback round for one solution proposal, but the research phase has not concluded yet.

In T49782#4210039, @Lea_WMDE wrote:

Yes, improving the rollback workflow is on the wishlist. However, we are still in the research phase (which is why there is no ticket for it yet). As @stjn pointed out, we did a feedback round for one solution proposal, but the research phase has not concluded yet.

... and the research phase has concluded - we now have a plan! Please see T199534. In short: There should be a confirmation, but it should definitely be opt-in on most wikis.
If you feel it makes sense, we can also merge the tickets.

Change 90729 abandoned by Bartosz Dziewoński:
Inline confirmation for rollback links

Reason:
Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/core/ /488048

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

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/488048/ got merged in T215020 which, if I understand the task description correctly, solved this issue.