Talk:Talk pages project/replying

Jump to navigation Jump to search

About this board

The team would value any thoughts and/or questions you have about this new tool for Replying to specific comments on talk pages.

Give preference to choose editor for once

16
Ammarpad (talkcontribs)
I don't like the way that the default editor is Visual Editor and always I have to switch to the source. I don't use VE at all, and I would like to not be forced to. Please give preference that I will tick so at all time, I will only see source editor. Another minor related issue is that I notice the window changes size when switching. It becomes bigger in VE. Is this intentional? is there any documentation of why this is good?, I'd expect the text in source editor to be larger in size, and not sure why its window is smaller. But this is minor issue, if you allow us to disable VE altogether (like we do in normal editing), this problem will go away. Thanks
Valereee (talkcontribs)
You can't set that in your Preferences>Editing tab?
Ammarpad (talkcontribs)
There's no preference to do that there. Or maybe I am not seeing it, can you give the exact name?.
Geraki (talkcontribs)
{{FlowMention|Ammarpad}} https://i.imgur.com/hqA2XVK.png
Ammarpad (talkcontribs)
This is my preferences page, I don't see that dropdown. https://imgur.com/YaguPWs.
Matma Rex (talkcontribs)
That preference doesn't appear if you disabled the visual editor, since "Always give me the source editor" would naturally be the only option.
Matma Rex (talkcontribs)
The default editor for the reply widget is not visual editor – it's whichever editor you have selected for editing articles (the preference Geraki linked), or if you selected "Remember…" or "Show me both…", it's whichever editor you used the last time. After you change editors in the reply widget, it should remember your choice and always use the editor you used last from then on. We didn't want to add another preference for a few reasons: *The usual – it adds clutter on Special:Preferences and it increases the complexity of the code *Switching editors in the reply widget is much faster than in articles, since we don't need to reload the contents of the page *Most of the time the comments on talk pages are just text, so it doesn't really matter which editor you use anyway
Ammarpad (talkcontribs)
*The presence of the two modes also adds clutter, more distracting than if it were on a special page, that I rarely visit. *This is a standalone extension, so I am not sure why it should not come with preferences for users to disable what they'll not use at all, but end up always seeing. *Users who want the source only don't anticipate any switching, so why not allow them use what they want. Why should we have duplicate things doing the same thing? *No, it matters. Even in articles significant percentage of edit is text. I cannot remember last when I added anything not text in article. I greatly appreciate that I am not being confronted with a switch button before saving.
Matma Rex (talkcontribs)
<blockquote>The presence of the two modes also adds clutter, more distracting than if it were on a special page, that I rarely visit.</blockquote>I agree with this actually, we have a task about it: [[phab:T255448|T255448]]. Personally I'd prefer a dropdown in the toolbar like the one we're using in Flow here.<blockquote>This is a standalone extension, so I am not sure why it should not come with preferences for users to disable what they'll not use at all, but end up always seeing.</blockquote>To be clear, there will always be a preference to disable the reply widget (and any related tools), currently you can do that by turning off the beta feature. I am not really convinced that we also need a preference to disable the ability to switch editors within the reply widget.
Ammarpad (talkcontribs)
Thank you for that ticket [[phab:T255448|T255448]]. The task issue is different from my feedback but they are indeed related. It's yet ''another'' confirmation that this tool will probably be better without this two modes, or at least a way to make it one per user. It confuses the new editors (per usability research in the task) and it annoys the older editors (who prefer source). I said 'probably', since I am not privy to the research you have done about it, but I believe giving option to disable it will not hinder any workflow. I hope you'll consider the third alternative of allowing people to choose one. On the second issue, I didn't know I can disable the tool entirely and I really hope not to. I like the tool and appreciate the people working on it, but if the VE mode kept distracting me, I believe I have to disable it one day.
Matma Rex (talkcontribs)
I think the real bug here is that the initial edit mode for you was visual, even though you also have completely disabled visual editor for articles in preferences. It seems that if you disable the visual editor, we stop updating the data about which editor you used the last time you edited, but we still remember which editor you used previously. If that was the visual editor, then it seems that the reply widget will also use visual mode initially. I filed a bug about this problem: [[phab:T257234|T257234]]
Ammarpad (talkcontribs)
I appreciate your clarification and starting that task. But it's not the real bug here. It will indeed ameliorate the issue, but the main issue remains. If you want feel of the real bug in this feedback, open [[w:Cisco Systems|this enwiki article]]. Imagine that every section edit button is followed by VE edit button, that I must choose in between during any edit. I am aware that some people see two buttons, some see only VE buttons, but that's fine because they intentionally choose to see that from their preference pages. I personally choose to see only single [edit] button always. We did not say, both buttons should be shown to everybody even if they elect to see only one.
Whatamidoing (WMF) (talkcontribs)
{{FlowMention|Ammarpad}}, which wiki are you talking about? It looks like you've posted a screenshot of Special:Preferences from MediaWiki.org but the only edit I can find you ever making with the Reply tool was [https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:Ammarpad/Test&diff=prev&oldid=169664023&diffmode=source at the French Wikipedia], which (of course) has different prefs settings.
Ammarpad (talkcontribs)
{{FlowMention|Whatamidoing (WMF)}}, yes the prefs page is of MediaWiki.org. But I am also testing the tool here on MediaWiki.org '''not''' on French Wikipedia. Actual editing with the tool is not necessary to understand the bug I described. So I intentionally didn't make any post with it, I just tested by opening/reloading the page and switching the tabs to see what happens. [[User:Ammarpad|Ammarpad]] ([[User talk:Ammarpad|talk]]) 19:41, 6 July 2020 (UTC)
Whatamidoing (WMF) (talkcontribs)
But perhaps if you actually made an edit, then that would record your preference, and thereby solve your problem?
Ammarpad (talkcontribs)
Thanks, I did here: [[Project_talk:Sandbox]]. It did not go away. The test text is self-explanatory. (Forget the bunch of nowiki tags and double signature that the VE mode added which did not go away after I switched mode.) And if you ask me why I start editing without switching, it's because I don't think I will be able to remember this always. From my feel, I will always start editing once I open the window, but the moment I saw my text being transformed to something else, it's the time I will attempt switching to Source. But then it's not always normal switching. I may inherit [https://www.mediawiki.org/w/index.php?title=Project_talk:Sandbox&diff=3952710&oldid=3952707 things like these], that may require another edit to cleanup.
Reply to "Give preference to choose editor for once"

V2 live observations: Pelagic

2
Pelagic (talkcontribs)
Wow, I was pleasantly surprised to see that Reply 2.0 is live now. One thing that I meant to mention from the mockups but think I neglected was the [ '''B''' ''I'' ] buttons instead of the [ '''''<u>A</u>''''' ˅ ] dropdown that's in VE and SD. Really happy to see [ '''''<u>A</u>''''' ˅ ] in the release version. <code>:)</code> (I'm not fussed whether bold and italic get their own buttons or appear on a submenu, but I want to be able to access all the other formatting like small, code, etc.) I had a small difficulty on iOS where I selected some text in the top line, and the native context menu obscured the toolbar. There was no way to make it disappear or scroll it out of the way, so I inserted a couple of temporary newlines to move the text down. Short of putting the toolbar below, which is rather drastic, I don't see an easy design fix for that.
Pelagic (talkcontribs)
Just noticed, is the @-dropdown not working in Source mode?
Reply to "V2 live observations: Pelagic"

Design feedback: version 2.0 mockups

87
Summary by PPelberg (WMF)
A list of tasks that have emerged from the conversations around [[Talk pages project/replying#Version 2.0|Version 2.0]] of the Replying tool: - {{Phabricator|T250329}}: Show aliases in username completion list for @ mentioning/pinging feature] - {{Phabricator|T250334}}: Implement more robust search for auto-complete for @ mentioning/pinging feature] - {{Phabricator|T246190}}: Reply v2.0: conduct usability tests (usertesting.com) - {{Phabricator|T246191}}: Reply v2.0: conduct usability test (MediaWiki) - {{Phabricator|T249072}}: Replying v2.0: add support in toolbar for special characters - {{Phab|T249074}}: Define approach for expanding the Replying tool's `visual` mode toolbar - {{Phab|T245222#6012991}}: How the Reply tool's "Watch this page" checkbox will work - {{Phabricator|T252084}}: Consider adding header to username suggestion list - {{Phabricator|T253434}}: Create an onboarding experience for the Reply tool
PPelberg (WMF) (talkcontribs)
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: #'''What aspects of the designs do not seem clear to you?''' #'''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: [[:File:Reply-V2-Source.png|source mode]] and [[:File:Reply-v2-Visual.png|visual mode]] *[[Talk pages project/replying#Version%202.0|Features planned for Version 2.0]]
Pbsouthwood (talkcontribs)
{{FlowMention|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.
Pbsouthwood (talkcontribs)
This reply is just to see where it will go and how it will be indented. PS: WYSIWYG, not a problem.
This post was hidden by Pbsouthwood (history)
Pbsouthwood (talkcontribs)
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.
Pbsouthwood (talkcontribs)
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.
Ad Huikeshoven (talkcontribs)
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.
Pbsouthwood (talkcontribs)
{{FlowMention|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?
Whatamidoing (WMF) (talkcontribs)
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)
Pbsouthwood (talkcontribs)
Trying a permalinked reply to see what happens if I later make another edit to {{FlowMention|Whatamidoing (WMF)}}'s post It is not clear what the permalink option is supposed to do, or if it actually does it. {{FlowMention|PPelberg (WMF)}}, could you explain?
Whatamidoing (WMF) (talkcontribs)
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.
Pbsouthwood (talkcontribs)
It would appear I can also hide your post, which is a thing I should generally not do.
Pbsouthwood (talkcontribs)
{{FlowMention|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.
PPelberg (WMF) (talkcontribs)
{{FlowMention|Pbsouthwood}} thank you for taking the time to review the [[Talk pages project/replying#/media/File:TalkPages-Reply-v2.0.png|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: #Feedback about [[flow|Flow]] [i], as {{FlowMention|Whatamidoing (WMF)}} notes [[Topic:Vju7lfcav875rt8r|here]]. #Feedback about the design of Version 2.0 of the new [[Talk pages project/replying|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''' {{Tq|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 [[Topic:Vju7lfcav875rt8r|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: #'''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 [[Topic:Vju7lfcav875rt8r|you alluded to]], people seeing an alphabetized list of the usernames who have already commented on the page upon typing "@". #'''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. {{FlowMention|Pbsouthwood}} how does the above logic sound to you? ''Current implementation'' <nowiki>*</nowiki>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 {{Tq|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. <br />
This post was hidden by PPelberg (WMF) (history)
Pbsouthwood (talkcontribs)
{{FlowMention|PPelberg (WMF)}} {{tq|#'''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
PPelberg (WMF) (talkcontribs)
{{Tq|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 [[Topic:Vju7lfcav875rt8r|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🙉. {{Talk quotation|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. {{Tq|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: [[phab:T249074|T249074]]. {{Tq|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? #Go to http://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page #Click "Reply" #Type the "@" symbol #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.''
Pbsouthwood (talkcontribs)
{{FlowMention|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.
PPelberg (WMF) (talkcontribs)
{{Talk quotation|'Previously commented on that talk page' is clear enough thanks.}} You bet. {{Tq|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 [http://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page 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. {{Tq|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: {{Phabricator|T232601#6057545}}. <br />
Pbsouthwood (talkcontribs)
{{FlowMention|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.
PPelberg (WMF) (talkcontribs)
{{Tq|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, {{FlowMention|Pbsouthwood}}. --- 1. {{Phabricator|T250329}}
TheDJ (talkcontribs)
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 ?
PPelberg (WMF) (talkcontribs)
{{Tq|I think it just adds clutter and confusion to the flow.}} {{FlowMention|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. {{Tq|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 '''<u>not</u>''' 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 {{FlowMention|Pbsouthwood}} alluded to [[Topic:Vju7lfcav875rt8r|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 [[phab:T233447|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.
TheDJ (talkcontribs)
{{tq|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. {{tq|The "Watch this page" is targeted for newer contributors}} Then we have to educate them. {{tq|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. {{tq|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.
PPelberg (WMF) (talkcontribs)
{{Tq|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.}} {{FlowMention|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: {{Phabricator|T246190}}. {{Tq|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: "Wh''at 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. <br />
Whatamidoing (WMF) (talkcontribs)
> 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.
Pbsouthwood (talkcontribs)
"Watch this thread" might be handy if practicable. [[User:Pbsouthwood|Pbsouthwood]] ([[User talk:Pbsouthwood|talk]]) 14:53, 9 April 2020 (UTC)
Whatamidoing (WMF) (talkcontribs)
Right now, it'd be a "watch this whole page" button.
TheDJ (talkcontribs)
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.
Pelagic (talkcontribs)
This post is about the @-mention prototype on patchdemo, rather than the mockups. *{{tq|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 <code>@</code> is magic? Will VE users be unsurprised since they're already used to <code>[[</code> and <code><nowiki>{{</nowiki></code> 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. **{{u|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 ]
Pelagic (talkcontribs)
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.: <nowiki>{{FlowMention|PPelberg (WMF)|Peter}}, {{u|Whatamidoing (WMF)|WAID}}, [[User:Whatamidoing (WMF)|Sherry]]</nowiki>. 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.)
Pbsouthwood (talkcontribs)
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.
PPelberg (WMF) (talkcontribs)
Definitely. The feature will support sending pings/notifications to people whether or not they have created a user page or not.
Pelagic (talkcontribs)
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.
PPelberg (WMF) (talkcontribs)
{{FlowMention|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.
PPelberg (WMF) (talkcontribs)
{{Talk quotation|...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 <code>@</code> 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 <code>@</code> + character(s) their username begins with. For example, typing <code>@pe</code> should return "'''pe'''ter" and "'''pe'''lagic" but not "sna'''pe'''" ''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<nowiki/>.''
PPelberg (WMF) (talkcontribs)
{{Tq|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
PPelberg (WMF) (talkcontribs)
{{Tq|<nowiki>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.</nowiki>}} 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: [[phab:T232601#6091882|T232601#6091882]]. We will test this assumption through testing in this task: [[phab:T246191|T246191]]
PPelberg (WMF) (talkcontribs)
{{Tq|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 ^ _ ^
PPelberg (WMF) (talkcontribs)
{{Talk quotation|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
Whatamidoing (WMF) (talkcontribs)
If you're not familiar with MediaWiki, then you would probably try to ping someone by the displayed name instead of the real username.
Pelagic (talkcontribs)
''> 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 <nowiki>[[User:john.q.citizen|John]]</nowiki> 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.
PPelberg (WMF) (talkcontribs)
This context is helpful - thank you for sharing it, {{FlowMention|Pelagic}}. I've included links to the comments you and {{FlowMention|Whatamidoing (WMF)}} shared about aliases in the task where we will consider implementing this functionality: https://phabricator.wikimedia.org/T250329.
PPelberg (WMF) (talkcontribs)
{{Tq|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 <br />
PPelberg (WMF) (talkcontribs)
{{Tq|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 {{FlowMention|Pbsouthwood}} raise a great point here. Fortunately, this functionality will send notifications to people whether they have created a user page or not.
PPelberg (WMF) (talkcontribs)
{{Tq|1=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.)}} 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.
This post was hidden by Pelagic (history)
Stjn (talkcontribs)
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.)
PPelberg (WMF) (talkcontribs)
{{Tq|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.
Stjn (talkcontribs)
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.
Whatamidoing (WMF) (talkcontribs)
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.
Stjn (talkcontribs)
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 :-)
Whatamidoing (WMF) (talkcontribs)
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.
Stjn (talkcontribs)
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.
Whatamidoing (WMF) (talkcontribs)
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.
Pbsouthwood (talkcontribs)
{{FlowMention|Stjn}}, What is description list syntax?
Stjn (talkcontribs)
<code>:</code> is semantic syntax for creating HTML description lists. <code>*</code> is semantic syntax for creating any kinds of lists. Using <code>:</code> for indentation in any tools is bad for accessibility and semantic code.
Pbsouthwood (talkcontribs)
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.
TheDJ (talkcontribs)
{{FlowMention|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.
Pbsouthwood (talkcontribs)
{{FlowMention|TheDJ}}<nowiki>, 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. ~~~~</nowiki>
Samat (talkcontribs)
Version 2.0 looks very promising! First comments from my side: #I miss the [[phab:T249072|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. #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. #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). #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.
PPelberg (WMF) (talkcontribs)
Thank you for these questions, {{FlowMention|Samat}}. I'm going to respond to each one in a separate comment...
PPelberg (WMF) (talkcontribs)
{{Tq|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 ([[phab:T249072|T249072]]) is a big help...thank you for continuing to do this, {{FlowMention|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:[[phab:T249074|T249074: Define approach for expanding the Replying tool's `visual` mode toolbar]].
PPelberg (WMF) (talkcontribs)
'''The "Watch this page" option...''' {{Tq|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. {{Tq|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:'' [[phab:T245222#6012991|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: #A usability test of this functionality with people who are new to participating on Wikipedia talk pages: {{Phabricator|T246190}}. #Listening for feedback about this functionality from volunteers at our partner wikis where this functionality recently became available. #Conducting testing of this functionality on MediaWiki once we have a prototype of the visual mode ready: {{Phabricator|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.
Whatamidoing (WMF) (talkcontribs)
{{FlowMention|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 {{FlowMention|MMiller (WMF)}} and {{FlowMention|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.
Samat (talkcontribs)
{{FlowMention|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...
PPelberg (WMF) (talkcontribs)
{{Tq|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 <code><nowiki>visual</nowiki></code> mode will be limited to linking, italicizing and bolding. {{FlowMention|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: [[phab:T249074|T249074: Define approach for expanding the Replying tool's `visual` mode toolbar]].
Samat (talkcontribs)
{{FlowMention|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 ([[:hu:Wikipédia:Kocsmafal (egyéb)/Archív256#V%C3%A1ltoz%C3%A1s%20a%20szerkeszt%C5%91i%20jogok%20be%C3%A1ll%C3%ADt%C3%A1s%C3%A1ban%2C%20v%C3%A1ltoz%C3%A1s%20a%20statisztik%C3%A1k%20adatainak%20%C3%A9rtelmez%C3%A9s%C3%A9ben|example1]], [[:hu:Wikipédia:Kocsmafal (egyéb)/Archív254#Kiemelt%20%C3%A9s%20j%C3%B3%20sz%C3%B3cikkek%20fel%C3%BCletes%20%C3%B6sszehasonl%C3%ADt%C3%A1sban|example2]], [[:hu:Wikipédia:Kocsmafal (egyéb)/Archív254#Wikipedia%20Asian%20Month%202019|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 [[:hu:Wikipédia:Munkatársak#Szerkeszt%C5%91i%20csoportok%20jogosults%C3%A1gai|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 <nowiki>__NOEDITSECTION__</nowiki> or with the wgExtraSignatureNamespaces parameter does not seem to support this separation for the project namespace, for example.)
PPelberg (WMF) (talkcontribs)
{{Tq|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 <code><nowiki>source</nowiki></code>mode 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 <code><nowiki>source</nowiki></code> mode.
Whatamidoing (WMF) (talkcontribs)
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.
Samat (talkcontribs)
How the 2.0 mockups ([[:File:Reply-v2-Visual.png|visual]], [[:File:Reply-V2-Source.png|source]]) relates to the [https://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page demo wiki]'s version? Which one is the newer conception?
PPelberg (WMF) (talkcontribs)
I'm glad you asked this, {{FlowMention|Samat}}. These mockups ([[:File:Reply-v2-Visual.png|visual]], [[:File:Reply-V2-Source.png|source]]) are the newest conception. What is available on the [https://patchdemo.wmflabs.org/wikis/3e6233fd55aa2f26fbd9c1986fe60a2c/w/index.php/Talk:Main_Page demo wiki] should be considered a technical prototype we (our team, you, everyone here, etc.) are using as a way to test functionality.
Pelagic (talkcontribs)
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.
Whatamidoing (WMF) (talkcontribs)
{{FlowMention|Pelagic}}, which tips would you add first?
Pelagic (talkcontribs)
{{FlowMention|Whatamidoing (WMF)}} The two above. <code>;)</code> *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 {{Em|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: *<nowiki>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. </nowiki> *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.
Pelagic (talkcontribs)
Assembling that, it could look like: *Reply will be automatically indented and signed. No need to type ::::: or <nowiki>~~~~</nowiki> *Type @ to mention and notify someone. *Use wikitext here, but for tables and complex markup edit the section instead. *<s>✏️switches to visual editing mode.</s> :Learn more • Discuss
Whatamidoing (WMF) (talkcontribs)
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?
Pelagic (talkcontribs)
{{FlowMention|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.
TheDJ (talkcontribs)
<nowiki>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 ~~~~.</nowiki>
PPelberg (WMF) (talkcontribs)
{{Tq|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, {{FlowMention|Pelagic}}. '''A clarifying question for you: What inspired the list of components you shared [[Topic:Vju7lfcav875rt8r|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:'' [[phab:T253434|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 {{FlowMention|TheDJ}} shared [[Topic:Vju7lfcav875rt8r|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)? <br />
Pelagic (talkcontribs)
{{tq|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!
Pelagic (talkcontribs)
<small>Oops, forgot echo {{FlowMention|PPelberg (WMF)}}</small>
PPelberg (WMF) (talkcontribs)
{{Tq|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.}} {{FlowMention|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?
Mar(c) (talkcontribs)
Hello {{FlowMention|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. <code>/* name of the section */</code>): *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
Pelagic (talkcontribs)
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 <em>me</em> 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”.
PPelberg (WMF) (talkcontribs)
{{FlowMention|Mar(c)}} and {{FlowMention|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.
Reply to "Design feedback: version 2.0 mockups"

V2 Feedback: Gnom

3
Summary by PPelberg (WMF)
[[phab:T254208]]: Revise position and behavior of Reply tool's text input [[phab:T255085]]: Clarify distinction between the Reply tool's two text input modes [[phab:T252445]]: Consider changing the presentation of the visual mode's editing toolbar [[phab:T255737]]: Username suggestion list lowercases text input
Gnom (talkcontribs)
==='''Version 2.0 testing feedback'''=== '''<u>TASK #4</u>: What are your initial impressions of the tool? What stands out to you? Do you find something particularly eye-catching? Confusing?''' *I can't believe this took us so long to finally have this feature. *I expected the edit window to open right under the comment that I selected to reply to, but it opened further down the page. So I asked myself whether my comment would end up further down instead. *Will newbies understand what 'source' and 'visual' mean? '''<u>TASK #5</u>: Could you figure out how to write and style a comment in the tool's <code>visual</code> mode do so? What did you think of this experience?''' *Yes, but the buttons for this shouldn't be hidden on the right side of the window. '''<u>TASK #6</u>: Could you figure out how to ping someone who has''' '''commented in the section you are replying in? What did you think of this experience?''' *Yes, and this is a game changer. '''<u>TASK #7</u>: Could you figure out how to ping someone who has <u>not</u>''' '''commented in the section you are replying in? What did you think of this experience?''' *Also very cool, but it appears that capitalisation of usernames doesn't work yet (entering "@Foo" to ping User:Foo is displayed as "@foo"). '''<u>TASK #8</u>: Could you figure out how to delete the ping you created in Task #7? What did you think of this experience?''' *Easy. '''<u>TASK #9</u>: Could you figure out how to see the comment you were writing in the <code>visual</code> mode, in the <code>source</code> mode before posting the comment to the talk page? What – if any – part the wikitext looked different from how you expected?''' *All great. Will the preview also display stuff like images and images (I didn't test that)? '''<u>TASK #10</u>: Could you figure out how to post the comment you had written in Tasks #1 - #9 to the talk page?''' *Yup. '''<u>TASK #11</u>: Does the diff you created by posting a comment look as you expected? What – if anything – were you surprised to see?''' *Maybe it should read, "reply to comment by User:Foo"? On a second thought, I suppose it should not. '''<u>OVERALL</u>: If there are other comments or questions you would like to make the team aware of, please write them here.''' *Awesomeness, keep up the great work!
PPelberg (WMF) (talkcontribs)
Thank you for the effort you put into trying the tool and sharing these thoughts, {{FlowMention|Gnom}}. Some '''follow up questions''' and '''comments''' in response to what you shared below... <br /> ===Follow up question for you=== {{Tq|I expected the edit window to open right under the comment that I selected to reply to, but it opened further down the page. So I asked myself whether my comment would end up further down instead.}} Mmm, I see. '''After posting the comment you'd written to the page did it become a bit more clear to you why the edit window appeared where it did?''' [1] In the meantime, I've added the experience you shared here to the ticket where we will be exploring how and where the edit window appears: [[phab:T254208]]. --- 1. I'm intentionally not sharing why the tool behaves in this way in an effort to learn whether its behavior becomes clear after use. {{Talk quotation|Will newbies understand what 'source' and 'visual' mean?}} Good question. '''What do you think might be better name(s) for these two modes?''' For context: the most recent round of usability tests we ran suggest people manage to understand/intuit what these words mean. With this said, there was at least one tester who was confused by them to the point of being fearful clicking <code>source</code> would discard the comment they'd written in the <code>visual</code> mode. ''See:'' [[phab:T255085]]. {{Tq|Yes, but the buttons for this shouldn't be hidden on the right side of the window.}} '''Are you expressing that the writing tools (B, I, etc.) being on the right side of the text input window made them hard to "reach"?''' ...I ask the above to make sure I'm understanding what you experienced correctly. By the way, here is the ticket where we are tracking the issue I described above: [[phab:T252445]] ===Comments=== {{Tq|...it appears that capitalisation of usernames doesn't work yet (entering "@Foo" to ping User:Foo is displayed as "@foo").}} Good spot. Ticket filed: [[phab:T255737]]. {{Talk quotation|Will the preview also display stuff like images and images (I didn't test that)?}} Ues, it will. {{Tq|Awesomeness, keep up the great work!}} ^ _ ^
Gnom (talkcontribs)
Hi @[[User:PPelberg (WMF)|PPelberg (WMF)]] – thank you for your direct and detailed response, that was a great experience! It's unbelievably cool to see the feedback turn into tickets in this way. Concerning your question, ''After posting the comment you'd written to the page did it become a bit more clear to you why the edit window appeared where it did?'': Yes, it did become clearer. Maybe we can somehow 'visually connect' the input box with that comment that the user responding to, perhaps with a thin line on the left-hand side? Concerning your question, ''What do you think might be better name(s) for these two modes?'': Maybe using longer names ("use wikitext mode"/"use visual mode") is better here. Concerning your question, ''Are you expressing that the writing tools (B, I, etc.) being on the right side of the text input window made them hard to "reach"?'': Yes, exactly.
Reply to "V2 Feedback: Gnom"

V2 Feedback: Kaartic

6
Summary by PPelberg (WMF)
[[phab:T255738]]: Make it clear in the visual mode comments will be automatically signed [[phab:T255560]]: Make reply links more discoverable [[phab:T255737]]: Username suggestion list lowercases text input [[phab:T252083]]: Treat links to user pages differently than normal wikilinks [[phab:T254208#6233879|phab: T254208]]: Revise position and behavior of Reply tool's text input [[phab:T248594#6233882|phab:T248594]]: Refine design of ConfirmEdit captcha workflow in DiscussionTools [[phab:T255740]]: Template swallows other parts of comment <br />
Kaartic (talkcontribs)
==='''Version 2.0 testing feedback'''=== '''<u>TASK #4</u>: What are your initial impressions of the tool? What stands out to you? Do you find something particularly eye-catching? Confusing?''' The in-line editing window looks great! I really like and the seamless switch between the text and the visual editor. The positioning and styling of the "Reply" links look a little odd, though. It would be nice if it could be a little more distinguished from the actual text possibly by italicizing it or something like that. '''<u>TASK #5</u>: Could you figure out how to write and style a comment in the tool's <code>visual</code> mode do so? What did you think of this experience?''' Yeah, that works nicely. The expected shortcuts work for styling. I love that <kbd>Ctrl+K</kbd> is mapped to adding links! '''<u>TASK #6</u>: Could you figure out how to ping someone who has''' '''commented in the section you are replying in? What did you think of this experience?''' Yeah, it's easy to do that. I type '@' and it shows a list of people who have already commented there. Nice. '''<u>TASK #7</u>: Could you figure out how to ping someone who has <u>not</u>''' '''commented in the section you are replying in? What did you think of this experience?''' Yeah, this is easy to do too. I just type @followed by the username of the person who hasn't yet commented there and hit enter. It even seems to be showing suggestions as and when I type. Nice. I noticed one issue. In some cases it seems to automatically lower-casing the first character of the username. For example, I was trying to ping the 'Acct creation test 030' user. I typed in 'Acct creation test 03' the suggestions went away. Then I just continued typing the last character ('0') and hit space. I was shown 'acct creation test 030' (note the lower-case 'a') as a suggestion. I hit enter. The suggestion was used and the first character of the username got lower-cased. Not sure why the suggestion shows a username where the first character is lower-cased. '''<u>TASK #8</u>: Could you figure out how to delete the ping you created in Task #7? What did you think of this experience?''' I just hit backspace until the username was deleted. So, it's nice and works fine. '''<u>TASK #9</u>: Could you figure out how to see the comment you were writing in the <code>visual</code> mode, in the <code>source</code> mode before posting the comment to the talk page? What – if any – part the wikitext looked different from how you expected?''' Yeah, switching to the "Source" tab revealed the wiki-text. The wikitext looked like what I expected in most cases. For the ping, I thought the ping template might be used but the user page was linked. I think it makes sense to link to the user page. '''<u>TASK #10</u>: Could you figure out how to post the comment you had written in Tasks #1 - #9 to the talk page?''' Yeah. <kbd>Ctrl+Enter</kbd> works! Cool. '''<u>TASK #11</u>: Does the diff you created by posting a comment look as you expected? What – if anything – were you surprised to see?''' Yes. It looks good. I forgot to add the signature to the comment possibly due to my infrequency of replying in talk pages. It's nice to see the signature automatically added. Also, it's great to see that it respects custom signatures. It might be nice to show a hint somewhere that the message would be auto-signed. '''<u>OVERALL</u>: If there are other comments or questions you would like to make the team aware of, please write them here.''' A few things: #It would be nice to visually distinguish the editor so that it is easily identifiable amongst the content while scrolling through the page. When drafting a reply, I happened to scroll the page to see other content but lost track of the location of the editor. It took me some time to find this. Given that the positioning of the editor could vary unlike the editors in other places, I guess it would be nice to visually distinguish this in a better way so that it could easily be identified. #When I try to post a reply after a few minutes, I got a request to complete CAPTCHA. The comment got posted after I completed the CAPTCHA but it's not clear why the CAPTCHA was necessary. It would be nice if the reason is mentioned somewhere. Apart from these, I noticed a issue when using the '<nowiki>{{quote}}</nowiki>' template. Consider the following wikitext which has been entered in the "Source" editor: <pre> Lorem Ipsum {{quote|Quoted text}} More text </pre> Now, each time I switch to the 'Visual' editor and then back to 'Source', I see that each line of text before the quote template gets prefixed with ':'. So, the text looks like this after the first switch: <pre> :Lorem :Ipsum :{{quote|Quoted text}} More text </pre> It looks like this after the second switch: <pre> ::Lorem ::Ipsum ::{{quote|Quoted text}} More text </pre> That doesn't look right, does it?
Kaartic (talkcontribs)
Curious. I now consistently see the following error when I try to reply to any comment in [https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Dogs?dtvisual=1 that page]: {{quote|The "Reply" link cannot be used to reply to this comment. To reply, please use the full page editor by clicking "Edit source".}} It doesn't say why. Not sure what's going on.
PPelberg (WMF) (talkcontribs)
This feedback is helpful - we appreciate the effort you've put into trying the tool and sharing these thoughts with us, {{FlowMention|Kaartic}}. Some '''comments''' in response to what you shared below... ===Follow up questions=== {{Tq|It might be nice to show a hint somewhere that the message would be auto-signed.}} Can you imagine how you might react if you had included <code><nowiki>~~~~</nowiki></code> in the comment you were writing and after posting, noticed that it had been auto-signed this making <code><nowiki>~~~~</nowiki></code> unnecessary? In the meantime, I've added this feedback to the ticket where we are tracking this issue: [[phab:T255738]]. ===Comments=== {{Tq|The in-line editing window looks great! I really like and the seamless switch between the text and the visual editor.}} We're glad to hear this! {{Tq|The positioning and styling of the "Reply" links look a little odd, though. It would be nice if it could be a little more distinguished from the actual text possibly by italicizing it or something like that.}} Well put. This is proving to be a common issue. We plan to address this as part of our larger effort to make the actions, activity and content within talk pages easier to idenitfy and understand. In the meantime, I've added the feedback you shared to the ticket where we will think specifically about the discoverability of the "Reply" links: [[phab:T255560]]. {{Tq|I noticed one issue. In some cases it seems to automatically lower-casing the first character of the username.}} Good observation. I've added the comments you shared to the ticket where we will be investigating this: [[phab:T255737]]. {{Tq|I think it makes sense to link to the user page.}} This is good to hear. If you're curious, here is how we arrived at the current approach and the enhancements we have planned for it: [[phab:T252083]]. {{Tq|It would be nice to visually distinguish the editor so that it is easily identifiable amongst the content while scrolling through the page. When drafting a reply, I happened to scroll the page to see other content but lost track of the location of the editor. It took me some time to find this. Given that the positioning of the editor could vary unlike the editors in other places, I guess it would be nice to visually distinguish this in a better way so that it could easily be identified.}} Well put. I've added this feedback to the ticket where we will be exploring how to address this issue: [[phab:T254208#6233879|phab: T254208#6233879]]. {{Tq|When I try to post a reply after a few minutes, I got a request to complete CAPTCHA. The comment got posted after I completed the CAPTCHA but it's not clear why the CAPTCHA was necessary. It would be nice if the reason is mentioned somewhere.}} Agreed. The tool should explain what prompted the CAPTCHA to be shown. I've posted this to the ticket where we have been discussing CAPTCHA: [[phab:T248594#6233882]]. {{Tq|...Apart from these, I noticed a issue when using the <nowiki>'{{quote}}</nowiki> template. Consider the following wikitext which has been entered in the "Source" editor...}} Thank you for bringing this example to our attention. In investigating the switching issue you raised (filed as: [[phab:T255742]]), I seem to have stumbled upon another issue:[[phab:T255740]] (Template swallows other parts of comment).
Kaartic (talkcontribs)
{{Tq|Can you imagine how you might react if you had included <nowiki>~~~~</nowiki> in the comment you were writing and after posting, noticed that it had been auto-signed this making <nowiki>~~~~</nowiki>}} I would realize that it's not necessary to sign the replies done using this interface anymore and would stop doing so. I would also remove the unnecessary signature in that post. Though I personally don't find it confusing. I could imagine how this exceptional auto-signing behaviour might be confusing to some. But in "Source" mode, the preview of the reply does a good job of communicating that the reply would be auto-signed. In "Visual" mode this still needs to be communicated. I also wonder if this auto-signing might be found as a "weird"/"unnecessary" behaviour by people who have been interacting a lot in talk pages. I'm not an experienced editor myself to say that. Anyways, if the experienced editors were to use this, I anticipate them asking for a preference to turn this auto-signing off ;-) Thanks for the detailed responses, by the way. Totally love them :-)
PPelberg (WMF) (talkcontribs)
{{Talk quotation|I would realize that it's not necessary to sign the replies done using this interface anymore and would stop doing so. I would also remove the unnecessary signature in that post.}} Understood. This is helpful to know. {{Tq|in "Source" mode, the preview of the reply does a good job of communicating that the reply would be auto-signed. In "Visual" mode this still needs to be communicated.}} I suspect this issue, and the initial approach to resolving it, will be the kinds of things that become more clear once more people use the tool. Considering many experienced contributors trying the tool for the first time will land in the tool's <code>source</code> mode, I wonder if the presence of the preview will "teach" them the tool will automatically sign the comments they post, as you alluded to. The thing I wonder about: will this group of people assume the tool will continue auto-signing posts if they post the comment they are writing in the tool's <code>visual</code> mode. {{Tq|I also wonder if this auto-signing might be found as a "weird"/"unnecessary" behaviour by people who have been interacting a lot in talk pages.}} We'll have to see... {{Tq|Thanks for the detailed responses, by the way. Totally love them :-)}} You bet and thank you for saying as much – that's nice to hear ^ _ ^
Kaartic (talkcontribs)
{{Tq|We'll have to see...}} Yeah. In the mean time, I think I figured out a reason why they {{em|might}} find it "weird". So far, the source editor had the "what you write is what gets published" phenomenon. As a matter of fact, even I really love the fact that I have control over what gets published. The automatic signing of messages kind of goes against this. So, this could come up as a reason why people might not like this. Just wanted to share this. :)
Reply to "V2 Feedback: Kaartic"

V2 Feedback: Barkeep49

4
Summary by PPelberg (WMF)
[[phab:T254366]]: Add @ mention affordance to visual mode's toolbar [[phab:T255738]]: Make it clear in the visual mode comments will be automatically signed [[phab:T250523]]: Determine which Reply text input should be shown by default
Barkeep49 (talkcontribs)
==='''Version 2.0 testing feedback'''=== '''<u>TASK #4</u>: What are your initial impressions of the tool? What stands out to you? Do you find something particularly eye-catching? Confusing?''' I like that it defaults to Wikisource for me but is that something that is user preference and/or something a community could decide which would be the default on its own? '''<u>TASK #5</u>: Could you figure out how to write and style a comment in the tool's <code>visual</code> mode do so? What did you think of this experience?''' I really like writing content in VE and this reminds me of that. '''<u>TASK #6</u>: Could you figure out how to ping someone who has''' '''commented in the section you are replying in? What did you think of this experience?''' I mean I guessed it was an @ sign but I don't understand why you don't make a button for that along with b, i, a, link. '''<u>TASK #7</u>: Could you figure out how to ping someone who has <u>not</u>''' '''commented in the section you are replying in? What did you think of this experience?''' Yes but that's because you've told me it worked. '''<u>TASK #8</u>: Could you figure out how to delete the ping you created in Task #7? What did you think of this experience?''' Yes because of VE experience. '''<u>TASK #9</u>: Could you figure out how to see the comment you were writing in the <code>visual</code> mode, in the <code>source</code> mode before posting the comment to the talk page? What – if any – part the wikitext looked different from how you expected?''' Easy enough '''<u>TASK #10</u>: Could you figure out how to post the comment you had written in Tasks #1 - #9 to the talk page?''' Very straight forward '''<u>TASK #11</u>: Does the diff you created by posting a comment look as you expected? What – if anything – were you surprised to see?''' Looks about right except that if I were only in visual mode I wouldn't know that it added the sig automatically and so I could easily type the four tildes and nothing happens until I post reply when I suddenly have my signature and just four plain tildes. '''<u>OVERALL</u>: If there are other comments or questions you would like to make the team aware of, please write them here.'''
PPelberg (WMF) (talkcontribs)
{{FlowMention|Barkeep49}} – great to see you again. Thank you for giving the tool a try and sharing the feedback you had. Some '''follow up questions''' and '''comments''' below... <br /> ===Follow up questions for you=== Regarding the text input mode that is shown by default, how – if at all – do you think the preference a community has set for what full page editing interface is shown in the article name space relates to the text input mode that is shown by default in the Reply tool? {{Tq|except that if I were only in visual mode I wouldn't know that it added the sig automatically and so I could easily type the four tildes and nothing happens until I post reply when I suddenly have my signature and just four plain tildes.}} Typing <code><nowiki>~~~~</nowiki></code> in the tool's <code>visual</code> mode to sign the comment you were posting: is this something you did instinctively or something you did intentionally to better understand how the tool works? In the meantime, here is a ticket for this issue: [[phab:T255738]] ===Comments=== {{Tq|I like that it defaults to Wikisource for me but is that something that is user preference and/or something a community could decide which would be the default on its own?}} Good question. The tool currently works in the following way: - When someone who has a preference set in Preference > Editing > Editing Mode uses the Reply tool for the first time, they will see the text input mode that matches the preference they have already set. - When someone who does '''<u>not</u>''' have a preference set in Preference > Editing > Editing Mode uses the Reply tool for the first time, they will see the text input mode that the community has defined. ...the logic above is explained in detail here: [[phab:T250523]] {{Tq|I really like writing content in VE and this reminds me of that.}} Awesome. If there are particular things you like about the <code>Visual</code> mode, we would be keen to hear, but no expectation. {{Tq|I mean I guessed it was an @ sign but I don't understand why you don't make a button for that along with b, i, a, link.}} Good call. A button for the pinging feature has been added. You can see how it looks and works here: https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats.
Barkeep49 (talkcontribs)
I type the four tildes out of habit. I'm discussing something so of course I'm going to sign it at the end. The button to mention a user is a big positive. Also makes clear you can mention other people.
PPelberg (WMF) (talkcontribs)
{{Tq|I type the four tildes out of habit. I'm discussing something so of course I'm going to sign it at the end.}} Simple enough. Thank you for explaining that. {{Tq|The button to mention a user is a big positive. Also makes clear you can mention other people.}} Excellent. <br />