This is an archive of past discussions on Wikipedia:Talk pages project. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I found it unexpected that there was no "edit comment" button next to the reply.
Editing was a little bit difficult but not impossible because there was no edit button.
I like the use of OOUI icons.
I think the prototype is fine.
I think this may break on pages like deletion discussions or RfCs where it may be needed to edit one multi-line reply or the RfC question but it may not be possible since the way that signatures have to be done for RfCs.
hi @Awesome Aasim – thank you for taking the time to try out the prototype and share what you thought about it here. Some comments and questions in response below...
2.I found it unexpected that there was no "edit comment" button next to the reply.
We hear you on this one...
The ability to edit specific comments is a feature we'd like to offer. Tho, it will likely be some time before this can happen as implementing it depends on some more involved technical work that we cannot take on right now.
In the meantime, here is where we are tracking this idea: phab:T245225.
5.I think the prototype is fine.
If there was any aspect of the design you were particularly pleased with, I'd value knowing. But no worries if nothing stood out to you :)
6.I think this may break on pages like deletion discussions or RfCs where it may be needed to edit one multi-line reply or the RfC question but it may not be possible since the way that signatures have to be done for RfCs.
Question: Are you able to share a link to a discussion that would enable me to see/experience the potential complication you're imagining? PPelberg (WMF) (talk) 23:45, 6 June 2022 (UTC)
I don't have one right now, but I do know from experience when setting up an RfC I have to structure it like this:
@PPelberg (WMF): The occasional need for two signatures is in order to comply with WP:RFCBRIEF. The RfC statement is delimited by the {{rfc}} tag and the first valid signature that occurs after that - within this span, we request brevity and neutrality. That portion of the RfC, less the {{rfc}} tag itself, is copied by Legobot (talk·contribs) to the RfC listing pages, such as WP:RFC/BIO. For some RfCs, it is necessary to provide a lengthy background, which can easily become not brief, and may well become not neutral either. Hence, two signatures - one to mark the end of the brief and neutral part, which gets bot-copied to the RfC listings; and a second to mark the end of the entire text posted by the person raising the RfC. As a recent example, consider Wikipedia talk:Manual of Style/Words to watch#RfC: Relative time references - 'today' or not 'today'?, and observe the two places where the timestamp 03:45, 6 June 2022 (UTC) occurs. If you also examine WP:RFC/HIST, you'll see the statement part of that RfC terminated with that same timestamp. --Redrose64 🌹 (talk) 12:26, 7 June 2022 (UTC)
It can already do this. See this edit. I typed the first ~~~~ and it added the second automatically.
We get occasional complaints about this, usually in the form of "Why did it add a duplicate signature at the end, after the P.S. I typed after my signature?" But it works perfectly for this use case. Whatamidoing (WMF) (talk) 17:25, 24 June 2022 (UTC)
Feedback: Xaosflux
Did you use mobile device or a laptop to test the prototype?
No I used a desktop (though I have no clue how this would differ from a laptop).
What did you find unexpected about the prototype?
That I was "subscribed" to things just because I replied. But I was only subscribed if I replied with the inline reply tool, not if I replied using the regular editor.
Bug? If a L2 header is followed by a L3 header, but the L2 header lead doesn't seem to have a signature in it, the magic counter and control headers seem to break.
Which steps in the "Try the Prototype" section did you find difficult to complete?
3,4 - they required manually looking at those heading counters in each section and trying to remember the counts of those values. 2 had the same challenge, but the page history helped I think.
This task is easier to do in vector-2022, as these counters appear in the TOC. Note, the prototype default skin is vector right now though. I have so many other problems with vector-2022 that I wouldn't use it just for this benefit right now.
What do you like about the prototype?
The inline reply links seem very easy for new editors to locate and use. I'd probably style them to be less aggressive for myself though.
What do you wish was different about the prototype?
The section counters are not authoritative, but the way they are presented makes it seem like they should be reliable.
In Minerva, the "Reply" link being on a newline instead of at the end of the line is a bit confusing.
(Optional) Can you imagine this design not working on some pages? If you can, please share links to these pages? It would be very helpful.
It seems to actually be in the way of anything other than basic indented discussions, for example this section
(meta) "Click the "Add topic" link/button at the top of this page."
meta-feedback. The directions for feedback start with "Start a new section on this talk page" - so this step at the end of the feedback procedure seems in error. (Besides this page doesn't have a "Add topic" button on my display, especially not when I'm already in the editor at this step. Also feedback prob shouldn't be new l2 sections on this entire page, I've changed the existing ones to l4.
Indeed it is! Thank you for taking the time to share this feedback with us, @Xaosflux. Some comments and questions in response below...
A)That I was "subscribed" to things just because I replied. But I was only subscribed if I replied with the inline reply tool, not if I replied using the regular editor.
Ah, I see. This is helpful to hear. While we are not yet ready to offer Topic Subscriptions at en.wiki, I thought you might be interested in hearing how - what we're calling – "Automatic Topic Subscriptions" is currently designed and implemented:
You have the ability to decide whether you are automatically subscribed to topics you comment in and/or start using the Reply or New Topic Tool within Special:Preferences
Automatic Topic Subscriptions will only be enabled by default for new accounts. People who have accounts when the feature is made available will have to explicitly enable the feature in settings to gain access to it
You are right. Right now, Automatic Topic Subscriptions is only available with the Reply Tool and New Topic Tool. Tho, if/when there is demand for the feature to be implemented in other editing interfaces, we'll prioritize work on phab:T290041.
B)Bug? If a L2 header is followed by a L3 header, but the L2 header lead doesn't seem to have a signature in it, the magic counter and control headers seem to break.
For context: in phab:T302450 we decided on the behavior you're currently experiencing. Of course, if you foresee complications with the approach we've taken so far, I'd value hearing them!
C)3,4 - they required manually looking at those heading counters in each section and trying to remember the counts of those values. 2 had the same challenge, but the page history helped I think. This task is easier to do in vector-2022, as these counters appear in the TOC.
We hear you on this. The new TOC that's available in vector-2022 eases the section-by-section review you referred to having to do.
D)The inline reply links seem very easy for new editors to locate and use. I'd probably style them to be less aggressive for myself though.
Noted. We're going to explore the design of the Reply button further in phab:T309904.
E)The section counters are not authoritative, but the way they are presented makes it seem like they should be reliable.
Can you please say more here? What about the "section counters" leads you to question their reliability?
F)In Minerva, the "Reply" link being on a newline instead of at the end of the line is a bit confusing.
"Confusing" as in seeing the "Reply" buttons being on a newline led you to be uncertain about what "Reply" button to tap to respond to a specific comment?
G)It seems to actually be in the way of anything other than basic indented discussions...
Can you share what "in the way" means to you in the context of the discussion you linked to? E.g. is there a particular action you find the new design makes it more difficult for you to access? Does the new design make some information more challenging for you to locate? Etc.
H)meta-feedback. The directions for feedback start...
I appreciate you putting thought to the process for sharing feedback itself. Can you share what edits you suggest we make to the Share Feedback instructions? I'm having a bit of a difficult time visualizing the issue(s) you're experiencing. PPelberg (WMF) (talk) 00:41, 7 June 2022 (UTC)
(B) yes in that section, the magic headers with summaries are missing, but that L3 section is an active discussion and could benefit from them. The L3 section there does "contain a discussion", but isn't getting any benefit of the discussion tool.
(E) the way the counters look in the UI make me think they are an authoritative count of actual actions and edits, but these seem to just estimates based off of the free-form wikitext (i.e. counting text that looks like signatures). For example in this section I forged someones signature, then used a malformed signature - so there actually are more "people in the discussion" and the counter is factually wrong. Most anywhere else in the mediawiki UI if a count is presented it is reliable, in this case it is a dynamic estimate.
(F) Yes, depending on the current line length/line wrap in some cases it made me think I was going to reply to the parent post - this only happens in Minerva where the replyto control is moved away from the end-of-line. I'd much rather it be inline, and be consistently located across skins.
(G) the presence of the reply links make me think I should be able to contribute to that section like the other entries in it, however it doesn't let me add to the ordered or bulleted lists, only insert unordered list comments to the existing bulleted or ordered items.
I appreciate you following up with these additional details, @Xaosflux.
The L3 section there does "contain a discussion", but isn't getting any benefit of the discussion tool.
Understood. Here is a ticket for the issue you've spotted: phab:T310560.
...the way the counters look in the UI make me think they are an authoritative count of actual actions and edits, but these seem to just estimates based off of the free-form wikitext (i.e. counting text that looks like signatures)...Most anywhere else in the mediawiki UI if a count is presented it is reliable, in this case it is a dynamic estimate
Ah, I see. Understood. I agree with you in thinking of the counters that appear each talk page section's heading as estimates.
Withe above in mind:
1) What harm/risk can you foresee resulting from these counters not being 100% accurate in cases like the ones you named? Asked another way: what do you worry could go wrong if the counts are slightly off in some cases?
2) Is there something about the counters beings shown beneath each talk page's section headings that you think causes them to require a higher level of precision than the estimates that are present elsewhere within mediawiki? I ask this question thinking about how the number of pages within a category can sometimes be inaccurate.
Yes, depending on the current line length/line wrap in some cases it made me think I was going to reply to the parent post...
Mmm, I see. I'll be curious to see if people experience confusion similar to what you've named here. In the meantime, I've added a note to phab:T309904 to make sure we remember this feedback.
the presence of the reply links make me think I should be able to contribute to that section like the other entries in it...
I see. Two resulting questions:
1) At what point did you realize the Reply links did NOT work in the way you described above?
2) Can you recall encountering a discussion like the vote you linked to where [ reply ] links were present and thinking they too would function as you described?
@PPelberg (WMF) Most of our "vote" things are usually in a namespace that doesn't support reply-link, so I don't have any good examples - I'm trying to view that from the eyes of a novice contributor as well - I'm very versed on wikimarkup and what is going on here that the only annoying parts I've run in to are trying to use reply-link somewhere, then just abandoning it and using the wikitext edtor when mixed list types are invovled; on the summary "counts" - I'd only see this as an issue on our project if someone tries to incorrectly present them as accurate later ("A people participated about idea X, while only B people participated about idea Y") - but as popular extensions can be used worldwide for any sorts of reasons, the veracity of that number could be more important to others. — xaosfluxTalk01:01, 14 June 2022 (UTC)
hi @Xaosflux – I appreciate you following up with me and I'm sorry it's taken me some time to get back to you.
on the summary "counts" - I'd only see this as an issue on our project if someone tries to incorrectly present them as accurate later ("A people participated about idea X, while only B people participated about idea Y")
Ah, I see. The case you had in mind is clear to me now. Although, if a scenario like the one you described were to occur, my instinct is to think, "Well, if people disagreed about the number of people who participated in a discussion, wouldn't volunteers generally agree that the page history is the ultimate source of truth and thus resolve the disagreement that way?
In stating the above I am not meaning to dismiss the issue you are raising, but rather I'm trying to understand what – if anything – DiscussionTools might do to minimize this kind of confusion.
...but as popular extensions can be used worldwide for any sorts of reasons, the veracity of that number could be more important to others.
Right right.
My instinct after thinking about the above is as follows:
"If and when people become confused by the "authoritativeness" of the people and comment counts contained within Topic Containers, let's consider iterating on the design to avoid this kind of confusion. In the meantime, let's leave them as is."
The key point is really whether you use the mobile site (en.m.wikipedia.org) or the desktop site, although knowing something about your hardware can be helpful, too. Whatamidoing (WMF) (talk) 20:23, 27 May 2022 (UTC)
hi @Tenryuu – thank you for taking the time to try out the prototype and write up this feedback! Some comments in response to what you shared below...
I was surprised that trying to reply to other comments is impossible when the reply tool is being used for one comment.
We hear you. Here is a ticket where we are considering revising this behavior so that people can have multiple Reply Tools open at once: phab:T257305.
For context, only being able to have one Reply Tool open at a time was a consequence of the necessary auto-saving NOT being in place to support it.
The reply link now has an icon associated with it.
Can you say a bit more here? What did you appreciate about the reply link having an icon associated with it?
Please add an edit link to one's own comments at the very least, like Convenient Discussions.
We'd like to be able to offer people the ability to edit specific comments.
Although, doing the above would require us to make some other, more involved, technical changes that we are not likely to be able to prioritize in the near-term.
Can you say a bit more here? What did you appreciate about the reply link having an icon associated with it?
@PPelberg (WMF): I'm a sucker for icons. They become associated with a concept rather quickly, which can help editors learn what things do faster if they encounter it or something similar somewhere else. —Tenryuu 🐲 ( 💬 • 📝 ) 04:57, 18 June 2022 (UTC)
Feedback: Barkeep49
Desktop
The subscription notifications.
I didn't initially see the # of people responding and # of comments until I went back to answer this question. Also it appears some topics don't have those?
The increased use of icons (including the bigger reply button)
A way to adjust the default subscription option when replying or starting a topic.
Topics only report the number of people/comments if there is a detectable signature in between the ==Section heading== and any ===Subsections=== (or the next ==Section==). For example, this section doesn't have and detectable signatures in the relevant location. Whatamidoing (WMF) (talk) 20:29, 27 May 2022 (UTC)
hi @Barkeep49 - thank you for giving the prototype a try and coming back here to share what you thought about it. Some follow up comments and questions in response below…
A)subsription notifications
Can you say more here? Would it be accurate for me to understand you as saying that you found it unexpected for the “🔔 Subscribe” buttons to appear as they did? Are you referring to how you might have been automatically subscribed to a discussion you started or commented within on the prototype wiki? Something else?
B)I didn't initially see the # of people responding and # of comments until I went back to answer this question.
Understood. And when you did notice the information that appears beneath ‘’some section titles’’ (more on this below), what did you think of it? Could you imagine finding that information useful? If so, how?
C)Also it appears some topics don't have those?
Assuming it is accurate for me to think the topics you are referring to above are H2’s that don’t contain any signed comments then this behavior is expected. Tho, if you found this to be confusing, I’d value knowing!
D) The increased use of icons (including the bigger reply button)
This is helpful to know.
E)A way to adjust the default subscription option when replying or starting a topic.
Just to make sure, you’re wanting to be able to decide whether you are automatically subscribed to a topic you are starting or a topic you are commenting in rather than making this decision “once” via Preferences?
F)I continue to appreciate the ways this project has progressed and features have been added. Knowing you find the work we are doing useful makes me, and the entire team, happy to hear…thank you for letting us know as much. ^ _ ^ PPelberg (WMF) (talk) 01:58, 18 June 2022 (UTC)
So I have to be honest I don't recall all my reactions from the time I did it. That said, here goes.
A) I think I was more taken aback that this was now technically feasible and was happening. The button itself was intuitive enough.
B) I definitely think I would find this useful - I turn on the XTools gadget
C) Yes that's what I was referring to. I didn't understand why, that explanation makes sense and means it's unlikely to be confusing in a non-test environment
E) Yes. Similar to the way that I have the checkbox to watch a page when I reply, which is checked if I'm already watching it
About A, we've wished for section watchlisting for so long, and been told it was impossible so many times, that anything related to it feels like a surprising gift. Whatamidoing (WMF) (talk) 16:52, 23 June 2022 (UTC)
Yikes, I'm sorry for the delay in responding, @Barkeep49. What you described definitely helps. Some quick responses below to close the remaining "open loops."
A) I think I was more taken aback that this was now technically feasible and was happening. The button itself was intuitive enough.
Oh, okay. Understood. If you're curious to try out the subscription feature for yourself, you can enable it in Special:Preferences. You'll want to look for the Enable topic subscription setting with the "Discussion pages" section and ensure you have the "Discussion tools" beta feature enabled.
B) I definitely think I would find this useful - I turn on the XTools gadget
Okay. This is good to hear.
C) Yes that's what I was referring to. I didn't understand why, that explanation makes sense and means it's unlikely to be confusing in a non-test environment.
Understood. If this proves not to be the case, please let me/us know.
E) Yes. Similar to the way that I have the checkbox to watch a page when I reply, which is checked if I'm already watching it.
The comments count, participants count, and last comment at the top of each level-2 section was the main new thing that stood out. Also, it was a little weird after I posted the new topic for it to immediately say "47 seconds ago" rather than starting at "0 seconds ago".
For steps 2–4, I had to scroll down the page, stopping at each section. The information wasn't available in the table of contents, nor was it possible to sort the discussions. Also, to edit my own comment, I had to go into source editor, rather than having a more convenient button to click.
I liked how each signature had a clear reply button after it.
I wish that more of the information was in the table of contents so I wouldn't have to scroll to find it. Also, it'd be nice if hovering over the participants count caused a list of them to come up (perhaps even identifying if any are admins, although that might be controversial).
Thank you for trying out the prototype, @Sdkb. Responses to the feedback you shared below. Although, I appreciate that it taking me ~2 months to respond may make it difficult for you to respond to the questions I'm asking. If that's the case, "I don't remember" is a perfectly acceptable response :)
...it was a little weird after I posted the new topic for it to immediately say "47 seconds ago" rather than starting at "0 seconds ago".
Great spot; this issue should now be fixed via phab:T310090.
For steps 2–4, I had to scroll down the page, stopping at each section. The information wasn't available in the table of contents, nor was it possible to sort the discussions.
Do you recall what skin you were using? E.g. "Vector (2022)" or "Vector legacy (2010)"?
If it was the latter, that would mean the new table of contents enhanced with comment counts wouldn't have been available to you.
Either way, I assume having access to comment counts within the table of contents would not have made finding the discussion with the most people participating in it.
Regarding sorting discussions, this is an idea that surfaced during usability testing that I agree would be valuable (T309468). Tho, I think it's unlikely we will have time to implement this during this phase of the Talk pages project
I liked how each signature had a clear reply button after it.
This is helpful to hear. So you're aware, we revised the design of the "Reply" buttons on desktop slightly by removing the arrow that appeared before them. We're thinking this will make the button less distracting without making them too hard to notice. You can see the latest design here.
I wish that more of the information was in the table of contents so I wouldn't have to scroll to find it.
We hear you on this. For now, we've kept the "metadata" that appears in the table of contents limited to comment counts in order to make it easer for people to read the heading list. See: phab:T309463.
If/when you start using the new table of contents on talk pages and come to find yourself wanting additional information to appear within the table of contents, I'd value knowing.
Also, it'd be nice if hovering over the participants count caused a list of them to come up (perhaps even identifying if any are admins, although that might be controversial).
Can you please more here? How can you imagine using the participant list you are describing? What "decision" might that help you make more easily?
@PPelberg (WMF), I've been using Vector 2022 on Wikipedia, but clicking on the link, for the test site it seems I'm on legacy Vector. I'm not sure how to change to Vector 2022 there.
The new design of the reply with bold but no icon looks fine. I kinda like the way it's currently designed, though, with the brackets around it, as that matches the design of the edit buttons so seems more consistent.
Re the participants list, it could help me understand a discussion at a glance better and decide whether to read through it all. I often already skim through a big thread to see who's participating, and that gives me a flavor of it. If there are a bunch of editors I know to be point of view-pushers, I'll expect it to be a partisan battleground. If it's no one I've ever heard of before, I'll expect it to be junior contributors perhaps in need of a more experienced editor to point to relevant guidance or otherwise help out. If it's got several names of admins I respect, I'll expect it to have good thoughtful discussion but perhaps not need my own insights as much. Etc.
Looking at the screenshot of your more recent mock-up, a few thoughts:
In the table of contents, space is very tight trying to fit in all the threads without having to have a nasty scroll bar. Given that, I don't think it's desirable to write out "comments" when with a tooltip would work just as well in far less space.
I like the bolding of "beginning" as a way to set it apart. The latest comment thing, space after the namespace, and vertical space between threads all look good, too.
For the add topic button, I'd encourage some more effort on centralizing that in a single place. Right now, there's "new section" next to the view history tab, "click here to start a new topic" in {{Talk header}} (under community control; if there are any changes you'd suggest to that template, I'd definitely be interested to hear), and then the button below the coffee roll before the first comment. These all do the same thing, and I think it might be confusing for some newer editors to have them all. It'd be nicer if there was just a single, very prominent "new topic" button, perhaps below the table of contents so that'd it be persistent as one scrolls. {{u|Sdkb}}talk17:26, 23 July 2022 (UTC)
Switched to New Vector for the demo patch. I like the symbols used in the ToC there, but they take up way too much space; I'd rather they be smaller and inline with the section name. {{u|Sdkb}}talk21:37, 25 July 2022 (UTC)
This additional context is helpful; thank you for following up with it, @Sdkb. Responses below...
The new design of the reply with bold but no icon looks fine. I kinda like the way it's currently designed, though, with the brackets around it, as that matches the design of the edit buttons so seems more consistent.
I hear you. I'll be curious to see how you, and other people, feel about the look once this new button treatment makes its way into the Discussion tools beta feature. Not to say what you shared isn't helpful, but rather that I think it will be good to see how/if this perception evolves over time.
Re the participants list, it could help me understand a discussion at a glance better and decide whether to read through it all...
This is precisely the kind of information I was seeking...thank you. I've added this to T309752.
I don't think it's desirable to write out "comments" when with a tooltip would work just as well in far less space.
We went back on this design quite a bit. The icon, as you alluded to, might end up being the least cluttered approach. Although, we found the text-only version to be the most legible in the testing we did. This might not end up being true in reality...let's see.
I like the bolding of "beginning" as a way to set it apart. The latest comment thing, space after the namespace, and vertical space between threads all look good, too.
This is nice to hear.
Right now, there's "new section" next to the view history tab, "click here to start a new topic" in {{Talk header}} (under community control; if there are any changes you'd suggest to that template, I'd definitely be interested to hear), and then the button below the coffee roll before the first comment. These all do the same thing, and I think it might be confusing for some newer editors to have them all.
This is helpful context and I agree with problem you named about people being confused by the duplicative calls to action that exist on the page.
To the idea you raised about there being, "...a single, very prominent "new topic" button...", we're working on doing what you described on desktop by way of introducing a new "Add topic" button within the new sticky header Vector (2022) is introducing. You can see what we have in mind in phab:T304187. If you have thoughts about it, I'd be curious to hear. PPelberg (WMF) (talk) 00:44, 26 July 2022 (UTC)
Putting the new topic button in the sticky header seems good to me! I'd lean a little toward primary styling with the blue background to make it obvious. The remaining question would then just be where to put it before you've started scrolling. {{u|Sdkb}}talk04:28, 26 July 2022 (UTC)
Thanks, @Whatamidoing (WMF). Expanding a bit on what you/@PPelberg (WMF) have brought up with the reply button design, the bolding looks fine on its own, but I worry it's not unified with any broader cohesive visual style. [ X ] seems to be the Wikimedia style for "take some action related to X," and I'd like to see that preserved. Ultimately, I'm hoping that there will be two buttons after every comment, reply and link, and [ reply | link ] or [ reply | ] seems like the intuitive way to design that. {{u|Sdkb}}talk19:53, 26 July 2022 (UTC)
The remaining question would then just be where to put it before you've started scrolling.
Adding a topic wasn't as clear as I'd like. I'd expect like a clear button maybe at the top of the page, rather than/alongside the "Add topic" tab option. Preferably, if it was alongside the "Last comment...." info at the top of the page and had a plus icon similar to this. I really don't like that the "reply" button is appended to the end of the comment on the same line and would prefer it be split to a different line to separate content and actions a bit better.
I love how modern and friendly it feels. I also like the ease of subscribing to each topic and the popovers telling me what I've subscribed to and how I'll be notified.
I would really like indent lines similar to Reddit and Convenient discussions so long threads can be collapsed and it is also easier to follow along. If possible, the signature should be split on to a new line and put alongside the action buttons (reply etc.) or the signature put on the top line.
hi @Ed6767! Wow. I'm sorry for the lag and I appreciate you taking the time to try out the prototype and share what you thought about it. There are some comments/questions in response. Although, if the amount the time that's passed makes the questions I'm asking difficult to answer, please say as much :)
The way discussion sections are split
Do you remember what you meant by "split" here? Are you referring to the horizontal line that appears between sections? How the actual == H2 == section headings are styled? Something else? Note: here is a link to the latest desktop and mobile designs in case a visual reminder would be helpful.
Adding a topic wasn't as clear as I'd like. I'd expect like a clear button maybe at the top of the page, rather than/alongside the "Add topic" tab option.
Great spot and we agree in the value in making the button for adding a new topic easier for people to notice and access. In fact, we're in the midst of adding a new "Add topic" button that will remain in view regardless of where people are on the page. You can see the design we have in mind in phab:T304187. Of course, if any questions/comments come up with what we're implementing, I'd value hearing them. Note: we're also considering a complimentary "Add topic" button that would be available on shorter talk pages where the sticky header phab:T304187 depends on would not be available. More in T309465.
I really don't like that the "reply" button is appended to the end of the comment on the same line and would prefer it be split to a different line to separate content and actions a bit better.
I love how modern and friendly it feels. I also like the ease of subscribing to each topic and the popovers telling me what I've subscribed to and how I'll be notified.
Oh, great. I'm glad to hear you think as much ^ _ ^
I would really like indent lines similar to Reddit and Convenient discussions so long threads can be collapsed and it is also easier to follow along.
Evolving how the comments and sub-topics within discussions are shown to make it easier for people to follow and make sense of the conversation is something that is on our mind as well. It is not looking like the Editing Team will have time to implement this as part of the Phase 1 of the Talk Pages Project. Tho, I've added what you shared above to the ticket where we're tracking this future work in Phabricator: T282269
Hi @PPelberg (WMF), thanks for your very detailed response, and for copying me into the relevant Phabricator tasks.I'm sorry I didn't go into more detail in my original feedback, but by split I think I did mean the way there was a horizontal division between sections, although with a fresh pair of eyes I think it looks okay. As for pages that it might not work on, take a look at a page like Wikipedia:Articles for deletion/Spiral Universe. When a discussion is closed not only is it wrapped in a template, I'd like to see the "reply" option disabled here, as the discussion is closed.As for everything else, that sounds good, and I'll be sure to keep a keen eye on the tasks when I can and participate in any further feedback. ✨ Edtalk! ✨ 01:41, 26 July 2022 (UTC)
If anyone wants to see that horizontal line "in the wild", then it's visible right now at a couple of wikis (but not here). Start by going to Special:GlobalPreferences#mw-prefsection-betafeatures and turning on "Discussion tools" at all the wikis. Save that change. Then go to any of these pages:
...by split I think I did mean the way there was a horizontal division between sections, although with a fresh pair of eyes I think it looks okay.
Understood! Thank you for clarifying.
As for pages that it might not work on, take a look at a page like Wikipedia:Articles for deletion/Spiral Universe. When a discussion is closed not only is it wrapped in a template, I'd like to see the "reply" option disabled here, as the discussion is closed.
Thank you for this example. I've added it to T249293 which is the ticket we are using to track work on making it possible to disable Reply links/buttons from showing/being operable in specific cases.
As for everything else, that sounds good, and I'll be sure to keep a keen eye on the tasks when I can and participate in any further feedback.
Finding the section with the most comments; I searched for all occurrences of " comments".
The "Last comment" info; it's an easy way to see if a discussion is still active.
Reply indicators are too obtrusive for my personal taste.
Asking to find the sections with the most comments or the most participants doesn't, in my view, reflect a real-world workflow for most editors. I appreciate it's hard to mimic an actual workflow that would make use of this info with a mockup, since this info is probably most useful when returning to a discussion. isaacl (talk) 02:55, 21 May 2022 (UTC)
hi @Isaacl – thank you for taking the time to try out the prototype and share what you think about it an I'm sorry for taking ~2 months to respond to you!
In either case, responses to the feedback you shared below...
Finding the section with the most comments; I searched for all occurrences of " comments".
I hear you. Since you first tried the prototype, we have made a change that we think will make it easier for people to determine the level of activity within each section...
The "Last comment" info; it's an easy way to see if a discussion is still active.
It's helpful to know you found the "last comment" indicator useful.
Reply indicators are too obtrusive for my personal taste.
Understood and we agree. We have since revised the design of the "Reply" buttons to make them less obtrusive/distracting by removing the arrow that had previously appeared before each one. You can see how the Reply links look now by visiting the same prototype I linked to above.
Asking to find the sections with the most comments or the most participants doesn't, in my view, reflect a real-world workflow for most editors. I appreciate it's hard to mimic an actual workflow that would make use of this info with a mockup, since this info is probably most useful when returning to a discussion.
I'm a bit puzzled by the question, as it sounds like you're asking me to reverse-engineer the user story that caused you to add the count of comments? I think showing the count in the table of contents, though, makes the feature more akin to how bulletin board software shows the number of posts in a thread in its list of threads. I can think of more user stories that take advantage of this design choice, but am interested in hearing the ones upon which the prototype is based. isaacl (talk) 22:40, 1 August 2022 (UTC)
@Isaacl, the user stories include scenarios like "How many people participated in this RFC that I'm closing?" (for large numbers of editors) and "This wall of text is TL;DR – did this person get a reply, because if anyone else replied, I'm not going to read it?" (for small numbers). Whatamidoing (WMF) (talk) 18:29, 2 August 2022 (UTC)
These are interesting user stories in that I think the exact number of participants is less relevant than "were there a lot of participants (for some threshold value of 'a lot')" for the first story, and "were there any participants" for the second story. For the first case, then, I'd suggest asking someone to look at three threads, and determine which ones seem ready for closure. For the second story, I'd suggest asking someone to look at the table of contents for three threads asking questions, and prioritize which one you think you ought to reply to first.
For me, when I look at a list of threads on a bulletin board web site, I'll use the reply count to consider which threads may have interesting discussion. For threads I've seen already, I'm more likely to look at the last comment timestamp to see if there have been new comments. isaacl (talk) 19:58, 2 August 2022 (UTC)
In some communities, you need a quorum for certain kinds of decisions. I understand that it's easier for computers to count the exact number than to say "enough people", even if the latter is the point. There are other times when people just want to add a quick description ("14 editors participated in this RFC") or to figure out whether it belongs in Wikipedia:Times that 100 Wikipedians supported something.
@Isaacl, have you tried out the [subscribe] tool? It tells you when new comments have been posted, but I'm loving the way it highlights the new comments. (Now if I could just get people to stop updating their timestamps if they fix a typo – the highlighting is based on the timestamp at original posting, so if you change it even by one minute, it can't find the comment.) Whatamidoing (WMF) (talk) 22:32, 2 August 2022 (UTC)
Oh, that might explain some of the cases where clicking through didn't find the corresponding comment... Yes, I do use it, but I usually only subscribe to select threads that I'm particularly interested in following. I think I might still find the bulletin-board-like behaviour useful, if the last comment timestamp were in the table of contents.
Sure, those are user stories for wanting to know the count. I don't personally find them compelling for most readers such that the info needs to be displayed all the time instead of using a tool (you'd still need to use another tool to count supports). isaacl (talk) 00:16, 3 August 2022 (UTC)
Feedback: MichaelMaggs
I have been using the beta version of this on enW for a while, so some of my suggestions are informed by my experiences of that as well.
1. Neither - desktop
2. Unexpected:
As discussed at length elsewhere, it's a bit odd that the edit summary is collapsed behind an "Advanced" link, but the "Reply" default seems fine
Probably just a testing issue, but I didn't expect to have to use an entirely new wiki which required me to set up a new account before I started. Can't recall having to do that when previously providing similar feedback. Hope not to have to do that every time
3. Difficulties:
It was difficult to edit my own comment, as there still seems to be no new option to do that (if there was I didn't see it), so I had to scroll right to the top and do it in the wiki editor. By no mean obvious for an inexperienced user. After saving the correction, I was left at the very top of a very long thread and had to scroll right down to the bottom again to assure myself that everything looked OK. In live editing, I find this to be a real hassle when working on long talk pages, and pages with many comments. All the scrolling up and down, and re-finding my place, takes ages!
In the beta version, the find user icon above the text box doesn't always find all the editors in the thread, but I didn't check that in this prototype.
4. Like:
I like the clear reply icons, and the orange flush that highlights a new topic. I don't find either intrusive
The visual/source option for the reply box works well, as does the preview underneath
The last edit date, number of users and number of comments are useful, and not too intrusive
The subscribe/unsubscribe icons on the right are clear
The Share feedback link is a nice touch
5. Would like to see:
an "edit" button next to (all) my own comments to avoid the need for the wiki editor
a one-click button somewhere to take me directly to the top of the page (and ideally to the top of the current section)
some way to collapse discussions
a "people in discussion" mouseover that provides a clickable list of users. Would be a quick way to go to a user's talk page
Are you testing how this integrates with 2022 Vector skin? Using that for live editing I see a few differences, such as a table of contents in the left margin that doesn't appear in the Patch demo prototype. (No actual conflicts so far as I can tell so far). MichaelMaggs (talk) 14:10, 26 May 2022 (UTC)
@MichaelMaggs: thank you for trying out the prototype of the potential new talk page design and for sharing what you thought about. A few comments and questions in response below.
Before that: I'm sorry it's taken me ~2 months to get back to you 😔
It was difficult to edit my own comment, as there still seems to be no new option to do that (if there was I didn't see it), so I had to scroll right to the top and do it in the wiki editor...All the scrolling up and down, and re-finding my place, takes ages!
We hear you on this one! Offering people the ability to edit specific comments is a feature that has been something we've had in mind for some time. Although, implementing this functionality is unfortunately dependent on some more involved technical work that we will not have time to prioritize as part of this phase of the mw:Talk pages project. In any event, I've added your support for this functionality to the ticket where we are tracking work on it: phab:T245225.
In the beta version, the find user icon above the text box doesn't always find all the editors in the thread, but I didn't check that in this prototype.
This sounds like a bug. If/when you notice this happen again, can you please share a link to the discussion so that we can try to reproduce the issue and, ideally, fix it?
an "edit" button next to (all) my own comments to avoid the need for the wiki editor.
I thinkT245225 would implement the functionality you are describing here. Although, please tell me if you think otherwise.
a one-click button somewhere to take me directly to the top of the page (and ideally to the top of the current section).
Good spot. Can you please give T314203 and T314204 a quick read and let me know if they accurately describe what you are seeking?
some way to collapse discussions
This is another feature we see value in, but will not be able to prioritize in the near-term. Regardless, I've added you to the ticket where we are tracking work on this: T269954.
a "people in discussion" mouseover that provides a clickable list of users. Would be a quick way to go to a user's talk page
When I reply to someone and I press the shift button when I intend to write a capital letter, many times the cursor gets to the beginning of my post's paragraph, even if Im writing at the end of it. Very annoying because I am forced to write the letter, cut and paste. Thinker78(talk)19:59, 26 July 2022 (UTC)
@Thinker78: This is off-topic for this page, which is about discussing improvements to Wikipedia:Talk pages project, you should be asking at WP:VPT. But the first few things that they will ask you will include: which operating system (and version) are you using? Which browser (and version)? Which skin? Which editor? --Redrose64 🌹 (talk) 20:15, 26 July 2022 (UTC)
@Redrose64 I think you are mistaken. The instructions in this project literally instruct to write about open bugs here. "You can leave feedback at mw:Talk:Talk pages project/replying or on the talk page here". Thinker78(talk)21:55, 26 July 2022 (UTC)
Thinker78, I still need your browser/OS information.
I also want to know:
if it happens every single time (yes?),
if it only happens in visual or wikitext source mode (or both, which is my suspicion), and
I was trying to reproduce the bug again but I was unable to until I changed from source to visual in the new reply interface of the talk page. But still I reproduced it only once. I will report if I get further issues with the bug.
Bug is kind of frustrating. I don't know what triggers it and it doesn't always show up. The annoyance is so great that I am rather using the old method of edit source at the first sign the bug starts. Thinker78(talk)18:35, 3 August 2022 (UTC)
Top-of-page "Latest comment ..." is too far left. Timeless in tablet-portrait width has very narrow margins, and the 'L' is cut off the left edge of the screen.
Need some vertical whitespace between that Latest comment line and the templates.
Lines above and below the topic head is interesting. I like how it groups the H2 and info line ("latest comment ... x comments y people ..." – do you have an official term for this?). And I like having something more than just white space between the info line and first comment.
Thicker elements of topic header (edit pencil, line below) are a lighter grey than the thin ones (x comments, line above). This looks balanced in day/light mode, but is noticeable when inverted for night use. (A proper dark colour theme would have its own perceptually-balanced gradation of lightness.)
Vector 2022
Yay, comment counts in ToC. But no other freshness / activity indicators.
Vector – no skin-specific observations.
Monobook
I notice the H2 font is heavier than in regular Monobook. As someone who doesn't usually read in Monobook, this doesn't strongly bother me, but interested in others' opinions.
Minerva, because I can't follow instructions, and because why not? Possibly our most-used skin given the proportion of mobile readers.
Have posted first impressions of an earlier demo elsewhere.
Not a fan of having Reply on its own line. Would rather see whole sig. on a separate line.
General
No "n comments, last edited ..." indicators in the ToCs (except partial in Vector2)? :(
What happens if a page has both talk-page styling and a short description? (In terms of visual consistency for the latest-comment and SD lines at top of page. Are there plans to display SDs without gadgets? I think there should be.)
I have mixed feelings about the blue Reply links.
I do think they are better without the arrow icon, which was too attention-grabbing where a section had numerous short comments.
With or without square brackets? Other action items like [ edit source ] have the brackets. Do we distinguish between things which work in-line (Reply, subscribe) versus ones that navigate away to an editing page (edit, edit source)?
What happens if rendered page content is copied and pasted as plain text? Should there be invisible brackets so that it pastes as “...2022 (UTC) [Reply]” not “...2022 (UTC)Reply”? (Note missing space between (UTC) and Reply.)
I really think the lines-above-and-below styling from Timeless (which might be accidental?) is worth considering for all skins.
The new [subscribe] button notifies people when someone replies to their comments. It helps newcomers get answers to their questions. People reply sooner. You can read the report. The Editing team is turning this tool on for everyone. You will be able to turn it off in your preferences.
In offering help on a talk page it's often useful to be able to show some code using "nowiki", but this doesn't seem to be on offer - though I can use code and strikethrough among many other options from the "style text" dropdown. Please consider adding "nowiki". Thanks. (Trying to take a month's wikibreak, so may not respond quickly). PamD13:59, 9 August 2022 (UTC)
@PamD, I agree with you. It's not hard to trigger nowiki codes on purpose in the visual mode, and that's what I usually use. Alternatively, I sometimes use <u> (the underline markup) and then replace the u with nowiki in the wikitext code. This method reduces the risk that I'll forget the / in the closing tag.
@Matma Rex and Whatamidoing (WMF): Interesting comments but what I'd like is just to see the "nowiki" option provided in the dropdown menu when adding a talk page comment using the new facility! Is this the right place to suggest/request that, or should I be somewhere else? PamD07:04, 18 August 2022 (UTC)
Pardon if this has been discussed before, but I'm lazy...The reply mechanism is really cool, but it's consistently messing up unblock requests. Its not the fault of "reply" itself, but reply could prevent it. There are some things that break if they are indented.
You can see an example of the problem at User talk:jpgordon#demonstrate unblock error (the unblock templates are wired to be unusable other than on user talk pages.) I wonder if "reply" could learn to not indent in some circumstances? I haven't made any headway trying to fix the underlying problem, but it seems to mostly show up in the case of people using "reply" to respond to block notices. --jpgordon𝄢𝄆𝄐𝄇23:50, 10 September 2022 (UTC)
@Jpgordon what is the workflow that is leading you to this situation? Reply-tool is designed for, well, replying in a discussion. Can you show the step by steps (with diffs) of the scenario that is leading to this situation? — xaosfluxTalk00:07, 11 September 2022 (UTC)
Sure. My most common scenario: here, editor uses "reply" in response to a block notice. So far so good; whatever the cause of the problem is, {{unblock}} alone doesn't trigger it. Then here, I use unblock-review (which is pretty widely used by admins who monitor the unblock request heap) to respond to the request. The cure on my side is simple, just another edit to get rid of the indent. A cure on the other side would be "don't indent if the reply is an unblock request." But I don't know if the reply mechanism has any context sensitivity, or should. I've discussed it previously at Template talk:Unblock reviewed#Can this be fixed?. --jpgordon𝄢𝄆𝄐𝄇01:05, 11 September 2022 (UTC)
@Jpgordon Hmm, context-aware - don't think that's going to happen. A few things to look at Template:Unblock and Template:Unblock reviewed are very complicated, and drag an entire sea of containers (div's, spans, etc) that really don't belong inside a dl (the "indent") - so are breaking in all sorts of ways. Perhaps these should include a suggested improvement from phab:T295553, and suppress the reply-tool in their section. — xaosfluxTalk01:46, 11 September 2022 (UTC)
yah, there are several ways to make the problem go away. I suspect really fixing it would require some deep diving. People used to pay me to do that stuff... --jpgordon𝄢𝄆𝄐𝄇01:57, 11 September 2022 (UTC)
Context sensitivity is phab:T263902, and it won't happen in this round (which is wrapping up on the engineering side). Much more promising is phab:T295553, which would let you put a magic word in the template and turn off all Reply buttons in that ==section==.
That's a pretty sledgehammer-filled approach. I just blew the whole thing away by creating my own version of unblock-review that inserts the newline in the useful place. --jpgordon𝄢𝄆𝄐𝄇14:23, 14 September 2022 (UTC)
Does the "Reply Tool" actually reply to the indicated user???
Nowhere in the help pages does it say.
Does the replied-to user get a notification you replied to them? Or not?
If not, why is the tool called "Reply tool" when you still must "ping" the user in question?
@CapnZapp by default, it does not generate an echo notification unless you click on the "+" and put their name in the box. Sometimes this is a good thing, say I opened a thread: "Does anyone want a free beer, reply below and I'll send you a coupon for one!" I certainly wouldn't want an echo notification from each "Yes please!". In combination with topic subscriptions, echo notifications would also be redundant. — xaosfluxTalk13:24, 9 September 2022 (UTC)
Due to history, English Wikipedia's conventions for discussion more closely approximate a Usenet newsgroup than an instant messaging solution. If using the visual editing interface in the reply tool, you can also type @ to trigger a prompt to enter a user name. I appreciate how some editors may find it helpful to opt into receiving notifications for a specific comment they made. On the other hand, we may prefer to encourage editors to be aware of the full discussion, which is facilitated by the current section-based subscription mechanism. isaacl (talk) 16:05, 9 September 2022 (UTC)
Thanks, but PLEASE understand that loads of users will simply expect the reply tool to actually informed the replied-to user of your comment.
Having to additionally reply to (or ping) a user when you are using a GUI feature called "reply to" is severely unintuitive.
Please a) update the documentation to make it clear that yes, you just replied to a user, but no, the user won't be notified by default and so can easily miss your reply; and b) consider tweaking the user experience to remove this obvious source of potential misunderstanding.
Basically: reconsider the idea to call this tool "reply to" without introducing clear graphical hints whether the user gets notified or not.
Yes, I myself understand that to any experienced Wikipedian it's obvious that, say, you won't actually {{reply to}} someone just by replying to him or her.
But if we lift our gaze above internal Wiki workings for a second, we immediately realize the absurdity of assuming the previous statement makes any sense whatsoever to most of our users. Hopefully, you will by now have realized something really fundamental got overlooked here. Please don't think it's reasonable to expect general non-expert users to understand they need to click a "+" sign or enter "@" characters for the UI to do what they will simply assume it does for free.
I'm not sure if you referring to me when you say "you will by now have realized...". I'm just an editor like you, with no involvement in the implementation.
It's not obvious to me that new editors will expect a notification to be sent by default. Responding on a talk page is a lot more like editing an article than using an interactive instant messaging tool. Nonetheless, as per the wiki way, you can certainly make changes to any relevant documentation or propose changes on their talk pages. isaacl (talk) 08:07, 11 September 2022 (UTC)
I like this the way it is, I don't want to be pinged every time someone replies to me, and especially not if I am subscribed to the thread. Doug Wellertalk09:59, 11 September 2022 (UTC)
What I would like to request is: for the UX to make it much more clear whether an user will actually be notified when you reply to them. Barring that, I would like to request a much more helpful documentation, again addressing the question directly, and helping the user how to understand the distinction between the reply tool and something like {{reply to}}. Thank you. CapnZapp (talk) 16:02, 14 September 2022 (UTC)
I believe automatic subscriptions are enabled for all new editors. I don't remember whether that's defined as "created account after August xx" or "had less than 100 edits as of August xx", but newcomers should be getting notified about all (detected; same rules as pinging someone) replies, even when they're not pinged. Whatamidoing (WMF) (talk) 17:45, 14 September 2022 (UTC)
I have not asked for that. I just want us to not take it for granted that users realize that their replies might never be seen by the recipient. CapnZapp (talk) 16:03, 14 September 2022 (UTC)
No, I'm not talking to you. I'm giving feedback on the feature. I think us Wikipedians have dropped the ball here, not directly addressing the issue. We should not simply assume users understand that the reply tool is completely separate from the notifications system. Cheers CapnZapp (talk) 16:06, 14 September 2022 (UTC)
Coming soon
Like this
The Beta Feature is supposed to get some updates this month. You can see "everything" at these links:
The bit that will actually reach the Beta Feature is what the team calls "topic containers". It's just the stuff around the ==Section heading==, not the stuff at the top of the page or the stuff in Vector 2022's new Table of Contents. If you login (make a new account, using a password you don't use elsewhere, or login as any of the accounts I've created – probably Neuling, Newbie, and Robert – with testsecret1) if you want to see the new subscribe button.
Any chance of a magic-word or something to allow us to force non-level 2 subsections to have a "subscribe" option? I'm thinking of pages like discussions on WP:TFD where the nesting levels are 3 or 4 deep (3 for the date, 4 for the individual templates). —Locke Cole • t • c01:14, 22 September 2022 (UTC)
I'm not sure if this is the right place to post this, or if this has already been noticed, but here goes. It seems like the new talk page tools (including Reply Tool) identify discussion posts based on the existence of a nicely-formatted timestamp in the format 22:29, 1 October 2022 (UTC). Unfortunately, it seems like posts in and prior to 2005 have timestamps in a slightly different format (most significantly, having a three-character abbreviation for month) which causes the new tools to not function.
Examples can be easily found in old archives. For example, at User_talk:Jimbo_Wales/Archive_B#Request_for_intervention, the new tools only picked up the May 2004 signatures, because "May" is already 3 characters, but the other signatures with abbreviated months in this section and others are ignored.
(Another example of a malformed signature date causing problems is in the screenshot to the right, where the post on 1 May 2006 is missing "(UTC)" and therefore is missing the discussion features.)
Could the talk page features be enhanced to recognize the earlier timestamp formats? The most common alternative formats I've seen are 01:50, 22 Apr 2004 (UTC) (three-digit month, seen consistently from late 2003 to 2005) and 23:51 10 Jul 2003 (UTC) (three-digit month and no comma, seen consistently in mid-2003). -M.nelson (talk) 22:29, 1 October 2022 (UTC)
It's a known issue on other projects too, e.g. frwiki: T246047. It's unlikely that we will work on this, since no one needs to reply or subscribe to these discussions, and people very rarely read them. Matma Rextalk11:02, 8 October 2022 (UTC)
Can I enable "subscribe" on a talk page?
Is there a way that I can enable the "subscribe" feature on my own user talk page or another discussion page that doesn't have it? --Tryptofish (talk) 23:42, 25 November 2022 (UTC)
I just looked around at other user talk pages, all of which do have subscribe enabled, and that makes me wonder whether I've just asked a dumb question – is the reason that I don't see "subscribe" on my own talk page because I automatically have the whole thing watchlisted, but it's already available to anyone else who is registered and comes to my talk? --Tryptofish (talk) 00:03, 26 November 2022 (UTC)
Yes, you already receive notifications for all messages posted to your talk page, so it's as if you were already subscribed to every topic. Others can subscribe to topics on your talk page, I see the buttons myself there. Matma Rextalk13:15, 26 November 2022 (UTC)
Wiki Education Foundation course assignment additions to Talk pages via PrimeBOT
Wiki Education Foundation course assignment notices invariably end up at the top of article talk pages, violating the standard practice of starting a new section at the bottom of the talk page. Here is an example of one I moved down (diff). Is this problem due to PrimeBOT? If so, is there a fix in the works? If the problem is caused by some other factor, what is it? Many thanks - Mark D Worthen PsyD(talk)[he/him]09:49, 5 December 2022 (UTC)
Jeez, this one keeps coming back to bite me in the arse. The PrimeBOT run (from January, mind you) was a hot-fix to deal with a template replacement issue, and was never intended to be the modus operandi or the method-of-use going forward. Anything you see from my bot regarding WikiEd can be safely ignored as "that one time a bot did something that was unusual". By all means, fix them if you find them, but I am not going to have my bot run through thousands of pages just to enforce a non-binding convention of "new posts at the bottom" (and if I recall correctly, that was also the consensus at the time). Primefac (talk) 20:24, 5 December 2022 (UTC)
I did not know that talk pages can be organized in different ways, and that there is no particular standard in this regard (chronology and placement). And I did not mean for my post to be a criticism of the bot, something I know a little about and is way over my head technically, so I defer to the judgment of others, who know a lot more about this than I do. I was trying to understand the possible cause of what I saw as a problem, but I now understand that this type of thing does not happen often, and many very experienced editors do not see it as a problem. I will just not worry about talk page organization as much as I had previously--I can be a bit too obsessive compulsive about such things. ;^) Thank you for your replies. Mark D Worthen PsyD(talk)[he/him]09:51, 6 December 2022 (UTC)
If not, please tell me and I'd be happy to add more details to [hopefully] address any questions/uncertainties that remain in your mind after reading the above.
...when "Reply" wraps to the next line after the signature time stamp, it has a space in front of it, which is undesirable and does not comport with normal behavior of text.
@Jonesey95: does the orange line I've added to the screenshot below illustrate the unexpected space you're referring to?
...design document appears to conflict with the link provided above that shows the "Subscribe" button/link as larger text that is not bold, and the section edit links still as bracketed plain-text, normal-weight links. If you're going to change the WP interface so that these links become buttons, at least do it all at once, please.
@Jonesey95: I hear you about it being a bit odd that the [ edit ] links remain bracketed while the Reply buttons no longer are.
Initially, we'd planned to do as you described: make it so both the "Reply" and "Edit" buttons were styled the same. Although, to start, we thought more experienced volunteers would value the sense of familiarity the bracketed edit buttons could provide for some yet-to-be defined transitional period.
The above may turn out not to be the case as you seem to be suggesting above. In which case, we'll move forward with restyling the "edit" links so that they are consistent with the other buttons on the page. Here's a ticket for this work: T324807. Note: you mentioning this was the reminder I needed to file that ticket :)
I think bold might be more prominent than I'd personally prefer. I agree that it would quickly fade into the background and I wouldn't care that much. However it might have a knock-on effect of causing me to pay less attention to other bold text. This probably isn't a big deal on talk pages, though.
@isaacl: thank you for naming this risk. After some use, I'd value knowing how – if at all – you notice yourself being impacted by the new Reply button styling.
How would it look with a hollow swooshy-arrow, that echoes the hollow (not-subscribed) bell?
@Pelagic: the design [I think] you're describing is one that we'll be introducing in the coming days for people who have their interface language set to any one of the following languages: Arabic, Chinese, Cantonese, Japanese, or Northern Thai.
Reason being: the word "Reply" ends up being quite short in those languages and so folks expressed a need for an additional element to help them more easily distinguish the reply buttons from other content on the page.
Re the extra space before "Reply" when there is a line break before "Reply": Yes, that screen shot captures it. It is particularly obvious when there is a series of indented discussion responses: the "Reply" link looks like it is the first line of the response instead of the last part of the paragraph ending with the signature. I will note that this extra space happens now, with the link style as "[ reply ]", so it's not a new problem. I just noticed it when you asked us to look more carefully. My naive assumption is that the software is inserting a hard space after a regular space instead of just using a regular white space character, but I know from painful experience that the real problem is probably five times more complex.
And re the new ticket to style the edit button: will you create a separate ticket to make the Subscribe link match the design document as well? In other words, make it regular size and bold instead of big and regular weight? Thanks for following up. – Jonesey95 (talk) 05:48, 9 December 2022 (UTC)
Current appearance of the subscribe button
I think the subscribe button is already regular size? It doesn't look big in this screenshot (ignore the green arrows, which are about the previous change). Whatamidoing (WMF) (talk) 17:06, 12 December 2022 (UTC)
Screen shot is here. Note that the edit link is normal size and bracketed, the Subscribe button is much larger and lower than the edit link (and larger than the Reply link), and the Reply link is normal size, slightly superscripted and bold. My normal skin is Vector, I do not use Visual Editor, and I use Firefox 107 on Mac OS. – Jonesey95 (talk) 18:52, 13 December 2022 (UTC)
Thanks, this is very helpful. I filed T325104. It looks like you've changed the default font size in Firefox (default is 16px, yours looks like 14px or 15px), and the font size for the Subscribe button is always the same and not relative to the default size. We did it that way because the button is technically inside the heading, and using a relative size would require tediously adjusting it for every skin's different heading sizes. Good news though, we're in the process of making it not be a part of the heading (for reasons of screen reader accessibility: T314714), which should also make fixing this problem easier. Matma Rextalk21:46, 13 December 2022 (UTC)
Re the extra space before "Reply" when there is a line break before "Reply": Yes, that screen shot captures it. It is particularly obvious when there is a series of indented discussion responses: the "Reply" link looks like it is the first line of the response instead of the last part of the paragraph ending with the signature.
Understood. Thank you for confirming, @Jonesey95. I've filed phab:T325416 for this issue.
To confirm: you expect the Reply button to appear left-aligned with the comment to which it is related, right?
And re the new ticket to style the edit button: will you create a separate ticket to make the Subscribe link match the design document as well? In other words, make it regular size and bold instead of big and regular weight?
It sounds like the ticket @Matma Rex linked to above (phab:T325104) captures the issue you named above. Although, please tell me if that's not the case.
I wasn't planning to do so, as it is not yet a bug, and I'm happy with the existing styling. The design standard document, if it is an actual standard that is intended to be applied, should naturally lead to that task being added to a work plan by the person or team responsible for implementing the design standard. – Jonesey95 (talk) 01:55, 17 December 2022 (UTC)
I like the example in the screenshot. I realized my issue with the example you showed originally was that there was way too much padding between the end of the text and the word "Reply". Adding an icon instead of just padding makes that problem go away. RPI2026F1 (talk) 12:19, 9 December 2022 (UTC)
Oh, wonderful. Thank you for taking another look at the design, @RPI2026F1.
@PPelberg (WMF): Changing the reply link makes sense in the context of the broader talk page redesign, but less as an isolated change which is how I was understanding the original thread. By the way, I do have the Discussion tools beta feature enabled and see the new design on article talk pages like Talk:Apollo 17, but not on this page or others like Wikipedia:Village pump (technical). Is that intentional? the wub"?!"00:25, 11 December 2022 (UTC)
Changing the reply link makes sense in the context of the broader talk page redesign, but less as an isolated change which is how I was understanding the original thread.
Ah, okay! Looking back at the original thread, I'm now realizing that we did not make it clear, as you said, that this change was part of the broader set of design changes...I'm sorry for the confusion about that.
By the way, I do have the Discussion tools beta feature enabled and see the new design on article talk pages like Talk:Apollo 17, but not on this page or others like Wikipedia:Village pump (technical). Is that intentional?
Great question, and yes. For right now, it is intentional that the new design is not appearing on pages outside of the article and user talk namespaces, like Wikipedia:Village pump (technical) as you mentioned.
While we do have plans to eventually make these changes available outside of the two namespaces above (this work will happen in phab:T251653), we're starting with this more narrow scope in an effort to make sure the design changes work well in what we consider to be a more "predictable" environment before expanding them to pages that are likely to have more bespoke/complex discussion-related workflows.
Update on this: @PPelberg (WMF) and I have been talking about pushing this out to all of the talk namespaces (e.g., Wikipedia_talk:, Template_talk:, File_talk:) before considering the non-talk pages where discussions take place (e.g., WP:ANI, WP:VPT, the mainspace at Meta-Wiki...). However, due to the wikitech:deployment freeze that started last Friday, that will probably happen in January. Whatamidoing (WMF) (talk) 18:12, 19 December 2022 (UTC)
Feature request: Option to auto-subscribe to all created sections by you
@RPI2026F1, there's a user script linked in phab:T284795, that would let you manually subscribe/unsubscribe to all existing sections on a page.
An idea for auto-subscribing is described in phab:T263821. The idea here is that you want to be told whether a new discussion was created, and then you personally decide whether to subscribe or not. Whatamidoing (WMF) (talk) 18:21, 19 December 2022 (UTC)
@RPI2026F1 when this idea occurred to you, what editing interface were you using? I ask the above because the New Topic Tool supports automatically being subscribed to the new sections/topics you start. You can enable this functionality by doing the following:
"You can also switch back to the legacy experience."
This part of the "A new way to start topics is here" note doesn't actually permanently stick. It just gives you the old style for that particular edit. Please add a link to instructions on how to permanently opt out of the reply tool, or back into the "legacy experience". CapnZapp (talk) 10:10, 28 December 2022 (UTC)
To clarify: while I know how to uncheck the various check boxes in my Preferences, the above help message isn't truly helpful since it doesn't say a word about these check boxes existence. The current experience can easily misled an editor into believing its only possible to enjoy the "legacy experience" by each time clicking that link, always defaulting to the new reply mode. This is easily fixed by merely inserting a link to some help page on the edit tab of Preferences. CapnZapp (talk) 10:14, 28 December 2022 (UTC)
new Reply Tool incompatible with certain templates
The new Reply Tool invisibly inserts indentation colons to match the indentation of the post you're replying to.
That sounds reasonable, but not enough care has been taken to not break certain templates.
For instance the {{cob}} template breaks if not placed first on its own line. There can't be any colons before it.
Let me show you. Note how you won't be able to read what's AFTER the collapse box, such as my signature. The template breaks, and you'll find it inside the collapsed content. It will appear correctly if you make sure to not add the indentation colons to any line where such a template exists.
I've amended the documentation and provided a rough workaround, but really, these things needs to be intelligently handled by your code. CapnZapp (talk) 10:20, 28 December 2022 (UTC)
This is easy to explain: the underlying code of {{cob}} is
<includeonly>|}</div></includeonly><noinclude>
{{Documentation|Template:Collapse top/doc}}
<!-- PLEASE ADD THIS TEMPLATE'S CATEGORIES AND INTERWIKIS TO THE /doc SUBPAGE, THANKS -->
</noinclude>
which boils down to
|}</div>
- it begins with the two characters |}, documented at H:BTM as the marker to end a table. The BTM page also explicitly states All this markup must start on a new line. At Help:Table#Indenting tables we also find Do not attempt to use colons for indentation anywhere within the rest of the table code (not even at the beginning of a line), as that will prevent the MediaWiki software from correctly reading the code for the table. --Redrose64 🦌 (talk) 22:27, 28 December 2022 (UTC)
@CapnZapp The only feasible way to "handle" arbitrary templates would be to disallow using them entirely, and we did not want to do that (I'm one of the developers). They are disallowed if you're using the visual mode of the reply tool, though. We do not have the resources to review every possible template in every one of 800+ Wikimedia projects and figure out whether and how it can be used in indented discussion comments. We decided to just let each user figure it out on a case-by-case basis.
Basically, our thinking was:
New users will prefer using the visual mode anyway, where templates mostly can't be added
Established users, who are more likely to use the source mode, will use the preview to check whether their templates display as expected
If they notice things don't display as expected, they can always use the full wikitext editor to leave their comment
It is unfortunate that this doesn't work very well with the collapsed templates (since you can only notice the unexpected behavior if you expand it), but I think we have to live with this
We decided to just let each user figure it out on a case-by-case basis. What, with zero documentation or guidance?? That must be one of the clearest example of dismissive and lazy engineer attitude I've seen recently. Hint: if you don't "got the resources", then how about not breaking it and then walking away for others to pick up the pieces of a mess you created. I clearly won't get anything useful out of this discussion, if your attitude is representative of your whole team :-( :-( :-( CapnZapp (talk) 11:01, 29 December 2022 (UTC)
This behavior appears to be a known limitation of the Discussion Tools. Comments exist in the following phabricator tickets: T243047, T247421, T253667, and T241388. The developers have repeatedly stated that multi-line templates and tables do not work with the Reply Tool, just as they do not typically work with manually inserted colons. Block templates and tables often do not work correctly, or generate syntax errors, or both, when they are preceded by colons. That is not the fault of the reply tool. – Jonesey95 (talk) 19:54, 9 January 2023 (UTC)
also hat/hab
To test further, I have to create a whole new section to see if the previous colon breaks the entire talk page.
This time, I'm seeing how Reply Tool would work with Hidden archive top:
This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
Yes...? And? What I mean is, is the team really content adding a new reply tool without in any way shape or form addressing the bugs, or even updating the relevant documentation?? (If you're not on this team, Redrose64: I'm not directing my consternation and bafflement at you) CapnZapp (talk) 11:05, 29 December 2022 (UTC)
No, I'm not on the team. I'm merely somebody who occasionally attempts to explain other people's markup problems, often caused by not reading the template documentation - in this case, the doc has included a warning for the last ten months. As with any other script-assisted edit, use of the reply tool does not absolve you from responsibility: any undesirable effects of saving your edit are primarily your burden to sort out. We have the WP:PREVIEW feature for a good reason. --Redrose64 🦌 (talk) 23:25, 29 December 2022 (UTC)
Sorry Redrose64 but "the doc has included a warning for the last ten months" and "As with any other script-assisted edit, use of the reply tool does not absolve you from responsibility" I call bullshit. The warning does not in any way explain that using ReplyTool will - without asking you - insert colons, thus ruining your template usage. The ReplyTool does not indicate those colons it will insert. And please don't equate using ReplyTool with installing and using scripts. One is foisted upon everyone without you doing anything, the other represents a certain degree of technical confidence, not to mention initiative. The situations are completely dissimilar. Had ReplyTool been something only technical people would install, and only by their own volition, your point would be valid. But it isn't. You're effectively telling new editors its their fault they don't understand how ReplyTool and these templates interact, and I don't think you should do that. The obvious standpoint to take is instead to realize that while you might not be able to introduce new tools to the general public without unintended sideeffects, when and if you find them, fix them instead of just shrugging ("the incompetents can just suffer"). At the very least, you'd expect the team to update the documentation of any problematic template. To take responsibility for their change. It's the addition of ReplyTool that is the cause here. CapnZapp (talk) 19:25, 9 January 2023 (UTC)
when and if you find them, fix them instead of just shrugging Sorry, no can do. As I mentioned earlier, I am not on the dev team, I'm merely a passer-by. --Redrose64 🌹 (talk) 22:00, 9 January 2023 (UTC)
Isn't there a preview tab that you can switch to in the corner? Haven't used the tool in a long time but I remember it being in either the top-right or bottom-right. —Tenryuu 🐲 ( 💬 • 📝 ) 20:01, 21 January 2023 (UTC)
It seems like they've changed it to switch between visual and source editor mode in the top-right corner. Looks like it works fine for me, and pinging with the tool is simple now that pressing @ brings up an immediate list of people in the conversation. —Tenryuu 🐲 ( 💬 • 📝 ) 20:30, 21 January 2023 (UTC)
No, it doesn’t bring up a complete list. I might have been missing the preview in source but if you use source you don’t get any list of people , if you use visual and try to add templates they are messed up with nowikis. Doug Wellertalk21:31, 21 January 2023 (UTC)
@Doug Weller for reply-tool: if you are in "Visual" mode it should be WYSIWYG - thus no preview, if you change to Source mode the preview should appear under the input box. — xaosfluxTalk23:20, 21 January 2023 (UTC)
@Xaosflux Yes, but then I need to switch back and forth if I want to reply to a particular person and then add, say, a CT template and preview. Still, so long as I remember. Doug Wellertalk08:17, 22 January 2023 (UTC)
@Xaosflux I just discovered that if the @ symbol doesn't show the name of the person I want to reply to I can just start typing the name. Wish I'd known that before. I presume it's documented. Doug Wellertalk08:24, 22 January 2023 (UTC)
You can also just add a normal link, since the link tool also searches for page names. The main advantage to the @-mention feature is that it begins by offering the names of people who have previously commented in the same ==Section==. The link (click the links-in-a-chain icon, or ⌘ Command+k, or in the visual mode, start typing the wikitext for an internal link, and you'll get a normal link search box, which will search for any page in any namespace. Whatamidoing (WMF) (talk) 04:01, 24 January 2023 (UTC)
I'm an idiot, of course. But I was confused by the "or, in the visual mode" and thought the chain etc was meant to be in source mode. Thanks. I've learned a lot about the two modes. Now if I can just be careful when trying to be in the right mode to avoid all the nowikis I get in the wrong mode, I've no idea why they are added and how that's a good thing. Thanks. Doug Wellertalk08:42, 24 January 2023 (UTC)
Templates are disabled because if you stick an infobox or a table in the visual mode, it will produce a serious mess. Imagine a comment that means to talk about a template, but what you see is something like
The devs have talked about a new bit of wikitext syntax that could solve this problem. It would also make it possible to have multiple paragraphs in a list (e.g., in the votes at RFA) or to add an image in the middle of a list without having to fiddle with the list formatting. You'd just start normally, e.g., * '''Support''' and when you decided that you were doing something odd, you'd add some sort of new wikitext code (e.g., <<<) around it. It's a bit of work, and of course there'd be the usual confusion ("What's all this stuff in my diff?!"), but I think it would be a good idea. Whatamidoing (WMF) (talk) 00:44, 28 January 2023 (UTC)
Should a user talk page that has been blanked then get the message a brand new editor gets?
A user-talk page that has been blanked exists, easily distinguishing it from a page that was never created and is a redlink. — xaosfluxTalk14:24, 25 January 2023 (UTC)
There are half a dozen messages (see the list), but none of them vary by experience level.
As this wiki doesn't do automated welcome messages, the first message on someone's talk page may happen when they are relatively experienced. I received my first talk page message when I'd made nearly 100 edits, months after I created my account. Just last week, I created the page for someone who's account is ten years old. Whatamidoing (WMF) (talk) 00:57, 28 January 2023 (UTC)
The is the one I've seen after a user has blanked their talk page is "Start a talk page with Newbie1". But I didn't check to see if they'd added it, so we can drop this discussion until and if I see it again, thanks. Doug Wellertalk12:22, 28 January 2023 (UTC)
Everyone with the Beta Feature enabled will see a small change to the top of the page, to add information about the most recent comment. If you're using the new Vector 2022, this will also change the new Table of Contents (to add a count of how many comments are in each section).
I think this is the penultimate update to the Beta Feature before general deployments can begin. They're still working on an extra "Add topic" button, so it won't be necessary to scroll all the way back up to the top to find that button.
Since you asked: This is an edge case, but I have restored numbering to my Vector 2022 TOC (see T307316), and the unindented gray number next to the word "comments" below the numbered blue section links is confusing (to me). I have added CSS to indent the "X comments" text by 8px so that it does not look like a section header in my TOC. Also, T325416 should be fixed before deployment; it's pretty ugly. – Jonesey95 (talk) 01:20, 23 February 2023 (UTC)
Also, I think that you will get negative feedback about the size of the "Latest comment: ..." text (too large) and the inconsistency between the [edit] (section edit) link, the Subscribe link (large, not bold), and the reply link (small, superscripted, bold). You asked us about it in November 2022, and it looks like zero improvements have been made; why would deployment happen now? I do not understand the WMF's apparent obsession with asking for feedback on beta skins and tools, creating bug reports that do not get acted on, deploying the software in an unfinished state, and then taking verbal abuse from editors and giving the appearance of not knowing how to deploy reasonably-debugged software. Couldn't that cycle have a few steps removed from it? Also see T324807; it doesn't look like anything has been fixed in this melange of link styles. It looks junky. (Edited to add: OK, now I feel a little bit bad, because the question is about mobile tools, and I went off on a rant about what I am seeing in my desktop view in Vector 2022. I'm going to leave it in case anything is applicable to mobile, which I find unusable for many reasons.) – Jonesey95 (talk) 05:33, 23 February 2023 (UTC)
Based on that screen shot, it looks like the non-bold "Subscribe" button and the bold "Reply" button have not been made consistent. – Jonesey95 (talk) 18:49, 23 February 2023 (UTC)
@Jonesey95, the "Latest comment" text is smaller than the body text on my screen. The "topic container" text is ~21px tall, and the text in the body of the comment is ~29px tall on my screen. Maybe try it in safemode, or a different web browser? Whatamidoing (WMF) (talk) 20:26, 23 February 2023 (UTC)
Yes, it could be something in the custom CSS that I set up to work around various Vector 2022 display bugs. I can't see the discussion tools features when logged out, since I don't have a way to enable the beta features. In safe mode while logged in, the "Latest comment" text still matches my screen shot above, as do the mismatched edit/subscribe/reply links. Feel free to copy my common.css file. If you can't replicate the problem, you could just follow the normal path and let editors figure it out after deployment. – Jonesey95 (talk) 20:38, 23 February 2023 (UTC)
@Jonesey95 The "Latest comment: ..." text font size issue is filed as T325104 (only occurs if you customized font size in the browser), and I have a patch waiting for review that should fix it. We've been busy with some other things recently, but I'll ask someone to review again.
For T325416 (space before the Reply button when it wraps to a new line), the obvious fix was impossible because it conflicts with the workaround for T260072 (incorrect behavior when using triple-click to select paragraph with reply links in Chrome), and I think that is the worse issue of the two. However, it looks the Chrome bug we were working around has been recently fixed, so we should be able to remove the workaround now. (It's fixed in Chrome 108; Chrome 107 and older are currently used by less than 2% of our editors, most of which on mobile where triple-clicking is probably rare.)
Regarding the various inconsistencies in buttons and links: it's just my personal opinion, and I'm willing to defer to designers here, but I think their current state represent a tenuous compromise between WMF design guidelines (big icons on bold buttons) and Wikimedian "get off my lawn" energy (plain text on plain links). I think you might be the only person ever to ask us to make the buttons bigger and bolder (or perhaps you're just pulling my leg). I'd expect a change like that to be received about as well as the recent skin deployment.
Thanks for the complaints. I appreciate them, and I trust you understand that we're trying to address them, but not everything can always be easily changed. Matma Rextalk22:05, 23 February 2023 (UTC)
Re buttons being bigger and bolder: I just want them to be consistent. If edit, subscribe, and reply were all the same size (body text size), non-bold, and vertically aligned with the elements around them, I think they would look fine. Right now, they are three different sizes and two different boldnesses.
Re text size: Logged out, Brave browser 1.48.158, Mac OS 10.14.6, private window: "Last comment..." is 14px (".ext-discussiontools-visualenhancements-enabled .ext-discussiontools-init-section-bar" overriding "vector-body", I think); vector-body text is 13.125px (inspector shows "calc(1em * 0.875);"); "Subscribe" is 14px. "[edit]" is 13px. "Reply" is 13.125px. My Brave Preferences have the default font and font size set to Lucida Grande 15.
Re complaints: I will keep complaining if it means that developers keep fixing things. I want Wikipedia to be a better web site. I know that easy problems are fixed quickly and that difficult problems have side effects and other challenges, including unreasonable humans like me who want things that don't make sense to other humans. So it goes. – Jonesey95 (talk) 23:20, 23 February 2023 (UTC)
The Editing team is beginning a project to help new editors of Wikipedia. It will help people identify some problems before they click "Publish changes". The first tool will encourage people to add references when they add new content. Please watch that page for more information. You can join a conference call on 3 March 2023 to learn more.
Re. The Editing team is nearly finished with this first phase of the Talk pages project. . . . beginning a project to help new editors of Wikipedia. Does that mean Reply Tool enhancements like adjust-indent and add-bullet are off the table for the foreseeable future? ⁓ Pelagic ( messages ) 18:13, 28 February 2023 (UTC)
New TP appearance and floating TOC (bug?)
I noticed on this page: in Vector 2022, when I have "Show discussion activity" enabled, the first section (currently "Wiki Education Foundation…") stays highlighted (bold black) when I scroll down the page to other sections. Tapping a ToC entry navigated to a section and caused the ToC item to change appearance, but the styling jumped back onto the first item when I started scrolling. When I disabled the preference, ToC returned to exhibiting the expected behaviour. Apologies for only posting here and not filing a Phab ticket. ⁓ Pelagic ( messages ) 18:43, 28 February 2023 (UTC)
There's a known issue where this occurs after posting a reply or new topic, until you refresh the page, filed as T316037. I hope that this is what happened (since you replied on this page just recently), and that it isn't some new issue; it'd be helpful if you could confirm that you don't see the problem if you re-enable that preference now and just view a page like this one. The Vector team recently worked on a fix for this, which should be included in this week's regular Thursday deployment! Matma Rextalk22:44, 28 February 2023 (UTC)
Just now I added a topic using the button in the Vector 2022 floating/sticky header without having to scroll to top. Love the convenience of that! I only wish iOS would handle sticky elements reliably. ⁓ Pelagic ( messages ) 20:04, 28 February 2023 (UTC)
It's wonderful to hear you're finding value in the Add Topic being easier to "reach for" – thank you for stopping by to say as much, @Pelagic ^ _ ^
And for anyone who might be wondering, "What is this "Add topic" they are talking about?" it's this (available when you have the Vector (2022) skin enabled): A screenshot showing the Add Topic button that is available within the Vector (2022) skin's sticky headerPPelberg (WMF) (talk) 22:46, 1 March 2023 (UTC)
with a tooltip would work just as well in far less space.
] seems like the intuitive way to design that. {{u|Sdkb}} talk 19:53, 26 July 2022 (UTC)
in the Reply tool box. If you're using a Windows computer the command you're looking for is Ctrl+K. —Tenryuu 🐲 ( 💬 • 📝 ) 08:30, 24 January 2023 (UTC)
Resolved
