Thanks for summarizing all this Kenan! Kaity and I will take a look at it. Lets figure a timeline around some next steps. This is an exciting problem, I hope we get to a well thought out solution that can get mobile to be something that even super users enjoy to use.
On Fri, Apr 4, 2014 at 4:07 PM, Kenan Wang <[email protected]> wrote: > Editors want to be able to patrol edits on pages that they care about. > Currently they use: > 1) Watchlist > 2) Article History > 3) Recent Changes > > The mechanism for "fixing" a problem with an edit is doing a revert. > Reverting allows you to go back to a revision of the article that existed > before the change that you want to "fix". Specifically it populates an edit > with the content of that previous revision and then you are actually able > to make any additional changes on top of that old content and then save. > > There are two special cases of reverting that are especially useful to > users: > 1) Undo - this is when you want to "fix" an edit but there have been edits > since the problematic edit that were productive. Undo tries to just undo > that specific edit in question instead of reverting all the way to the > revision before the edit. The reason to use undo is that sometimes there > was a problematic edit but since then there have been productive edits. > Specifically, what undo does is it tries to revert to the revision before > the problematic edit and then computationally add back in the edits since > then. Sometimes this isn't possible. Sometimes it is. When it is possible > to undo automatically the user gets the revision plus the "productive > edits" that occurred since the edit being undone, all of that content is > populated into an edit interface and the user can make any additional edits > (sometimes necessary to make the article make sense after the undo) and > then save. > > 2) Rollback - this is when you take all of the edits of the last user and > revert to the revision before those edits. The purpose of this is when > there is a user that has been committing vandalism you can quickly rollback > those edits. This is a one step process because it just does the revert and > saves automatically. > > note 1: generally speaking vandalism gets caught quickly and is often the > most recent or most recent set of edie by a single user i.e. the situation > that rollback is designed for > > note 2: undo occurs on an edit, revert and rollback operate on revisions. > on desktop the list of edits and the list of revisions is the same > interface but it may make sense to divide these on mobile. Thus on mobile > we may have separately a list of revisions (possibly grouped by user) that > may allow reverts and rollbacks, and a list of edits that allows for unto. > > We will likely prioritize revert/rollbacks because that covers the biggest > use case (vandalism on articles that are changing at a moderate velocity. > Also, > this may have implications for how we display watchlist items: considering > grouping edits by user, and only displaying most recent edits (i.e. only > rollback eligible edits) > > There a detailed view of revisions in addition to a list view of > revisions and. We need to understand what goes into a detailed view of a > revision. Maybe we show the diff to current version because this is what > would be affected by a revert, actions, username, time, other details.We > may want to consider changing the interaction of reverts a bit (maybe > should be 2 click action instead of putting user into edit). > > Let me know if I missed anything. > > -- > > Kenan Wang > Product Manager, Mobile > Wikimedia Foundation >
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
