Topic on Talk:Talk pages project/Replying/Flow

A list of tasks that have emerged from the conversations around Version 2.0 of the Replying tool:

- task T250329: Show aliases in username completion list for @ mentioning/pinging feature]

- task T250334: Implement more robust search for auto-complete for @ mentioning/pinging feature]

- task T246190: Reply v2.0: conduct usability tests (usertesting.com)

- task T246191: Reply v2.0: conduct usability test (MediaWiki)

- task T249072: Replying v2.0: add support in toolbar for special characters

- task T249074: Define approach for expanding the Replying tool's `visual` mode toolbar

- task T245222#6012991: How the Reply tool's "Watch this page" checkbox will work

- task T252084: Consider adding header to username suggestion list

- task T253434: Create an onboarding experience for the Reply tool

We would value your input on the proposed design of Version 2.0.  

Specifically, the team is curious to know how you answer the following questions:

1. What aspects of the designs do not seem clear to you?
2. What problems do you think the current designs could introduce?

Here are some links to help you answer the questions above:

• Designs for Version 2.0: source mode and visual mode
• Features planned for Version 2.0

@PPelberg (WMF), Another question. If I add mention of another user after saving the original reply, will the ping work? This is a problem with the standard system - people forget to mentions someone, and then add the link, but the ping does not function, which is not the intuitive result, and has caused a lot of confusion with new users, and is also often forgotten or misunderstood by more experienced users. It would be a real improvement if a mention later added would work.

Also why does the "style text" icon have a caret next to it? It does not seem to be functional..

The pencil icon for switch editor was not intuitive to me, I thought "what is this for, I am already in edit mode" but I can't think of anything better, and the mouseover works fine, as do the option if you click the pencil.

Going into visual editor by clicking preview was unexpected but not excessively startling.

This reply is just to see where it will go and how it will be indented.

PS: WYSIWYG, not a problem.

How does the hide function work if someone has replied already?

I see that a hidden post is not viewable from the history page for an ordinary editor. Can admins see the hidden stuff?

This line added after after the permalinked post below. to see what happens.

I used the permalink option on the post above. It has made it uneditable, which I suppose is the point, but that was not an intuitive result.

This line added after going back to the previous post and re-editing after the original posting of this post. Still trying to get a handle on the permalink function.

Looks good to me. Intuitive enough, both for source and visual mode. Nice set of features. However, users on Dutch Wikipedia might prioritize changing the edit summary and or extending the tool to some specific non-talk pages like the village pump over any of these features.

@PPelberg (WMF), Looks reasonable. Obviously there may be things that turn out to be different in reality, but the design looks good at this point. I do not see any immediately obvious problems. The proposed changes look constructive.

Where is the selection of users for mention taken from? Everyone who has previously contributed to the thread?

I think (but I might be wrong) that the idea is that you're searching all editors on the wiki. Would you prefer to have it restricted to a smaller list?

(It seems I can edit someone else's post. No offense intended, this is purely experimental, and this is the only post available to test on and I have no idea what is going to happen when I publish this)

(Mildly surprised that this is possible, undecided whether it is acceptable. Was expecting a warning that I was refactoring another person's post)

(editing after the permalinked reply below, to see what happens)

Trying a permalinked reply to see what happens if I later make another edit to @Whatamidoing (WMF)'s post

It is not clear what the permalink option is supposed to do, or if it actually does it. @PPelberg (WMF), could you explain?

This is Flow. The new DiscussionTools aren't available on this wiki yet.

I'm amused by your remarks about editing my post. One of the persistent complaints about Flow at our home wiki is that what you just did supposedly isn't possible. Obviously, it is possible, and it always has been, but the false rumor apparently has fleeter wings than the diffs proving that the rumor is wrong.

It would appear I can also hide your post, which is a thing I should generally not do.

@Whatamidoing (WMF) It is a feature I have never seen before, so I was wondering how it was intended to work. On most talk pages I am most likely to wish to mention a user who has already commented in a thread. Next most likely is someone who has previously edited the article, or a previous thread on the same talk page, probably fairly recently (not in archives). In this specific case these options would all look the same, as, in fact, they do, so inspection of the available evidence does not answer my question. Therefore my question stands.

@Pbsouthwood thank you for taking the time to review the version 2.0 mockups and share your questions and comments.

In reading through this thread, it seems like the feedback you shared fits into two categories:

1. Feedback about Flow [i], as @Whatamidoing (WMF) notes here.
2. Feedback about the design of Version 2.0 of the new Reply tool.

I'm going to focus my response here on the feedback and questions you shared about Version 2.0 of the new Reply tool. Although, you might find this FAQ helpful: Structured Discussions/FAQ.

And please let me know if I can make anything below more clear...

V2.0 design feedback

Where is the selection of users for mention taken from? Everyone who has previously contributed to the thread?

We have not yet finalized the logic that will determine how the list of suggested users to mention will be populated. This is why I was glad to see you share how you expect this to work...thank you for sharing how you are thinking about this.

With the above said, I can share how we are thinking about determining this logic and what we have implemented so far...

Logic

The logic we end up implementing for the "suggested users" list should increase the likelihood of the following being true:

1. The suggested users list makes it possible for people to quickly and easily find the person they are wanting to notify...this could mean, as you alluded to, people seeing an alphabetized list of the usernames who have already commented on the page upon typing "@".
2. The suggested users list makes it clear to people how to find the username of someone who is not currently shown in the list of suggested users...this could mean if after Person A types "@", they don't see the username of Person B (the person they are trying to mention) populated in the suggestions list, Person A will know what they need to do to have Person B's username show up in the list.

@Pbsouthwood how does the above logic sound to you?

Current implementation

*Currently,* we have implemented the suggestion list in a way such that after you type "@" you will see a list of the usernames who have previously commented on that talk page. You can see an early prototype for how this is working here: http://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page

Looks reasonable. Obviously there may be things that turn out to be different in reality, but the design looks good at this point. I do not see any immediately obvious problems. The proposed changes look constructive.

This is encouraging to hear.

---

i. E.g. switching between editors, hiding comment and permalinking.

@PPelberg (WMF)

#The suggested users list makes it clear to people how to find the username of someone who is not currently shown in the list of suggested users...this could mean if after Person A types "@", they don't see the username of Person B (the person they are trying to mention) populated in the suggestions list, Person A will know what they need to do to have Person B's username show up in the list

Nice in theory, but how would it work in practice? Bear in mind that a lot of people have a signature that differs considerably from their user name, and which may well be the identification the editor is more likely to think of at the time.

This reply gave me another idea. It could be useful to have a "Quote" tool. which will provide a talk page quote formatted copy of highlighted text in the edit box at the cursor position. Preferably it would display an exact copy of what one sees rather than copying the list format code, so the text I quoted above would have the same numbering as it had in your post.

I checked your link, but could not work out what I was supposed to be seeing

Nice in theory, but how would it work in practice?

Are you asking what determines which usernames show up in the list of suggested users to @ mention?

I tried to explain that in the comment I posted above, beginning with, "*Currently,* we have implemented the suggestion list in a way such that after you type..." but your question is leading me to wonder whether I could make my response more clear🙉.

Bear in mind that a lot of people have a signature that differs considerably from their user name, and which may well be the identification the editor is more likely to think of at the time.

Excellent point. We need to take this into consideration.

It could be useful to have a "Quote" tool.

Agreed! Tools like this will become possible to include in the "toolbar" that will accompany the release of Version 2.0 of the Replying tool. I've added this idea to the place on Phabricator where we are keeping track of ideas like this: T249074.

I checked your link, but could not work out what I was supposed to be seeing.

Ah, I'm sorry for the lack of instructions...

To test out the early @ mentioning prototype we have ready, can you please follow these steps?

1. Go to http://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page
2. Click "Reply"
3. Type the "@" symbol
4. Observe a list appears showing the usernames of the people who have already commented on the page

Note: the @ mentioning prototype exists on a test wiki. Meaning two things: 1) you can edit without being concerned for affecting other people/content and 2) you will not be able to @ mention people who have accounts on live wikis.

@PPelberg (WMF), 'Previously commented on that talk page' is clear enough thanks.

Prototype test objective now clear, but test would be more informative if there were more section and more user names on that page to illustrate.

'Previously commented on that talk page' is clear enough thanks.

You bet.

Prototype test objective now clear, but test would be more informative if there were more section and more user names on that page to illustrate.

Good call. Hopefully the page now contains enough content to get a sense for how the first iteration of the feature will work.

Please note: it looks like the the feature doesn't seem to be showing usernames in the suggestion lists from other sections on the page. We'll get to the bottom of this.

Bear in mind that a lot of people have a signature that differs considerably from their user name, and which may well be the identification the editor is more likely to think of at the time.

I'm glad you brought this up. Had you not, I'm not sure I would've thought to investigate whether the current implementation will accommodate this use case. Fortunately, it should. You can see a full explanation of the current implementation and our planned improvements to it on Phabricator here: task T232601#6057545.

@PPelberg (WMF), the display of the user identification in the "mention a user list" might be less surprising if it includes both actual registered user name and the signature used on the page, rather than one or the other. You may have intended to imply this, but just making sure it is considered. It is customary to reply to the registered user name, leaving the signature as only used by the user, hence the term signature. Some may consider it forging the signature if it is used as an identifier in a mention, but I cannot speak for everyone on this, and I am not aware of a discussion on this point. Also, this may vary between wikis.

Some may consider it forging the signature if it [another person's alias] is used as an identifier in a mention...

Good spot. I've added the following question to the task [1] where we will consider this particular part of the implementation:

For people who have aliases set, is it customary for people wanting to @-mention them to refer to them by alias or by their registered username?

The feedback you've offered here has been wonderful – thank you for thinking through this with us, @Pbsouthwood.

---

1. task T250329

Why do we need the 'watch page' option down there ? I think it just adds clutter and confusion to the flow. Are we targeting newbies or advanced users with that ? If the first, we should better explain what it does, if the second, do we really, really, really need it ?

I think it just adds clutter and confusion to the flow.

@TheDJ, can you expand on this a bit? What about the "Watch this page" do you think could cause confusion? And what kinds of people do you think could find this functionality confusing?

One thought that comes to mind: The verb to "Watch" isn't currently explained or defined anywhere in the interface, which could lead newer people to be uncertain about what affect the checkbox has, discouraging them from "checking" it.

Why do we need the 'watch page' option down there?...Are we targeting newbies or advanced users with that ? If the first, we should better explain what it does, if the second, do we really, really, really need it ?

Good question. The "Watch this page" is targeted for newer contributors.

Now, the question: Why is the "Watch this page" checkbox presented as it is?

In short, we think having the checkbox there will increase the likelihood newcomers will find out about replies to comments they post.

The above is informed by the fact that, by default, all newcomers across all wikis [1] will not have the "Add pages and files I edit to my watchlist" preference turned on.

Meaning, if the "Watch this page" element was to be excluded from the Replying workflow, there's a higher likelihood newer contributors could miss out on the input/guidance/help they came seeking.

I should note: "Watching" an entire talk page could become a distraction which is why, as @Pbsouthwood alluded to here, we intend to iterate on the "Watching" action to make it more "specific" with time.

Some examples of ideas we've started thinking about include: being able to watch specific sections and being able to elect to receive notifications when someone responds to a comment you post and/or a conversation you start.

If you have thoughts on this broader area of making it easier for people to stay informed about updates that are relevant to them and/or issues that prevent this from happening, I'd value you sharing them...here or on ticket T233447 in Phabricator both work.

---

1. There are two exceptions to the above: Arabic and Czech Wikipedias have overriden this default setting. Meaning, everyone has the "Add pages and files I edit to my watchlist" enabled by default.

What about the "Watch this page" do you think could cause confusion? And what kinds of people do you think could find this functionality confusing?

I think that no person that isn't a wiki veteran will understand what 'watch this page' means and what its effect will be. There is a 'scary checkbox' (as my father would say), which will pause their minds as they ponder its functionality and delays them from achieving their goal of answering.

The "Watch this page" is targeted for newer contributors

Then we have to educate them.

In short, we think having the checkbox there will increase the likelihood newcomers will find out about replies to comments they post.

I'm sure they will find it, but they won't necessarily know what to do with or, nor will feel empowered to figure out what it does.

Meaning, if the "Watch this page" element was to be excluded from the Replying workflow, there's a higher likelihood newer contributors could miss out on the input/guidance/help they came seeking.

Some examples of ideas we've started thinking about include: being able to watch specific sections and being able to elect to receive notifications when someone responds to a comment you post and/or a conversation you start.

I agree with that assessment, but i don't think that the watch this page option is good path to solving the problem, not even as an intermediate (and honestly, it will come back as a boomerang when later on seasoned editors will demand it to stay). I'd just skip it and not waste the time, and explore the more complex and more useful ideas in the 3.0 version.

I think that no person that isn't a wiki veteran will understand what 'watch this page' means and what its effect will be. There is a 'scary checkbox' (as my father would say), which will pause their minds as they ponder its functionality and delays them from achieving their goal of answering.

@TheDJ, you may be right here: newcomers may not understand what it means to "Watch this page" and worse yet, become confused to the point they abandon posting their reply.

Although, these usability testing will help us better understand the extent to which the above are in fact true. Here is the usability test we have planned to figure the above out: task T246190.

I agree with that assessment, but i don't think that the watch this page option is good path to solving the problem, not even as an intermediate (and honestly, it will come back as a boomerang when later on seasoned editors will demand it to stay).

This is on my mind too: "What if we make a change that doesn't have the affect we intend it to, but people become attached to it?"

Although, I think the risk of this is low for now, considering the Reply tool is being used by people on a select number of wikis, many of whom are aware that it is an experimental state where functionality changes on a weekly basis.

With the above said, you might be right, this intermediate step may not end up being valuable in which case, we can revise it before the tool gets deployed beyond our partner wikis.

> by default, all newcomers across all wikis [1] will not have the "Add pages and files I edit to my watchlist" preference turned on

Maybe we should solve that problem at the source, then. If we want people to use their watchlists, then making it default-on is probably the right choice.

"Watch this thread" might be handy if practicable. Pbsouthwood (talk) 14:53, 9 April 2020 (UTC)

Right now, it'd be a "watch this whole page" button.

And to clarify

> if the second, do we really, really, really need it ?

It can be moved into a submenu. Or even as a submenu option of the save button for instance. [Save][▾] with in the menu "[un]watch", "Do [not] notify mentioned users", "Add summary" etc.

This post is about the @-mention prototype on patchdemo, rather than the mockups.

• it looks like the the feature doesn't seem to be showing usernames in the suggestion lists from other sections on the page – I assumed that was intentional.
• When there's a lot of users, how would you indicate that there's more than are displayed?
• It wasn't immediately obvious to me that I could keep typing after the @ to filter the list. But once I discovered that, it was easy to use and felt responsive (though the latter can be hard to judge on a small test page).
  • Is the intention to keep it like this or make it more like the Mention tool in Structured Discussions editor (Visual mode)? I find the SD tool can be a little slow to retrieve names. It does have the affordance of a search box, but you have to tap into that rather than just typing in place. I can see advantages to both.
• How to inform people that @ is magic? Will VE users be unsurprised since they're already used to [[ and {{ causing things to pop up? If you hadn't said ‘go here and type @’, I wouldn't have thought to try it.
• After a little practice, I did discover how to type a (possibly multi-word with spaces) username that's not on the suggestion list and insert it. (Reasoning was along the lines of "oh, they are displaying the characters I typed at the bottom of the list in addition to on-page, I wonder if that's tappable/clickable.") Also how to change the display text since it's just a normal link and invokes the usual VE link tool.
  • TheDJ's suggestion of working with both the username and display alias is intriguing. Could you have a two-column list and set the link text to one or the other by tapping on the left or right side? E.g. I type "@gu" and get something like below.

    [ JzG       | Guy       ]
    [ Guy Macon | Guy Macon ]
    [ gu                    ]

Oh, haha, I just switched to Desktop web and tried typing '@' in visual editing mode here in SD. It behaves almost the same. You could maybe just slap in the same Mention UI and extract the names differently (as wiki talk and SD have different underlying structure).

SD Mention starts out suggesting people who've posted to the board or topic, but then when I start typing it searches everyone. Would it be better to filter the list as in the prototype and add an item to "find more people"?

If I edit a mention in SD, the Remove button is bottom-left and is obscured by a list drop-down. Let's not copy that aspect, please.

One thing I've noticed in the past is that SD wouldn't let me Mention a person with a redlinked user page. There are a lot of new users and IPs who fall into that category, check en-wp Teahouse for example. Often they have a blue talk page with a welcome template, but not always.

I also want to be able to set custom display text for a Mention, e.g.: {{FlowMention|PPelberg (WMF)|Peter}}, {{u|Whatamidoing (WMF)|WAID}}, [[User:Whatamidoing (WMF)|Sherry]]. In SD, I can do that in source but not visual mode for FlowMention. Do we want to give that ability to teh noobs, um, Junior Editors? (VE user != noob, not always, but no need to digress further on that.)

There are quite a number of longer term editors on English Wikipedia who have redlinked user pages because they want it that way. There is no requirement to have a user page, but we want to be able to mention those users in discussions.

Definitely. The feature will support sending pings/notifications to people whether or not they have created a user page or not.

Minor aside: not picking on the Guys for any reason other than they were the first concrete example that came to mind. Andy Mabbet and SaraSV are two other notable wikipedians who are well known by both their usernames and their signature display-names. If it's inappropriate for me to use real people as examples, then please advise and I'll replace it with some fictional ducks.

@Pelagic, the comments you posted above lead me to think you gave the early prototype a thorough review...thank you for doing this! You brought up a few different points. I'm going to respond to each of those in separate comments in an attempt to make them more legible.

...it looks like the the feature doesn't seem to be showing usernames in the suggestion lists from other sections on the page.

That's right. As the functionality is currently planned, when someone types @ the suggestion list willl show the usernames of the people who have commented in the section where the reply is being drafted.

As I think you discovered, to mention someone that's not in the suggestion list, you would need to type @ + character(s) their username begins with.

For example, typing @pe should return "peter" and "pelagic" but not "snape"

You can see the more advanced ways of handling search we've discussed (but have not yet prioritized) in this task on Phabricator: https://phabricator.wikimedia.org/T250334.

It wasn't immediately obvious to me that I could keep typing after the @ to filter the list. But once I discovered that, it was easy to use and felt responsive (though the latter can be hard to judge on a small test page). -- Is the intention to keep it like this or make it more like the Mention tool in Structured Discussions editor (Visual mode)? I find the SD tool can be a little slow to retrieve names. It does have the affordance of a search box, but you have to tap into that rather than just typing in place. I can see advantages to both.

Our plan is for the search experience to happen within the text input itself, rather than have peoples' focus be shifted to a separate search box as is done in Flow/Structured Discussions.

With this said, you raise an important question for us to be mindful of: Do people find it intuitive that they can continue typing after the @ to affect the suggestion list?

If they do not, we could explore implementing something like Phabricator where the text typed into the comment box is also shown in the suggestion list thereby making the relationship between them more clear.

Anyway, I've represented this question on Phabricator in this task: https://phabricator.wikimedia.org/T246191#6091905

How to inform people that @ is magic? Will VE users be unsurprised since they're already used to [[ and {{ causing things to pop up? If you hadn't said ‘go here and type @’, I wouldn't have thought to try it.

In the initial version, we are planning for there to be one way to initiate the username suggestion list: typing @.

Reasoning: we assume that typing @ is a known design pattern/convention that does not need to be visually communicated in the interface.

Caveat: you raise a good point and calls into question the assumption we've made that typing @ to initiate the suggestion list will be intuitive to everyone.

We are tracking this assumption on Phabricator in this task: T232601#6091882.

We will test this assumption through testing in this task: T246191

After a little practice, I did discover how to type a (possibly multi-word with spaces) username that's not on the suggestion list and insert it. (Reasoning was along the lines of "oh, they are displaying the characters I typed at the bottom of the list in addition to on-page, I wonder if that's tappable/clickable.")

I appreciate you sharing this internal monologue. Seriously! One of the things we are constantly trying to do is figure out what people are thinking/expecting as they use features. So, having you share your thoughts with us explicitly makes that question a bit more knowable ^ _ ^

TheDJ's suggestion of working with both the username and display alias is intriguing. Could you have a two-column list and set the link text to one or the other by tapping on the left or right side? E.g. I type "@gu" and get something like below.

Great question. Short answer: yes, it is possible to have the suggestion list show the usernames exactly as they appear in the page (alias or not).

With this said, we have not prioritized this functionality in the initial version. Which leads me to wonder:

What led you to ask about aliases? Are there people you communicate with regularly who you refer to by their alias? Are there other people you see doing this? Something else?

And related to the above: Have you read any documentation that talks about what the "correct" way is to refer to ping someone who has an alias set?

You can read more details about how we are currently thinking about aliases in this Phabricator task: https://phabricator.wikimedia.org/T250329

If you're not familiar with MediaWiki, then you would probably try to ping someone by the displayed name instead of the real username.

> What led you to ask about aliases?

I saw comments elsewhere in this topic. Hadn't crossed my mind before that.

> Are there people you communicate with regularly

not really

> refer to by their alias?

If I suspect the person might not want to be called by their username (maybe they don't hate it enough to change it or abandon the account, but prefer their displayname), I'll try to respect that. If it's someone I don't know well, I could be guessing wrong. Only one comes to mind, but I don't want to make an example of them here.

> Are there other people you see doing this?

It can be noticeable when they don't. E.g. If a comment is signed "Guy" and the next commenter mentions "JzG", any reader who is unfamiliar with the way he signs will do a double-take, and eventually may hover (or long-press) the names to discover that they link to the same user page. It's unusual for the alias and username to lack an obvious connection, but it does happen.

Can't say I've really noticed how often people do pipe the user link. It might be possible to do some automated analysis to quantify this. I suspect unpiped is more common, but could be waaay off-base there.

I see people like WhatamIdoing, Iridescent, and GorillaWarfare referred to as WAID (sometimes), Iri, and GW (often), but usually in plain text and not as part of the ping. (See next.)

> Something else?

Sometimes I'll risk being overly-familiar and manually pipe a shorter version than the display and user names. Maybe initials for a really long name, or something like [[User:john.q.citizen|John]] for someone who uses what looks like a real name. That's probably not a common practice, and isn't changed by the search-and-insert function.

> Have you read any documentation that talks about what the "correct" way is ...?

No, I wish I had.

> If you're not familiar with MediaWiki, then you would probably try to ping someone by the displayed name instead of the real username.

Yes. In the current method of replying, I start a section-edit and can see the previous users' sigs in their wikitext forms. I can copy-paste a user-page-name directly, with its User: prefix; and, if it's unstyled, the piped displayname also. But if a user is replying in a discrete box, the displayname/alias is the thing they see on-page, and they need to know about hovering or long-pressing a link to see the URL, then discern the username from that.

This context is helpful - thank you for sharing it, @Pelagic. I've included links to the comments you and @Whatamidoing (WMF) shared about aliases in the task where we will consider implementing this functionality: https://phabricator.wikimedia.org/T250329.

SD Mention starts out suggesting people who've posted to the board or topic, but then when I start typing it searches everyone. Would it be better to filter the list as in the prototype and add an item to "find more people"?

Maybe...for now, we're intentionally taking, what we think is a straightforward approach [i] to help people form a clear mental image for the feature and then augment it if/when we discover inefficiencies or parts of the experience that are not clear.

---

i. See the "Requirements" of this task's description: https://phabricator.wikimedia.org/T232601

One thing I've noticed in the past is that SD wouldn't let me Mention a person with a redlinked user page. There are a lot of new users and IPs who fall into that category, check en-wp Teahouse for example. Often they have a blue talk page with a welcome template, but not always.

You and @Pbsouthwood raise a great point here. Fortunately, this functionality will send notifications to people whether they have created a user page or not.

I also want to be able to set custom display text for a Mention, e.g.: @Peter, WAID, Sherry. In SD, I can do that in source but not visual mode for FlowMention. Do we want to give that ability to teh noobs, um, Junior Editors? (VE user != noob, not always, but no need to digress further on that.)

You should be able to set a custom display text in the Reply tool's `source` mode. Although, we do not have plans to support this in the visual mode.

I really do not like that this interface doesn’t look like any editing interface people might be using in other parts of MediaWiki. Even Flow uses a more familiar layout, despite having the same shortcomings like rightward ‘Reply’ button etc. I hope this is just mockup, and not a finished version of the design.

(I also hope that someday the team will listen to people telling it to stop the propaganda of description list syntax for indentation in discussions.)

I hope this is just mockup, and not a finished version of the design.

It is very much a mockup/technical prototype; the version that gets deployed will be visually consistent with editing interfaces people use in other parts of MediaWiki.

In fact, you can see some examples of the design we have planned here: Talk pages project/replying#Version 2.0.

If you have feedback about these, we would be keen to hear it.

Maybe I am missing something, but I was commenting on those exact images in that section. Glad to hear that it would reflect (did I get that right?) other editing interfaces, that’s great.

I'm not sure that you two are talking about the same thing. Just in case, just for clarity, there are no plans to use the toolbars from any existing wikitext editor. There are also no plans to support multiple toolbars, so every user will see the same thing.

It seems rather strange that you would use essentially visual editor (or not?) for edit forms in the second version, but would reinvent the entire toolbar. Either way, I’m not the PM :-)

The reply box shrinks (horizontally) as the conversation becomes more indented, so the regular toolbar won't fit. Some editors complain about it not fitting properly even when it has the whole screen available, so getting only a fraction of the screen would be impossible. Try it out after comment 20 at https://fr.wikipedia.org/wiki/Discussion_utilisatrice:Whatamidoing_(WMF)?dtenable=1#Test_2 Imagine that with a bit of zoom, or on a smaller screen.

Flow’s edit form is similar in the size on my screen, but I do get the argument. If you try Russian Convenient discussions script, it uses the default edit form of WikiEditor and typically fits it on one row for me circa until 20th level of indentation. A good thing WikiEditor does if it doesn’t fit on a row is overflowing onto a separate row, I would guess the devs here would want a similar behaviour.

On my screen, it's much narrower, and with WikiEditor's "Advanced" tab open, the height of the toolbar (using a window with that width) is double the height of the Reply tool's editing box.

@Stjn, What is description list syntax?

: is semantic syntax for creating HTML description lists. * is semantic syntax for creating any kinds of lists. Using : for indentation in any tools is bad for accessibility and semantic code.

OK, Aware of the problem. just didn't recognise the terminology. I thought it was definition lists. Same thing really I guess. As I understand it, its the gaps that wreck the logic for accessibility.

@Pbsouthwood "its the gaps that wreck the logic for accessibility." No it's always an accessibility problem. Just one that most screenreader users have accepted and one that isn't terribly 'noisy'. Adding gaps in the mix turns that accessibility problem into an absolute clusterf*#k that turns the screenreader experience into a some sort of audio/tactile pinball machine experience.

@TheDJ, I am quite happy to accept that it is never good. Currently I don't need a screenreader so don't have any personal experience of the problem, but also strongly in favour of accessibility to all, so would be interested to know what does work. ~~~~

Version 2.0 looks very promising! First comments from my side:

1. I miss the character toolset from both the source and the visual input surface. I don't say, it is a priority task, but I hope that it will appear in the close future, and it would be useful to find out its place and conception in the mockup already in this phase.
2. I don't see the importance of the highlighted Watch this page option under the input field. Everybody can change in their settings if a page should be added to the Watchlist in case of editing the page or not; and anybody can any time add or remove a page from the Watchlist by a single click on the page. I think, this option is even confusing: what happens if I already watch a page but I leave this box empty? I would omit this option completely from the Reply tool.
3. Will be the Inserting options for experiences editors of VE like visual table editing available as part of the tool? It would be great (and important).
4. Can't we just use the toolset which the 2017 wikitext editor or VisualEditor has at the top of the input area? It is there, and the user experience could be unified on the different types of pages.

Thank you for these questions, @Samat. I'm going to respond to each one in a separate comment...

I miss the character toolset from both the source and the visual input surface. I don't say, it is a priority task, but I hope that it will appear in the close future, and it would be useful to find out its place and conception in the mockup already in this phase.

Adding use cases (as you think of them) to the task (T249072) is a big help...thank you for continuing to do this, @Samat! This makes it easier for us to make an informed decision about prioritization.

Regarding prioritization...

While the initial set of tools (linking, italicizing and bolding) is set for the initial release, we will revisit whether additional tools need to be added once we are confident the feature is stable.

Said another way: we do not currently have plans to add support for additional tools beyond those listed above; however, we will revisit this once the tools has been deployed to our partner wikis (Arabic, Dutch, French and Hungarian).

This thinking will happen in this task:T249074: Define approach for expanding the Replying tool's `visual` mode toolbar.

The "Watch this page" option...

I don't see the importance of the highlighted Watch this page option under the input field. Everybody can change in their settings if a page should be added to the Watchlist in case of editing the page or not; and anybody can any time add or remove a page from the Watchlist by a single click on the page.

These are good points. It sounds like you see this functionality as redundant.

With this in mind, I wonder if it would be helpful for me to share a bit more about how we're thinking about this feature. So you're aware, some of the below is copied from the interaction TheDJ and I had above here: Topic:Vju7lfcav875rt8r.

We think having the checkbox within the Reply tool will increase the likelihood newcomers will find out about replies to comments they post.

The above is informed by the fact that, by default, all newcomers across all wikis will not have the "Add pages and files I edit to my watchlist" preference turned on.

I think, this option is even confusing: what happens if I already watch a page but I leave this box empty? I would omit this option completely from the Reply tool.

The "Watch this page" checkbox within the Reply tool will "talk" to the "⭐️" atop the talk page as well as Watchlist preferences.

So, in the case you are describing, the "Watch this page" checkbox within the Reply tool will already be "checked." You can read more details about how the checkbox will interact with Watchlisting preferences in this Phabricator ticket: T245222.

With the above said, you may be right here: people, across experiences levels, may not understand what it means to "Watch this page" and how it interacts with other Watchlisting preferences/actions.

Although, we think we will be in a better position to know the extent to which this part of the interface is confusing, helpful, valuable, etc. once people have been able to experience it for themselves. To this end, we have three things planned:

1. A usability test of this functionality with people who are new to participating on Wikipedia talk pages: task T246190.
2. Listening for feedback about this functionality from volunteers at our partner wikis where this functionality recently became available.
3. Conducting testing of this functionality on MediaWiki once we have a prototype of the visual mode ready: task T246191.

If specific questions come to mind that you think would be valuable for us to seek answers to in the testing we have planned, please let us know.

@Samat's question about "what happens if I already watch a page but I leave this box empty?" is all too plausible to me. We could end up with newcomers accidentally un-watching the page. If we want newcomers to get pages on their watchlists, then maybe we should be talking to @MMiller (WMF) and @Trizek (WMF) about changing those defaults (presumably the database folks would have to agree) or teaching newcomers what a watchlist is and how to click the star at the top of the page.

@PPelberg (WMF) thank you for the detailed answer! Actually, I do not feel this problem very critical, I just wanted to share my personal impression about the prototype. Turning on the "Add pages and files I edit to my watchlist" preference by default would solve the mentioned goal ("will increase the likelihood newcomers will find out about replies to comments they post") "more naturally", cleaner in my option, than the need to explain for newcomers what watchlist is and for experience editors why do they have redundant options inside a visible part of a page (and how they connected or interact each others).

Though, using this feature for watching the actual section separately would add an extra, useful functionality to it...

Will be the Inserting options for experiences editors of VE like visual table editing available as part of the tool? It would be great (and important).

Initially, no – the editing toolbar within the Reply tool's visual mode will be limited to linking, italicizing and bolding.

@Samat, can you share a bit more what prompted this question? Are there particular reasons when/why you'd value inserting a table, image/media, etc.?

I ask because this kind of information will be important to have on-hand when we explore adding more tools to the editing toolbar in this task: T249074: Define approach for expanding the Replying tool's `visual` mode toolbar.

@PPelberg (WMF) I thought on your question, and I can say that strictly in discussions usage of tables, images, etc. is not typical. Sometimes we use them (example1, example2, example3), but not very often. They are rather nice-to-have features, but we can probably live without them :)

What I thought and wanted to say, that I miss very much the VisualEditor's features from non-discussion pages, where they are not available. For example we have large tables on many pages in the Wikipedia namespace. Editing these pages is often a nightmare. Workflow: I create a page on my user subpage (where VE is available), then I move to the Wikipedia namespace. I realize, that I should change something. Option1: spending half hour with programming wikicode, or Option2: copy the wikicode to a user subpage, edit there with VE in 5 secs, then copy the changed wikicode back to the Wikipedia page, and save there. How nicer would it be with VE Option3: open, edit in 5 secs, save? Example (happened with me): please replace the "bot" and "járőr" columns in this table (side note: VE cannot handle background colors, therefore the example is not perfect: I originally used X which I replaced later with the css code). Until now (despite of several requests), VE developers were against deploying VE on other namespaces because it is not developed for discussions. Do you see the possibility that we can separate the discussion and non-discussion pages, then on the discussion pages we make the DiscussionTools and on the non-discussion pages the VE available? (Current page selection with __NOEDITSECTION__ or with the wgExtraSignatureNamespaces parameter does not seem to support this separation for the project namespace, for example.)

Can't we just use the toolset which the 2017 wikitext editor or VisualEditor has at the top of the input area? It is there, and the user experience could be unified on the different types of pages.

This is a good question. We have talked about using the 2017 wikitext editor for the Reply tool's sourcemode although, we do not currently have plans to implement this.

Although, this could change if people start requesting an editing toolbar in the Reply tool's source mode.

The toolbar is too big. Right now, if your window/zoom combination is too narrow, the toolbar wraps onto a second (or even third) line. This uses a lot of screen real estate. We talked in ~2015 about the need for a system that would collapse it or scroll it or something, so that it was only one line, but we never got anywhere with that.

How the 2.0 mockups (visual, source) relates to the demo wiki's version? Which one is the newer conception?

I'm glad you asked this, @Samat.

These mockups (visual, source) are the newest conception.

What is available on the demo wiki should be considered a technical prototype we (our team, you, everyone here, etc.) are using as a way to test functionality.

Can we have a❓hint button that pops up a list of tips? On Phab I'm always using the 📒 book buttton to remind myself how to do things in Remarkup, and I find its location above the edit box handy.

Yes it adds a translation burden, but I'm thinking of soemething really short that highlights the most non-obvious features, like:

• Comment will be automatically indented and signed.
• Type @ to mention and notify someone.

@Pelagic, which tips would you add first?

@Whatamidoing (WMF) The two above. ;)

• Plus indicate any wiki markup that isn't (yet) supported/recommended, e.g. tables. I noticed some of our colleagues on fr-wp asking about that.

• Do we need to say explicitly that the box accepts wikitext? The other tips could be worded to imply it.

• Maybe note anything that differs from ReplyLink for the benefit of people who use it, on applicable wikis. (I don't have experience with it myself.)
• Edit summary will be automatically generated. [if applicable, but there's a better alternative]
• Link to a more-info, help, or discussion page.

When visual mode arrives, do we need a separate tips-list for each mode? The visual toolbar may be self-evident enough. But then with the cut-down toolbar in Mobile VE and in SD, it's not obvious how to do templates or block-level formatting if you don't know the magic keystrokes.

Consider whether to automatically pop up the tips box on first use. (Too intrusive? Question-mark button obvious enough by itself? Do people have trouble intuiting the equivalent button on Phab? but that's a very different audience.)

Rationale:

• Auto-signing should be evident from the preview, but it doesn't hurt to mention. We see people adding ~~~~ here in Structured Discussions out of habit.

• Indenting. The visible indent of the edit box is a hint, but for those used to wikitext it mightn't be obvious at first that means they should leave out the :::
• @-mentions. Not obvious until you discover it.
• Edit summary. Long-time users will wonder “where is the edit summary?” or “will there be one?”. I'd prefer to have a box that actually displays the summary and gives me the option to tweak it, rather than a tip that tells me I can't.

Good suggestions.

Assembling that, it could look like:

• Reply will be automatically indented and signed. No need to type ::::: or ~~~~
• Type @ to mention and notify someone.
• Use wikitext here, but for tables and complex markup edit the section instead.
• ✏️switches to visual editing mode.

Learn more • Discuss

Do you want to see that every time you reply, or only the first (second/third/?) time? Or should it all be hidden in a "(?)" info button?

@Whatamidoing (WMF): Info button so it’s always available for users to consult. Pop-ups tend to get in the way of people achieving what they set out to do, and can be dismissed/closed without absorbing the message. Plus if it’s once-only or has a "don’t show this message again", then you have to track that for each user, and what about IP editors?

Including the about and feedback links (or, as verbs, learn more and discuss) increases the usefulness of the button beyond being just a hints list and toward general help. After the initial phase, you mightn’t need the separate feedback text below the licensing message, if it’s present here? My thought was to combine immediate brief answers with links to more detail. Whether to use about, help, feedback, learn more, discuss, etc. (multiplied by x-number of languages) is an open question.

When a user enters ~~~~ we should pop up a warning and say something like "With this form, your post will be signed automatically, you do not need to use ~~~~ to do so". But don't forbid people to do so, just warn. There might be cases where signatures are discussed for instance and it is appropriate to use ~~~~.

Can we have a❓hint button that pops up a list of tips? On Phab I'm always using the 📒 book buttton to remind myself how to do things in Remarkup, and I find its location above the edit box handy. Yes it adds a translation burden, but I'm thinking of soemething really short that highlights the most non-obvious features...

The idea of adding explicit guidance/help to the Reply tool to help people more quickly form a clear and accurate mental image of how the tool works is a great idea to explore, @Pelagic.

A clarifying question for you: What inspired the list of components you shared here?

Outside of the above a few other questions come to mind (below)...

Questions

Please do not feel an obligation to answer these questions, although please do if you feel compelled! I'm mostly sharing the below as a way to bring form to the thoughts in my mind. They are also now in this Phabricator task: T253434.

- [ ] What "foundational" aspects/details about the Reply tool contribute most to peoples' understanding of it and confidence in it? How do these aspects/details vary between people have lots of experience contributing to Wikipedia and people who are newer to the project?

- [ ] Once those aspects/details have been defined, what is the most effective sequence for introducing/teaching those concepts?

- [ ] What is the best way to teach those concepts?

- [ ] What "tertiary" concepts/functions are important to explicitly communicate in the interface? Here, I'm thinking of ideas like hints around what kinds of wikicode the Reply tool supports and doesn't as well as how the tool handles signatures, per the feedback @TheDJ shared here.

- [ ] What is the right balance between guiding (e.g. a walkthrough) and self-guided discovery (e.g. tooltips, hints, etc. that are presented in context, in response to peoples' explicit actions)?

What inspired the list of components you shared Initial inspiration was that I found the @-mention non-obvious, and noticed the contrast versus Structured Discussions where there is a +👤 button. Then I tried to think of other things that people might trip up on, but also considered comments others have made.

Without finding specific links right now, a couple of people have asked about including the ::: explicitly in the edit box; the pencil icon for switching edit mode comes up not infrequently in VE and newbie discussions (but I was forgetting that the mocks and now the 2.0 prototype don’t use that! so I’ll strike it out); people from the pilot wikis have asked about what markup will/won’t eventually work.

For the other questions, I’ll have a think and try to answer at the Phab task, but thanks for listing them here!

Oops, forgot echo @PPelberg (WMF)

Edit summary. Long-time users will wonder “where is the edit summary?” or “will there be one?”. I'd prefer to have a box that actually displays the summary and gives me the option to tweak it, rather than a tip that tells me I can't.

@Pelagic can you share a bit more about your experience with edit summaries when editing or reading talk pages?

...what typically leads you to customize the edit summary when posting comments on a talk page?

...what typically leads you not to customize the edit summary when posting comments on a talk page?

How does whether or not someone has provided a custom edit summary when responding on a talk page affect your experience as a "consumer" of those edits?

Hello @PPelberg (WMF), I'd like to share my thoughts about edit summaries:

In general, any discouragement of using the edit summary (or: accomodating not getting accustomed to using it) isn't a good idea in my opinion, since it is an Important Part™ of wiki editing. When posting comments on a talk page:

• My most used edit summary is probably just "re", similar to the default summary "Reply".
• I guess I typically don't customize that default when I'm in a one-to-one discussion with somebody (or in a one-to-one part of a larger discussion). Probably also out of laziness sometimes.
• I tend to add the name of the one I'm replying to, particularly in discussions with multiple participants (e.g. "re PPelberg").
• Other habits (instead of, or in addition to, "re" or "re <name>") include a short summary of the comment or some other (mostly positive) remark – "addition" (or: "+"), "agreed" (or: "+"), "agree with <name>", "great!", "nice idea!" – or a response to the previous edit summary (reflecting the on-page discussion, or acting more like a [light-hearted] sideline conversation).
• When I want to draw someone's attention to the discussion, but there's no need to include their name in the comment, I can mention them in the edit summary.

As long as we're not able to change the edit summary, I'd like to see any default summary like "Reply" removed (so limit it to just the autocomment part, i.e. /* name of the section */):

• Whatever word is chosen as the default summary, it will never cover all possible uses of the reply tool: it might be a reply in most cases, but it might as well be a semi-related comment or an addition to a previous (own or someone else's) comment.
• "Reply" (or any similar word) looks like a user-added text, which it actually isn't; such a default summary i.m.o. doesn't look very professional (for an otherwise quite professional tool, I'd like to add!).
• Something like "Comment added using the [reply tool]" would be better than "Reply", but since we already have the tags, it's superfluous (and unnecessarily cluttering the history page).

With kind regards

what typically leads you to customize the edit summary when posting comments on a talk page?

• If I’m likely to make multiple replies in a section, I might want to distinguish them as “reply to Soandso” or “comment about somesuch aspect”.
• If I’m just thanking someone or acknowledging their input without adding anything substantive, I may put “thanked Soandso” or similar in the summary. That way watchers can know they don’t need to click through to read the details.
• Certain editing interfaces don’t include the section heading in the edit summary. Others do but don’t display it prior to saving/publishing. I’m always forgetting which is which. So if I’m not using Old Faithful (a.k.a. the "classic" editor), I might write something more descriptive than “Reply”, just in case. Assuming that it’s even possible to add a summary at all.
• Like Mar(c) above I may write “agree” or even “agree with Soandso about the something”; conversely “alternate proposal” or “different take on this”. What leads me to that? Maybe the hope that it could be useful. Or a sense that good summaries are "the done thing" for content space so why not also for discussion space?

what typically leads you not to customize the edit summary when posting comments on a talk page?

• If the section is brief, and has a descriptive heading, and I’m confident that section heading will be automatically included in the summary, then there's not much more to add beyond “comment” or “reply”.
• For a complex post, it could be hard to come up with a short summary that does it justice, so I’ll settle for generic “response”.

How does whether or not someone has provided a custom edit summary when responding on a talk page affect your experience as a "consumer" of those edits?

• If it's something I want to refer back to, then having a descriptive summary can help me find it again from my contribs (improved search in contribs and history is also needed).
• I don’t tend to work my watchlist, but for those that do, maybe it could help draw attention to a significant comment with a custom summary to distinguish it from a routine reply?
• If someone's making a minor correction, they can indicate that; if refactoring a conversation, hatting and collapsing a long ramble or doing something non-standard, then they should explain themselves either on-page, in the edit summary, or preferably both. Neither of these currently apply to the Reply feature.
• Descriptive summaries, if they were used more, would make the page History more approachable, and useful as an overview. Picture a list that contains a some mix of “support”, “oppose”, “different idea”, “agree with Bob”, “call for calm”, “take it to ANI” versus “Reply”, “Reply”, “Reply”, “Reply”.

@Mar(c) and @Pelagic: thank you for being patient.

And thank you for sharing these wonderfully clear and comprehensive explanations of how you think about and use edit summaries and how you imagine others do the same.

You can expect me to be back in touch about edit summaries and the Reply tool in the next couple of weeks.

For context: now that the usability testing of Version 2.0 of the Reply tool is complete, we are shifting our attention to how the tool can be improved in response to the issues that surfaced during testing.

@Geraki, @Gryllida, @Mar(c) and @Pelagic: you all shared feedback about the ability – or lack thereof – to customize the edit summary that accompanies comments made with the Reply Tool.

We are now working on this and have an initial approach for how this can be implemented... what do you think of the approach we have in mind (below)?

Approach to supporting custom edit summaries

Here is the initial approach we have in mind for adding support for custom Edit Summaries to the Reply Tool...

People would be able to customize the edit summary that accompanies a comment they write using the Reply Tool by turning on "advanced mode" (exact name TBD) within Special:Preferences.

Once this to-be-named preference is enabled, people would see an affordance (e.g. a link, arrow or button) within the Reply Tool that, when clicked, would expose a field where they could write the edit summary that would accompany the comment they are writing.

The above is inspired, in part, by how @Jack who built the house has implemented similar functionality in Convenient Discussions:

A screenshot showing Jack who built the house's Convenient Discussions tool.

Advanced users will understand what the extra line is doing. I doubt novices would understand this. So it is a good thing this is an advanced mode preference.

Advanced users will understand what the extra line is doing. I doubt novices would understand this.

Thank you for thinking about this @Ad Huikeshoven; what you described matches up with what we are thinking as well.

Users are generally advised to always leave an edit summary, and an edit summary field is displayed on all edits just above the "Publish" button, so I am sure that novices will understand it, if there is a description like MediaWiki:Summary (Summary ^(?):) next to it.

If there is a need to hide the field (I don't believe there is) and expose it on demand, then put a tick box that would reveal it, but not hidden in preferences.

@Geraki, thank you for putting thought to this...a follow up question for you.

Follow up questions

Can you share what's leading you to think the option to add a custom edit summary should be exposed by default and not something that is exposed by turning on a preference?

Two thoughts come to mind that led you to suggest the custom edit summary be exposed by default: A) you are assuming tenured editors will expect the custom edit summary to be available by default and/or B) as @Mar(c) mentioned below, you see edit summaries as a core action and should be treated as such (exposed by default).

Yes, experienced users expect that an edit summary field is always displayed for every edit or action. In fact there are only a handful of actions among hundrends where a user does not have the chance to provide an edit summary. And even there, users find workarounds to leave a comment of why and what they did (f.e. sysops adding a summary through the url parameter in a rollback, or leaving a comment in the description when they change something in the abusefilter).

Communities already mention that "It is good practice to fill in the edit summary field, or add to it in the case of section editing" and this was reflected to MediaWiki itself: There is a preference "Prompt me when entering a blank edit summary (or the default undo summary)". Currently the Reply tool does not raise a prompt to enter an edit summary because the reply tool adds a "Reply", but this is a hack. It is still a default.The community has even created more than one tools to analyze the usage of the edit summary (most modern https://xtools.wmflabs.org/editsummary/en.wikipedia.org/Jimbo%20Wales) Some people in enwiki actually do look at the numbers among other things to judge if a user can become a sysop!

So, there is a contradiction here, asking the users to utilize the edit summary, providing a function to prompt them when they don't, and then not exposing it by default?

At least Flow -now Structured Discussions- does put an edit summary that is not default, but the begining of the post. https://www.mediawiki.org/w/index.php?title=Talk:Talk_pages_project/replying&action=history I like this approach and I would love to see it as the fallback if the user does not manually enter an edit summary.

Thank you for adding this additional context, @Geraki. Two follow up questions for you...

1)Currently the Reply tool does not raise a prompt to enter an edit summary because the reply tool adds a "Reply", but this is a hack. It is still a default.

Can you share what you mean by the Reply Tool not prompting people to enter an edit summary as being a "hack"? As i understand, the Prompt me when entering a blank edit summary (or the default undo summary) preference is disabled by default...

2) Can you confirm I'm understanding "A," "B" and "C" as you intended them?

A. "...asking the users to utilized the edit summary..."

Here you are suggesting this "ask" is being made by the tradition/custom described here: https://en.wikipedia.org/wiki/Help:Edit_summary#Always_provide_an_edit_summary

B. "...providing a function to prompt them when they don't..."

Here you are referring to the existence of the Prompt me when entering a blank edit summary (or the default undo summary) preference.

C. "...not exposing it by default."

Here you are referring to the Reply Tool NOT currently showing the custom edit summary field by default.

@PPelberg (WMF)

1) Yes, the preference is disabled by default but I do have it enabled globally (I disable it per wiki). It does not raise a prompt when I reply through the tool. Obviously, MediaWiki is not prompting since the "Reply" or "Réponse" part is added after the initial generation of the default edit summary by core MediaWiki. But essentially it is a default edit summary prepared by the software.

Examples: this did not raise a prompt (reply tool), this did raise a prompt (simple edit).

(Note: a prompt is raised on some talk namespaces and not all, f.e. not in user_talk.)

2) A. Yes. B. Yes, C. Yes.

Thank you for clarifying, @Geraki. A quick follow up question related to the below...

Yes, the preference is disabled by default but I do have it enabled globally (I disable it per wiki). It does not raise a prompt when I reply through the tool.

Ah! I understand what you are saying here. A clarifying question and please excuse me if you've answered this elsewhere...

How would you expect the Reply Tool to behave considering the following?

• You have the Prompt me when entering a blank edit summary (or the default undo summary) preference enabled
• The Reply Tool automatically generates edit summaries

@PPelberg (WMF), I'm glad to read this is being worked on!

With Geraki, and as expressed before: edit summaries are part of wiki editing in general. In my opinion, making the ability to customize the edit summary an opt-in preference conflicts with this principle. I recommend making it an opt-out preference.

In addition to the preference, the ability to show/hide the input field within the Reply Tool interface would indeed be nice. PPelberg mentions a link, arrow or button, Geraki mentions a tick box. I.m.o. the arrow would be the nicest option – if that's what I think it is: some sideways collapser button. For a while something like the following has been in my mind as a neat, integrated sollution (collapsed vs [four options of] expanded):

< Reply Cancel

/* Topic heading */ > Reply Cancel

/* Topic heading */ Reply to PPelberg> Reply Cancel

→‎Topic heading: (edit summary)> Reply Cancel

→‎Topic heading: Reply to PPelberg> Reply Cancel

The state of the field (expanded or collapsed) should be remembered between uses of the Reply Tool, just like the state of the list of abbreviations on Special:Watchlist is remembered between visits, and the state of the TOC on any page.

With kind regards, Mar(c).

@Mar(c), we appreciate you reviewing the approach and even putting together some mockups! A few comments in response...

Comments

In my opinion, making the ability to customize the edit summary an opt-in preference conflicts with this principle. I recommend making it an opt-out preference.

This makes sense. I'm going to share a response to this point in another comment so it's easier for you, @Geraki and I to discuss.

I.m.o. the arrow would be the nicest option – if that's what I think it is: some sideways collapser button. For a while something like the following has been in my mind as a neat, integrated sollution (collapsed vs expanded):

Nice! I've added this suggestion to the ticket (T249391#6314205) so our team's designer can consider this when thinking about how the edit summary might look when embedded within the Reply Tool.

The state of the field (expanded or collapsed) should be remembered between uses of the Reply Tool, just like the state of the list of abbreviations on Special:Watchlist is remembered between visits, and the state of the TOC on any page.

Good thought; I've added this to the ticket as well (T249391#6314205) so I can discuss it with the engineering team.

Another approach would be to always show the auto-generated summary (in its preview not source form), with a "change" link next to it. Similar to Galobbter's w:en:Wikipedia:Shortdesc helper. Rather than being an "advanced" feature, it becomes part of the live preview experience.

Experienced users will already be accustomed to seeing the formatted summary in Preview (desktop classic or NWE source editing, but not mobile nor VE ^[1] ), and in History, Watchlist, etc.. Inexperienced users might encounter edit summaries for the first time at Reply, and learn something useful about Wikimedia in the process.^[2]

Examples with varying levels of default text:
Edit summary: (→‎ Some topic of discussion: Reply.) change
or
Edit summary: (→‎ Some topic of discussion: Reply to PPelberg.) change
or
Edit summary: (→‎ Some topic of discussion: Reply to PPelberg, "Another approach would be ...".) change

[1] I consider lack of an edit-summary preview, and inconsistent approaches to silently prepending the section or not, to be anti-features in the latter two, something I’d prefer not replicated in Reply.

[2] Might a small "change" or "modify" link might be less confronting to newbies than a full text box? [ /* Some topic of discussion */ Reply. ]

Another approach would be to always show the auto-generated summary (in its preview not source form), with a "change" link next to it. Similar to Galobbter's w:en:Wikipedia:Shortdesc helper. Rather than being an "advanced" feature, it becomes part of the live preview experience.

@Pelagic, this is an interesting approach. Were we to implement the approach you are suggesting above, are you thinking the edit summary [and the ability to edit/customize it] would be exposed in the source mode of the tool only? I ask this in an effort to make sure I'm accurately understanding what you have in mind before going any deeper on the implementation.

This would also be a nice approach, and indeed fits the live preview experience.

With kind regards, Mar(c).

Most of these examples are for edits that can't be made with the Reply tool, or in circumstances that won't exist: multiple replies in the same edit (can't be done), refactoring/re-organizing the discussion (can't be done), hatting/collapsing discussions (can't be done), correcting typos (can't be done), and when the section heading isn't included in the edit summary (if one exists, then it always will be added).

The main reason to do it seems to be to distinguish multiple comments from each other in history/RecentChanges mode. Unless people actually decide not to read discussions based upon edit summaries, then the practical value might be minimal, and mostly related to finding the edit much later (e.g., "I told you this on 23 January 2017, and here's the diff to prove it").

Absolutely, Whatamidoing!

In my last list ‘edit summary ... experience as a "consumer" of those edits’, I was thinking of any talk edits generally, beyond just the rare ply case. [autocorrect!]

When I wrote "multiple replies in the same section", I meant multiple separate saves (with differing summaries), not multi-reply in a single edit (with one explanatory summary). Sorry if I was unclear on that.

I don’t regularly work my Watchlist, so I can’t say how much summaries help there for talk vs. articles. Given that people lie in edit summaries and minor flags, one has to consider other factors, and often visit the change anyway. As you say, finding a specific diff from History would be a major use case. Also finding a discussion from my own Contribs, where the topic heading was blah, but I put something descriptive in the summary.

On the subject of refactoring, your reply has become separated from mine, partly because SD doesn’t indent the last reply in a topic. It’s good that DT does indent the last.

I’d like to see an option to post a top-level comment (which SD does have), but that could cause issues in environments that expect everything but the OP to be indented by at least one level.

dummy comment, so that I can indent

This comment is intended for @MarcoAurelio to reply to so they can share their comments about edit summaries in the place where we're all talking about them...

@Ad Huikeshoven, @Geraki, @Mar(c), @MarcoAurelio and @Pelagic: thank you all for thinking through this and coming up with ideas for how we implement custom edit summaries within the Reply Tool.

Below are, what I understand to be, the "Assumptions" that surfaced in this conversation. These "Assumptions" are followed by the "Initial approach" I'd like for us to experiment with and the "Open questions" that still need to be answered.

Please let me know if anything about the below is not clear or warrants further discussion.

Note: all of the above has been in the Phabricator ticket where this work is happening: T249391.

Assumptions

Below is what I understand to be the assumptions that surfaced in this conversation.

• If the edit summary field/function is too prominent, Junior Contributors will become confused
• If the edit summary field/function is too hidden, Senior Contributors will not know it exists and become confused as to why it is not present.
• If the action required to expose the custom edit summary field/function is too "far away" (e.g. presented within Special:Preferences), people wanting to enable it will become frustrated they are being "asked" to switch contexts to complete an action (read: turn on/enable/expose custom edit summaries) that is relevant to the context they were just in (read: writing a comment).

It's with these "Assumptions" in mind that we've arrived at the "Initial approach" described below.

Initial approach

Below are the requirements that will guide the initial approach we try.

• Meta
  • The ability to customize the edit summaries should not be too 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.
  • 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.
  • People writing a comment with the Reply tool should not be led to wonder or think about whether a custom edit summary is required.
• 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 questions

Below are the remaining implementation questions we need to answer.

• In what – if any – cases should the custom edit summary field/functionality be exposed/turned on by default?
  • Idea prompted by @Geraki: people who have the Prompt me when entering a blank edit summary (or the default undo summary)enabled should see the custom edit summary field/functionality automatically.
• 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? Should it have an explicit affordance, like what @Mar(c) is proposing in T249391#6314205 and T249391#6316452?