Topic on Talk:Talk pages project/Usability/Prototype

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