Page MenuHomePhabricator

"Undo" and "rollback" should not both exist
Closed, DeclinedPublic


Author: ayg

Mockup of proposed interface

Currently we have two options, undo and rollback, that have nearly identical functionality but different names and slightly different functionality and different availability. The difference between them is not made clear to new users. The code paths are also entirely different, which results in unnecessary differences in functionality. Differences that I know of are

  1. Rollback works immediately, no intermediate confirmation page with diff.
  2. Rollback can be restricted and is by default.
  3. Rollback does not work on old edits.
  4. Rollback works on all consecutive edits by a user, always, whereas undo normally works on exactly one revision and can work on an arbitrary stretch of revisions if given the proper URL parameters.
  5. They're called something different.

(1) is the reason for (2), and those two should be the only difference between the two sets of functionality. (3) and (4) should be adapted to give rollback the same (superior) functionality as undo. (5) should be eliminated, preferably in favor of the more intuitive term "undo". Rollback could be called "quick undo". In the course of adding the flexibility of undo, it makes the most sense to adopt its URL scheme for rollback, perhaps with parameters such as quickundo{,after} instead of undo{,after}, or with an additional &quick=1 parameter.

I've attached a mockup for the proposed interface.

Version: unspecified
Severity: enhancement


undomockup-cropped.png (85×810 px, 11 KB)



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:48 PM
bzimport set Reference to bz10531.
bzimport added a subscriber: Unknown Object (MLST).

ssanbeg wrote:

I've always thought of them as fairly different, although I guess they could be converged; i.e. undo specified versions vs undo specified user's versions & normal vs "instant" undo.

A few minor points are that new users probably won't have access to rollback, so there shouldn't be confusion there, while blind sysops probably won't like to click, since they won't use a GUI, so "instant rollback" would look better there.

ayg wrote:

I meant to include some kind of button that would work like current rollback, too, in my mockup, but I forgot. "Revert the edits of the last user to edit this page" is potentially useful functionality. On the other hand, in most cases (where the last user to edit made only one edit) it's identical to just clicking the link corresponding to the particular edit. Either way the functionality would of course be maintained for reverse compatibility, so wikis could add a link to the top of the page if they liked.

Many new users to wikis outside of Wikimedia are sysops, because wikis are often created in the context of an existing organization, in which case more senior/privileged members of the organization may be sysops or sysop-equivalents. There's no excuse in any case for giving sysops non-intuitive interfaces, but it should be borne in mind that many sysops may be new to MediaWiki, and in fact may be the ones to decide whether or not to keep it on the basis of their experience with it.

They're both for different things - rollback to revert vandalism, and undo to undo the effects of a certain edit. One is a sledgehammer to be used in case of vandalism, another is a pair of tweezers to undo harmful effects of a good-faith edit.


ayg wrote:

If I had agreed with that, I wouldn't have filed the bug. Rollbacks are a shortcut to a specific case of undos, namely undoing a specific range of revisions in one click. They should be treated as such, not as a different phenomenon. There's no reason, for instance, that a sysop should have to go through all the extra clicks a normal user needs merely because someone's made a trivial edit since someone else's vandalism.

Generally speaking, you are correct Simterical. Rollbacks are a shortcut for sysops to do a set of undoes all in one click, thus to undo vandalism more rapidly. It is a useful feature, so it should be there. I see no benefit in renaming it, or changing the way it works.

thomas.dalton wrote:

I'd keep it as it is. The suggestion seems to be, basically, to remove Undo for admins - Undo is a very useful feature. It's not just a cut down version of Rollback, since it allows partial reverts.

ayg wrote:

(In reply to comment #6)

The suggestion seems to be, basically, to remove Undo for admins

No, it is not. The functionality of rollback and undo would both still exist more or less exactly as today. Please see the interface mockup (which is for an admin, but accidentally omits the current rollback button). The primary concern, however, is that there's no reason to have conceptually similar features with entirely different names and implementations. Giving them different names is a usability/interface problem, and giving them different implementations is a code hygiene problem. There is also no good reason I can see why sysops should be allowed to undo the top edits in one click, but not other edits.

Indeed a better idea is to keep the "revert" link as is, and just change the address of the link to what you said above (undo link with &quick=1 at the end). This way, the current users of MediaWiki won't feel any change in the interface, yet the code behind the two features will be the same. Surely, the &quick parameter should only work for sysops, to avoid abuse.

I don't think we should merge the undo and rollback code. Rollback is a simplified case of undo (since you're undoing one or more revisions from the top, you can just change the page's content to an earlier revision), and for that reason much more efficiently implemented.

thomas.dalton wrote:

That's an excellent point - rollback is not only quicker for the user, but probably quicker for the servers as well.

ssanbeg wrote:

If rollback is just a simplified undo, then merging the code would make undo faster in the simple case, as a side effect of making the code more manageable.

(In reply to comment #11)

If rollback is just a simplified undo, then merging the code would make undo
faster in the simple case, as a side effect of making the code more manageable.

Rollback is not just a simplified undo, it also behaves differently UI-wise: undo makes you check the diff and provide a summary, while rollback is just a one-click action. In the merged code, we'd have to differentiate between the two for that and other reasons (rollbacks are marked as minor, and include an option to mark the rollback and the edits rolled back as bot as well), which would result in crufty code.

Also, rollback is to revert edits by a single user. Undo can be done on any diff, even with revisions in the middle.

mike.lifeguard+bugs wrote:

WONTFIX AFAICT - we want both rollback and undo because they do different things (both of which should be do-able) and the diff of proposed changes is necessary for the use-case it covers