Talk:Talk pages project/Usability/Prototype

T282269: Make it easier to identify and understand the relationships between the threads and comments

Feedback: Jay

1. Laptop
2. Nothing
3. None
4. The "Latest comment" feature
5. Wish was different:
   • The bolded Reply at the end of each post is distracting. Unbold, and preferably italicize like Reply
   • I would like vertical lines indicating threads like this

I believe that the designer once considered light gray vertical lines, similar to what you linked. I don't remember what the decision was (e.g., save the idea for the future, technical problems, etc.).

@Jay: thank you for taking the time to try out the prototype and come here to share what you think about it.

A couple of comments in response...

The bolded Reply at the end of each post is distracting. Unbold, and preferably italicize like Reply

I hear you on this one. I wonder how – if at all – your perception of the Reply buttons will evolve should you decide to keep this new design enabled on talk pages once it becomes available.

What Wikipedia do you spend the most time on? I'm asking this so that I can set a reminder to check in with you once this new design becomes available there.

I would like vertical lines indicating threads like this

@Whatamidoing (WMF): great memory. And @Jay the idea you raised in the bit I've quoted above is one we've been thinking about in T282269. Although, it is not likely that we'll have the opportunity to prioritize work on designing and implementing this kind of functionality during this phase of the Talk pages project.

Thanks for responding. I spend more time on the English wikipedia.

You bet and understood.

I've written myself a reminder to follow up with you once the new Reply link/button design becomes available as a Beta Feature at en.wiki.

I had visited mediawiki for the new skin feedback, and was catching up with my previous edits here. And I saw this reminder of yours. The "Reply" link was no longer distracting. In fact I didn't even notice there was a Reply link at the end of posts! I don't use it. I go to the top of the discussion thread, click "edit source" and place my indent where I want to. But now when I looked again, in order to provide feedback, I find the bolded Reply distracting again. I can't unsee it once I have focussed on it!

Thank you for following up to let us know, @Jay!

I wonder how/if at all your experience with the button might change when the new design becomes available at, what appears t be, your home wiki: en.wiki...

1. Did you use mobile device or a laptop to test the prototype?

Desktop, with an actual portrait-orientation desktop monitor.

2. What did you find unexpected about the prototype?

Well, the "reply" link and the line with counts and the latest comment are new.

3. Which steps in the "Try the Prototype" section did you find difficult to complete?

Editing my existing comment. Also, filling out the CAPTCHA; it didn't have a submit button distinct from the Reply.

4. What do you like about the prototype?

The reply feature so we don't have to edit the source and figure out how many colons to use to indent properly.

5. What do you wish was different about the prototype?

I'd kind of like to see an "edit" button on my own posts. I suppose discouraging editing of comments after-the-fact is somewhat healthy, as we're not supposed to do that in a way that changes the meaning. However, I think it would mostly be used to fix typos.

It seems to be missing a way to input special characters, like the degree symbol or Greek letters - the sort of thing common in STEM articles on Wikipedia.

6. Can you imagine this design not working on some pages? If you can, please share links to these pages? It would be very helpful.

Any talk page on enwiki where there's an RFC or merge discussion or something where people are voting. Then we need the ability to add an item in a bulleted list. See the "Discuss" links from https://en.wikipedia.org/wiki/Wikipedia:Requested_moves/Current_discussions for examples.

Sometimes discussions also end up with very deep nested replies, which causes the text to become extremely narrow. Someone eventually "outdents" it to reset it to the left margin so the conversation can continue readably. I'm not sure how that would be done here other than by editing the source to put in . -- Beland (talk) 06:47, 3 August 2022 (UTC)

Testing on my Android phone, what I would want most is a way to expand all the sections at once, so I can search the whole page for a certain text string. Right now I have to manually go through and expand all the sections one by one before I can search them. This requires a lot of scrolling and care and aim, unless you realize it's easier to go from bottom to top. Use cases include 1. finding the section on the page where I was previously involved in a conversation, 2. checking to see if a certain user had made comments on the page, and 3. checking to see if a certain issue or chunk of text or source had already been discussed.

The "Return to Reply" and link from the header that scrolls you to the most recent comment in a thread - nice features! -- ~~~~

what I would want most is a way to expand all the sections at once, so I can search the whole page for a certain text string

Actually, this is a feature that would make just as much or even more sense in articles as well. Could we have it for both?

hi @Beland! Wow. how generous of you to try out the experience on both mobile and desktop and share what you thought of both here...thank you :)

I'm going to use this post to respond to the feedback you shared about desktop and then follow up with a separate message to respond to the feedback you shared about mobile.

I'd kind of like to see an "edit" button on my own posts.

We hear on the value of adding this functionality. And while we won't have time to implement this during this phase of the Talk pages project, we are keeping track of the work that would be involved in doing this later in T245225.

It seems to be missing a way to input special characters, like the degree symbol or Greek letters - the sort of thing common in STEM articles on Wikipedia.

We will be adding the special characters toolbar in the coming weeks. You can track progress on this implementation in T249072.

...we need the ability to add an item in a bulleted list. See the "Discuss" links from https://en.wikipedia.org/wiki/Wikipedia:Requested_moves/Current_discussions for examples

Can you please give the steps below a quick read and let me know if I've misunderstood the functionality you are describing above?

Ideal workflow:

1. Visit https://en.wikipedia.org/wiki/Wikipedia:Requested_moves/Current_discussions on a mobile or desktop device
2. ✅ Observe there is a button/link that would open a tool like the one that currently appears when you click/tap a [ reply ] link that would enable you to add a new bulleted list item within a section of your choosing (e.g. ===August 6, 2022===)

If the above accurately describes the functionality you are seeking, then I will update the task where we are tracking this idea (T249886) with the example you shared.

Sometimes discussions also end up with very deep nested replies, which causes the text to become extremely narrow. Someone eventually "outdents" it to reset it to the left margin so the conversation can continue readably. I'm not sure how that would be done here other than by editing the source to put in

I see. It sounds like you are seeking a way to be able to manually adjust the depth at which the comment you are drafting will be published from within the Reply Tool....do I have that right?

No, that page is maintained by bot. The ideal workflow would be to go to a talk page discussion like w:Talk:Agni Poolu (film)#Requested move 15 July 2022 and respond to the move proposal by adding a new item in the bulleted list. Which typically includes a phrase like Support or Oppose or Comment and some reasoning. -- ~~~~

BTW, I get "-- ~~~~" in this form instead of my signature if I click the "preview the result" link and then click "Reply". If I just click "Reply" in source mode, it works as intended. If I go to preview and then back to source editing before saving, I see that the system has added unwanted "nowiki" tags.

Now on to responses to the feedback you shared about the new mobile experience...

...what I would want most is a way to expand all the sections at once, so I can search the whole page for a certain text string.

Would it be accurate for me to understand the above as you requesting the ability to expand and collapse all of the sections on a per-page basis?

I ask the above to make sure what you are describing is distinct from the existing setting within Special:Preference that enables you to decide whether all sections on mobile are expanded or collapsed by default.

The "Return to Reply" ...

We just added this! @Esanders (WMF) will be glad to know you found this helpful.

...link from the header that scrolls you to the most recent comment in a thread - nice features

:)

Aha, I've been using mobile Wikipedia for years, and I never knew there was a setting that expanded all sections by default! I'm going to enable that and see how I like it. It does have the tradeoff of making articles more difficult to navigate by section. On the desktop version, there's a table of contents you can look at to see if you want to skip to a specific section, but if you just keep reading everything's always fully visible. I think either showing a TOC on mobile if all sections are expanded, or having a per-page "expand/collapse all sections" toggle on mobile would mitigate the problem that the "always expanded" and "never expanded" settings have. -- Beland (talk) 02:15, 6 August 2022 (UTC)

It does have the tradeoff of making articles more difficult to navigate by section...

I agree with you here. I do not think the setting resolves the issue you shared above.

I think either showing a TOC on mobile if all sections are expanded, or having a per-page "expand/collapse all sections" toggle on mobile would mitigate the problem that the "always expanded" and "never expanded" settings have.

+1. It turns out we have do have an existing ticket for implementing the "per-page 'expand/collapse all sections'" feature you are describing above: T269954.

And while I do not think we will have time to prioritize work on implementing this feature as part of the first phase of the Talk pages project, I've added the need you expressed for it on the ticket so that our future selves will remember the need for this :)

Beland, I'm curious how your experiment has gone. Do you like having everything expanded by default, or did you turn off that preference setting?

I did indeed keep that preference setting. Sometimes I do collapse a bunch of sections in order to get the equivalent of a table of contents, if a search doesn't find what I'm looking for or I just need an overview of an article. So it would still be nice to have a expand all/collapse all toggle, or some way to get a TOC while keeping everything expanded.

1. Did you use mobile device or a laptop to test the prototype?
   • Laptop
2. What did you find unexpected about the prototype?
   • Surprisingly familiar
3. Which steps in the "Try the Prototype" section did you find difficult to complete?
   • None
4. What do you like about the prototype?
   • Not too different from what we're used to
5. What do you wish was different about the prototype?
   • Editing talk pages becomes another skill for editors (new and old) to learn. We still need to master editing articles etc. (i.e. pages which won't use this new workflow) but will now need a second set of processes for editing talk.
6. (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.
   • Discussion pages which are not in talk namespaces. English Wikipedia examples include Teahouse (relevant to new editors), AfD and the Village Pump.

How do you imagine the design being inappropriate in the Teahouse or a Village Pump? (I have some doubts about AFD pages myself. For example, w:en:Wikipedia:Articles for deletion/Log/2022 August 31 has no ==Level 2== section headings.)

If the new design works at the Teahouse then it may be appropriate. I just saw technical difficulties in working out which non-talk pages it should apply to. One option is simply to continue the current methods for such pages (edit them like articles) but that difference from talk pages may cause confusion.

The Reply button only appears if there is an "Add new section" button at the top of the page. (This can be controlled locally with a magic word.) Do you think that would be a reasonable signal for whether you want the new discussion activity information displayed?

I'd never *want* the new discussion activity information displayed: I still think that having to learn two different editing systems is a step backwards, and I'll opt out if there is any facility to do so. However, the "new section" button seems like a reasonable signal for when to offer it.

If you want to opt out, then Special:Preferences#mw-prefsection-editing-discussion gives you all the buttons. I believe that if you go to Special:GlobalPreferences#mw-prefsection-editing-discussion here at MediaWiki.org (specifically), then you can even opt out of any/all parts of it on all the wikis in one fell swoop.

Thanks, that's very useful and thoughtful. I'll give the new system a fair try, but it's good to know that it's optional for us Luddites who are used to a more traditional way of editing.

As a side note, I've been really happy recently to see people giving Vector 2022 a fair try. It's a big change, and there are things I personally don't love about it, but it's been really heartening to see people try it out for a week or two instead of seizing onto a first impression.

1. Did you use mobile device or a laptop to test the prototype?
   • Laptop
2. What did you find unexpected about the prototype?
   • A few things:
     • I tried clicking on the "Last comment: ..." area, expecting it to do something, like either linking to the most recent comment, or highlighting it, or at least popping out a bit more information about it (eg, the author of the comment, or a more precise timestamp). That it didn't do anything was unexpected and a little jarring, especially since the cursor didn't indicate it was plain text.
     • That after one reply was posted, all the reply buttons were greyed out and unclickable. (I assume this was a bug?)
     • I would have expected there to be some way to ping multiple users at the same time, either grouped in a template or with usernames separated by commas (as is a typical method, I think). Going through the "Mention a user" button multiple times in sequence just adds more "@"s before every user. Also, holding Ctrl while clicking options (as is occasionally a standard for multi-option selection) doesn't do anything.
3. Which steps in the "Try the Prototype" section did you find difficult to complete?
   • None.
4. What do you like about the prototype?
   • The overall appearance is very clean, and it's pretty easy to use.
5. What do you wish was different about the prototype?
   • I don't like that it's making wikitext itself be outputted differently on talk pages. Having it always be that any wikitext can be safely pasted anywhere for the same output was very useful. Also, the output isn't the same on the preview as on the reading mode. I really think that the header underline should be kept, or at least something should make it very easily recognizable that it's the same type of element as those headers in the mainspace. New users should be able to easily recognize that every formatting element they learn about in one setting can also be used in any other.
   • The big blue arrows seem kind of off-brand for the "content" part of the page itself. That area is normally kept deliberately plain. I don't think it needs to be quite as far as the old "[reply]" bits, but maybe somewhere in between the two?

In general, I like the progress that this project is making. Nice work!

hi @Yair rand – we appreciate you trying out the prototype and taking the time to share what you think about it here. Some comments and questions in response to what you shared below...

I tried clicking on the "Last comment: ..." area, expecting it to do something, like either linking to the most recent comment, or highlighting it, or at least popping out a bit more information about it (eg, the author of the comment, or a more precise timestamp). That it didn't do anything was unexpected and a little jarring, especially since the cursor didn't indicate it was plain text.

Great spot. We agree with you in thinking that people should be able to click on the "Latest comment..." information and, as you described, be taken to the most recent comment. In fact, the latest version of the prototype works in this way.

That after one reply was posted, all the reply buttons were greyed out and unclickable. (I assume this was a bug?)

We hear you. The issue you experienced here is a consequence of some limitations around how draft comments are saved. You can see more context about this issue in T257305.

I would have expected there to be some way to ping multiple users at the same time, either grouped in a template or with usernames separated by commas (as is a typical method, I think). Going through the "Mention a user" button multiple times in sequence just adds more "@"s before every user.

The "typical method" you referred to above...are you able to share a link to where you've seen this kind of functionality implemented before? No worries if an example doesn't come to mind.

The overall appearance is very clean, and it's pretty easy to use.

This is reassuring to hear :)

I don't like that it's making wikitext itself be outputted differently on talk pages. Having it always be that any wikitext can be safely pasted anywhere for the same output was very useful.

Can you say more about this? Where did you encounter wikitext being outputted differently from what you expected? This happening sounds unexpected to me.

The big blue arrows seem kind of off-brand for the "content" part of the page itself. That area is normally kept deliberately plain. I don't think it needs to be quite as far as the old "[reply]" bits, but maybe somewhere in between the two?

We agree with you about this. In fact, the latest designs does away with the arrows. See this screenshot.

Good to hear about the changes. :)

Re typical method for @s: See the default behaviour on Template:Reply to, which is present on many wikis, including here, Meta, ENWP, and many others.

Re different wikitext output on talk pages: I was specifically referring to the appearance of H2 elements, which are being shown with the horizontal bars above the text instead of below the text, as H2s have on content pages.

Re typical method for @s: See the default behaviour on Template:Reply to, which is present on many wikis, including here, Meta, ENWP, and many others.

Oh, okay! I understand now. Thank you for following up with these additional details, @Yair rand.

Re different wikitext output on talk pages: I was specifically referring to the appearance of H2 elements, which are being shown with the horizontal bars above the text instead of below the text, as H2s have on content pages.

Right. Yes, the H2 text is styled differently. Although, can you please share how the new H2 text styling is impacting how the text behaves when it is copy and pasted?

Yes, the H2 text is styled differently. Although, can you please share how the new H2 text styling is impacting how the text behaves when it is copy and pasted?

@PPelberg (WMF) as Yair said, as you said, and as I came here to say, H2 is styled differently. I am guessing that you are looking for "more" of an answer because you find it hard to imagine that is the problem being raised?

Let me try to explain it in a broader sense. The WMF tends to view Talk pages as a forum. For us Talk pages are Wikipages, they are our wiki workplace, we can and do use Talk pages for arbitrary work, we expect to be able to copy-paste article content to a talk page and have it show up exactly the same. That allows us valuable freedom to casually invent and modify workflows on the fly. We don't have to stop to think about all of the functionality and flexibility and compatibility of wikipages - we expect that as a fundamental background fact. That is our universe, and we expect the laws of physics do not randomly change. The fact that "discussion" is the most common content on Talk pages is almost incidental.

When the WMF proposes any replacement or change for Talk pages, there is a fast and critical test I preform. I go to our article for United States to grab a large and diverse sample, and I copy-paste it to Talk. I checked the preview for this on the current test wiki, with generally good results. Aside from the issue of various templates not existing on the test wiki, I only spotted a single problem. The new system clearly goes out of its way to explicitly mangle H2 headers. (Note: I use "mangle" in the broad sense of any modification from the canonical result.) It's good that "Last comment/# comments/# people" is not being added if there are no comments in a section. However the placement of horizontal bars is getting mangled. They're above the section title rather than below it. That is inconsistent and potentially confusing. H2 headers should be returned to normal, regardless of whether comments are detected in a section.

I could have written a shorter comment, but I think it valuable to keep trying to improve understanding on some of the "odd" expectations and requirements that community has.

hi @Alsee – I appreciate you expanding on the point @Yair rand raised above to help me get a better "grip" on what you both are describing. Some comments and questions in response below...

...valuable freedom to casually invent and modify workflows on the fly

Well put and understood! Preserving the freedom you described above has been, and continues to be, a requirement that all of the changes we are proposing as part of the Usability Improvements portion of the project meet.

However the placement of horizontal bars is getting mangled. They're above the section title rather than below it. That is inconsistent and potentially confusing.

While I appreciate that the horizontal bar appearing above section titles is different from how they appear in other contexts (e.g. the main namespace), the confusion you alluded to above is not currently clear to me...can you please say more about the confusion you imagine resulting from the horizontal bars appearing above rather than below H2 section titles?

I could have written a shorter comment, but I think it valuable to keep trying to improve understanding on some of the "odd" expectations and requirements that community has.

+1 – I'm grateful that you invested the time and effort to compose this thorough response.

At the time I wrote that I was referring to the general mental gear-crashing/freeze up when you've seen something the same way hundreds of times, then the standard patterns are broken and your brain has to stop to figure out what you're looking at.

However with this now deployed on Meta, I can give you a better answer. I came across a page where this resulted in a particularly bad mess. I didn't foresee this particular result, and I'm betting you didn't foresee it either. In the middle of several discussion sections there was an empty section. The result was two horizontal lines in a row, like this:

Comments
HeadingA

---

---

HeadingB
Comments

That is just plain bizarre, and I bet that it never occurred to you that that was going to happen. Two lines in a row is extremely unexpected and nonsensical. I expect many people seeing that will experience it a very distracting WTF mental trainwreck.

In that particular case the empty section was intended to invite discussion on topic HeadingA. However it could just as well have been a sample of article content posted on talk. Mangling article content posted on talk pages would be bad, therefore HeadingA is correct and the bizarre double-line is being caused by the inconsistent styling on HeadingB.

At the time I wrote that I was referring to the general mental gear-crashing/freeze up when you've seen something the same way hundreds of times, then the standard patterns are broken and your brain has to stop to figure out what you're looking at.

Understood. Also, I appreciate you naming/describing this experience...I relate to, what sounds like, the period of adjustment that can arise when I return to a place I've visited before to find that things are not where I'm used to them being or looking.

In the middle of several discussion sections there was an empty section. The result was two horizontal lines in a row, like this...

Oh, interesting – can you please share a link to the page where you noticed this? I'd value seeing this case in the context it emerged within.

In the meantime, would it be accurate for me to understand the wikitext that produced that behavior you noted above as what I've written here? And if not, could you please edit meta:User_talk:PPelberg_(WMF)/Sandbox so that it contains the wikitext that produced the behavior you encountered?

the period of adjustment that can arise when I return to a place I've visited before to find that things are not where I'm used to them being or looking.

Actually I particularly had new users in mind. They've been reading articles and they have a lot of "free" knowledge built in from that. One bit of free knowledge they have is section headings look like, from seeing countless section headings in articles. They go to Talk and you're randomly hitting them with scrambled page elements. Either they don't recognize the section heading and they need to process what they're looking at from scratch, or even worse they do "recognize" and the mismatch with their implicit knowledge mentally crashes in active confusion. Why make things more difficult and unpleasant for new users??

I previously tried to explain simplicity, and you never understood what I was trying to say. You thought I was saying editors are familiar with what we have therefor it is "simple" for us. That's not it. This heading formatting is a small piece of what I was trying to explain. If headings work the same on both pages, there is literally nothing to learn. Making them work differently is a (small) increase in complexity, it's an additional thing you need to learn, it's an additional thing you need in your head when you're using the system. This is a small bit of added complexity, but a pile of a thousand small bits of complexity becomes far more difficult to learn and more difficult to use. When we say "a page is a page", that embodies thousands of things that you don't need to learn. There's more to it, but that's part of it.

Why make things more complex, needlessly inserting random inconsistency?

@Alsee: thank you for following up with this additional detail...

It sounds like we agree:

1. It is important that new users arriving on talk pages understand them as places to communicate with other volunteers about changes to improve Wikipedia

2. It is important that the Editing Team considers the experiences new users have with reading articles as we come up with solutions/designs to achieve what "1." describes

3. The more "things" people need to consciously think about/learn about Wikipedia's interface, the more difficultly they will having using Wikipedia

It sounds like you assume:

4. Ensuring section headings look the same on desktop article pages and desktop talk pages will reduce the amount of complexity new users will need to cope with/learn

If I assume the above to be accurate then:

I think the point of difference between what the Editing Team is thinking and what it sounds like you are thinking is the following...

We think that section headings looking the same on desktop article pages and desktop talk pages will increase the amount of complexity new users will need to cope with/learn and therefore detract from "1." rather than contribute to it.

We've come to think this based on, among other things, two bits of primary research.

First, is the new user tests we ran as part of the Talk pages consultation wherein we learned that new users were confused by the similarity between how section headings were presented on article and talk pages, "...once on the talk page, many users thought the headers of the discussions corresponded to the sections of the article. In other words, they thought that discussions about articles were organized around article sections."

Second, is the usability tests we ran of this new design with new users and Junior Contributors wherein we learned that most test participants accurately recognized talk pages as places to communicate with other volunteers within ~15 seconds of landing on the page.

Of course, if there is research you've done/seen that leads you to think that section headings looking the same on desktop article pages and desktop talk pages will reduce the amount of complexity new users will need to cope with/learn I'd value knowing!

I found the page I saw:m:Talk:Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Board_of_Trustees_elections/Discuss_Key_Questions
I hadn't examined the source and I had misinterpreted what was happening. The actual issues are as follows:

1. =H1 headers= render with the line below the heading, resulting in the double line effect. You can see this in the top half of your sandbox. "General comments" has a double line after it.
2. When I paste article content on talk it's mangling the ==H2 headers== putting them above the heading. You can see this on the bottom half of your sandbox. (I could have sworn I tested this before, I though my previous test correctly put the lines were below the headings, and I assumed it was because no comments were detected in the sections.)

Thank you for following up with these examples. Before filing a ticket, a couple of questions about what you're noticing...

I) Two lines appear above =H1= section headings when they are immediately followed by an H2

1. On desktop, visit a talk page where Topic Containers are enabled and said talk page contains a minimum of one H1 section heading that: a) does not contain any content within it and b) is followed by an H2. E.g. meta:Talk:Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Board_of_Trustees_elections/Discuss_Key_Questions
2. ❗️Notice two horizontal lines appear beneath the H1

Question: what would you expect to happen in this case?

II) A horizontal line appears atop ==H2== section headings that do not have discussions happening beneath them

1. On desktop, visit a talk page where Topic Containers are enabled and said talk page contains a minimum of one H2 section heading does not contain a discussion. E.g. meta:User_talk:PPelberg_(WMF)/Sandbox#Electrification
2. Notice == Electrification == has a horizontal line above it

Question: what concerns you about this?

Starting with your second question, I find this so obvious that I struggle with how to respond. We're both programmers, so maybe I can make an analogy. Some language conventions allow more than one file extension for code. For example in C++ you typically use a file extension of .cpp the main body of a program, and included header files typically use a .h extension.

• A file is a file: It works the same way not matter what you put in it.
• C++ code is C++ code: It means the same thing and behaves the same way, no matter what file extension it happens to have.
• There may be conventions that .cpp and .h files tend to be used for somewhat different purposes, but those conventions don't alter the underlying behavior. During actual work, it is expected that you will sometimes need to move a chunk from one place to the other. That works seamlessly.

Now imagine someone comes along as says to you they want to change how the print function works, depending on the file extension. Output will be formatted one way if the code has a cpp file extension, and output will be formatted differently if it has an h file extension. That is theoretically doable, however it makes things more complex and confusing if the meaning or behavior randomly and unexpectedly change when you copy-paste a block from one place to another.

If you look back you can replace replace "C++ code" with Wikitext, replace file with page, replace ".ccp" with article pages and ".h" with talk pages. And in this example, the print function formatting is the header formatting. The header formatting is not a huge or catastrophic in itself, but breaking the definition and behavior of wikitext appears as obvious of an issue as breaking definitions and behavior in any other language.

If I may quote former Board member Doc James' response in the Talk Page Consultation, he made a point many others have made:

• ...Content can be copied and pasted from the main article to the talk page and the formating remains the same... Doc James 06:16, 24 February 2019

Most editors consider that an implicit fact. Our wiki-world is built out of wikitext, wikitext works everywhere, and wikitext has a definition. Editors were in disbelief when the lead Dev on the previous project said the unthinkable, that wikitext would have a random different definition and random different behavior on different pages. Editors had to learn to state the unthinkable. We had to learn to expressly say that when you copy-paste wikitext, the definition does not randomly change. When editors don't say this out loud, it's usually because they can't imagine it needs saying.

I negotiated the uninstall of the previous project from EnWiki, as well as uninstall consensus at Meta, and Commons. I am the person primarily responsible for getting the WMF to re-evaluate it's Talk page plans, and ultimately the 2019 Talk Page Consultation. I was extensively involved in the preparation and process for the Talk page consultation. First on the list of Possible Solutions, as posted by DannyH, was "Building features on top of wikitext talk pages, to make them easier and more efficient." The support for that option was so overwhelming - had been overwhelming for years - that the WMF really shouldn't have needed to go through the motions of a formal Consultation.

Building features on top of wikitext talk pages, to make them easier and more efficient, should not alter the underlying and pre-existing behavior of wikitext itself. At least, not without consulting the community on any proposed changes.

P.S. On the first question, "what would you expect to happen in this case?" my expectation is incredibly simple. I expect my expectation is the same as pretty much all editors' expectation. I expect wikitext to have a single definition. I expect all wikitext, including all levels of =headers=, to have consistent behavior on all pages.

The ugly double-line mess caused entirely by the new upsidedown formatting on ==H2==.

...wikitext works everywhere, and wikitext has a definition. Editors were in disbelief when the lead Dev on the previous project said the unthinkable, that wikitext would have a random different definition and random different behavior on different pages.

For you, it sounds like == Heading name == rendering with a horizontal line beneath it in the main namespace and a horizontal line above it in the talk namespace is a substantial enough difference that you consider it as changing the definition of what == == means and you anticipate other volunteers will reach the same conclusion.

Building features on top of wikitext talk pages, to make them easier and more efficient, should not alter the underlying and pre-existing behavior of wikitext itself. At least, not without consulting the community on any proposed changes.

+1 to what you're saying here. In fact, we're planning to make these heading changes available as an opt-in beta feature in the coming days at en.wiki and I'll be curious to learn whether the concern you've named here is a concern other volunteers share as well.

In parallel, I'll be on the lookout for comments from volunteers at other wikis about this.

Note: the changes to how H2 section headings are styled on talk pages are available on all Wikimedia wikis as a beta feature except de.wiki, en.wiki, and ja.wiki.

The ugly double-line mess caused entirely by the new upsidedown formatting on ==H2==.

I'm glad you spotted this. I've now filed T318198 so that we can track the prevalence of this issue and figure out what could be done to prevent it from happening.

you anticipate other volunteers will reach the same conclusion

I quoted for you a Board member during the Talk page consultations making the point themself. We expect consistent behavior when we copy-paste wikitext.

Is that really so hard to believe? Would it help if I go dig up quotes from various other editors who have said the same thing in one form or another over the years? Would it help to have an RFC asking whether we want consistent wikitext behavior?

the changes to how H2 section headings are styled on talk pages are available on all Wikimedia wikis as a beta feature

I currently have no opinion on the "Latest comment..." stuff, but if an editor does want it, how do they fix the H2 problem? Or is the H2 problem forced on anyone who wants the "Latest comment..." stuff?

I'm more concerned about the output not being the same in the preview as in the reading mode (presumably in the 2010WTE and 2017WTE). If that hasn't been addressed, then we should probably file a bug (and possibly organize a meeting about it soon, since it might need to be coordinated with the Content Transform Team, plus CommTech's live preview work is getting busy).

1. Did you use mobile device or a laptop to test the prototype?

Desktop PC.

2. What did you find unexpected about the prototype?

The order the text and numbers are displayed is odd. This have to be corrected.

Please see the suggested corrections below:

1) TOP

If below is what you want to say:

Latest comment: {{aged}} by {{posted-by}} in topic {{topic-name}}

Then make the translation appear this way:

最新のコメント: {{aged}} | トピック: {{topic-name}} | 投稿者: {{posted-by}}

Reverse translation:

Latest comment: {{aged}} | Topic: {{topic-name}} | Posted by: {{posted-by}}

The demo as it is mean something like this, which is odd:

Latest comment: 2 days ago written by TopicVotes's Carol

2) By Topic

Likewise, if this is what you want to say:

Latest comment: {{aged}} | {{n-comments}} comments | {{n-participants}} people in discussion

Then this is how it should be displayed:

最新のコメント: {{aged}} | コメント数: {{n-comments}} | 参加者数: {{n-participants}}

Reverse translation:

Latest comment: {{aged}} | No. of Comments: {{n-comments}} | No. of Participants: {{n-participants}}

3) "Subscribe"

For "Subscribe" in this case, "更新を通知" fits better.

Reverse translation: Notify updates

You have 「最新の」and「最後の」for the same word "Latest". Either will do, but let's stick to 「最新の」in this case. (Like I did above.) 「最後の」is more like "last". They're interchangeable in many cases , if not always.

3. Which steps in the "Try the Prototype" section did you find difficult to complete?

None.

4. What do you like about the prototype?

It's nice to have a quick view over these stats.

5. What do you wish was different about the prototype?

Showing the number of comments and "latest" post in the "Contents" summary for PC (the same way as in the mobile version) would be nice.

Hope this helps.

hi @Jaw Salvager – thank you for taking the time to share the feedback you have about the prototype as well as the text strings that appear within it!

Showing the number of comments and "latest" post in the "Contents" summary for PC (the same way as in the mobile version) would be nice.

Two follow up questions for you:

1. By "Contents summary" are you referring to the box that appears on the left side of the desktop version of the prototype that shows the names of each section and the number of comments within each section?
2. Assuming the answer to the question above is "yes," can you please share what might be leading you to suggest that information about the latest comment within each section be added to the "Contents" summary portion of the page? For example, how might having the "latest comment" information within the table of contents box help you?

Hi @PPelberg (WMF), yes, that's right, I mean that box.

Imagine there's a talk page that have multiple sections where ongoing comments are being made here and there. With the "latest comment" info in the Contents summary, I'll be able to see whether there is a relatively new comment in a section other than the one that will be indicated at the top, without having to scroll through the whole talk page. It will be particularly useful when a talk page has many sections with long comments. Obviously, for a talk page with only one or two section with short comments, it won't be that much useful.

The translations on Patch Demo are temporary and need to be redone for the live sites anyway on translatewiki.net (separate account required). Feel free to put the correct translations and/or fix the existing ones there.

Hi, @Tacsipacsi, thanks for your info.

I opened an account over there and am awaiting my account upgrade for edit right now.

Thank you for sharing this guidance, @Tacsipacsi.

I can fix the translations on the PatchDemo prototype wiki if you give me the right codes. You can see the current versions at:

• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/MediaWiki:Discussiontools-pageframe-latestcomment/ja
• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/MediaWiki:Discussiontools-topicheader-latestcomment/ja

(Click 'view source' to see the wikitext. Try this link: https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:Main_Page?uselang=qqx to see where each message appears, and https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:Main_Page?uselang=ja to see page in Japanese.)

1. Did you use mobile device or a laptop to test the prototype?
   • Laptop
2. What did you find unexpected about the prototype?
   • nothing remarkable
3. Which steps in the "Try the Prototype" section did you find difficult to complete?
   • none
4. What do you like about the prototype?
   • if it has only minor bugs: nothing (but still prefer source code editing)
5. What do you wish was different about the prototype?
   • since I'm an old school editor: no disturbing things found, okay for me.
6. (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.
   • no

hi @Flossenträger – thank you for taking the time to try out the prototype and share what you thought about it with us.

A quick follow up question for you: do you recall what "minor bugs" you noticed?

Hi PPelberg, I didn't find any Bug (in this short test) , but is there any Sw without? So if there no big issue, let's go ahead. Sorry for it bring Mode Preise. 188.126.191.191 03:11, 8 September 2022 (UTC)

Understood – thank you for following up !

I would recommend your Excellencies check the following for some hints on the talk page design:

• https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style?oldid=1108339662#Hyphen-Traumas
• https://en.wikipedia.org/wiki/User_talk:MasterQuestionable
• https://en.wikipedia.org/wiki/Talk:Byte?oldid=1106446452#%5B20220818%5D_On_recent_editing_that_had_references_%22broken%22
• https://en.wikipedia.org/wiki/Template_talk:Portal?oldid=1104009396#Use_of_%22Johnny-automatic-scales-of-justice.svg%22

No one reasonable does serious writing in one-liner seriously.

We may rely on syntax highlighting (and alike sophisticated post-rendering) to aid readability, but not which to support readability.

Further related: https://en.wikipedia.org/wiki/User_talk:MasterQuestionable/6

I would recommend your Excellencies check the following for some hints on the talk page design:

hi @MasterQuestionable – can you please say more about the above? What are you wanting to use the links you shared to tell/show us?

Greetings. Thanks for your attention.

I fear I would have to redirect most of the discussion to my talk page (aforementioned): as the board's posting mechanism seems to break things seriously.

"for some hints on the talk page design": including general formatting (through my usage), and advanced topic management (on my talk page).

1. Ich habe die Demoversion über einen Laptop ausprobiert.
2. Die Anzeige der letzten Bearbeitung zu dem Thema, welche echt pracktisch ist.
3. keine.
4. Die Anzeige der letzten Bearbeitung sowie der Anzahl der Beiträge und Diskutierenden zu dem Thema?
5. Die Anzeigen mit den Diskussionsinformationen könnte etwas weniger hoch sein?
6. Nein.

Es freut mich, das die Anzeige der letzten Bearbeitung sowie der Anzahl der Beiträge und Diskutierenden zu dem Thema dir gefahlt.

hi @Wandelndes Lexikon – than you for taking the time to try the prototype and share this feedback with us.

4. Die Anzeige der letzten Bearbeitung sowie der Anzahl der Beiträge und Diskutierenden zu dem Thema?

It sounds like you're saying that you would value the information that appears beneath each section title to be adjusted...can you please describe what led you to suggest this?

I like the informations and because of these I find the discussion clearer and more structured.

I like the informations and because of these I find the discussion clearer and more structured.

Understood! We're glad to hear this, @Wandelndes Lexikon.

1. A laptop
2. Not really, although the spacing between "Talk:" and the name of the page is slightly odd
3. Editing a comment is still somewhat unintuitive for newer users - I knew about the edit source button, but I suspect most newer users would expect a separate "edit comment" button
4. It's a lot cleaner and more modern than the current design for talk pages
5. I'm somewhat :/ on the font (I'm not a huge fan of bolded Arial), although I appericate this is a wider skin issue that would require a lot more development/discussion. I'm also not a fan of the space between "Talk:" and the name of the talk page; if you want to make it more clear that these are "talk pages" it might be better to use some kind of box/icon instead of the space?
6. I can't think of any off the top of my head, although I imagine project-space talk pages might be a bit problematic in some cases (at least on en-wiki)

hi @Remagoxer! I appreciate you taking the time to try out the prototype and share the feedback you had about it with us here. Some comments and questions in response below...

Comments/Questions

1. ...the spacing between "Talk:" and the name of the page is slightly odd

"Odd" in the sense that it's not what you're used to? "Odd" in the sense that you are concerned that it could interfere with a workflow you've come to depend on? Something else? Note: I see that you mentioned this spacing in "4." as well.

2. Editing a comment is still somewhat unintuitive for newer users - I knew about the edit source button, but I suspect most newer users would expect a separate "edit comment" button

Good call and we agree with you. In the future, we hope to be able to offer people the ability to edit specific comments. Although, that feature depends on some more involved technical work that the Editing Team will not be able to prioritize as part of this initial phase of the Talk Pages Project.

3. I'm somewhat :/ on the font (I'm not a huge fan of bolded Arial), although I appericate this is a wider skin issue that would require a lot more development/discussion.

I hear you and I appreciate you saying as much. I think the new font is going to take some getting used to.

4. I can't think of any off the top of my head, although I imagine project-space talk pages might be a bit problematic in some cases (at least on en-wiki)

5. I can't think of any off the top of my head, although I imagine project-space talk pages might be a bit problematic in some cases (at least on en-wiki)

We share the assumption that there might be adjustments we might need to make to ensure this design works well in the project namespace. For this reason, we're constraining these changes to the article and user talk namespace to start.

Once we're confident they're working and effective in these namespaces, we're thinking we'll reconsider offering this design in more namespaces where discussions happen.

No worries - I'm happy to help however I can.

In regards to the spacing, I think it's just that I'm not really used to it - off the top of my head, I can't think of any workflows in particular that this would impact.

I don't really have much more to say at the moment, although I appreciate the work y'all are doing to make talk pages easier to use ^^

In regards to the spacing, I think it's just that I'm not really used to it - off the top of my head, I can't think of any workflows in particular that this would impact.

Thank you for putting some additional thought to this and understood. Note: if/when you happen upon a case where the space between "Talk:" and the name of the page could cause issues, I'd value knowing :)

I don't really have much more to say at the moment, although I appreciate the work y'all are doing to make talk pages easier to use ^^

Understood and we appreciate you stopping by to see what we're up to and share what you think about it.

1. Hast du ein Mobilgerät oder einen Laptop für den Test des Prototyps verwendet?
   • Windows 11 Convertible Notebook (3:2; Firefox Nightly 106.0a1, 2022-08-31; Vector 2022)
2. Was hat dich am Prototyp überrascht oder was hattest du nicht erwartet?
3. Welche Schritte aus dem Abschnitt „Probiere den Prototyp aus“ waren kompliziert?
   • keiner
   • none
4. Was magst du an dem Prototyp?
   • Die Zähler unter den einzelnen Abschnittsüberschriften und im Inhaltsverzeichnis gefallen mir sehr gut.
   • I really like the counters under each section heading and in the table of contents.
5. Was hätte beim Prototyp anders sein sollen?
   • Als ich den Text »Bearbeite die Antwort, die du veröffentlicht hast.« gesehen habe, hatte ich erwartet, dass man jetzt endlich einen extra Button bei eigenen Kommentaren hat, um nur sie und nicht den ganzen Abschnitt zu bearbeiten. Bislang muss man aber wohl immer noch den ganzen Abschnitt bearbeiten, um einen eigenen Kommentar zu korrigieren :(
   • When I saw the text "Edit the reply you posted." I expected to finally have an extra button on my own comments to edit only them and not the whole section. But so far I guess I still have to edit the whole section to correct my own comment :(
6. (Optional) Kannst du dir vorstellen, dass dieses Design auf einigen Seiten nicht funktioniert? Wenn ja, kannst du diese verlinken? Dies würde uns sehr helfen.
   • Mir fällt keine Seite ein, wo dies der Fall sein könnte.
   • I can't imagine a site where this could be the case.

hi @Dwain Zwerg – thank you for taking the time to try out the prototype and share the experience you had with it...in both German and English!

Below are some comments in response to what you've shared.

I really like the counters under each section heading and in the table of contents.

I'm glad to hear this!

When I saw the text "Edit the reply you posted." I expected to finally have an extra button on my own comments to edit only them and not the whole section. But so far I guess I still have to edit the whole section to correct my own comment :(

We agree with you in thinking that introducing a button to edit specific comments would make a lot of peoples' lives easier :) It's an idea we've started thinking about (see T245225). Although, it's not a feature we'll be able to implement in the near-term as it depends on some more involved technical work.

I can't imagine a site where this could be the case.

Understood! Well, if and when you happen upon a page that you think would challenge the way the design works, please do let us know.