On Sun, Jun 27, 2010 at 6:59 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote:
> Again— I must ask where there is evidence that we are in need of tools > to increase the _speed_ of reversion actions on pages with pending > changes at the expense of the quality of those determinations? Feel > free to point out if you don't actually believe a bulk revert button > would be such a trade-off. I'm willing to consider a more conservative implementation. How about the newly added alternative C? http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision#Alternative_C > > I think making "accept"/"unaccept" into a single toggling button is the > > right thing to do. > > Because of page load times by the time I get the review screen up > someone has often approved the revision. If I am not maximally > attentive will I now accidentally unapprove a fine version of the page > simply because the button I normally click has reversed its meaning? > "Unaccept" seems suitably rare that I think we should consider a confirmation screen which shows the effect of unaccepting (i.e. a diff between the latest accepted revision and the penultimate accepted revision). Does that seem like a reasonable enough failsafe to keep this from being used unintentionally? This seems beneficial even in the case where the reviewer knew they were hitting "unaccept". > > Furthermore, because of the potentially confusing result > > of "unaccepting" something, I'd even recommend only making it possible > when > > looking at the diff between the penultimate accepted revision and the > latest > > accepted revision, which is documented in this request: > > http://www.pivotaltracker.com/story/show/3949176 > > That sounds good to me. Though the review screen which you'd visit > with the intent of reviewing a change fits that description and if you > change the meaning of a commonly used button it will result in errors > of the form I just raised. > With a confirmation screen, I think we could actually leave it enabled in most contexts, since the reviewer would need to look at the diff before confirming. You would propose to change the operation of the software to align > better with the user's misunderstandings— that a special > reviewer-reject is _needed_ above, beyond, and distinct from the > regular editing tools— I'd rather we try to make the software less > confusing so that it's obvious that the regular tools do what people > need and want. I think we probably need to agree to disagree on this point, assuming you read the Spolsky article and still come away with the same conclusion. For anyone else who is interested why I feel the way I do, this is the article that I'm referring to ("User Interface Design For Programmers" by Joel Spolsky): http://www.joelonsoftware.com/uibook/fog0000000249.html ...which I referenced in my longish reply here: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Revision Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
