Thanks for sharing! The approach makes sense as a first pass. Looking forward to seeing it in action!
On Fri, Apr 4, 2014 at 4:27 PM, Moiz Syed <[email protected]> wrote: > 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 > _______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
