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.
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 kwang@wikimedia.org wrote:
Editors want to be able to patrol edits on pages that they care about. Currently they use:
- Watchlist
- Article History
- 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:
- 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.
- 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
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 msyed@wikimedia.org 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 kwang@wikimedia.org wrote:
Editors want to be able to patrol edits on pages that they care about. Currently they use:
- Watchlist
- Article History
- 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:
- 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.
- 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 Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Uh oh, look out -- it's the pedant police! :)
There are two special cases of reverting that are especially useful to users:
- Undo - this is when you want to "fix" an edit but there have been edits
since the problematic edit that were productive.
I'm not sure how you guys came to this definition, but it doesn't quite match the current existing one onwiki. Undo and revert are used interchangeably to describe the action of removing a single edit, either the latest edit to a page or earlier ones (in which case, it usually has to be done manually and is a huge pain). Because it's so much easier to do and because there's a community of users who do this almost exclusively (using terrible/fun software like Huggle), the primary use-case of "undo" is reverting the most recent edit.
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.
- 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
Well, not really. Rollback is designed for the rarer use-case of the persistent vandal who makes a bunch of bad edits to a page. But most edits that are reverted are first-time test edits/light vandalism of the clueless newbie variety, which is usually just the one most recent edit.
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.
I'm confused -- edits and revisions are synonymous. In both cases, we're talking about atomic changes to a single document that are stored sequentially as a version history. Am I missing something?
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.
If I may offer my 2 cents now, since I was unable to attend this meeting: I think you guys are overcomplicating things a bit. It's almost like you've been talking to Wikipedians about this ;)
From a 10,000 foot perspective, here's what happens on desktop Wikipedia today:
1) Clueless newbie wanders into an article, mashes some keys, and hits save 2) Some editor is watching that article, sees the diff of the stupid edit, and reverts it
OR
3) Some reader/editor is reading the article, sees the stupid edit, and manually edits the dumb thing out
AND, LATER THAT NIGHT
4) Some Huggler loads up the 10,000 latest revisions and reverts them all back in about an hour.
What it feels like you need on mobile is one or both of these:
a) a way to revert edits from your watchlist diff view if they're the most recent revision b) an edit button c) a mobile Recent Changes first-person shooter game (basically, Huggle for mobile)
You've already got b. and c. is kind of evil, imho. So I think maybe just focus on building a really lightweight way to accomplish a.? Getting into the complexity of article histories and rollback is going to be a ton of work to support an extremely rare user need, and frankly just not worth the time/hassle.
On Fri, Apr 4, 2014 at 5:03 PM, Maryana Pinchuk mpinchuk@wikimedia.orgwrote:
- 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
Well, not really. Rollback is designed for the rarer use-case of the persistent vandal who makes a bunch of bad edits to a page. But most edits that are reverted are first-time test edits/light vandalism of the clueless newbie variety, which is usually just the one most recent edit.
To be fair rollback is actually much more common then that. While it shines the most in the multi edit scenario it's most often used in the single edit variety as well and is actually required for normal huggle usage. This is because it's all one action and is significantly faster then a manual 'click undo' (which requires you to go through extra steps). When I was heavily involved in anti vandal/abuse fighting rollback was 'the' revert compared to the manual undo which people did for a while to get trusted enough to use gain the rollback right. (there are a couple reasons you needed to be trusted but one of the biggest ones is exactly because you can do reverts so quickly without an extra confirmation page).
James
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
Maryana,
Undo and revert are specific actions. Undo does do the thing that i described, but it is more of a power user feature and what I'm hearing is that in practice undo is typically just used for the most recent edit which basically makes it the same as rollback except that rollback isn't offered to everyone and rollback is a one step process.
The difference between an edit and a revision is that the edit is actual atomic change, while the revision is the version of the document at the time of that change. I think on desktop we've been conditioned to think about them the same because we can display so much data, but on mobile displaying both edits and revisions together is quite challenging.
But the point is well taken that the most important use case is: The most recent change from the watchlist with a quick revert/rollback/undo functionality. We don't need to worry too much about reverting to versions from a long time ago, or complicated undo procedures for specific edits in the middle of a stream of edits.
*Design: *Maybe that means that in Watchlist we highlight the most recent changes somehow (maybe grouped by user) and then make rollback/undo only available for those changes for now. Same thing on article history page. This seams like a reasonable MVP.
Kenan
On Fri, Apr 4, 2014 at 5:18 PM, James Alexander jalexander@wikimedia.orgwrote:
On Fri, Apr 4, 2014 at 5:03 PM, Maryana Pinchuk mpinchuk@wikimedia.orgwrote:
- 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
Well, not really. Rollback is designed for the rarer use-case of the persistent vandal who makes a bunch of bad edits to a page. But most edits that are reverted are first-time test edits/light vandalism of the clueless newbie variety, which is usually just the one most recent edit.
To be fair rollback is actually much more common then that. While it shines the most in the multi edit scenario it's most often used in the single edit variety as well and is actually required for normal huggle usage. This is because it's all one action and is significantly faster then a manual 'click undo' (which requires you to go through extra steps). When I was heavily involved in anti vandal/abuse fighting rollback was 'the' revert compared to the manual undo which people did for a while to get trusted enough to use gain the rollback right. (there are a couple reasons you needed to be trusted but one of the biggest ones is exactly because you can do reverts so quickly without an extra confirmation page).
James
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
There is another important difference. Rollback is 'aggressive'. It can only leave 1 editsummary:
"Reverted edits by User A (talk) to last version by User B"
Undo however leaves you a bit more flexibility. The default editmessage can be replace and should be for any case where any AGF can potentially can come into play.
DJ
On 5 apr. 2014, at 03:36, Kenan Wang kwang@wikimedia.org wrote:
Maryana,
Undo and revert are specific actions. Undo does do the thing that i described, but it is more of a power user feature and what I'm hearing is that in practice undo is typically just used for the most recent edit which basically makes it the same as rollback except that rollback isn't offered to everyone and rollback is a one step process.
The difference between an edit and a revision is that the edit is actual atomic change, while the revision is the version of the document at the time of that change. I think on desktop we've been conditioned to think about them the same because we can display so much data, but on mobile displaying both edits and revisions together is quite challenging.
But the point is well taken that the most important use case is: The most recent change from the watchlist with a quick revert/rollback/undo functionality. We don't need to worry too much about reverting to versions from a long time ago, or complicated undo procedures for specific edits in the middle of a stream of edits.
Design: Maybe that means that in Watchlist we highlight the most recent changes somehow (maybe grouped by user) and then make rollback/undo only available for those changes for now. Same thing on article history page. This seams like a reasonable MVP.
Kenan
On Fri, Apr 4, 2014 at 5:18 PM, James Alexander jalexander@wikimedia.org wrote:
On Fri, Apr 4, 2014 at 5:03 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
- 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
Well, not really. Rollback is designed for the rarer use-case of the persistent vandal who makes a bunch of bad edits to a page. But most edits that are reverted are first-time test edits/light vandalism of the clueless newbie variety, which is usually just the one most recent edit.
To be fair rollback is actually much more common then that. While it shines the most in the multi edit scenario it's most often used in the single edit variety as well and is actually required for normal huggle usage. This is because it's all one action and is significantly faster then a manual 'click undo' (which requires you to go through extra steps). When I was heavily involved in anti vandal/abuse fighting rollback was 'the' revert compared to the manual undo which people did for a while to get trusted enough to use gain the rollback right. (there are a couple reasons you needed to be trusted but one of the biggest ones is exactly because you can do reverts so quickly without an extra confirmation page).
James
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
--
Kenan Wang Product Manager, Mobile Wikimedia Foundation _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
One important note and p.s. on the nitpick.
Kenan Wang, 05/04/2014 01:07:
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)
Very important: what you propose here is called enhanced recent changes. https://meta.wikimedia.org/wiki/Help:Enhanced_recent_changes It will become the default in 1.23, but not on Wikimedia projects. https://bugzilla.wikimedia.org/show_bug.cgi?id=35785
Maryana Pinchuk, 05/04/2014 02:03:
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.
I'm confused -- edits and revisions are synonymous. In both cases, we're talking about atomic changes to a single document that are stored sequentially as a version history. Am I missing something?
What Kenan meant is that the undo feature undoes *the diff*, i.e. applies the specific diff you're reverting, in the opposite direction. Rollback on the other hand is an older and more drastic feature which completely restores a previous revision as a whole, whatever happened after it.
Nemo