Talk:Talk pages project/Usability/Archive 2

Big white space at the top of the page

Tracked in Phabricator
Task T315581

I added an archive box to this page to demonstrate the issue (by the way, this page is quite long, so it may make sense to actually fill it 😉). Three factors combined cause the big white space at the top of the page:

• Floating archive boxes. They are quite common in user and other non-article talk namespaces.
• New Vector’s new TOC. Traditional tables of contents at least partially fill the white space (unless they’re also floated, which usually happens only on a few very busy community pages), but the new TOC is moved out of there, leaving nothing behind.
• clear:both on topic containers, which prevents the first topic to fill the white space.

An even more extreme example (would be, if topic containers were already enabled in project namespace) hu:Wikipédia:Kocsmafal (jogi), where the only topic is much shorter than the floating boxes. Imagine how would it look like if there was no TOC and the topic started below these boxes… —Tacsipacsi (talk) 14:18, 21 July 2022 (UTC)

Great spot, @Tacsipacsi and I'm sorry for the lag in responding here.

I think I've captured this issue you are identifying here within T315581. Although, if you think there is anything missing or inaccurate about the task description, please let me know or adjust it yourself :) PPelberg (WMF) (talk) 16:15, 18 August 2022 (UTC)

The Editing team talked about the clear:both question this week. I think we'll see some improvements there soon. Please let us know if the new "fixes" turn out to be new "problems" instead. Whatamidoing (WMF) (talk) 20:31, 25 August 2022 (UTC)

Localising Topic Containers

I would like to localise the Topic Containers. When I use 'uselang=qqx', I cannot see the message name for the 'days ago' / 'months ago' phrase. From where does that come and how can it be translated? The Discoverer (talk) 07:02, 9 August 2022 (UTC)

@The Discoverer: They come from MediaWiki core. I don’t know the message names, but you should find them in the list of all core messages on Translatewiki. —Tacsipacsi (talk) 20:03, 9 August 2022 (UTC)

Thanks for the info. The Discoverer (talk) 10:42, 10 August 2022 (UTC)

The messages used on Wikimedia wikis are actually not those defined in MediaWiki core – they are provided by the CLDR extension using data from the Common Locale Data Repository. I've never done it myself, but I found some instructions for contributing as Wikimedians at https://translatewiki.net/wiki/CLDR. Matma Rex (talk) 02:38, 19 August 2022 (UTC)

Thanks @Matma Rex. This makes sense, because even after translating the relevant messages of Core, the ago phrase is still not localised. The Discoverer (talk) 08:09, 21 August 2022 (UTC)

The Discoverer, the "official" list for DiscussionTools is at https://translatewiki.net/wiki/Special:Translate?action=translate&group=ext-discussiontools-user&language=hi&filter=%21translated

Some messages appear at TranslateWiki before they appear on wiki. Messages in the prototype/test systems may not be in TranslateWiki yet. Whatamidoing (WMF) (talk) 20:36, 25 August 2022 (UTC)

the hr tag with clear:both causes big vertical boxes to make a big blank space

Tracked in Phabricator
Task T315581

See my talk page at esW. That's all. Ignacio Rodríguez (talk) 15:07, 18 August 2022 (UTC)

hi @Ignacio Rodríguez – thank you for stopping by to report this issue. We're going to work on fixing this in T315581.

Note: if you see anything missing from or inaccurate in T315581, please let me know so that I can fix it. PPelberg (WMF) (talk) 16:13, 18 August 2022 (UTC)

Oh! And if other thoughts/ideas/concerns strike you as you are using the new heading design, I'd value knowing :) PPelberg (WMF) (talk) 16:14, 18 August 2022 (UTC)

Ignacio Rodríguez, the Editing team talked about this problem this week, and I think we'll see some improvements. Please post again if the "improvements" turn out to cause a new problem. Whatamidoing (WMF) (talk) 20:40, 25 August 2022 (UTC)

@Whatamidoing (WMF), thanks. I'll keep an eye on this Ignacio Rodríguez (talk) 00:02, 26 August 2022 (UTC)

Feedback: Awesome Aasim

I like the second design a bit, but I also like the idea of having two buttons for the same function, one at the top and one at the bottom. I think the "new topic" button could also be sticky in the corner to allow for quicker creation of new sections from anywhere on the page without having to scroll. I don't see any prospective issues with these designs as they seem intuitive for message boards. I would probably also like to see if the page could be formatted like a discussion board (i.e. the current Flow on MW and the new Discord forum channels) as it makes it obvious that the talk page is for discussion. I find it most frustrating when new users do not properly format their comments and the bot has to fix them. I feel like there might not be enough cues on a talk page to indicate that the page is for discussion. I'd still have a "switch to wiki page" to allow experienced users see the old talk page design :D Aasim 00:35, 23 August 2022 (UTC)

Thank you for taking the time to review the designs, @Awesome Aasim :) Some comments and questions in response below...

1) ...I also like the idea of having two buttons for the same function, one at the top and one at the bottom.

Question: Would it be accurate for me to think that you like the idea of the two buttons because, as you went on to say, two buttons would, ...allow for quicker creation of new sections from anywhere on the page without having to scroll.?

2) I would probably also like to see if the page could be formatted like a discussion board (i.e. the current Flow on MW and the new Discord forum channels) as it makes it obvious that the talk page is for discussion.

+1 to the importance of making it obvious to people, particularly to those who are new, that talk pages are meant for discussion.

In fact, a key goal of the Usability Improvements we are making is to do just what you described.

Question: With the above in mind, what do you think of the talk page we're talking on now? Do you find that its design effective in demonstrating to people that this page, and others like it, are meant for communicating with other volunteers? PPelberg (WMF) (talk) 23:16, 25 August 2022 (UTC)

I think this is an improvement, but I think there should be a few customization options in terms of the layout. Having the talk page collapsed and allowing the threads to be sorted by date updated will allow for easy navigation through discussions. Aasim 23:49, 25 August 2022 (UTC)

Feedback: Ad Huikeshoven

Thanks for the ping. First of all, here on mediawiki there is already an 'add topic' button on top of the page. Nonetheless, I have looked at the designs. I discovered there is a new Vector skin, and the current default skin is now called Vector 2010. I compared the designs with the current situation. For the new skin I had to adjust my eyes to see the familiar buttons below the title instead of above. After that I disovered that in the design the add topic button is in the place where the language selector drop down button is now, and wonder where that one has moved.

For the old skin, an add topic button at the bottom looks good. I do agree with Awesome Aasim that it would be okay to have them both. Ad Huikeshoven (talk) 14:20, 23 August 2022 (UTC)

The "Add topic" button on this site is in Vector 2022's "sticky header". It's not visible until you scroll away from the top of the page.

If you'd like to compare it, you can see this talk page in Vector 2010. (No new buttons have been added to the old skin [yet?].) Whatamidoing (WMF) (talk) 20:47, 25 August 2022 (UTC)

Thanks for the ping.

You bet – thank you for promptly having a look at the designs and sharing what you think of them, @Ad Huikeshoven :)

First of all, here on mediawiki there is already an 'add topic' button on top of the page.

If it would be accurate for me to think that you are referring to the "Add topic" button that appears in the "sticky header" that stays present as you scroll this page, then great spot.

I should note that the designs I shared above are for cases when that "sticky header" is not available, as @Whatamidoing (WMF) mentioned above.

...I disovered that in the design the add topic button is in the place where the language selector drop down button is now, and wonder where that one has moved.

In the Vector (2022) skin on pages where this new "Add topic" button would appear above the "Read," "Edit," and "View history" links, the language selector drop down button would appear next to this new button. You can see a screenshot of what we have in mind here:

PPelberg (WMF) (talk) 23:37, 25 August 2022 (UTC)

Feedback: Izno

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?
   1. 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.
   2. 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).
   3. 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'.
   4. 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.

(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)

About the Talk: Name 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 phab: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 phab: 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 phab: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: phab: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)

1. 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 {{#urlencode:}} and related parser functions, and {{FULLPAGENAME}} 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".
2. 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).
3. is the kind of "displayed content" you had in mind? yes
4. 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 {{urlencode:Talk: Example}} by hand instead of {{urlencode:Talk:Example}}, 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 Talk%3A+Example instead of Talk%3AExample.

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 {{urlencode:{{{1|Example}}}}} and then the innocent user is going to type |1=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=Talk%3A+Talk+pages+project%2FUsability 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: 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)

Tracked in Phabricator
Task T309666

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 phab: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 phab: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 phab: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 phab: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 User talk: and Article talk: 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)

Incomprehensible recent addition

@PPelberg (WMF): 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

@Whatamidoing (WMF): 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: 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)

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 __NEWSECTIONLINK__. However, according to phab:T331635, this mode is currently only enabled on Hungarian and German Wikipedias. I think if you request enabling it as described at m: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: [1].)

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)