Page MenuHomePhabricator

Add support for customizing edit summaries for comments posted using Reply tool
Open, Needs TriagePublic

Description

This task about is implementing a way for people to customize the edit summaries that accompany comments (read: edits) posted with the Reply tool.

Background

Currently, the Reply tool automatically generates the edit summary that accompanies comments posted using it.

Some people have requested [1][2][3] support be added to the tool that would enable them to customize the edit summaries for comments they post using the Reply tool. This way, people monitoring the conversation (e.g. via their Watchlist, email notifications, page history, etc.) can more easily decide whether an edit is needing of their attention.

Requirements

  • Meta
    • The ability to customize the edit summaries should not be prominent in the tool's UI; it should be a feature that is visible and accessible to those seeking it out. Said another way: the ability to customize an edit summary should not catch the attention of someone who is not looking for it.
    • People writing a comment with the Reply tool should not be led to wonder or think about whether a custom edit summary is required.
    • The tool should continue to feel "lightweight" regardless of whether someone decides to customize the edit summary of the comment they are writing. E.g. it would be undesirable to introduce the custom edit summary as an additional required "step" in the posting flow.
  • Tactical
    • Within the Reply Tool, Senior Contributors should be able to easily know how to customize the edit summary that will accompany the comment they are posting
      • This is not to say the custom edit summary field needs to be exposed by default, but rather that Senior Contributors need to be able to easily show/hide the custom edit summary field/functionality in context (read: without having to navigate away from the comment they are writing to a separate page, like Special:Preferences).
    • Junior Contributors should not become distracted by the custom edit summary functionality nor should they feel an obligation to engage with it.
    • People should be able to customize the edit summary for the comment they are writing in the tool's visual and source mode.
    • The custom edit summary field should be pre-populated with the automatic summary that, if unchanged, would be posted with the comment they are writing.

Implementation details

To start, we will implement an approach that most closely resembles Approach 2: expose "Edit Summaries" inside the tool.

  • Character counter: the character counter will be displayed when people are within 100 characters of reaching the limit
  • Text field: the summary text field should not adapt to the text written into it (read: the text people write should not impact the size of the field)
  • Text field heading: the summary field should have a header called Comment summary
  • The "Advanced" affordance should be visible in both of the tool's input modes: source and visual

Open questions

  • 4. How should the affordance to expose/enable custom edit summaries be presented? Should it exist within a "Settings" interface/modal that people can interact with in the context of the tool as is done in Convenient Discussions [4]? Should it have an explicit affordance, like what @Marc is proposing [5][6]?
    • This question will be through the mockups @iamjessklein will be creating.
  • 5. Should the tool be able to "remember" whether people have used the custom edit summary functionality in the past?
    • To start, the tool will NOT remember – implicitly via a sticky preference or explicitly via a setting – whether someone prefers the custom edit summary field be exposed within the Reply Tool.
  • 1. What should the "edit summary" be called in the context of the Reply tool? Context: T241403.
    • "Edit summary" is fine in this context considering it is unlikely Junior Contributors (read: the people most likely to be confused by the non-discussion specific language) will be engaging with this part of the tool.
  • 3. In what – if any – cases should the custom edit summary field/functionality be exposed/turned on for people when using the Reply Tool for the first time?
    • None. To start, the custom edit summary field/functionality will be presented to all people in the same way. We will revise this approach If/when we become aware of evidence that suggests this approach should be revised.
    • People using the Reply Tool for the first time should see the custom edit summary field exposed by default when using the Reply Tool for the first time if they meet both of the following conditions:
      • A) They explicitly turned on the Prompt me when entering a blank edit summary (or the default undo summary) setting in Special:Preferences AND
      • B) They are not using the Reply Tool at ar.wiki
  • 2A. If Approach #1 is implemented, where should the preference it requires be located?
    • We will not be trying Approach #1 to start.
  • 2B. If Approach #1 is implemented, where should the preference it requires be called?
    • We will not be trying Approach #1 to start.

Done

  • An "Approach" that meets the "Requirements" above is decided upon
    • We will start by experimenting with an approach that most closely resembles
  • All "Open questions" are answered
  • The chosen "Approach" is implemented

  1. https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AKonzult%C3%A1ci%C3%B3_a_vitalapokr%C3%B3l_%C3%A9s_a_k%C3%B6z%C3%B6ss%C3%A9gi_kommunik%C3%A1ci%C3%B3r%C3%B3l&type=revision&diff=22425243
  2. T249072#6021222
  3. https://nl.wikipedia.org/wiki/Wikipedia:Discussietools

Approaches

Approach 1: expose "Edit Summaries" outside the tool

  1. For people to enable custom edit summaries in the Reply tool, they would turn on a preference within Special:Preferences > Editing [i][ii]
  2. After enabling said "preference," people would see an additional call to action of some kind (e.g. a link, button, checkbox, etc.) within the Reply tool
  3. When people engaged (read: click) that "call to action" they would see a one-line edit summary text field
    • Said "text field" would be pre-populated with the automatic edit summary which people could in turn change
  4. After changing the edit summary text within the one-line edit summary text field, they would click the tool's pre-existing "Reply" button to publish the comment they wrote which would be accompanied by the custom edit summary they composed.

Approach 2: expose "Edit Summaries" inside the tool

  1. For people to enable custom edit summaries in the Reply tool, they would interact with a call to action of some kind (e.g. a link, button, checkbox, etc.) that is present within the Reply tool's UI by default
  2. When someone engaged with (read: clicked) said "call to action," they would see a one-line edit summary text field
    • Said "text field" would be pre-populated with the automatic edit summary which people could in turn change
  3. After changing the edit summary text within the one-line edit summary text field, they would click the tool's pre-existing "Reply" button to publish the comment they wrote which would be accompanied by the custom edit summary they composed.

i. Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
JTannerWMF moved this task from 📚 Backlog to 📢 To Do on the Editing Design board.
JTannerWMF moved this task from Incoming to Design on the Editing-team board.
ppelberg added a subscriber: iamjessklein.EditedJul 14 2020, 2:23 AM

Notes from today's conversation with @iamjessklein + @Esanders:
Below are a few approaches that surfaced...

Approach 1: expose "Edit Summaries" via an Advanced Mode

  1. For people to enable custom edit summaries in the Reply tool, they would turn on a preference within Special:Preferences > Editing [i][ii][iii]
  2. After enabling said "preference," people would see an additional call to action of some kind (e.g. a link, button, checkbox, etc.) within the Reply tool
  3. When people engaged (read: click) that "call to action" they would see a one-line edit summary text field
    • Said "text field" would be pre-populated with the automatic edit summary which people could in turn change
  4. After changing the edit summary text within the one-line edit summary text field, they would click the tool's pre-existing "Reply" button to publish the comment they wrote which would be accompanied by the custom edit summary they composed.

Approach 2: expose "Edit Summaries" be default

  1. For people to enable custom edit summaries in the Reply tool, they would interact with a call to action of some kind (e.g. a link, button, checkbox, etc.) that is present within the Reply tool's UI by default
  2. When someone engaged with (read: clicked) said "call to action," they would see a one-line edit summary text field
    • Said "text field" would be pre-populated with the automatic edit summary which people could in turn change
  3. After changing the edit summary text within the one-line edit summary text field, they would click the tool's pre-existing "Reply" button to publish the comment they wrote which would be accompanied by the custom edit summary they composed.

Provisional decision
Absent of either of the "Conditions" below being met, we will move forward with Approach #1 as we think this implementation of the custom edit summary preserves the lightweight nature of the tool, without creating an opportunity for people who are not expecting it/seeking it out to become distracted/confused by it.

Conditions to revise decision

  • A yet-to-be defined approach that better satisfies the "Requirements" described in the task description
  • Compelling reasons why Approach 1 would create more issues than it solves

The task description has been updated to include the above.


Next steps


i. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing
ii. The precise location and name of this preference within Special:Preferences is yet-to-be defined
iii. There is a larger conversation to be had about how DiscussionTools preferences are "expressed"; that conversation will happen in this ticket: T257889

Next steps

I've posted an invitation for feedback on mediawiki.org: https://www.mediawiki.org/w/index.php?title=Topic:Vju7lfcav875rt8r&topic_showPostId=vq7kequp4e7a3bm7#flow-post-vq7kequp4e7a3bm7.

Next steps

  • Once we've heard back from volunteers; @ppelberg to finalize the initial approach we'll take to implementing custom edit summaries within the Reply Tool.
ppelberg added a subscriber: Marc.Jul 16 2020, 11:35 PM

Implementation ideas
Below are a couple ideas @Marc shared that we ought to consider when we start working on an implementation:

  • Consider using a sideways arrow to show/hide the custom edit summary field [i]
  • Consider making it so the tool remembers whether someone used the custom edit summary in a previous comment. Said another way:
    • If someone was to use the custom edit summary field in Edit 1
    • The next time that person opens the Reply Tool, they should see the custom edit summary without having to do anything "extra"

i.

Marc added a comment.Jul 18 2020, 12:36 AM

@ppelberg Thanks for sharing this here. In case new users shouldn't be confronted with mark-up code (like the special section linking mark-up in the summary box) too soon, that part could be left out of the text field. I updated the mockup also with empty vs prefilled with a default summary (the one I see most fit, see T254117):

Collapsed state, and four examples of how 'expanded' could look like, initially
https://www.mediawiki.org/wiki/User:Mar(c)/mockup-replytool-editsummary-collapser
ppelberg updated the task description. (Show Details)Jul 23 2020, 12:13 AM
ppelberg added a subscriber: geraki.
ppelberg updated the task description. (Show Details)EditedJul 23 2020, 12:25 AM

Meta
I think the conversation we've been having on mediawiki.org [i] surfaced the key "Assumptions" that will guide the "Initial approach" we try as well as the "Open questions" we'll need to answer to complete implementation.

As such, the task description has been updated to include these "Assumptions," "Initial approach" and "Open questions." [ii]

Next steps

  • @iamjessklein to start iterating on a design to meet the "Requirements" listed in the task description
  • @ppelberg to answer remaining "Open questions" in the task description

i. https://w.wiki/X5s
ii. You can also review how these were shared in context by reviewing this comment I posted in the thread on mediawiki.org where we've been talking about custom edit summaries: https://w.wiki/Xcy

  • Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Good idea, but unfortunately that’s a default preference on arwiki (T220186) and thus not a very good indicator there—people who have it on implicitly (i.e. no preference stored in DB) include junior contributors (obviously not a good idea to enable for them), while people who have it on explicitly are almost certainly a proper subset of those who would turn it on if it wasn’t the default, so taking explicit preferences into account excludes a lot of people (which may be acceptable, but should be considered).

  • Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Good idea, but unfortunately that’s a default preference on arwiki (T220186) and thus not a very good indicator there—people who have it on implicitly (i.e. no preference stored in DB) include junior contributors (obviously not a good idea to enable for them)

I'm glad you said something about this, @Tacsipacsi! I'd been assuming the Prompt me when entering a blank edit summary (or the default undo summary) preference was not a default preference at all wikis.

... while people who have it on explicitly are almost certainly a proper subset of those who would turn it on if it wasn’t the default, so taking explicit preferences into account excludes a lot of people (which may be acceptable, but should be considered).

Can you say a bit more here? Who are the people you are thinking will meet the following conditions?

  1. People who expect to see custom edit summary field within the Reply Tool shown by default and
  2. People who do not have the Prompt me when entering a blank edit summary (or the default undo summary) enabled?
  • Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Good idea, but unfortunately that’s a default preference on arwiki (T220186) and thus not a very good indicator there—people who have it on implicitly (i.e. no preference stored in DB) include junior contributors (obviously not a good idea to enable for them)

I'm glad you said something about this, @Tacsipacsi! I'd been assuming the Prompt me when entering a blank edit summary (or the default undo summary) preference was not a default preference at all wikis.

Actually arwiki is the only Wikimedia wiki that has this preference on by default (search for wmgForceEditSummary in InitialiseSettings.php).

... while people who have it on explicitly are almost certainly a proper subset of those who would turn it on if it wasn’t the default, so taking explicit preferences into account excludes a lot of people (which may be acceptable, but should be considered).

Can you say a bit more here? Who are the people you are thinking will meet the following conditions?

  1. People who expect to see custom edit summary field within the Reply Tool shown by default and
  2. People who do not have the Prompt me when entering a blank edit summary (or the default undo summary) enabled?

I think very few people have this preference explicitly turned on if it’s implicitly on (they can’t even tick the preference in Special:Preferences since it’s already ticked, probably unchecking and re-checking would make it explicit, but that’s not very intuitive). I think most people who do have this preference on are those who have turned it on before May 2019 (when the patch in the mentioned task was merged). So the people meeting your conditions are basically (almost) everyone who became aware of the importance of edit summaries in the last 14 months.

ppelberg updated the task description. (Show Details)Jul 28 2020, 4:43 PM
  • Idea prompted by @geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary) Special:Preferences enabled should see the custom edit summary field/functionality automatically.

Good idea, but unfortunately that’s a default preference on arwiki (T220186) and thus not a very good indicator there—people who have it on implicitly (i.e. no preference stored in DB) include junior contributors (obviously not a good idea to enable for them)

I'm glad you said something about this, @Tacsipacsi! I'd been assuming the Prompt me when entering a blank edit summary (or the default undo summary) preference was not a default preference at all wikis.

Actually arwiki is the only Wikimedia wiki that has this preference on by default (search for wmgForceEditSummary in InitialiseSettings.php).

Got it – thank you for point us to this configuration setting.

... while people who have it on explicitly are almost certainly a proper subset of those who would turn it on if it wasn’t the default, so taking explicit preferences into account excludes a lot of people (which may be acceptable, but should be considered).

Can you say a bit more here? Who are the people you are thinking will meet the following conditions?

  1. People who expect to see custom edit summary field within the Reply Tool shown by default and
  2. People who do not have the Prompt me when entering a blank edit summary (or the default undo summary) enabled?

I think very few people have this preference explicitly turned on if it’s implicitly on (they can’t even tick the preference in Special:Preferences since it’s already ticked, probably unchecking and re-checking would make it explicit, but that’s not very intuitive). I think most people who do have this preference on are those who have turned it on before May 2019 (when the patch in the mentioned task was merged). So the people meeting your conditions are basically (almost) everyone who became aware of the importance of edit summaries in the last 14 months.

Understood.

With the above in mind, I think we have enough information to develop an initial approach for determining in which cases the custom edit summary field/functionality should be exposed for people using the Reply Tool for the first time: [i]

  • People using the Reply Tool for the first time should see the custom edit summary field exposed by default when using the Reply Tool for the first time if they meet both of the following conditions:
    • A) They explicitly turned on the Prompt me when entering a blank edit summary (or the default undo summary) setting in Special:Preferences AND
    • B) They are not using the Reply Tool at ar.wiki

The above prompts a new question about what is done at ar.wiki which I am going to post in a separate comment so it's easier to discussion.


i. This approach has been added as an answer to question #3 in the task description's "Open questions" section.

ppelberg updated the task description. (Show Details)Jul 29 2020, 12:05 AM
ppelberg added a subscriber: Dyolf77_WMF.EditedJul 29 2020, 12:17 AM

The above prompts a new question about what is done at ar.wiki which I am going to post in a separate comment so it's easier to discussion.

@Dyolf77_WMF, a question for you about how custom edit summaries within the Reply Tool are implemented. Before I ask that question, some context...

Context: we will be adding the ability for people to customize the edit summary that accompanies comments posted with the Reply Tool. A part of implementing this functionality involves us determining which people will expect for the custom edit summary functionality to be "turned on" when the use the Reply Tool for the first time (for the majority of people, the custom edit summary field will not be turned on when they use the tool for the first time).

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?


i. T249391#6332703
ii. At all other wikis, people need to manually turn on the Prompt me when entering a blank edit summary (or the default undo summary) preference which, we think, means it will reliable indicate that a particular person would expect to see the custom edit summary field within the Reply Tool when they use it for the first time.

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.
Now about the method, I think it's already solved for newcomers but for senior editors,
a. if they ping a user from outside the conversation (not participating in the discussion),
b. if they reply to the discussion for the first time,
it will be convenient to type a summary of the edit (and an option to save preferences for the future).
Does this make sense?

Question: considering that on ar.wiki the Prompt me when entering a blank edit summary (or the default undo summary) preference is turned on for everyone by default [i][ii], we wonder whether you can think of another method the software can use to determine whether someone will expect to see the custom edit summary field available within the Reply Tool when they use it for the first time?

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.

Can you say a bit more to this point? Are you saying that before replying to a comment on a talk page, you'll first notice the edit on your watchlist, review the edit summary that accompanied said edit and then go about drafting a response?

Now about the method, I think it's already solved for newcomers but for senior editors,
a. if they ping a user from outside the conversation (not participating in the discussion),
b. if they reply to the discussion for the first time,
it will be convenient to type a summary of the edit (and an option to save preferences for the future).
Does this make sense?

I think it does; I'm understanding the above as you describing the scenarios in which you would expect to be able to customize the edit summary that accompanies the comment you are writing with the reply tool. If that's not accurate, please let me know!

@Dyolf77_WMF, I should note: the question I asked in T249391#6343113 was to help us develop an approach for how we might identify users who might expect the custom edit summary functionality to be turned on within the Reply Tool the very first time they use it.

However, this is no longer a question that needs answering. Reason: the Reply Tool's custom edit summary will behave the same way for all people, until we become aware of evidence that suggests this approach needs to be revieded.

I've edited question #3 within the task description's "Open questions" section to reflect this thinking.

ppelberg updated the task description. (Show Details)Aug 3 2020, 10:18 PM

@ppelberg thanks for asking this, before answering your question I would like to inform you that summary edits is what I personally look at when replying comments.

Can you say a bit more to this point? Are you saying that before replying to a comment on a talk page, you'll first notice the edit on your watchlist, review the edit summary that accompanied said edit and then go about drafting a response?

@ppelberg no, usually (without the reply tool) I make my comment and before saving it, I type the summary edit.
With the reply tool, I make my comment and before posting my answer I would like to describe what I just wrote in the summary edit, that is not available with the reply tool. That is my personal approach, the summary edit is what I want to add to the Reply tool.

I made a few low fidelity sketches for the purposes of discussion. The challenge here is making a design that is obvious for senior contributors (such as @Dyolf77_WMF and marc) while simultaneously being non-disruptive to junior contributors. For in-context commenting, take a look at figma, otherwise, here are three ways we can go:

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

This should be pretty obvious for senior contributors, probably a bit too prominent for junior ones.

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

I think this is far too prominent for junior contributors, while not very intuitive for senior ones.

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

This is maybe the least prominent of all—good for juniors, but maybe not very obvious for seniors.

As a conclusion, I think A is probably a bit better than C, while B should definitely be avoided.

ppelberg added a comment.EditedAug 5 2020, 12:47 AM

I made a few low fidelity sketches for the purposes of discussion...

Great idea, Jess.

A. Tap in to add a message - this will always display the input field and you just need to tap into and then add the meage

This should be pretty obvious for senior contributors, probably a bit too prominent for junior ones.

+ 1

B. Tap floating Button to expand - this is a material design-esque pattern of having a floating button of sorts that expand on click to reveal the input

I think this is far too prominent for junior contributors, while not very intuitive for senior ones.

+ 1

C. Tap icon to reveal a shelf dropdown - a small icon will appear but open up a shelf with more options on click.

This is maybe the least prominent of all—good for juniors, but maybe not very obvious for seniors.

@iamjessklein, this is the direction I think we should continue to explore.

"Rationale," "Enhancements to explore" and other "Considerations" to keep in mind below.


Rationale
I think we should continue to explore direction C: Dropdown for the following reasons:

  • Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors
  • Considering some percentage of Senior Contributors will expect, and subsequently be looking for edit summary functionality within the Reply Tool, I think they will be more likely to notice an affordance that we might otherwise think to be too obscure in a different context. [i]
    • Of course, if Senior Contributors are not noticing the affordance, we can iterate on the implementation to make it more likely that they do.

Enhancements to explore

  • In response to the @Tacsipacsi raised above RE this direction potentially not being obvious for Senior Contributors, can we play around with how and where the affordance is presented so that it is more closely related to the "posting process/flow"?
    • Thinking: if the affordance is more closely related to/positioned in the context of the "posting process/flow", Senior Contributors will be more likely to explore (read: click) the affordance because it will cause some version of the following thought process:
      • 1. "Ok, I've written them comment I want to post and now I want to post it."
      • 2. "Here is the button I need to click to post the comment."
      • 3. "But hold on, what about the edit summary?"
      • 4. Looks in the vicinity of the "Reply" button for something that might reveal the edit summary field
      • 5. Notices the affordance we're talking about above.
      • 6. Clicks it.
      • 7. ✅ Learns how to expose the edit summary field in the Reply Tool

Considerations

  • I think we should avoid adding affordances to the lower right hand corner of the text input area for it will likely conflict the ULS IME component (T255191).
  • The custom edit summary field should be pre-populated with the automatic summary that, if unchanged, would be posted with the comment they are writing.

i. This assumes the affordance is presented and positioned in a context within the tool where Senior Contributors are most likely to be thinking about/looking out for the functionality it offers.

Thanks @Tacsipacsi and @ppelberg I am going to do another round of iteration that incorporates your feedback and will post here.
I'd like us to still keep A in the mix for the purpose of conversation. I wouldn't want to make this a horrible experience for Senior Contributors and in fact this this might be an opportunity to enhance this experience slightly.

Esanders added a comment.EditedAug 5 2020, 1:57 PM

Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors

Why are Junior Contributors a consideration here if this feature is only available to those who explicitly enable it in their preferences?

Not also that on article pages the edit summary label is defined in the message summary which many wikis override, for example in en.wiki it links to a help page and says "Briefly describe your changes" in small text: https://en.wikipedia.org/wiki/MediaWiki:Summary

Communities may expect this custom label to be used here as well, but we could also make a case for this being a different enough context that we want to create new messages from scratch.

Ahh good point @Esanders Ill add that summary to the requirements.

You also make a good point about the junior contributor not seeing this unless its enabled, which makes me want to lean in more to making it obvious. Thoughts @ppelberg? @Tacsipacsi ?

In looking into this with Jess, the summary edit message is heavily customised on many wikis, for example on zh.wiki it is used to provide a gadget that adds clickable common edit summaries:


https://zh.wikipedia.org/wiki/%E8%AF%BA%E5%B0%94%E8%B4%9D%E6%B4%9B?action=submit

This gadget will probably have to be updated to make it work, but that is for the zh.wiki community to fix.

ppelberg added a comment.EditedAug 5 2020, 4:03 PM

Of the three, it seems least likely to catch the attention of, and [potentially] subsequently confuse, Junior Contributors

Why are Junior Contributors a consideration here if this feature is only available to those who explicitly enable it in their preferences?

I'm glad you voiced this, Ed. Two things in response:

  1. We decided to have the functionality exposed within the tool rather than in Special:Preferences. The task description's "Implementation details" section was updated on Wed, Jul 22, 17:13 (PST) to reflect this. [i]
  2. I did not explicitly mention the update above in a comment; IIRC, this is something Jess and I talked about offline. This is a good lesson for me about why it's important to make sure every edit to an in-progress task's description is accompanied by a comment announcing said edit.

i.

To start, we will implement an approach that most closely resembles Approach 2: expose "Edit Summaries" inside the tool.
This means, all of the actions people need to take to customize their edit summary will happen within the Reply Tool.

ppelberg added a comment.EditedAug 6 2020, 7:11 PM

In looking into this with Jess, the summary edit message is heavily customised on many wikis, for example on zh.wiki it is used to provide a gadget that adds clickable common edit summaries:

Follow up question

  • @Esanders are there reason(s) why we would need to recycle the summary component? Reason I ask: I wonder whether by using summary in the context of the Reply Tool, the tool would "inherit" messaging that was written for a full-page editing context and thus be perpetuating the issues T241403 is intended to resolve.
  • 5. Should the tool be able to "remember" whether people have used the custom edit summary functionality in the past?

As discussed with @Esanders and @iamjessklein offline, to start, the tool will NOT remember – implicitly via a sticky preference or explicitly via a setting – whether someone prefers the custom edit summary field be exposed within the Reply Tool.

Reason: let's first learn how people use the functionality.

The task description's "Open questions" section has been updated with the above.

ppelberg updated the task description. (Show Details)Aug 10 2020, 6:56 PM

Here's an iteration that I'd love feedback on. The idea is to keep it simple with a very subtle advanced toggle that opens up a shelf with the summary input. cc/ @ppelberg @Esanders

subtle advanced toggle

reveal shelf with SUMMARIES and WATCH THIS CONVO

or just reveal shelf with SUMMARIES:

ppelberg added a comment.EditedAug 11 2020, 4:46 PM

Here's an iteration that I'd love feedback on. The idea is to keep it simple with a very subtle advanced toggle that opens up a shelf with the summary input.

I think these are moving in a good direction; nice work, Jess.

A couple quick things:

  • It looks like F32034315 is missing the "Watch this page" checkbox by the "Reply" and "Cancel" buttons...can you post an updated mockup that includes that checkbox?
  • It looks like in F32034315 and F32034201, the custom edit summary field is NOT being pre-populated with the automatic summary [i], can you post updated mockups that include this?

i. /* Section heading */ Reply

ppelberg added a comment.EditedAug 13 2020, 12:55 AM

Update: 12-August
Below are the notes and next steps from the conversation @iamjessklein and I had today about the mockups that were posted in T249391#6374275.

Notes

  • We came to agree that the "Watch this page" checkbox is a setting that should be considered an "advanced" function of the tool.
    • Where "advanced," in this context, means it is functionality that people do not need to know about/interact with to use the tool successfully.
  • We came to agree the "Advanced" language is a good way of meeting the requirement that, " People writing a comment with the Reply tool should not be led to wonder or think about whether a custom edit summary is required."

Next steps

  • @iamjessklein is going to update the screenshots in T249391#6374275 to show edit summary field pre-populated with automatic edit summary [i]
  • @iamjessklein is going to explore where and how the "Watch this page" checkbox should be represented within the tool and how that checkbox should relate to the new "Advanced" affordance such that the following requirements are met:
    • Junior Contributors do not become distracted by it
    • Senior Contributors will know how to find it
    • Generally: people understand the "Watch this page" checkbox to be a non-required/advanced setting

i. /* Section heading */ Reply

ppelberg added a comment.EditedAug 13 2020, 4:15 PM

Additional questions
A couple of other questions that came to mind:

  • @iamjessklein: Are you able to show a mockup of how the custom edit summary will look in the Reply Tool's source mode? Thinking: I'm curious to see how it will interact with the tool's preview. I also assume this will be the mode Senior Contributors will use it most often in.
  • @iamjessklein: Can you experiment with introducing a heading called "Reply summary" near the edit summary text field? Thinking: I wonder whether a bit of context will help those Junior Contributors who do happen upon this field understand what it is. It also seems to be a common pattern. [i]
  • @Esanders: do you foresee any issues with the character counter that is shown in the mockups in T249391#6374275? Thinking: I wonder whether the character count will be accurate across languages considering the edit summary limit seems to technically be [i] 500 unicode points rather than 500 characters.

i.


ii. https://en.wikipedia.org/wiki/Help:Edit_summary#The_500-character_limit

Updates

Below are "Decisions" and "Next steps" that emerged in the conversation @Esanders, @iamjessklein and I had earlier today.

Decisions

  • Character counter: the character counter will be displayed when people are within 100 characters of reaching the limit
  • Text field: the summary text field should not adapt to the text written into it (read: the text people write should not impact the size of the field)
  • Text field heading: the summary field should have a header called Reply summary
  • The "Advanced" affordance should be visible in both of the tool's input modes: source and visual

The "decisions" above have been added to the "Implementation details" section of the task description.

Next steps
@iamjessklein to experiment with the following:

  • Making the "advanced shelf" less prominent within the tool differentiated from the commenting area
  • Adding the Reply summary heading to the summary text field
  • Identifying a place for the "Watch this page" checkbox within the advanced shelf/area
ppelberg updated the task description. (Show Details)Aug 13 2020, 11:23 PM

The latest round of mockups are to be used for the purpose of pulling together a rough prototype.

High level changes:

  • "Advanced Shelf" is below the widget via a left aligned dropdown
  • Reply Summary is now incorporated into the shelf
  • Watch this page is now incorporated into the shelf
  • There are treatments for when the user is approaching the point limit and when they surpassed it

Mockups

Advanced button - unclicked

Default - in visual mode

Approaching Point Limit - Visual

Past point Limit - Visual

Default - Source - Signed Out

Default - Visual - Signed Out

@Esanders - If you have any confusion during prototyping, just use your judgement, document what you aren't sure about and then we can tag team on it together.

The team will pick this up this week

Change 622343 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP Edit summary in advanced mode

https://gerrit.wikimedia.org/r/622343

Change 622343 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP Edit summary in advanced mode

https://gerrit.wikimedia.org/r/622343

Update

  • The patch demo linked below [i] implements the core functionality spec'd in this task. It intentionally is not opinionated about interface polish/presentation.
  • The patch demo linked below assumes when someone affects the contents of the custom edit summary field without inputting any content into the Reply Tool's text input area, the comment will be considered to be empty. Therefore, the changes to the custom edit summary field will NOT be auto-saved and the Reply Tool will NOT re-open upon the page being reloaded.

Next steps

  • @ppelberg to review patch demo [i]
  • @ppelberg to share the patch demo [i] on mw.org for community members to try and share feedback

https://patchdemo.wmflabs.org/wikis/23fd7e0b373b74aceaf8ddec1d82ab09/w/index.php/Talk:Main_Page

Hello, I asked somebody to test new demo version, but he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

Next steps

This is looking good, @Esanders. Some "Tweaks" and a "Question" below. [i]

TWEAKS

  • A. Until we decide to revise the behavior of the automatic edit summary (T254117), can the Reply summary field be pre-populated as follows /* Section heading */ Reply ?
  • B. Can we make it so you can press to shift focus from the Reply Tool's text input area to the Advanced link as described below?
    • 1. Write a comment in the Reply Tool (doesn't matter what mode)
    • 2. Press have the browser's focus go to the Advanced link
  • C. Can we make it so you can press to shift focus from the Reply Tool's text input area to the Reply summary field as described below?
    • 1. Write a comment in the Reply Tool (doesn't matter what mode)
    • 2. Click the Advanced link so as to expose the Reply summary field
    • 3. Modify the contents of the Reply summary field
    • 4. Press + (x2) to have the browser's focus go back to the Reply Tool's text input field
    • 5. Press to have the browser's focus go to the Reply summary field (❗️Currently, the browser's focus remains on the Reply Tool's text input at this step)
  • D. Can we make it so you can press + Enter to publish a comment after having written something in the Reply Tool's text input and having the browser's focus be in the Reply summary field?

QUESTIONS

  • Why is it that a custom edit summary is retained is "Scenario A" but not retained in "Scenario B"?
    • Scenario A
      • 1. Type a comment in the Reply Tool (shouldn't matter what mode)
      • 2. Click Advanced to expose the Reply summary field
      • 3. Modify the contents of the Reply summary field
      • 4. Reload the page [after bypassing the browser's warning]
      • 5. Notice the Reply Tool opens with the comment you drafted in Step 1 and the Reply summary field and content you drafted in Step 3 intact
    • Scenario B
      • 1. Type a comment in the Reply Tool (shouldn't matter what mode)
      • 2. Click Advanced to expose the Reply summary field
      • 3. Modify the contents of the Reply summary field
      • 4. Click Advanced to hide the Reply summary field
      • 5. Reload the page [after bypassing the browser's warning]
      • 6. Notice the Reply Tool opens with the comment you drafted in Step 1 and the Reply summary field is NOT exposed
      • 7. Click Advanced to expose the Reply summary field
      • 8. Notice the summary you drafted in Step 3 has been discarded

i.

  • The patch demo linked below [i] implements the core functionality spec'd in this task. It intentionally is not opinionated about interface polish/presentation.

Note: Considering the above, I've limited feedback to the custom edit summary's functionality.

Hello, I asked somebody to test new demo version...

Thank you for taking the initiative to try out the patch and share this with others, @Patriccck!

A comment and two follow up questions to the feedback you shared in line below...

...he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

It sounds like for this person, and potentially others, the way the Advanced link is presented within the tool is not obvious enough.

A resulting question for you:

  • 1. How did you ask this person to try the Patch demo prototype? I ask this curious to know what this person might've been thinking as they were trying out the prototype.

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

  • 2. What did you take their reaction to mean?

...without the context of the interaction it's a bit hard to know what "interesting" means :)

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

This is great to hear.

Next steps

T249391#6414799

  • @ppelberg to share the patch demo [i] on mw.org for community members to try and share feedback

See: https://www.mediawiki.org/wiki/Topic:Vstemnhdi8w8iw95.

Patriccck added a comment.EditedThu, Aug 27, 7:36 AM

Thank you for taking the initiative to try out the patch and share this with others, @Patriccck!

A comment and two follow up questions to the feedback you shared in line below...

...he did not register new label Advanced (he used tool before). He wrote: "OK then, why not" Short tutorial how to customize summary should be great. What do you think?

It sounds like for this person, and potentially others, the way the Advanced link is presented within the tool is not obvious enough.

Yes, I think it too. I think that this button or label (?) could be difficult to find and use for some users.

A resulting question for you:

  • 1. How did you ask this person to try the Patch demo prototype? I ask this curious to know what this person might've been thinking as they were trying out the prototype.

I wrote: "Try reply. There should be a prototype for filling summaries."

To another user I wrote, that he should click on Advanced. He wrote that it is 'interesting"

  • 2. What did you take their reaction to mean?

...without the context of the interaction it's a bit hard to know what "interesting" means :)

He wrote, that this new function for filling summaries is interesting. :-) Nothing more, nothing less.

I found Advanced immediately and I think it is good function for many users. For example at Administrations Noticebord at Czexh Wikipedia admins usually use "(not) done" or something like that (not "reply").

This is great to hear.

Needless to say, I use the tool more than all users at cswiki. :-) And I also sawn this post.

All tabbing issues are covered by T172694.

Adding "Reply" and the auto-save issue are fixed in the latest patchest.

I've set it to highlight the word "Reply" when you open the drawer as a compromise to make it easier to remove, as someone editing the commit message will likely not want to use this default text.

All tabbing issues are covered by T172694.

Roger that. @Esanders: does "D" from T249391#6414799 [i] qualify as a tabbing issue?

I've set it to highlight the word "Reply" when you open the drawer as a compromise to make it easier to remove, as someone editing the commit message will likely not want to use this default text.

Good call.

Adding "Reply" and the auto-save issue are fixed in the latest patchest.

Is this [ii] the right Patch demo wiki to be testing the patchset on? I assume so, considering the patches on which it is built was updated earlier today [iii], but for some reason I'm not seeing the changes you mentioned above implemented. [iv]


i.

D. Can we make it so you can press + enter to publish a comment after having written something in the Reply Tool's text input and having the browser's focus be in the Reply summary field?

ii.


iii.

iv. Notice the Reply summary field is not pre-populated with /* Section heading*/ Reply:

All tabbing issues are covered by T172694.

Roger that. @Esanders: does "D" from T249391#6414799 [i] qualify as a tabbing issue?

  • As discussed during today's standup, "D" [i] does NOT qualify as a tabbing issue and should be implemented as part of this task.

Adding "Reply"

I can confirm this looks fixed.

...the auto-save issue are fixed in the latest patchest.

Based on what I've seen so far, this does not appear to be fixed. Here is the behavior I've encountered:

  1. Visit https://patchdemo.wmflabs.org/wikis/65ba8c5ba1bd0a7be13e324ce9c522d1/w/index.php/Talk:Main_Page
  2. Type a comment in the Reply Tool (shouldn't matter what mode)
  3. Click Advanced to expose the Reply summary field
  4. Modify the contents of the Reply summary field
  5. Click Advanced to hide the Reply summary field
  6. Reload the page [after bypassing the browser's warning]
  7. Notice the Reply Tool opens with the comment you drafted in Step 2 and the Reply summary field is NOT exposed
  8. Click Advanced to expose the Reply summary field

Actual

  1. ❗️Notice the Reply summary you drafted in "Step 4" has NOT been retained; instead, the default copy – /* Heading name */ Reply – appears

Expected

  1. ✅ Notice the Reply summary you drafted in "Step 4" has been retained

i. Assuming you've already written something in the text input are, pressing + enter while your cursor is in the Reply summary field should cause the comment you wrote to be posted to the page.

Notes from conversation with Ed:

  • icon next to Advanced should be used from OOUI

  • The Advanced dropdown will appear underneath preview (as seen in this mockup showing source mode)

  • The character counter should show inside the text input.

ppelberg added a comment.EditedThu, Sep 3, 12:49 AM

Update: 2-September
Today, @iamjessklein and I talked about the prospect that people seeking to customize the edit summary that accompanies the comments they write with the Reply Tool might not find it. We decided this is something we should revisit once the functionality is deployed and we've gotten feedback from a larger number of people.

This work will happen here: T261908.

ppelberg updated the task description. (Show Details)Wed, Sep 9, 5:24 AM
JTannerWMF added a comment.EditedWed, Sep 9, 4:47 PM

@ppelberg needs to file a ticket for the comment summary auto-save issue (issue d). Will additionally talk to @iamjessklein about what the edit summary field will be called in UI.

@ppelberg needs to file a ticket for the comment summary auto-save issue (issue d).

Done: T262501

Will additionally talk to @iamjessklein about what the edit summary field will be called in UI.

@iamjessklein and I talked about this and agreed that we'd like for the text that appears above the summary field to read: Comment summary.

Reason: "comment" is the noun many volunteers have used to refer to what the Reply Tool produces.[i][ii][iii][iv][v]

Note: it could turn out that Senior Contributors find this language confusing or undesirable. If that's the case, we can revisit this decision once we have evidence of such.

Next steps


i. https://w.wiki/bep
ii. https://w.wiki/beq
iii. https://w.wiki/ber
iv. https://w.wiki/bet
v. https://docs.google.com/document/d/1jfuWa6T1hYgyhdDFqfRG2HJSpcZ0eAOxeE_plBOOzTk/edit#heading=h.fp4nukpilegf

👍 on design review

Deployment note
Support for custom edit summaries (what this task introduces) can be deployed once it's gone through code review.

Notes

  • T261816 is not blocking the deployment of custom edit summaries.
    • Reason: the decisions that depend on T261816 (e.g. how we prioritizeT261539) will be negligibly impacted by the us not having 1-2 week's worth of usage data.
  • QA for this task will happen as part of T261477; I've added the custom edit summary test cases as rows 26-30 to the "T261477" sheet in the Reply Tool QA workbook. (We may end up representing this testing differently depending on what @Ryasmeen thinks is best).

Change 622343 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Edit summary in advanced mode

https://gerrit.wikimedia.org/r/622343