On tablet, this appears to have been depreciated (using beta). Removing pre-loaded summaries would be useful, maybe replacing with summaries used frequently be the editor in question (maybe let the user create a subpage to enter them manually?). Either way, default edit summaries such as these can be over odvious and intimidating.

(In reply to Mdann52 from comment #1)

Either way, default edit summaries such as these can
be over odvious and intimidating.

Our data completely disagrees with this statement. Both highly experienced users and totally new users have virtually the same success rate at proceeding through the edit summary and preview screen. In contrast, registered users are over five times as likely as anonymous users to get through the first edit screen where you see wikitext.

Because of the above, realistically we are not going to be focussing our efforts on the edit summary screen for quite a while as we have much more pertinent issues to address.

I disagree completely. When I first got to the screen, it took me a good 15-20 seconds to find I could enter a custom summary, yet alone not have to use the default ones.

However, I appreciate why, with the more major bugs in the software, why this is not getting attention any time soon. I have personally found much more pressing things that need resolving that (appear) to have already been reported.

Surely there is always experience that differs from the majority exposed in gathered data (as long as gathered data does not show 100% for one certain behavior or expectation). :)

(In reply to Andre Klapper from comment #4)

Surely there is always experience that differs from the majority exposed in
gathered data (as long as gathered data does not show 100% for one certain
behavior or expectation). :)

Indeed. However, the data does show that the reaction of crippling confusion at the edit summary screen is literally in the minority, as over 50% of both registered and anonymous users make it past that screen.

Ideally, I think you'd want to start ppl off with a flow like that, and then after they have passed the screen a few times, you would 'nudge' them and ask "instead of picking one of the predefined summaries, you can write your own. Try it !"

(In reply to Derk-Jan Hartman from comment #6)

Ideally, I think you'd want to start ppl off with a flow like that, and then
after they have passed the screen a few times, you would 'nudge' them and
ask "instead of picking one of the predefined summaries, you can write your
own. Try it !"

Agreed. It is not made clear enough that the edit summary step is optional and that one can save without an edit summary. We are undoubtedly losing some edits because of this.

That said, not our immediate priority right now, per the above. :-)

This seems to apply equally to iOS and Android really. Tagging as such.

Currently (again) being discussed here: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Can_this_huge_canned_edit_summary_issue_with_Wikipedia_be_fixed.3F

Thanks for bringing this discussion on EN to our attention @TheDJ

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box. But I don't believe we'll have the time to investigate objectively and across languages whether this is systemically problematic. So, in this case I'd lean to deferring to these en.wp editor's sentiment and remove them.

Ideally @Jdforrester-WMF or other members of the Editing or Collaboration team would weigh in here as well, since this technically falls in their jurisdiction, but given the "unique" arrangement of apps I'll work this though our process as is.

In T71168#3324893, @JMinor wrote:

Thanks for bringing this discussion on EN to our attention @TheDJ

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box. But I don't believe we'll have the time to investigate objectively and across languages whether this is systemically problematic. So, in this case I'd lean to deferring to these en.wp editor's sentiment and remove them.

Ideally @Jdforrester-WMF or other members of the Editing or Collaboration team would weigh in here as well, since this technically falls in their jurisdiction, but given the "unique" arrangement of apps I'll work this though our process as is.

At it.wiki we have an ad hoc filter to mark these edits since, most of time, they are anything but typos: https://it.wikipedia.org/wiki/Speciale:FiltroAntiAbusi/372

In T71168#3324893, @JMinor wrote:

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box.

Yes, this seems to be a bit jumbled up. The sentiment seems to be "Because the canned edit summaries are used with bad edits, the canned edit summaries are causing bad edits." This is the post hoc ergo propter hoc fallacy, as Murph9000 pointed out in the discussion on enwiki. The onus is not on us to disprove a fallacious argument.

Now, there is a point here that is logical: there's not much point in having the canned edit summaries there if they're not being used properly. I did some very quick data analysis on edits with canned edit summaries, and:

• 51.4% were good edits
• 49.6% were bad edits

The interesting thing was that 36.9% of the good edits had misleading canned edit summaries; the edits themselves were good, but the summary chosen didn't really match what the edit changed.

I'd be interested to compare this to non-canned edit summaries. Specifically, are 49.6% of all edits with an edit summary bad? I expect not, and that generally that is much lower. This would seem to suggest that canned edit summaries are bad, but there are confounding factors, such as it being possible that it's more of a reflection on mobile editing than canned edit summaries. On the other hand, over half of them are helpful edits, and nearly two thirds of those are correctly tagged. This would seem to suggest that canned edit summaries are good. It's also unproven that canned edit summaries are helpful at increasing the edit success rate.

In short, the quick data analysis I performed is inconclusive as to whether canned edit summaries are bad or not. There are reasons to suggest they might be bad, and reasons to suggest they might be good.

I really don't know what to suggest.

In T71168#3332049, @Deskana wrote:

In T71168#3324893, @JMinor wrote:

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box.

Yes, this seems to be a bit jumbled up. The sentiment seems to be "Because the canned edit summaries are used with bad edits, the canned edit summaries are causing bad edits." This is the post hoc ergo propter hoc fallacy, as Murph9000 pointed out in the discussion on enwiki. The onus is not on us to disprove a fallacious argument.

Now, there is a point here that is logical: there's not much point in having the canned edit summaries there if they're not being used properly. I did some very quick data analysis on edits with canned edit summaries, and:

• 51.4% were good edits
• 49.6% were bad edits

The interesting thing was that 36.9% of the good edits had misleading canned edit summaries; the edits themselves were good, but the summary chosen didn't really match what the edit changed.

I'd be interested to compare this to non-canned edit summaries. Specifically, are 49.6% of all edits with an edit summary bad? I expect not, and that generally that is much lower. This would seem to suggest that canned edit summaries are bad, but there are confounding factors, such as it being possible that it's more of a reflection on mobile editing than canned edit summaries. On the other hand, over half of them are helpful edits, and nearly two thirds of those are correctly tagged. This would seem to suggest that canned edit summaries are good. It's also unproven that canned edit summaries are helpful at increasing the edit success rate.

In short, the quick data analysis I performed is inconclusive as to whether canned edit summaries are bad or not. There are reasons to suggest they might be bad, and reasons to suggest they might be good.

I really don't know what to suggest.

What is the purpose of the edit summary field? Filling a box in some ways or giving a brief decription/ratio of edits?

I think the problem here is mostly a UX problem actually. curators use the edit summary to make a quick judgement call ( which mostly is "edits with edit summaries took people more effort and are therefore more likely to be ok"). Canned edit summaries has messed with that baseline expectation (this is an often brought up point, that doing something for 'readers' effects the way 'editors' work).

Now the interesting thing to me is, that I highly doubt that edit summaries should be used as an indicator for edit quality to being with. It might sound nice in theory, but the review filters + ORES are probably a much more fair indicator. The problem of course is that most people are not using that yet.

I think an easy way to improve this would be to just change the order of some things here.. I would have the design of the labels as:

• Fixed typo
• Fixed grammer
• Added links
• Other (default selected)

empty textfield, with placeholder (Describe your changes)

This way you provide 'speed up' and simplification, yet still keep the ppl who really won't care inside the normal 'pattern' where they would just keep "Other" selected, not fill in the textfield and just hit publish.

What is the purpose of the edit summary field?

I take it to be a voluntary summary of the change you made to the content base. This summary can then be used for patrollers and also for people looking at specific article history without having to read diffs in detail.

I assume the thinking was that some summary is better than none, and that on mobile anything we could do reduce the amount of typing would encourage people to provide summaries, when they otherwise might not. Again, this predates me, so I can only guess.

My suggestion is to put this into the queue for an upcoming iOS release, have our designer propose a change based on @TheDJ's and reach out to Bongwarrior and others on Village Pump and ask them to provide feedback. If its okay, we'll release it on iOS and schedule it for Android. If the consensus is "we think it'd be better to just remove them entirely" we'll proceed from there.

In T71168#3371728, @JMinor wrote:

I assume the thinking was that some summary is better than none, and that on mobile anything we could do reduce the amount of typing would encourage people to provide summaries, when they otherwise might not. Again, this predates me, so I can only guess.

Definitely a bad idea, users no longer rely upon summaries, assuming defaults ones are simply fake.

In T71168#3376596, @Vituzzu wrote:

Definitely a bad idea, users no longer rely upon summaries, assuming defaults ones are simply fake.

Hindsight is a wonderful thing. :-)

@JMinor Guessing we can now re-write/amend the ticket description to more specifically define what we need to change?

Would we want to run some quick usability testing on this flow? We have testing credits and could easily have 5 users work through the editing flow. I've identified some potential UX issues below, but I'm confident that there would be more we could identify through testing. If we don't want to test now, we can definitely test any future designs with first time editors.

Potential UX issues for users:

• It is not clear to users that they can proceed without selecting one of the edit summary tags as the CTA in the top left ('Publish') looks inactive as it is not blue like the majority of active elements on this screen and in the app generally
• It is not clear that there is a free-text option (eg. that 'Other' isn't a complete input unto itself)
• It is not clear how the edit summary is being used, therefore potentially making it harder for users to select an appropriate option (eg. is anyone going to see this? is it better for me to pick something rather than nothing? is a canned response easier understood / more useful than a written response?) Users might feel that they are being more helpful if they select a canned option rather than providing their own free text

Questions:

• Is their a hierarchy of edits that are easiest to triage?
  • Edits without summaries
  • Edits with manually entered summaries
  • Edits with incorrect summaries
• Would it be possible to only show canned summaries for edits where the dif is below a defined character limit?
• Are there other broad edit summary 'tags' that should be added to any canned list? Eg. would having more options make selection clearer for users?

We are about to implement a new version of the submission flow. This version does not completely remove canned edit summaries but deemphasizes them and turns them into ways to quick input text (which we are hoping will lead to more users modifying the summaries or writing their own) https://phabricator.wikimedia.org/T209172