Talk:Talk pages project/Usability

Feedback: Hgzh
Tested on a desktop device. Doing the tasks itself was easy. Unexpected were the design changes and to be honest I don't like them. I see no point in styling the headings differently than in other pages, especially when in preview mode it's still the old styles. The margins between the comments are too big, in combination with the line height in a reply with more than one visible line it's difficult to see what is a new comment and which line exists because of wrapping one comment. the reply link with icon and bold type is too prominent in my opinion. Imagine having a colourful or image signature, there will be too much distraction from the comment by 'services'. I like the indicator of the latest comment on page below the page title, but the by-section information of number of comments and people in discussion is of little use in my opinion. What am I going to do with this information? It could be somewhat additional, but in current view it's too prominent. The by-section indicator of last comment date is more useful, but I also don't need this as the first thing I want to know when I look at a discussion. Maybe move it to the right, make it small and remove the icon, that would be enough for me. Regards, hgzh 06:36, 20 May 2022 (UTC)


 * hi @Hgzh – thank you for taking the time to try out the prototype and articulate what thoughts they brought to mind for you.
 * A couple of questions in response below...
 * 1. ...the design changes and to be honest I don't like them.
 * Are you able to say a bit more here? E.g. can you imagine the design changes preventing you from being able to do something as effortlessly as you're used to doing?
 * For context: you will be able to opt-out of these design changes.
 * 2. I see no point in styling the headings differently than in other pages...
 * For context: the decision to style talk page headings differently than headings that appear in content namespaces is a response to newcomers mistaking talk page sections as corresponding/relating to the sections in the articles to which the talk page is adjoined. ''More context here: New user tests.
 * 3. Imagine having a colourful or image signature, there will be too much distraction from the comment by 'services'...
 * Would it be accurate for me to understand the above as you expressing concern that the way the "Reply" buttons are currently designed leads you to worry that they will visually overwhelm/distract people from the comment to which they are adjoined?
 * 4. ...the by-section information of number of comments and people in discussion is of little use in my opinion. What am I going to do with this information?
 * I appreciate you were likely asking this question rhetorically. Although, in case you are curious in the rationale...
 * This metadata is intended to do two things:
 * A) Make it easier for people who are new to intuitively recognize talk pages as being filled with discussions as opposed to being filled with sections of an article
 * B) Make it easier for people who are experienced to more quickly get a sense for the "size" and "shape" of the discussion.
 * Related to "B)" @Klein Muçi surfaced the idea of making it possible for people to use the "number of people" information to reveal the people who have published a comment in a particular discussion (T309752.
 * If you can imagine yourself using that information, I'd value knowing how...
 * 5. It could be somewhat additional, but in current view it's too prominent...
 * We hear you and agree that some additional work is needed to make the information that appears beneath each section title to be less distracting / easier to parse. This work will happen in T309666
 * 6. The by-section indicator of last comment date is more useful, but I also don't need this as the first thing I want to know when I look at a discussion
 * It's helpful to know you see some value in seeing the date the last comment was posted within each section.
 * We're considering an idea about enabling people to click on the last comment date and be shown the last comment the indicator is referring to...can you imagine that being of use to you? ''More context in T309751. PPelberg (WMF) (talk) 23:44, 2 June 2022 (UTC)
 * Hi @PPelberg (WMF), thank you for your reply. I'll try to make things a bit more clear:
 * ad 1: I don't like them was a hint in which direction my feedback generally would point. My main concern was the following: The margins between the comments are too big, in combination with the line height in a reply with more than one visible line it's difficult to see what is a new comment and which line exists because of wrapping one comment. That is the point that would make reading talk pages harder for me. I hope you understand what I mean with that, expressing things in english on point is still sometimes hard for me.
 * ad 2: Thanks for giving the context, I understand the rationale and the different styling isn't something I'm hardly opposed to. However, it still looks a bit unformed to me, but that's maybe a thing of habituation. Preview (source editing) should use the same styling then for consistency.
 * ad 3: yes, that's my concern. I like the simple reply link in current styling; icon, bold text and different color are a bit too much for me. I understand that you want to make reply link more visible and that currently it's maybe not prominent enough for everyone, but it (and also signatures) shouldn't take the attention from the actual thing that matters, the comment itself.
 * ad 4: I see, thanks. I still think the use of the information itself is little in comparison to the prominency of the visual presentation, also for me as an experienced editor (size and shape is in my opinion already visualized by the amount and structure of text), even though I can see some small use cases so if it's styled a little less highlighted it would be okay for me. I like the additional idea Klein Muçi brought up and that would make this block more useful.
 * ad 5: Thanks for rethink styling.
 * ad 6: Jumping to the last comment would be helpful.
 * Another question came up while writing this reply: how do you identify a page as a talk/discussion page? There are also some pages in project namespace that contain discussions and on the other hand talk namespace pages that should not contain reply links anymore (archives). I guess there should be a switch like __DISCUSSION__/__NODISCUSSION__/__NOREPLYLINK__ and a page property. Regards, hgzh 06:10, 3 June 2022 (UTC)
 * After having used the new appearance for some weeks, I want to revise my opinion about it. It's actually quite useful having the topic containers and together with the headline style they help recognising a new section on a long page. So thank you on working on this. Regards, hgzh 16:07, 11 October 2022 (UTC)
 * Thanks for giving it a try, and double thanks for coming back here to share the updated information. Whatamidoing (WMF) (talk) 18:24, 11 October 2022 (UTC)
 * @Hgzh! I'm sorry it's taken me this long to get back to the additional context you shared in June. See responses form me below.
 * Although before that +1 to what @Whatamidoing (WMF) expressed above: I'm grateful that you invested the time and effort to experiment with these new features and to come back here to share the experiences you had with them 🙏🏼😊
 * Now, a couple of responses to the additional feedback you shared in June...
 * ad 2: Preview (source editing) should use the same styling then for consistency.
 * Are you still experiencing this issue? For context: this issue should have been resolved in mid-August by way of T309423.
 * ad 3:...but it (and also signatures) shouldn't take the attention from the actual thing that matters, the comment itself.
 * Well put and we agree with you in thinking that people being able to notice the Reply button should not come at the expense of overwhelming the content of peoples' comments themselves.
 * In the coming weeks, we plan to make the new Reply button styling available as a beta feature at more wikis via T320683. I think this next deployment will help us get a sense for whether the issue you described is occurring.
 * ad 6: Jumping to the last comment would be helpful.
 * Are you wanting to be able to "jump to the last comment" within a given section? The last comment posted on the entire page? Something else? ''I ask this, because we are planning to introduce the two "last comment" features I described. In fact, you should be able to try them both on this page by clicking the links that appear after the various "Latest comment:" text snippets that appear throughout this page.
 * Another question came up while writing this reply: how do you identify a page as a talk/discussion page?
 * For right now, the visual changes we are introducing will be limited to pages within the  and   namespaces. PPelberg (WMF) (talk) 00:07, 13 October 2022 (UTC)
 * Hi PPelberg (WMF), thanks for your additional reply. Preview styling is fine now. The styling of the reply link like it is on this page is okay for me, although I liked the [ reply ] version a bit more. I saw the jump links and I like them, thanks. To the last point: I still think it would be useful to have this styling on all pages where discussions take place, so all talk namespaces and some specific pages in project namespace (village pump etc.) Regards, hgzh 18:44, 10 November 2022 (UTC)
 * Preview styling is fine now.
 * Excellent. Thank you for letting me know, @Hgzh.
 * The styling of the reply link like it is on this page is okay for me, although I liked the [ reply ] version a bit more.
 * Understood and I appreciate you letting us know. If the styling of the new Reply button proves to be disruptive, I'd value knowing.
 * I saw the jump links and I like them, thanks.
 * Wonderful!
 * To the last point: I still think it would be useful to have this styling on all pages where discussions take place, so all talk namespaces and some specific pages in project namespace (village pump etc.)
 * Understood and it's helpful to know this. I've added what you shared here to the ticket where we are tracking work on making this styling available on all discussion pages. See T304750#8387884. PPelberg (WMF) (talk) 19:52, 10 November 2022 (UTC)
 * Understood and it's helpful to know this. I've added what you shared here to the ticket where we are tracking work on making this styling available on all discussion pages. See T304750#8387884. PPelberg (WMF) (talk) 19:52, 10 November 2022 (UTC)

Feedback: Izno
(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. -> Archive pages probably don't need this. Izno (talk) 21:02, 15 June 2022 (UTC)
 * 1) Laptop, though I went and looked at the mobile version.
 * 2) What did you find unexpected about the prototype? N/A
 * 3) Which steps in the "Try the Prototype" section did you find difficult to complete? None.
 * 4) What do you like about the prototype? N/A
 * 5) What do you wish was different about the prototype?
 * 6) I strongly dislike the differentiation in talk. I get what you're going for, but I think the bolding doesn't achieve its mission and I think the addition of the space is going to confuse users into thinking there's actual space in the page title (when there's not). Even if that space is there due to CSS, and even if we have the luxury that a link like Talk: This will still link to the same place as Talk:This (the latter of which I don't think should be relied on, and I would be sad regardless if I saw links with that space there). In general, talk pages are still wiki pages (I saw Flow mentioned earlier) and their titles should be treated consistently accordingly. Getting people to get to and use talk pages is the key part, and I don't think this change enables that at all, and just introduces an inconsistency otherwise.
 * 7) Eh to the "discussion summary" points in grey. They don't seem generally like a good use of space. Maybe if they were floating to the right on desktop (but then they won't be seen, IDK). I do like seeing when the last activity was, but I have this suspicion that there are better ways to provide a discussion summary. Maybe even including some of this in the table of contents as displayed content? I agree with above that for my primary areas at least, it matters more to have an idea on whether someone experienced has commented in the discussion, and how if so (I want to make sure that other users, when I have an answer, are getting the help or feedback they need to contribute positively).
 * 8) Not really a fan of flipping the borders on the H2s. Same general 'these are the same as any wiki page, even if you're probably using DT to interact with them'.
 * 9) Not really a fan of the big arrows though I get the rationale for them. It's just visual clutter for an experienced user. If this were a forum board, there'd be a row of actions a user could take to interact with a post (quote, reply, permalink, etc.). Maybe something that direction as a hover for reply or each comment might be an interesting direction.


 * About the  formatting:  Do your objections to the space disappear if it applied to all namespaces?  That would make the titles consistent.
 * As an update, the font (serif/sans) change won't happen, and I think I remember hearing that the bold will also be removed. The curly arrows on the [reply] button are also being removed.  I think the designer decided that they were a bit 'heavy'. Whatamidoing (WMF) (talk) 23:45, 29 June 2022 (UTC)
 * At least one objection remains regardless, that of Talk: X and Talk:X. That said, I don't think it's a win regardless in the 'don't change what definitely is not broken' vein. Izno (talk) 22:36, 23 August 2022 (UTC)
 * @Izno, hi! Thank you for spending the time to review the prototype and share the experience you had with it here. Some follow up comments and questions in response below. Although, please do not worry if some of these questions are difficult for you to recall answers to considering the amount of time that's passed between when you tried the prototype and now.
 * ...I think the bolding doesn't achieve its mission...
 * Point taken. As @Whatamidoing (WMF) mentioned above, the changes to the talk titles will be limited to adding a space between the namespace and page title. This work is happening in T313636.
 * I think the addition of the space is going to confuse users into thinking there's actual space in the page title (when there's not)
 * I appreciate you naming the potential for confusion here.
 * Question: Can you please say a bit more about what you could see resulting from people who are new thinking there is a space between the namespace and page title? Is there a particular workflow that would break because of this? I ask these questions thinking you are imagining scenarios we might not have considered.
 * In general, talk pages are still wiki pages (I saw Flow mentioned earlier) and their titles should be treated consistently accordingly...
 * If it would be accurate for me to understand the concern "underneath" what you're expressing above as something like, "It's important that people continue to understand talk pages as wiki pages with edit histories they can inspect, source "code" they view, change, and copy without constraint, etc." then I think we are aligned in thinking that this new designs needs to NOT degrade peoples' understanding of talk pages as wiki pages.
 * Question: can you think of signals that might help us detect whether the kind of "misunderstanding" we both seem to be concerned with is happening?
 * One quick idea that comes to mind: an uptick in newcomers asking questions at the wp:Teahouse about how to do/find things they are used to being able to do on article pages on talk pages.
 * I do like seeing when the last activity was, but I have this suspicion that there are better ways to provide a discussion summary. Maybe even including some of this in the table of contents as displayed content?
 * It seems like our minds are landing in the same place on this one. If you look at the Vector (2022) version of the prototype, you'll notice a new table of contents that includes the number of comments in each discussion section.
 * Question: ...is the kind of "displayed content" you had in mind?
 * I agree with above that for my primary areas at least, it matters more to have an idea on whether someone experienced has commented in the discussion...
 * Question: Would it be accurate for me to interpret the above as you valuing the functionality T309752 would implement?
 * Not really a fan of the big arrows though I get the rationale for them.
 * +1. We decided to remove these arrows for the reason you mentioned. This change happened in T309904.
 * ...a row of actions a user could take to interact with a post (quote, reply, permalink, etc.).
 * We hear you on this one. I can imagine a future like what you're describing wherein each comment has multiple actions associated with it and we might need to revisit the design to accommodate them.
 * Speaking of permalinks for comments, this is functionality we would like to be able to offer in the near-term via: T302011.
 * Archive pages probably don't need this.
 * Noted. For the time being, these changes will be limited to talk pages in the User and article/main namespaces. PPelberg (WMF) (talk) 00:55, 5 August 2022 (UTC)
 * Is there a particular workflow that would break because of this Come to think of it, yes, you're going to make some template programmer's life more difficult if someone thinks a space there when there's not. See  and related parser functions, and   isn't sufficient to work around that issue. That's ignoring my aesthetic "no, I do not want a space there, it's just going to confuse everyone into thinking there's a space there".
 * can you think of signals that might help us detect whether the kind of "misunderstanding" we both seem to be concerned with is happening? None with any reliability off the cuff. Probably "people with DT enabled but who make an edit without it" is a good starting spot for thinking about non-talk uses (and of course other uses such as replying to multiple comments).
 * is the kind of "displayed content" you had in mind? yes
 * Would it be accurate for me to interpret the above as you valuing the functionality phab: T309752 would implement? This direction would be the groundwork, but I'm suggesting something more: the users with social trust being highlighted in the discussion. If Redrose64 and SlimVirgin and someone with 10 edits are all in a discussion, I can probably rest easy that the 10-edit editor has gotten a quality answer. We get into multiple social issues that direction of course (both the general "edits don't make the editor" and "we don't want to give unfair voice to some users"). I'm not sure how interesting it is to go that direction accordingly. If we could highlight some users like Microsoft MVPs or our Teahouse hosts better, that might be interesting (a few forums, like en:WP:Bot requests with User:EnterpriseyBot/BOTREQ status at least as of this revision and earlier, do that, while most don't).
 * I did forget one issue in my original comments, and it's that the h2s are too opinionated/aggressive/in the "wrong" place for ResourceLoader in their primary styling, being sans-serif, bold, and larger (or at least they seem larger). Timeless has serif headings and that's getting blown away by DiscussionTools. Izno (talk) 22:52, 23 August 2022 (UTC)
 * Can you help me out with the urlencode point, preferably in very simple words? You seem to be worried that someone who has enough familiarity with the wikis and enough technical skills to know that parser functions exist and when/how to use them will type   by hand instead of , even though the name of the magic word indicates that you should be looking at the URL rather than the page title, and even though copying and pasting would have avoided this problem.  As a result, they'll get   instead of.
 * And this matters because ...I don't actually know why this matters in practice, but I'm pretty sure you wouldn't be concerned about it if it didn't matter.
 * Do you have the same concerns about DISPLAYTITLE, which is also used to add spaces and formatting? Whatamidoing (WMF) (talk) 20:26, 25 August 2022 (UTC)
 * I am no fan of DISPLAYTITLE. :) It is, thankfully, basically restricted to italics in the mainspace and elsewhere, mostly just users with "I WaNt A pReTtY uSeR pAge" syndrome.
 * No one is going to type that except template programmers, which is why I said that's whose life would be made more difficult. What the template programmer is going to type is  and then the innocent user is going to type Talk: ABC and then pandemonium. IDK if that is functionally equivalent today to just Talk: A space working though. Izno (talk) 01:37, 26 August 2022 (UTC)
 * There wouldn't be pandemonium, a space (or underscore) in this position is already accepted and ignored by the software, e.g. https://www.mediawiki.org/?title= Matma Rex (talk) 16:58, 26 August 2022 (UTC)
 * (I lost interest in DISPLAYTITLE when I discovered ~2014 that it wouldn't let me 'rename' James F's user page. 😜) Whatamidoing (WMF) (talk) 00:53, 27 August 2022 (UTC)
 * One reason I wouldn't want the space displayed is confusion with mainspace pages, which routinely have a Title: Subtitle name structure with an actual space in it.(cf. Gadget as a particular fun point). The close colon makes it obvious that it's not a normal mainspace page. Izno (talk) 23:22, 28 August 2022 (UTC)

Feedback: Greg at Higher Math Help
It seems like a good idea to improve the visibility of the "Add topic" functionality. I actually found this page because I was looking for a way to make it more visible for new users. Thanks for working on this!

Here's my use case. I want to invite educators to discuss a course plan that I've started on Wikiversity. They have a lot of expertise to share, but many of them have probably never edited a wiki. Asking them to interpret the navigation tabs ("Resource," "Discuss," "Read," "Edit source," "Add topic," etc.) seems like too much to ask; many may not even notice that the navigation tabs are there.

Also, in the legacy skin, which is the default on the talk page I'm working with, the functionality of the "Add topic" tab is inconsistent with that of the other tabs. All the other tabs open an entirely new page rather than a new section, which may create confusion (maybe "Add topic" will be interpreted as adding a new page).

A button closer to where the new section will be added seems more intuitive. That's my initial impression, at least. Including a button at the bottom of the other sections, as in the legacy mockup you shared, might be ideal, although there's one possible problem that I noticed: positioning it directly below a comment might cause some confusion between "Add topic" and "Reply." Maybe there could be some kind of separator?

For now, I've created a working "Add topic" button at the top of the talk page I'm working on. It's a temporary fix, but I think it solves my immediate issue. Now I can direct new users to "Click the 'Add topic' button to start a new conversation," and that's really all they need to know, since the DiscussionTools interface takes care of the rest.

As others have mentioned, having an "Add topic" button at both the top and bottom of the page could be helpful (or even a sticky button), but the possible confusion between "Add topic" and "Reply" at the bottom may need to be sorted out.

Thanks again! -- Greg at Higher Math Help (talk) 21:07, 6 December 2022 (UTC)


 * @Greg at Higher Math Help, on some pages, volunteers have put some text around a top-of-page button, to explain its use even further ("To start a new discussion thread on this page, click on this button:"). You could consider that as an option. Whatamidoing (WMF) (talk) 04:14, 10 January 2023 (UTC)
 * Done! Thanks for the suggestion. Greg at Higher Math Help (talk) 00:56, 16 January 2023 (UTC)

Incomprehensible recent addition
Please review what you added in this edit to the linked section. I simply don’t understand what you wanted to say – half-finished sentences, suddenly first-person singular instead of first-person plural (is it a quote? from where/whom?)… —Tacsipacsi (talk) 11:37, 11 December 2022 (UTC)


 * Good spot; thank you for saying something. Hopefully this edit clarifies things. Tho, please let me know if that's not the case. PPelberg (WMF) (talk) 22:12, 13 December 2022 (UTC)

Old [reply] button
You wrote that the old, bracketed [reply] button will be removed everywhere. Does this mean that it will be unavailable, or just that it will be non-default but kept for people opting out of the usability improvements? —Tacsipacsi (talk) 01:54, 13 December 2022 (UTC)


 * You wrote that the old, bracketed [reply] button will be removed everywhere. Does this mean that it will be unavailable, or just that it will be non-default but kept for people opting out of the usability improvements?
 * The latter thing you described – "it will be non-default but kept for people opting out of the usability improvements" – is accurate. Do you think this edit makes this clear, @Tacsipacsi? Also: good spot; thank you for saying something. PPelberg (WMF) (talk) 22:09, 13 December 2022 (UTC)

Feedback: Proposed Revisions to "Add topic" button
There is a prototype ready that we would value feedback on: https://patchdemo.wmflabs.org/wikis/e22ef06cf7/wiki/Talk:DiscussionTools

The prototype introduces two changes for people using the  skin:


 * 1) The "Add topic" button appears in a more prominent location on the page (above the existing page toolbar that contains actions links like "Page," "Discussion," "Read," "Edit," "Edit source," etc.)
 * 2) The "Add topic" button is styled differently

Feedback prompts PPelberg (WMF) (talk) 00:10, 15 February 2023 (UTC)
 * What – if anything – concerns you about this proposed change?
 * What – if any – ambiguity might we be able to address that would make it easier for you to evaluate this change?

Proposal: Add a config to configure this extension on any page
According to this discussion, I think a configuration should be added to the tool. This is because Wikimedia forums are held in the project namespace, and forums are therefore deprived of these benefits. খাত্তাব হাসান (talk) 09:47, 11 July 2023 (UTC)


 * It’s actually already implemented: usability improvements work on all non-talk pages that have . However, according to T331635, this mode is currently only enabled on Hungarian and German Wikipedias. I think if you request enabling it as described at Requesting wiki configuration changes, the developers will be happy to fulfill your request. —Tacsipacsi (talk) 19:14, 11 July 2023 (UTC)
 * @Tacsipacsi Thanks a lot! খাত্তাব হাসান (talk) 19:39, 11 July 2023 (UTC)

Proposal: fix talk page archiving so links don't break when a topic is moved
I'm not sure if this is being addressed in the scope of work, but with the enhancements I hope addressing how talk pages handle the lifecycle is being taken into account. Currently archiving is bot or manually curated, but in the process the sections move and old url links break. Talk pages should be designed to be an archive from the start with a URL structure that allows for a permalink ie no url change for links to a topic. Which means probably moving away from just anchor links to an ID structure that would handle each topic individually https://www.mediawiki.org/wiki/Talk:Talk_pages_project/Usability#Moving_page_to_Talk_pages_project/Legibility to possibly https://www.mediawiki.org/wiki/Talk:Talk_pages_project/Usability/T2#Moving_page_to_Talk_pages_project/Legibility which inserts an incremental ID and the associated topic to any moved topic to a new page would maintain its direct link or something that would allow reconstructing links to anchor linked topics that are moved due to page size. Wolfgang8741 (talk) 12:37, 10 August 2023 (UTC)


 * We have been actually working on this!, although we looked at the problem from a different angle.
 * We felt that changing the discussion system as you describe would likely not be accepted by the entire community, and could result in a big failure like the deployment of Flow back in the day. (Although it is possible to do even today, if you convince people who would use those discussions that it's a good idea – as an example, Portuguese Wikipedia's village pump page is set up that way, where each topic is on a separate page like this one: .)
 * Instead, we're trying to track the topics as they're moved to the archive, and we introduced a special page that functions as a permanent link to a topic (or a single comment). For example, Special:GoToComment/c-Wolfgang8741-20230810123700-Proposal:_fix_talk_page_archiving_so_links_don't_break_when_a_topic_is_moved is a permanent link to this thread. Right now it links back to this page, but when it gets archived, it will redirect to the archive. As another example, Special:GoToComment/c-Whatamidoing_(WMF)-2021-02-05T20:13:00.000Z-Test_page is a link to the first thread on this page – I had just set up archiving here, so it should get archived today and then you'll find that the link goes to the archive.
 * We're still in the process of deploying this feature to all wikis (you can follow the progress at T315510), and deciding how to make it accessible in the interface (at this moment, it's just a "secret" special page). Matma Rex (talk) 19:47, 10 August 2023 (UTC)
 * For some high-traffic pages, I have wished occasionally for something less extreme than the single discussion/separate page approach used at ptwiki, like w:en:Wikipedia:Administrators' noticeboard/Incidents to be split at least by year. That page presently has more than 1.3 million revisions, and gets ~60K edits per year. Whatamidoing (WMF) (talk) 17:19, 28 August 2023 (UTC)