Page MenuHomePhabricator

rev_deleted should use the history buttons to affect ranges of revisions on the history tab
Closed, ResolvedPublic

Description

Author: mike.lifeguard+bugs

Description:
Instead of requiring users to do whatever to each revision individually (courtesy of the clunky user interface), the radio buttons should be used for affecting ranges of revisions. That's what they're there for already, this is simply using an existing UI element for a new purpose. This would require adding such functionality to the backend, if it doesn't exist already (affecting ranges of of revisions instead of one at a time), and adding a button to go to Special:RevisionDelete.


Version: 1.14.x
Severity: normal

Details

Reference
bz16607

Event Timeline

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

It should use checkboxes, rather than radio buttons. Radio buttons supports only 1 choice.

mike.lifeguard+bugs wrote:

(In reply to comment #1)

It should use checkboxes, rather than radio buttons. Radio buttons supports
only 1 choice.

Except there is already UI for doing one revision at a time. I suppose it's still ugly for multiple revs that aren't together. However the need for affecting multiple non-contiguous revisions is going to pose big problems, but the need to affect multiple contiguous revisions /is/ a problem, for which this is a solution. Using the radio buttons which are already present on the history form is nice and clean, and supports a common use case using a pre-existing UI element.

If there is a demonstrable need for affecting multiple non-contiguous revisions in a manner not adequately supported by the existing UI, then perhaps you should open a bug requesting an interface like Special:Undelete which lists revisions with checkboxes (dunno how paging might be affected there) - repurposing the history form for that is a bad idea (and I don't know that it is needed in any case).

mike.lifeguard+bugs wrote:

However the need for
affecting multiple non-contiguous revisions is going to pose big problems, but

*isn't* going to pose big problems

FT2.wiki wrote:

Replacing the
"Compare selected versions"
button by
"Compare or Show/hide selected versions"
would do the job neatly

mike.lifeguard+bugs wrote:

(In reply to comment #4)

Replacing the
"Compare selected versions"
button by
"Compare or Show/hide selected versions"
would do the job neatly

No, you want two different buttons. One for the diff, one for show/hide selected range. (and another for visual diff if it's enabled)

FT2.wiki wrote:

I was thinking links rather than buttons. Same thing in the end though.

mike.lifeguard+bugs wrote:

(In reply to comment #6)

I was thinking links rather than buttons. Same thing in the end though.

Yes, see bug 16165. Buttons in this context are horrid for usability.

Note that the whole history page is already a big form for diffs, so it's not easy to *also* make it work for checking revision for RevisionDelete.

It would be easier to make some sort of JS checkboxes that build up a link though...

mike.lifeguard+bugs wrote:

(In reply to comment #8)

Note that the whole history page is already a big form for diffs, so it's not
easy to *also* make it work for checking revision for RevisionDelete.

It would be easier to make some sort of JS checkboxes that build up a link
though...

That'd be nice & could work for log hiding too, I imagine. That'd be really useful, instead of having "hid content for 1 event" tons of times, we could do it in batches.