Page MenuHomePhabricator

Make flagging from difflinks for unsighted pages less error prone
Closed, ResolvedPublic

Description

Author: pbirken

Description:
In the discussion mentioned, several users report that when they look at a diff from an article that has no flagged revision, they sometimes flagged that as sighted by accident. I have had the same experience.

A solution would be to handle this case optically different from the one where a flagged revision exists, for example by adding a new class for this case and showing the box in a different color or maybe remove it alltogether for that case.


Version: unspecified
Severity: enhancement
URL: http://de.wikipedia.org/wiki/Hilfe_Diskussion:Gesichtete_und_gepr%C3%BCfte_Versionen#Darstellung_der_Box_zum_Markieren

Details

Reference
bz15249

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:19 PM
bzimport set Reference to bz15249.

I'm tempted to remove the box in those cases (not diff to stable)

Removing the box was a terrible idea; it makes flagging much more complicated and in many cases impossible (e. g. in cases where an article has no flagged revision and the user has carefully studied the version history and then decided to flag not the current but a previous version as stable - the UI now offers absolutely no hint how to achieve that).

A better (and in fact the only tolerable) solution would be to give a different ID to this box and then maybe have it as display:none per default CSS. But having the box is essential.

(In reply to comment #3)

Removing the box was a terrible idea; it makes flagging much more complicated
and in many cases impossible (e. g. in cases where an article has no flagged
revision and the user has carefully studied the version history and then
decided to flag not the current but a previous version as stable - the UI now
offers absolutely no hint how to achieve that).

A better (and in fact the only tolerable) solution would be to give a different
ID to this box and then maybe have it as display:none per default CSS. But
having the box is essential.

All one has to do is click that old revision (like one would do to edit it) and use the review form there.

(In reply to comment #4)

All one has to do is click that old revision (like one would do to edit it) and
use the review form there.

True, but it's still an additional click (I would assume that most people don't flag by looking at the text of a revision but by looking at diffs, because that's where you see what has been changed); it breaks the established workflow; it breaks tools (like this one: http://toolserver.org/~dab/jservlets/flaggedrevs/showunsighpages?twoYears=true&redirect=true ) etc.

In short, it makes flagging more difficult than it was before, and the problems cited by the recent changes people that have caused this change can be solved by the solution outlined (new ID + display:none per default) without breaking things for the flaggers.

Wouldn't display:none still require an extra click?

Why would the ID be different?

(In reply to comment #6)

Wouldn't display:none still require an extra click?

Nope, display:none would mean that the box isn't there for casual users but the people doing all the flagging work (i. e. on the 250,000 articles on dewiki that have no flagged revisions yet) could put a display:block for that ID in their own stylesheets.

(In reply to comment #7)

Why would the ID be different?

The discussion P. Birken referred too (and hence the only reason for this bugfix) was that people doing vandalism fighting could not distinguish between "new unflagged revision of an article with flagged revisions" and "new revision of an article w/o flagged revisions" and therefore would sometimes accidentally flag an article when in fact they just wanted to flag the diff. A different ID would solve that problem because those people would not see the box or could adjust their CSS to display it in a different color or whatever.

One could still say that the "UI now offers absolutely no hint" how to review pages in this cases. Editing CSS is even less obvious.

However, if this is what the patrollers want, then it can be easily done.

(In reply to comment #9)

One could still say that the "UI now offers absolutely no hint" how to review
pages in this cases. Editing CSS is even less obvious.

True, although it is obvious to the people whose complaints started this bugfix (AFAIK there are *no* people doing vandalism patrol on dewiki who *don't* use customized JS and CSS; they all know how to edit CSS; and the same probably holds true for the power flaggers).

As an aside: UI clutter is one thing frequently criticized about FlaggedRevs, but I don't think the problem will be solved in the long run by removing features that many people depend on. The better solution seems to be to have certain IDs hidden per default, without restricting the freedom of power users to make them visible if they need them.

However, if this is what the patrollers want, then it can be easily done.

Would be appreciated.