The app team showed a demo to the mobile web team today of the latest editing experience for the new Wikipedia app that is being worked on. The mobile app editing experience was very consistent with mobile web which is a great thing, that said it had one significant difference - canned edit summaries.
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we should be doing that at the start of the workflow in my opinion - tell a new user what they can, give them a better idea using the article issues templates.
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
Jon, Agree with you here. Designs are up on the Trello board for now. I don't know that we are posting them anywhere else for apps.
Regarding the edit summary - We decided to make this a regular input field with tags as suggestion, so a new user isn't quite lost about what to say here. Along with providing help at the start, having these in tag/autocomplete form makes it faster so a user doesn't have to type them in or even wonder how to describe their small change.
Key things the guide text needs to do is -Explain when and why an edit summary is useful -Provide some quick actionable examples -If you added key information, or edited a large amount, provide specificity about what you did.
Thanks Vibha
On Mon, Mar 10, 2014 at 2:32 PM, Jon Robson jdlrobson@gmail.com wrote:
The app team showed a demo to the mobile web team today of the latest editing experience for the new Wikipedia app that is being worked on. The mobile app editing experience was very consistent with mobile web which is a great thing, that said it had one significant difference - canned edit summaries.
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we should be doing that at the start of the workflow in my opinion - tell a new user what they can, give them a better idea using the article issues templates.
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Jon,
Please also check out Pau's prototype design on the Content Translation Editor (which Language Eng is working on currently) for multilingual translation/editing.
http://pauginer.github.io/prototype-translate/content-translation.html#mies-...
Best, Alolita
Alolita Sharma आलोलिता शर्मा Director of Engineering Internationalization & Localization Wikimedia Foundation
On Mon, Mar 10, 2014 at 2:37 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Jon, Agree with you here. Designs are up on the Trello board for now. I don't know that we are posting them anywhere else for apps.
Regarding the edit summary - We decided to make this a regular input field with tags as suggestion, so a new user isn't quite lost about what to say here. Along with providing help at the start, having these in tag/autocomplete form makes it faster so a user doesn't have to type them in or even wonder how to describe their small change.
Key things the guide text needs to do is -Explain when and why an edit summary is useful -Provide some quick actionable examples -If you added key information, or edited a large amount, provide specificity about what you did.
Thanks Vibha
On Mon, Mar 10, 2014 at 2:32 PM, Jon Robson jdlrobson@gmail.com wrote:
The app team showed a demo to the mobile web team today of the latest editing experience for the new Wikipedia app that is being worked on. The mobile app editing experience was very consistent with mobile web which is a great thing, that said it had one significant difference - canned edit summaries.
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we should be doing that at the start of the workflow in my opinion - tell a new user what they can, give them a better idea using the article issues templates.
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Alolita - can you elaborate? I'm not sure how this demo from Pau relates..
Vibha, tags and autocomplete forms are 2 very different things so I'm a little confused what you are saying - you are saying there will be both?
I worry tags will encourage laziness and on the long term not very useful summaries for poor wiki patrollers. There are other ways to educate e.g. help icon that elaborates or "see some examples".
On Mon, Mar 10, 2014 at 2:43 PM, Alolita Sharma asharma@wikimedia.org wrote:
Jon,
Please also check out Pau's prototype design on the Content Translation Editor (which Language Eng is working on currently) for multilingual translation/editing.
http://pauginer.github.io/prototype-translate/content-translation.html#mies-...
Best, Alolita
Alolita Sharma आलोलिता शर्मा Director of Engineering Internationalization & Localization Wikimedia Foundation
On Mon, Mar 10, 2014 at 2:37 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Jon, Agree with you here. Designs are up on the Trello board for now. I don't know that we are posting them anywhere else for apps.
Regarding the edit summary - We decided to make this a regular input field with tags as suggestion, so a new user isn't quite lost about what to say here. Along with providing help at the start, having these in tag/autocomplete form makes it faster so a user doesn't have to type them in or even wonder how to describe their small change.
Key things the guide text needs to do is -Explain when and why an edit summary is useful -Provide some quick actionable examples -If you added key information, or edited a large amount, provide specificity about what you did.
Thanks Vibha
On Mon, Mar 10, 2014 at 2:32 PM, Jon Robson jdlrobson@gmail.com wrote:
The app team showed a demo to the mobile web team today of the latest editing experience for the new Wikipedia app that is being worked on. The mobile app editing experience was very consistent with mobile web which is a great thing, that said it had one significant difference - canned edit summaries.
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we should be doing that at the start of the workflow in my opinion - tell a new user what they can, give them a better idea using the article issues templates.
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Forwarding emails (with permission) from Vibha and Maryana that might shed some light (slightly edited to remove some unrelated content):
(From Vibha): ---
Hi Maryana,
I had some thoughts and questions on which we need your input. This is realted to the Editing workflow, specifically edit summaries.
With apps, we are hoping for a relative friendly and stable editing environment. A chunk of these will be first time edits.
We had looked at some canonical categories for mobile web if you remember - The categories were
1. Modified Content 2. Added Links 3. Fixed Typos/ Grammar
Yuvi pointed to a gadget that adds checkboxes for common edit summaries. Its an optional step, but one that could create a bit of context if done right. Do you think this will help the new editor in the edit workflow?
From a design perspective, this could serve 2 purposes for new editors -
1. Discovery of common edit types. 2. Lightly reflect on their action while being aware that there is a review process. 3. Making it easier to explain what they did
I'll hover around your desk to show you some mocks so there's a bit more context.
Thanks
----------------
From Maryana:
We had looked at some canonical categories for mobile web if you remember - The categories were
- Modified Content 2. Added Links 3. Fixed Typos/ Grammar
All three of those are the same thing (adding links and fixing typos *are* modifying content) :)
Though it's a good idea in principle, I'm still not sure there's a set of categories that make sense, since editing (even VE editing) is so open-ended. And, again, if you have all mobile app edits tagged with the same canned edit summary – even if there are 3 options to choose from, human psychology indicates people will gravitate toward the first or most open-ended option – you're not providing anything useful to the community who's monitoring these edits, and they're the ones it really matters for. It's not clear to me what value to the app user it's providing to have to stop and figure out which of 3 very high level categories their edit belongs to; that feels like a test or a CAPTCHA or something. In fact, this might be something to consider in order to intentionally reduce editing velocity if you see a lot of low-quality edits coming from this vector.
If you want to provide the additional context to the community that these edits are coming from an app, people could be new & not quite know what they're doing, etc., you could just use "Edited with the Wikipedia mobile app" as the summary.
Yuvi pointed to a gadget that adds checkboxes for common edit summaries. Its an optional step, but one that could create a bit of context if done right. Do you think this will help the new editor in the edit workflow?
From a design perspective, this could serve 2 purposes for new editors -
- Discovery of common edit types. 2. Lightly reflect on their action while being aware that there is a review process. 3. Making it easier to explain what they did
I can see how having this data would be useful for analytics purposes, certainly, but you're also probably going to find a lot of miscategorization, people rushing through the process just to submit their edit, etc., so it's not all that better than qualitative hand-coding, which is how we get that data now.
Jon,
Re: Pau's work around CX (content translation editing) - we are looking specifically in a couple of areas that may relate:
a. Making the users editing experience easier (reading, editing) for non European languages (e.g. RTL, Indic, CJK) with a first-class UX on tablets and desktops in mind
b. Providing aids such as dictionaries, terminology glossaries, spellcheckers as tools in languages beyond English to help the editing experience
Both of these areas could be leveraged in the editing experience / edit summaries functionality you are looking at :-)
HTH.
Best, Alolita
Alolita Sharma आलोलिता शर्मा Director of Engineering Internationalization & Localization Wikimedia Foundation
On Mon, Mar 10, 2014 at 3:05 PM, Jon Robson jdlrobson@gmail.com wrote:
Alolita - can you elaborate? I'm not sure how this demo from Pau relates..
Vibha, tags and autocomplete forms are 2 very different things so I'm a little confused what you are saying - you are saying there will be both?
I worry tags will encourage laziness and on the long term not very useful summaries for poor wiki patrollers. There are other ways to educate e.g. help icon that elaborates or "see some examples".
On Mon, Mar 10, 2014 at 2:43 PM, Alolita Sharma asharma@wikimedia.org wrote:
Jon,
Please also check out Pau's prototype design on the Content Translation Editor (which Language Eng is working on currently) for multilingual translation/editing.
http://pauginer.github.io/prototype-translate/content-translation.html#mies-...
Best, Alolita
Alolita Sharma आलोलिता शर्मा Director of Engineering Internationalization & Localization Wikimedia Foundation
On Mon, Mar 10, 2014 at 2:37 PM, Vibha Bamba vbamba@wikimedia.org
wrote:
Jon, Agree with you here. Designs are up on the Trello board for now. I don't know that we are posting them anywhere else for apps.
Regarding the edit summary - We decided to make this a regular input field with tags as suggestion,
so
a new user isn't quite lost about what to say here. Along with providing help at the start, having these in tag/autocomplete form makes it faster so a user doesn't have to type them in or even
wonder
how to describe their small change.
Key things the guide text needs to do is -Explain when and why an edit summary is useful -Provide some quick actionable examples -If you added key information, or edited a large amount, provide specificity about what you did.
Thanks Vibha
On Mon, Mar 10, 2014 at 2:32 PM, Jon Robson jdlrobson@gmail.com
wrote:
The app team showed a demo to the mobile web team today of the latest editing experience for the new Wikipedia app that is being worked on. The mobile app editing experience was very consistent with mobile web which is a great thing, that said it had one significant difference - canned edit summaries.
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we should be doing that at the start of the workflow in my opinion - tell a new user what they can, give them a better idea using the article issues templates.
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
On Mon, Mar 10, 2014 at 10:05 PM, Jon Robson jdlrobson@gmail.com wrote:
I worry tags will encourage laziness and on the long term not very useful summaries for poor wiki patrollers. There are other ways to educate e.g. help icon that elaborates or "see some examples".
Jon: don't worry about that. We already use mass revision tagging effectively this way with AbuseFilter, and in extensions like GettingStarted, mobile, or VisualEditor. Patrollers see thousands and thousands of edits, and these tags really do help with context.
I think it's good to do some exploratory design with canned edit summaries, if we keep in mind that this is new and we've never put something like this in production before. It may or may not work, but it doesn't hurt to take a stab at it. In my mind, the challenge here is not the UI. Whether it's tags or a dropdown or whatever we can work out easily. The hard part is figuring out what edit summaries are so common that they should be canned. Since there are so many different kinds of edits, that's the difficult part.
On Tue, Mar 11, 2014 at 3:48 AM, Steven Walling swalling@wikimedia.org wrote:
The hard part is figuring out what edit summaries are so common that they should be canned. Since there are so many different kinds of edits, that's the difficult part.
Indeed! Here's some research data from Oliver Keyes about the canned summaries gadget that's on enwiki:
-------
So, the research question; what does the usage of the default edit summaries gadget look like?
Using data for the last 60 days from enwiki, I investigated.
Results 371 distinct users who edited in that time period have the gadget enabled. This is 0.1% of the editors who have edited in that time period (224,946). 5,392 edits were made by these users that matched the dropdown options, which is 0.05% of the total (9,145,360). One counter to this is that most people are unaware of the tool's existence, which is true, but edits were made in the last 60 days by 2,338 people who have it enabled. In other words, only 15% of the people who even have it enabled find an excuse to use it in 2 months.
In terms of how this usage was distributed, I've attached two graphs. One is the distribution of those edit summaries over users - in other words, how many users were distinctly using each one. The other is the distribution over edit frequency - how many times they were used, full stop.
Conclusions As a researcher, I cannot find any evidence that this gadget is being widely used, however widely it might or might not be installed. It is sourceable to 0.05% of recent edits, at most (see 'caveats'), from 0.1% of users. Accordingly, I recommend against treating it as a feature for general release without a decent research plan for following up on its usage and investigating how people react to it.
If such a release (and plan) is desired, I'm happy (as Mobile's Secondary) to be involved. It looks like an interesting project, even if there isn't quantitative support for the idea of its utility.
Caveats This is only enwiki; retrieving substantive chunks of the revision table is painful for global queries. If I had more time I could probably have done it trivially. More importantly, the actual edit summary strings are presumably localised on a per-language basis, and so the query would have to be tweaked on a per-language basis - and those strings live in a .JS file, which isn't easily accessible in an automated fashion.
Jon, Specific to your question-
What I was proposing was common tags because they provide a vocabulary for the user before he/she starts typing. As a fall back, if we can't do that we can resort to autocomplete.
There's data and context to this discussion.The idea has been altered from the feedback provided by Maryana, Kenan, Oliver & Steven. Its difficult to discuss design thinking on email. I'm happy to chat with you more about the use here and post a detailed summary to the list when you have time.
Thanks VIbha
On Mon, Mar 10, 2014 at 3:24 PM, Yuvi Panda yuvipanda@gmail.com wrote:
On Tue, Mar 11, 2014 at 3:48 AM, Steven Walling swalling@wikimedia.org wrote:
The hard part is figuring out what edit summaries are so common that they should be canned. Since there are so many different kinds of edits, that's the difficult part.
Indeed! Here's some research data from Oliver Keyes about the canned summaries gadget that's on enwiki:
So, the research question; what does the usage of the default edit summaries gadget look like?
Using data for the last 60 days from enwiki, I investigated.
Results 371 distinct users who edited in that time period have the gadget enabled. This is 0.1% of the editors who have edited in that time period (224,946). 5,392 edits were made by these users that matched the dropdown options, which is 0.05% of the total (9,145,360). One counter to this is that most people are unaware of the tool's existence, which is true, but edits were made in the last 60 days by 2,338 people who have it enabled. In other words, only 15% of the people who even have it enabled find an excuse to use it in 2 months.
In terms of how this usage was distributed, I've attached two graphs. One is the distribution of those edit summaries over users - in other words, how many users were distinctly using each one. The other is the distribution over edit frequency - how many times they were used, full stop.
Conclusions As a researcher, I cannot find any evidence that this gadget is being widely used, however widely it might or might not be installed. It is sourceable to 0.05% of recent edits, at most (see 'caveats'), from 0.1% of users. Accordingly, I recommend against treating it as a feature for general release without a decent research plan for following up on its usage and investigating how people react to it.
If such a release (and plan) is desired, I'm happy (as Mobile's Secondary) to be involved. It looks like an interesting project, even if there isn't quantitative support for the idea of its utility.
Caveats This is only enwiki; retrieving substantive chunks of the revision table is painful for global queries. If I had more time I could probably have done it trivially. More importantly, the actual edit summary strings are presumably localised on a per-language basis, and so the query would have to be tweaked on a per-language basis - and those strings live in a .JS file, which isn't easily accessible in an automated fashion.
-- Yuvi Panda T http://yuvi.in/blog
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Sure, and I'm all for trying new things - if you know me you know this is the case - I'm all for stabs at anything. It was just something interesting I saw in the apps that I hadn't come across before, and I was wondering about it for the purpose of mobile web and whether such a thing would be useful there.
It wasn't 100% clear to me however what the goals for canned edit summaries were and what the rationale was for it - hence this discussion. I imagine there is data to back up the need for this, but there is no conversation anywhere on a mailing list - so hence this conversation and a request to please share that and show me they are useful so I spend my free time coding it for mobile web :-).
I know I personally with an autocomplete/tag setup would become lazy. Whereas I might currently use an edit summary like "it's->its" might instead resort to the easy "Spelling/grammar change". I don't know which of those edit summaries would be more useful to the people that deal with them on a day to day basis.
On Mon, Mar 10, 2014 at 3:18 PM, Steven Walling swalling@wikimedia.org wrote:
On Mon, Mar 10, 2014 at 10:05 PM, Jon Robson jdlrobson@gmail.com wrote:
I worry tags will encourage laziness and on the long term not very useful summaries for poor wiki patrollers. There are other ways to educate e.g. help icon that elaborates or "see some examples".
Jon: don't worry about that. We already use mass revision tagging effectively this way with AbuseFilter, and in extensions like GettingStarted, mobile, or VisualEditor. Patrollers see thousands and thousands of edits, and these tags really do help with context.
I think it's good to do some exploratory design with canned edit summaries, if we keep in mind that this is new and we've never put something like this in production before. It may or may not work, but it doesn't hurt to take a stab at it. In my mind, the challenge here is not the UI. Whether it's tags or a dropdown or whatever we can work out easily. The hard part is figuring out what edit summaries are so common that they should be canned. Since there are so many different kinds of edits, that's the difficult part.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Since my first email about what is happening in apps might not have been clear:
1. Me and Vibha had a lot of conversations about this, with Inputs from Oliver, Maryana and others. 2. For now we are just having a freeform text field there, with autocomplete for previously entered edit summaries 3. There will be guider text around the text field telling users what it is, with pointers to concrete examples.
Hope that clears things up :)
On Tue, Mar 11, 2014 at 3:02 AM, Jon Robson jdlrobson@gmail.com wrote:
If the goal is to make the users editing experience easier (which it should be), personally I think it would be more useful to have an autocomplete that allows an editor to recycle older edit summaries.
This is what is going to happen on Android, at least. I think iOS might also move to this. They will be clearly labelled with help available to tell new users what it is, but no canned edit summaries.
PS. Is there a link to a wiki page for these designs, so other people can see what I'm talking about?
https://trello.com/c/RNKoukle/18-design is the best we have now. Is public and I believe anyone can comment. Discussion there welcome. Note that the designs there are always a work in progress, and not set in stone.
On 11.03.2014, 1:32 Jon wrote:
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
Russian Wikipedia was doing that for ages to everyone's satisfaction. The only problem is where to cram them in, but that's solvable.
2014-03-11 1:00 GMT+02:00 Max Semenik maxsem.wiki@gmail.com:
On 11.03.2014, 1:32 Jon wrote:
The interface showed various buttons that when clicked would populate the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
Russian Wikipedia was doing that for ages to everyone's satisfaction. The only problem is where to cram them in, but that's solvable.
Hebrew and Polish Wikipedias are doing it for ages, too, and probably some other languages.
In fact, numerous people complained that VisualEditor breaks this feature. Editors don't care whether it's a local custom gadget or something else - for all they care, it's a feature and VE breaks it.
Anyway, it would be a lovely feature to productize and make available for all languages, for both mobile and desktop interfaces. The code is basically there - just take the gadget from one of the Wikipedias that currently use it and package it as an extension.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore