Talk:Talk pages project/Usability/Archive 1

Test page

This page has been set up as a wikitext talk page. This should make it easier to see and test the visual enhancements, but it might make it harder for people to notice replies, especially if they're editing at a different wiki. Please remember to @-mention or {{Ping }} me and other people. Whatamidoing (WMF) (talk) 20:13, 5 February 2021 (UTC)

Test respose EAkinloose (talk) 21:08, 2 March 2022 (UTC)

Welcome to this page, @EAkinloose! Whatamidoing (WMF) (talk) 04:06, 3 March 2022 (UTC)

Moving page to Talk pages project/Legibility

@Whatamidoing (WMF): do you have any concerns about us moving this page to Talk pages project/Legibility?

Having articulated the objectives of this work (see #Objectives), I think "legibility" [i] more accurately describes the work we will be doing as part of this project and the impact this work is intended to have than "visual enhancements" does.

---

i. Here, I am using "legibility" to refer to what Kevin Lynch in The Image of the City as, "...the ease with which its parts can be recognized and organized into a coherent pattern. Just as this printed page, if it is legible, can be visually grasped as a related pattern of recognizable symbols, so a legible city would be one whose districts or landmarks or pathways are easily identifiable and are easily grouped into an over-all pattern.” PPelberg (WMF) (talk) 20:20, 22 April 2021 (UTC)

@PPelberg (WMF), I like that name, but it might be confusing. It sounds like maybe changing the font size (e.g., so I can read without my glasses on). It might also get translated in odd ways, to mean something like "Readability". Maybe Talk pages project/Appearance? Talk pages project/Organizing? Talk pages project/Changing appearance? Talk pages project/Adding information? Whatamidoing (WMF) (talk) 19:22, 27 April 2021 (UTC)

I like that name, but it might be confusing. It sounds like maybe changing the font size (e.g., so I can read without my glasses on). It might also get translated in odd ways...

Good call, @Whatamidoing (WMF). Are you able to move this page to Talk pages project/Usability?

Thinking: "usability" can be translated without much lossiness across a variety of languages and "usability" represents the objectives of this project well: to help people better understand talk pages and use them more effectively. PPelberg (WMF) (talk) 00:24, 31 July 2021 (UTC)

@PPelberg (WMF), I've  Done the page move. I don't think we're going to find a perfect name, but this is a good option, as it should be clearer that the point is to make it easier to use, rather than changing the appearance beyond what's helpful for practical reasons. Whatamidoing (WMF) (talk) 22:52, 2 August 2021 (UTC)

Excellent and agreed. Thank you, @Whatamidoing (WMF) PPelberg (WMF) (talk) 23:34, 2 August 2021 (UTC)

THe objectives are obviously locked. Maybe in the future junior contributors would have been "communicate safely and receive responses other volunteers and locate the tools and clear procedures to do so"

Senior Contributors to be "encouraged with tools to behave in a respectful manner" and have "a page that is easy to focus on" Wakelamp (talk) 11:14, 2 November 2021 (UTC)

Hi, @Wakelamp. The general objectives for this project were decided during the Talk pages consultation 2019. I think that some of your points:

• receive responses
• locate tools and procedures
• a page that is easy to focus on

are within scope of this project. Respect and safety issues sound more like "people" than "software". I believe there is a broader project for that with the m:Universal Code of Conduct work. Whatamidoing (WMF) (talk) 22:37, 8 November 2021 (UTC)

Added information about discussions

@JKlein (WMF), you might want to look at w:en:Wikipedia:WikiProject Hospitals/Article alerts. This is a bot-generated list of links to (mostly) other discussions, and it is interesting to see what extra detail/context the bot provides about these discussions. For example, the deletion list says how many people have participated in the discussion. Whatamidoing (WMF) (talk) 02:19, 1 May 2021 (UTC)

This is great, @Whatamidoing (WMF). I've also added a link to Wikipedia:WikiProject Hospitals/Article alerts within T295392 where we are exploring the idea of enabling people to more easily make/customize discussion lists/feeds. PPelberg (WMF) (talk) 20:35, 19 November 2021 (UTC)

A question about reading talk pages

When looking at a talk page, what do you think would make it easier for you to know what conversations are worth reading? PPelberg (WMF) (talk) 02:03, 24 July 2021 (UTC)

Probably the ones worth checking are those with many replies, so maybe the TOC could show that number after the title, or add a symbol/icon, something like that.

Also, some privileged user might have the power to manually highlight topics. This also could be shown in the TOC. Wedhro (talk) 04:36, 24 July 2021 (UTC)

Does it have to be a privileged user? If it's to high, someone else can reduce. Even if a priority is set, it might not change the chance of resolution Wakelamp (talk) 10:59, 2 November 2021 (UTC)

@Wedhro, do any communities currently highlight topics? Whatamidoing (WMF) (talk) 16:50, 11 November 2021 (UTC)

Some indication of how many replies have been posted within each topic...understood and this makes sense. I've made a note of this in Phabricator where we will be working on this particular aspect of the project.

As you are using talk pages, if other kinds of information or visual changes come to mind that you think you could make it easier to understand what people are talking about, we'd be curious to know.

Any way, thank you for stopping by to share what you think, @Wedhro. PPelberg (WMF) (talk) 01:07, 30 July 2021 (UTC)

Those are the first things that I thought about without really reflecting about the matter, to be honest. The most representative element of a specific discussion is the title of its section, but often people don't know how to write a good one and there's nothing which can be done about it, I guess.

Another thing that could help people understand what's going on (but it's unrelated to the matter being discussed in the page) is how comments from different users are only differentiated by the final signature, which doesn't help even if users heavily customize them. Maybe a visual break would help, such as a horizontal line after each comment, or a different background for each comment.

I'll let you know if I get more ideas, thanks for working hard to make things better for everyone. Anyway, I have a question: is there any plan about being able to move talk pages (or even single sections) without breaking links or messing with the page history? Is one of the things that makes life hard for moderators because there's a lot of OT comments that need to be moved or long pages that need to be archived, and there's no clean method to do any of that. I know it's OT, I'm just curious because it's a big issue and I've not seen it discussed (if it was, my bad).Wedhro (talk) 19:26, 30 July 2021 (UTC)

The most representative element of a specific discussion is the title of its section, but often people don't know how to write a good one and there's nothing which can be done about it, I guess.

Can you say a bit more about this...what do you consider to be a "good" title in this context? Is a good tile one that clearly communicates what is being discussed? Is a good title short enough to be consumed while skimming the page? Etc...

Another thing that could help people understand what's going on...is how comments from different users are only differentiated by the final signature, which doesn't help even if users heavily customize them.

I'm glad you mentioned this. I've added this feedback to the ticket where we are thinking about this issue of how comments can be more clearly related and distinguished: T282269.

is there any plan about being able to move talk pages (or even single sections) without breaking links or messing with the page history? Is one of the things that makes life hard for moderators because there's a lot of OT comments that need to be moved or long pages that need to be archived, and there's no clean method to do any of that.

We do not currently have plans to try to improve the experience for moving talk pages or individual sections within them as part of this first phase of the Talk pages project (I know the issue around archiving came up in the 2019 Talk Page Consultation).

With the above said, I am curious to better understand what your experience is like for archiving pages/moving individual conversations and the undesirable aspects of both processes. If you feel compelled to share this, I think starting a new conversation on Talk:Talk pages project would be a great place to do so :). PPelberg (WMF) (talk) 00:56, 5 August 2021 (UTC)

A good title should be a concise but understandable summary of what the sub-discussion is about. Summarizing is a skill that not everyone has, though, so often people use titles so generic or vague it's impossible to tell what they're about (such as "Help"). It's not an issue with MediaWiki in itself, you see this in all kind of social websites, for example Reddit. I really have no idea how to fix this, except from extreme deviations from regular MediaWiki such as auto-titling with an excerpt from the comment, or not having titles at all.

About archiving thanks for the link, I had no idea it was being discussed.Wedhro (talk) 04:59, 5 August 2021 (UTC)

Rather than which topic to focus on, Are there too many other distractions on Talk so focus is hard? And many topics are not acted on just archived Wakelamp (talk) 10:28, 2 November 2021 (UTC)

@JKlein (WMF), I believe you've been thinking about this question. Whatamidoing (WMF) (talk) 22:38, 8 November 2021 (UTC)

Yes, it's a concern that I share @Wakelamp

We are exploring ways to display the topics alongside relevant metadata (how many responses there have been, how many different people are talking, is this a really popular topic etc). Additionally we are looking into alternative models for surfacing the information that usually appears at the top of many Talk pages. JKlein (WMF) (talk) 00:13, 9 November 2021 (UTC)

The problem is that there are topics that are worth reading based on the topic names, but the cognitive load to read them makes me avoid them. The cognitive load increases with depth, fragmenting of comments, number of replies, identifying the editor, and not having seen the conversation change. For instance, someone in this thread has said " "comments from different users are only differentiated by the final signature", but I don't know who.

I am beginning to think that Wiki conflict is in part caused by the fragmentation and loss of authorship/identity. Without a way to refer to fragments and there author then there is no easy way to summarise to gain consensus. My experience is that as the cognitive load increases, most people skim, , conflict increases, the number of conflict seekers increases, the chances of a decision decrease, and the cost benefit of my involvement decreases Wakelamp (talk) 22:35, 9 November 2021 (UTC)

I agree: we may skim a long conversation, or we even skip reading it entirely. Whatamidoing (WMF) (talk) 16:40, 11 November 2021 (UTC)

I think there may be a huge difference between the way more experienced editors and others use talk page. More experienced read and refer to each other's comment, and there is less fragmenting. I wrote out some use cases based on the type of Talk page usage. The most important question was is this topic still undone.I see these in computer games [[1]] [[2]] where they also use edit requests and set the flag to YES. I am not sure how it works in practise, but they seem to be creating a bug and escalation flow like bugzilla flow, or Jira and I assume phabricator. Wakelamp (talk) 12:36, 12 November 2021 (UTC)

Comparison of internet forum software has a discussion about the difference between threaded and flat. A major difference with flat is the ability to easily quote each other which allows the bringing together of threads The other thing common to both, but used in wikipedia but in media wiki is the ability to flag a post up and down - or maybe in our case just unhelpful Either would help you assess whether it is worth reading. and important Wakelamp (talk) 12:36, 12 November 2021 (UTC)

I am more likely to read in depth if there are new editors, and if the conversation is constructive; you can't identify either easily. Wakelamp (talk) 22:35, 9 November 2021 (UTC)

When and who

@JKlein (WMF), I'm posting a quick link here about a conversation on Getting information about a discussion at the Dutch Wikipedia, which had a very concise and useful idea of the information needed: We need to know "who" is in the discussion, and "when" it happened. These are key points. Whatamidoing (WMF) (talk) 20:14, 20 August 2021 (UTC)

Feedback: Topic Containers Design Concepts

The first intervention we are working on as part of the Usability Improvements portion of the Talk Pages Project is Topic Containers.^[i]

A series of Topic Containers design concepts.

A set of initial design concepts are ready for you all to review and share what you think about them.

Below is the information you will need to:

1. Review the design concepts and
2. Share feedback about the design concepts

If any questions come up as you are reviewing the concepts (e.g. "What is this icon referring to?", "What do you envision happening if someone were to click/tap this?", etc.) , please post them here...it is likely someone is wondering something similar to what you are.

---

i. Topic Containers are an effort to evolve the way talk page section headings (read == H2 ==) appear, and introduce new information within them, in order to help:

• Junior Contributors easily recognize talk pages as containing discussions
• Senior Contributors assess the level of activity on talk pages

PPelberg (WMF) (talk) 00:07, 18 December 2021 (UTC)

Review the design concepts

To see the Topic Container design concepts visit Commons: Topic Containers Design Concepts.

Share feedback

Once you have reviewed the design concepts and you are ready to share what you think of them, please do the following:

1. "Start a new topic" on this talk page
2. Name this new topic: "Topic Container Design Feedback: YOUR USERNAME"
3. Write answers to these questions
   1. What you appreciate about these design explorations?
   2. What do you wish were different about these design explorations?
   3. What other ideas do you think would be worthwhile exploring in the next iteration of Topic Container design concepts?

PPelberg (WMF) (talk) 00:07, 18 December 2021 (UTC)

I have to really zoom into the image to be able to see the changes. I'm liking the idea of a new "Copy link" option to get the URL with the section heading. That would save me some time.

@Quiddity was telling me that he doesn't like having the edit button right next to the section heading's words, because all the words can run together when you're reading quickly: "Question for you edit source", rather than "Question for you" followed by "edit source". I therefore suspect that he would like "Exploration 3" (putting the actions in a dropdown menu) better than having the section headings look like "Question for you edit source copy link". Whatamidoing (WMF) (talk) 18:53, 20 December 2021 (UTC)

I don't understand this dislike; we've already been-there-done-that several years ago when edit links got moved to the left from their original right. Izno (talk) 00:32, 22 December 2021 (UTC)

@Izno for context, I was showing her a screenshot of my interface, where I have a many-years-old user-CSS rule that moves those links back to the right. (Stored on github so that I can easily toggle them on/off, and use on non-SUL wikis). –Quiddity (talk) 20:46, 22 December 2021 (UTC)

Oh, so you're just old then. Got it ;) Izno (talk) 23:03, 22 December 2021 (UTC)

...been-there-done-that several years ago when edit links...

@Izno, are you able to share a link(s) to the discussion(s) you were referring to above? I'm curious to learn more about what considerations / use cases came up in these conversations that could inform how we approach the Topic Container design. PPelberg (WMF) (talk) 02:06, 23 December 2021 (UTC)

PPelberg (WMF), yes, this was a deliberate design change in 2013. Following the trail in order from where I guessed where to look, English VPT when it happened, then wiki-friendly documentation at meta, then the implementing task and then meta research. I think there's a few links between the set of those you can chase further, as well as more than a few remaining technical contributors interspersed you can ask. Izno (talk) 04:55, 23 December 2021 (UTC)

Oh, wonderful – I value you spending the effort to retrace your steps and share these links with us, @Izno. PPelberg (WMF) (talk) 02:14, 24 December 2021 (UTC)

On desktop, I definitely don’t like the third version—we have plenty of place, why hide important links like subscribe and edit in a dropdown menu? (This is very controversial in new Vector as well.) On mobile, it’s more acceptable; actually it’s the one that I like the most in its current form. In the first mobile version, the subscribe link is really out of space—especially because of the vertical line, but even without that, I think nothing should be above the section title, only next to it and below it. In the second mobile version, I think the positions of the four icons are confusing: there are three icons below the title, of which two are metadata (I suppose they aren’t clickable/tappable) and one an action button; of the two action buttons, one is next to the title, and one below it. By the way, the copy link is only in two desktop versions and one mobile version, it’s missing from the other three versions, is that intentional? —Tacsipacsi (talk) 23:18, 21 December 2021 (UTC)

I agree with we have plenty of [space] in this context. Izno (talk) 00:37, 22 December 2021 (UTC)

@Tacsipacsi, if automatic subscriptions are deployed for everyone, and if people mostly use the [reply] tool instead of the section's [edit] button, then do you think the [subscribe] and [edit] buttons will be used very often? If they're not commonly used, then they might not be the most important links any longer. Whatamidoing (WMF) (talk) 19:09, 22 December 2021 (UTC)

@Whatamidoing (WMF): The different discussion tools are supposed to be independent in the sense that one can select how many or few of them one wants to use. If one wants to have the usability improvements but not the reply tool and/or automatic topic subscriptions, these links become part of the everyday workflow (at least the edit link for sure: if one opts out not only from automatic but also manual topic subscriptions—or is logged out—, the subscribe links shouldn’t appear at all, not even in a dropdown). Logged-out users can’t even actually opt out from the reply tool, only opt not to use it, so “put it in the dropdown if the reply tool is on” is neither a good criterion. —Tacsipacsi (talk) 21:24, 22 December 2021 (UTC)

Thanks. Coming from enwiki, whose long-time editors are not generally design enthusiasts, I have trouble imagining someone who would turn on the usability/appearance changes, but turn off everything else. I expect the most common variation will be the opposite. I appreciate you mentioning the hassle this could cause for logged-out users, who can't opt in or out of anything. Whatamidoing (WMF) (talk) 21:00, 4 January 2022 (UTC)

I honestly don't want automatic subscriptions, so I think there should be a way both to turn off auto subs and subsequently subscribe to threads. Izno (talk) 23:04, 22 December 2021 (UTC)

And I still use the edit button, though I wish I didn't need to, to correct people's bullets; there will be some subset of users who reject the coming interface. Izno (talk) 23:04, 22 December 2021 (UTC)

I have auto subs on in both my accounts, though it didn't seem to be working for me (in Firefox/volunteer account). I love auto subs for work-me, but I haven't made up my mind for volunteer-me. Whatamidoing (WMF) (talk) 21:01, 4 January 2022 (UTC)

@Tacsipacsi: the feedback you shared is clear and helpful – thank you. I've added it to T296119 where we are gathering the feedback people share and will determine what – if any – next steps we will take in response.

Are you able to read T296119#7586926 and comment here or in the ticket if you see anything missing or unexpected in the way I've interpreted what you've shared above? PPelberg (WMF) (talk) 02:51, 23 December 2021 (UTC)

@PPelberg (WMF): Thanks for summarizing it! It’s mostly what was in my mind, except for issue #3, where I think it wouldn’t be unclear for me what the “Subscribe” affordance does—I wouldn’t even interpret it as an “affordance”, but as a simple link at the end of the previous section (in case I’d notice it at all, since I don’t necessarily concentrate on the previous section). (By the way, you don’t need to use interwiki links to link to Commons files: file:Topic_Container_Design_Concepts.jpg links to the same description page, just on mediawiki.org.) —Tacsipacsi (talk) 23:00, 23 December 2021 (UTC)

I wouldn’t even interpret it as an “affordance”, but as a simple link at the end of the previous section (in case I’d notice it at all, since I don’t necessarily concentrate on the previous section).

Ah, I see – I appreciate you clarifying, @Tacsipacsi. I've updated the Phabricator ticket to reflect what you clarified above. See: T296119#7589037.

Thanks for summarizing it!

You're welcome ^ _ ^

(By the way, you don’t need to use interwiki links to link to Commons files...

Ah, okay. Thank you for the tip. PPelberg (WMF) (talk) 02:12, 24 December 2021 (UTC)

the copy link is only in two desktop versions and one mobile version, it’s missing from the other three versions, is that intentional?

Good spot; I'm glad you thought to ask this.

Affordances for copying the link to a discussion being present in some of the design approaches ( Exploration 1 (desktop), Exploration 3 (desktop), and Exploration 3 (mobile) and being absent in others ( Exploration 1 (mobile)), Exploration 2 (desktop + mobile) is not intentional.

We will fix this inconsistency, and the sizing issue @Whatamidoing (WMF) mentioned above, in another iteration of the Topic Container Design Concepts. PPelberg (WMF) (talk) 03:07, 23 December 2021 (UTC)

I'm pinging some people to this thread who I think would be interested in and have insightful feedback to share^[1] about the new talk page section heading design concepts the Editing Team is exploring.

If you can think of other people who might be interested in discussing how talk pages' appearance could evolve, we would value you inviting them to participate in this discussion.

@Aza24, @BillyJSimsIII, @Dyolf77 (WMF), @Evolution and evolvability^[3], @He7d3r, @Guy Macon, @Klein Muçi, @Izno, @Mar(c), @Mathglot, @Nick Moyes, @Jncwtopac, @Partywiki, @Pelagic, @ProcrastinatingReader, @Samat, @Skkb, @TheDJ, @Quisqualis @Wladek92, @Wedhro, @Wakelamp

---

i. The list above is by no means exhaustive. Many of the people I pinged above have expressed an interested in talk page design in the past. E.g. en:Thinking about a radical reduction of talk page banners, mw:Topic:Vvk381a12bxqsxxw, T249579: Make the actions, activity and content within talk pages easier to understand, Talk pages project/Participate PPelberg (WMF) (talk) 00:10, 22 December 2021 (UTC)

Is it too late to give feedback about it? If not, when is the deadline? J. N. Squire (talk) 21:50, 5 February 2022 (UTC)

@J. N. Squire, it is definitely not too late. They're going to start the initial work soon (next week?), so sooner is better than later. However, there is no set deadline. Whatamidoing (WMF) (talk) 04:51, 7 February 2022 (UTC)

Quick question: I don't see a subscribe link as shown in the "current experience" example. I tried this logged in and not logged in. Why am I seeing something different?

Related: did someone add a way to watch a talk page section instead of the entire talk page and associated page (the "add this page to your watchlist" star in the tabs, right next to "view history")?

Also, all of the alternatives to the "current experience" example have a bolder font. Has the decision been made to change the font? I don't personally care either way, but some folks might want to discuss the change. Guy Macon (talk) 02:43, 22 December 2021 (UTC)

Guy Macon (talk) 02:43, 22 December 2021 (UTC)

Topic subscriptions is also part of the talk pages project and is currently a beta feature. You may have to enable the DiscussionTools beta feature in Preferences / Beta features and then enable topic subscriptions in Preferences / Editing / Discussion pages to see the [subscribe] links. —Tacsipacsi (talk) 14:20, 22 December 2021 (UTC)

@PPelberg (WMF), I wonder if we could set the Beta Feature default-on for this wiki. As we get into this project, in particular, it would be really nice if people using this page could automatically see the current state on this page.

@Guy Macon, if you click on https://www.mediawiki.org/w/index.php?title=Talk:Talk_pages_project/Usability&dtenable=1 then it should reload this page with the current version of the Beta Feature (but with auto-subscribe still turned off, I believe. You'd still need to go to Special:Preferences#mw-prefsection-editing-discussion to enable that.) Whatamidoing (WMF) (talk) 19:28, 22 December 2021 (UTC)

The above steps turned on the subscribe link. Thanks! May I assume that if this feature leaves beta I will see my subscriptions on my watch list instead of at Special:TopicSubscriptions?

I see a potential problem with topic subscriptions. Certain annoying users create a new topic for every reply they post to a thread in an attempt to make the pearls of wisdom that drip from their typing fingers more prominent in the table of contents.   :(   This means I won't see part of the discussion if I subscribe to the topic.

Even experienced veteran users sometime write things like this:[3]

"Start a new topic" on this talk page

Name this new topic: "Topic Container Design Feedback: YOUR USERNAME"

This means that is anyone follows those directions, I won't see part of the discussion if I subscribe to the topic.   :o   --Guy Macon (talk) 03:18, 23 December 2021 (UTC)

Topic subscriptions use Special:Notifications, not the watchlist. There is a technical reason for this, but my eyes glazed over when the devs tried to explain it to me. What I recall amounts of it being easy to do this in Echo/Notifications but very extra extremely time-consuming to do this in watchlist. They're not saying that it's actually impossible, just that it's out of scope for this project, and unlikely to be prioritized in the future.

Topic subscriptions apply to any ==Level 2 section== that begins with a (machine-recognizable) signed comment. Subscribing to existing topics does not get you notified about the creation of other/future topics on the same page. Use your watchlist for that. Whatamidoing (WMF) (talk) 21:07, 4 January 2022 (UTC)

Getting back to the question asked, I don't think we should use a Kebob menu.[4] or any other kind of Mystery Meat Navigation. Also see [5].

Also, I have seen multiple sites that use the bell icon or the person icon, and they all assign slightly different meanings to them. And I have no idea what that icon to the left of the person icon is. ---Guy Macon (talk) 03:18, 23 December 2021 (UTC)

@Guy Macon, I appreciate you stopping by to review the concepts! Responses and a couple of follow up questions to the feedback you've shared^{[1] [2] [3]} below...

...all of the alternatives to the "current experience" example have a bolder font. Has the decision been made to change the font? I don't personally care either way, but some folks might want to discuss the change.

Good question. The decisions has not yet been made to change the font. Tho, we are curious to know what people think of this potential. With this in mind, can you think of a place where we ought to consider posting this call for feedback to increase the likelihood the people you alluded to above might see?

And I have no idea what that icon to the left of the person icon is.

It's helpful to know you did not find the meaning/function of the bell icon to be obvious. If you were to make a guess, what do you think the bell icon means/does? Note: in the meantime, I've added this feedback to T296119. PPelberg (WMF) (talk) 02:33, 24 December 2021 (UTC)

Many people on the English Wikipedia don't read mediawiki.org. An announcement on the village pump that uses Template:Centralized discussion would reach a lot of them.

The bell icon is to the right of the person icon. I have no idea what that icon to the left of the person icon is. The most visible use of the bell Icon is on youtube, where it means "notify me" (with no explanation as to how that differs from the subscribe button, which also notifies you when a channel posts a new video). The person icon is used on a lot of sites where you log in, and brings up your profile, where you can change credit card info, password, email address, profile picture, etc. Discussion groups sometimes use the person icon as the default of you don't upload a profile avatar/picture. I have never seen whatever that thing on the left is.

Again, there are a lot of places that discuss Hamburger icons, Kebob icons, Bento icons, Meatball icons, Döner icons, etc. Anyone can get used to anything, but many new users find them confusing, and users of touch-based mobile devices with no mice or pointers won't see any hover text explaining them. --Guy Macon (talk) 06:24, 24 December 2021 (UTC)

The icon that looks a little bit like  ? I believe it counts the number of comments in that ==Section==. Whatamidoing (WMF) (talk) 21:12, 4 January 2022 (UTC)

• They're all an improvement over the current one. I think the date of last comment (in #1) is useful. The other two are presumably number of comments and number of unique users, which I think are useful as well. I don't like the info presented on a newline, as in #3, it looks strange to me. I don't know how you're meant to edit in #2 (unlike the other explorations, it seems to be missing an edit button or icon on desktop?). The collapsing functionality is nice, and ideally should apply to h3/h4 levels too to be honest (helps filter through bludgeoning and hopeless sections, particularly on mobile devices). My overall preference would be something incorporating concepts from both #1 and #2. ProcrastinatingReader (talk) 02:26, 11 January 2022 (UTC)

  @ProcrastinatingReader – we appreciate you taking the time to review the design concepts and being patient as it's taken me some time to respond back here. A comment and follow up question about what you shared below...

  I think the date of last comment (in #1) is useful. The other two are presumably number of comments and number of unique users, which I think are useful as well.

  Question: can you share what you imagine being useful about the information/metadata you described above? I have sense for the answer to this question, tho I'm curious to hear how you describe it...

  I don't like the info presented on a newline, as in #3, it looks strange to me.

  Noted. "Looking strange" is a valid response! Tho, if/when you think of ways in which the metadata being presented beneaththe section title could prevent you from doing something you're used to or make itm ore difficult, I would value you sharing this. PPelberg (WMF) (talk) 19:05, 11 February 2022 (UTC)

Topic Container Design Feedback: Klein Muçi

So, to give a hopefully very "first-reaction" like review, I'm deviating a bit from the 3 suggested questions (even though I'll try to answer them all).

My knee-jerk reaction when I first saw the mockups (the picture is a bit hard to navigate) was: Why are we doing this? The edit and subscribe links were already there more or less, only the "copy link" button was a new thing from the buttons. The informative icons was what really looked like the heart of the change and after having to think a bit about what the first icon might represent, I understood that it must be comments (since the other icon looked like it represented commenters). Then I read the explanation usability project carefully and fully understood what I was supposed to be seeing. A part of me imagines typical discussions at EnWiki and it's not sure how much knowing the metadata would be helpful per se. We're talking about environments where discussions sometimes flow in a chat-like conversation manner, especially where there are debates going on, and in those types of environments the number of comments or commenters doesn't feel like too much helpful. I feel like old discussions may benefit more from this feature but even then, auto-archiving processes might interfere. Or, if we consider user talk page discussions, (if we remove talk page stalkers) again, discussions rarely have a need for comment/er metrics because usually there are only 2 people involved.

BUT having said all that, I do understand that the real purpose of this is to make talk pages more recognizable as talk pages and these details help a lot in that direction by also providing more data in the meanwhile which can prove helpful in a lot of other cases beside what I said above. My desktop favorite exploration wasn't in the mockups' list I believe. I'd like to have the edit and subscribe link close to each other (same or different style doesn't matter much), have the copy link on the same line but maybe a bit further (what exactly happens when you click it? maybe it can be "collapsed" into an icon instead of "copy link"?) and have the metadata on the line right below it (does anything happen when you click/hover on them?). For mobile, my favorite is exploration 1.

As for new ideas, I believe we should really put as much effort as we can to the reply/editing mechanism. Find ways to edit past replies without having to edit the entire discussion (opening the code for the whole conversation just to fix a typo feels like a nightmare) make it more reliable on multi commenters/levels conversations (the reply tool starts breaking down if you want to use different indentations for different replies to different participating users in the same discussion - radical idea: maybe we should start utilizing colors?) and give it limits to indentation (so it starts outdenting after the limit is reached instead of having to do that manually). We should try creating a discussion environment that's fully handled by the interface, without needing in any case to access the source code for it. - Klein Muçi (talk) 01:16, 22 December 2021 (UTC)

What a thorough review, @Klein Muçi – thank you! I'm going to respond to what you've shared in two comments: the first comment (read: this one) will be a response to the feedback you shared about the Topic Container Concepts and the second comment will be a response to the "new ideas" you shared.

...after having to think a bit about what the first icon might represent, I understood that it must be comments (since the other icon looked like it represented commenters).

That's accurate. The first icon represents the number of comments and the second, the number of commenters. Note: I've added a reminder to T296119 for us to explore how intuitive others find the meaning of those two icons.

...especially where there are debates going on, and in those types of environments the number of comments or commenters doesn't feel like too much helpful.

Interesting...can you please say more here? What kind of information would you imagine being helpful to know about debate-style discussions?

I feel like old discussions may benefit more from this feature but even then, auto-archiving processes might interfere.

Would it be accurate for us to understand the above as meaning something like the following? "Being able to see information like the number of people who have commented in a discussion, the number of comments in the discussion, and the last time a new comment was posted might be helpful to people deciding whether to archive a discussion, but that use case seams uncommon at Wikimedia wikis considering how often the work of archiving is done by bots."

...these details help a lot in that direction by also providing more data in the meanwhile which can prove helpful in a lot of other cases beside what I said above.

I appreciate you sharing this; it's helpful to know that, at a minimum, you see these design concepts as being effective at helping people who are new recognize talk pages as containing discussions.

My desktop favorite exploration wasn't in the mockups' list I believe. I'd like to have the edit and subscribe link close to each other (same or different style doesn't matter much), have the copy link on the same line but maybe a bit further (what exactly happens when you click it? maybe it can be "collapsed" into an icon instead of "copy link"?) and have the metadata on the line right below it (does anything happen when you click/hover on them?).

This detail is great! Before responding to the questions you posed, can you share what's leading you to suggest the above? Asked another way: why would you value the edit and subscribe links close to one another?

Now, to the questions you posed...

We've been thinking that clicking on "copy link" would: A) highlight the comment and B) automatically add the link to said comment to your device's clipboard. You can actually experiment with this functionality right now. Although, I should note, it is not likely the "copy link" functionality will be included in the first version because it depends on some larger infrastructure changes.

We have not yet specified what will happen when people click/hover on the metadata. This leads me to wonder: what would you expect to happen if you were to click/hover over the metadata? PPelberg (WMF) (talk) 03:07, 24 December 2021 (UTC)

...we should really put as much effort as we can to the reply/editing mechanism. Find ways to edit past replies without having to edit the entire discussion (opening the code for the whole conversation just to fix a typo feels like a nightmare)

It's helpful to know the value you see in having the ability to edit specific comments without opening the full-page source editor. While we have not yet prioritized work to implement this functionality, we will post a comment to T245225 when we do.

...make it more reliable on multi commenters/levels conversations (the reply tool starts breaking down if you want to use different indentations for different replies to different participating users in the same discussion...

Are you able to describe this issue in a bit more detail so that we can try to reproduce the experience you are describing?

...radical idea: maybe we should start utilizing colors?

Colors...interesting. What for? To help people more easily understand how comments within a discussion relate to one another? Something else? PPelberg (WMF) (talk) 03:16, 24 December 2021 (UTC)

@PPelberg (WMF), as is the tradition, I'll respond with bullet points to hopefully make the following discussion more concise:

• I'm not sure why but I found the commenters icon more intuitive than the other one. Maybe because the message bubbles are not easily recognizable as such, my mind went into a process like "oh, squares...inside other squares...with a human... what?". :P
• What would be interesting to know in debate style comments: Main points, pros and cons. Summaries. Maybe some considered-good comments standing aside. This is rather tricky to achieve automatically. Facebook has created algorithms that automatically set some comments and replies aside (while collapsing others) which are deemed to be of a bigger importance in regard to the discussion (I don't know if the chosen comments change per user viewing them, which could be, because Facebook is well-known to provide user-preferences tailored experiences). I don't know but I suppose such weighing in of comments is achieved by likes and replies the comments get. Reddit has implemented the upvote/downvote system for the same reason and I believe YouTube does something similar. We already do something like that manually when we create the Support/Oppose/Neutral subsections or with the summary feature here in MediaWiki. I'm not sure if even the largest threads of EnWiki though are that large as to be compared with the typical Facebook/Reddit/YouTube environments which means those mechanism I described maybe are not what we exactly need but they can provide food for thought.
• No, it's not related to archival benefits. The benefit it's related to participation. You see an old discussion, that is, supposedly, a rather long thread, about a topic which interests you and you want to participate in it. But before you participate in it, you usually skim through it to get some needed information:

1. How many people are involved in the conversation? The more there are, the more can keep joining it. (For example: if it is a "personal" conversation between 2 people there is a barrier that must be broken for that to grow to 3, because of socio-ethics.) If it is a large conversation between 2 people, some may be disappointed and be like, "oh, never mind, it's not really a big discussion which may have practical repercussions in the near future, I won't join for now".
2. When was the last comment done? For different reasons, people generally don't want to be joining conversations that have ended long time ago and that helps with that. If for some reason they feel like they want to participate even though they see that quite some time has passed, that information helps in deciding if they should mention (@Someone) the other users or not (the logic being that they should if a lot of time has passed).
3. The number of comments it's just a nice added information to have.

But all what I said above doesn't really apply to Wiki World because of auto-archiving processes that are involved. If you see something there it's almost sure that it's happening now, it's not stale and that the users involved will more or less see your answer no matter if you mention them or not.

• I would like to strongly emphasize though that I'm not against adding the metadata. What I wrote there were just my "instinctual thoughts". I'd love to have them and I do believe that the more information that we have about a discussion, the better it is. I see no downsides whatsoever in having them.
• I believe editing and subscribing to a discussion form the basis of a conversation. You want to talk (type) [edit] and you want to listen (read) [subscribe]. Copying the link is rather a "side dish" functionality to the conversation itself so I'd prefer it set aside. I tried the copy link gadget and I must say that I'm surprised: It worked exactly as I expected it to work only that it provided the link for the specific comment! Is that what the "copy link" "button" in the mockups is supposed to do? I thought it would provide a link for the discussion section. (I was about to ask if it would be a link or a permanent link.) Can't really think of something that I'd expect to happen when hovering or clicking on them. I don't believe there is anymore detailed info to add that can be accessible after clicking/hovering, they look exhaustive on their own. (Maybe the last comment icon can jump you to the last comment as a hidden function but I'm not sure...)
• Considering the copy link gadget that you pointed me at, can't that functionality be "extended" (I do understand that what I'll propose it's completely a different thing tech-wise) to make way for editing specific comments? It would still open the entire section but somehow point you to the comment you wanted to edit. That would still mean working with source code but it would be better than nothing.
• Multi-indentation in multi-user conversations: Conversation has 2 users, A and B. They comment back and forth and the indentation grows with 1 level at each comment. Suddenly a third user comes (user C) and says something specific (a kind of side-request) to user B. This also makes the indentation level grow +1. However that has created a subthread which should be able to be followed on its own. User B comes and answers to User C indenting +1 and continues answering to user A on the indentation level they had left their thread before user C intervened. User B and C are using source code while user A is using the reply tool. User A continues the conversation on the "mainthread" with user B and eventually wants to say something to user C which has continued talking with User B on its own subthread with their own indentation levels. User A goes to the last comment in that subthread and presses "Reply to User C" with the tool. The tool doesn't understand subthreads at all. Not only it doesn't follow the level of indentation but won't post a comment in what it thinks it is "the middle of the conversation" and automatically adds the new comment in the end of "the main thread". When I go to comments which are above the last comment and press reply, I expect my comment to be put right there with the correct indentation level, not as "a last comment". So the request can be reworded to be: Make the reply tool understand subthreads. This of course brings the question: Should we allow subthreads to be created in a discussion or no? Maybe they can be considered confusing and we must set rules that new comments should always be put after the last one but I was surprised some days ago when I was part of the situation I just described and the tool insisted on putting my comment past the last one, no matter which comment I chose to reply above. Why does it even give the option to reply to old comments then? The idea of subthreads also correlates with the colors idea. Maybe when hovered, a comment can highlight in a color to which comment is "an answer to". Maybe only 1 color is needed altogether. But subthreads (that name on Reddit, reply levels on Facebook) are usually an inevitable component of conversations and with the current infrastructure, if they're allowed to exist, they are bound to get confusing and accidentally merged when the indentation levels with different subthreads or the mainthread start pairing up. That's where other mechanisms should be thought and my first thought was colors, if not other graphical elements.
• While functionalities like editing comments and treating subthreads may be "things of the future", can we implement automatic outdentation? I've always thought that would be part of the tool itself because there would be no reason why not to be but apparently it just goes on forever adding +1 indentation levels with every added comment. - Klein Muçi (talk) 13:44, 24 December 2021 (UTC)

But all what I said above doesn't really apply to Wiki World because of auto-archiving processes that are involved. If you see something there it's almost sure that it's happening now, it's not stale and that the users involved will more or less see your answer no matter if you mention them or not – this may be true for enwiki’s village pumps, but smaller wikis often don’t have archive bots, so no automatic archival takes place at all. Even on larger wikis, I’m pretty sure most talk pages are not auto-archived, only the fairly busy ones. On an article talk page, it may happen that only six topics were created since the article was started 20 years ago, but one of them, which was started 15 years ago, contains dozens of comments from several users. So this can well be helpful on Wikimedia wikis as well. —Tacsipacsi (talk) 14:46, 24 December 2021 (UTC)

@Tacsipacsi, you're probably right. In my homewiki we've activated autoarchiving for ALL talk pages as soon as some criteria is met. I also rarely deal with articles myself, mostly working with technical aspects so my viewpoint may be biased in that point because of those 2 reasons. - Klein Muçi (talk) 13:59, 25 December 2021 (UTC)

@PPelberg (WMF), check the current situation in this conversation with the added comment by user Tacsipacsi. This is a typical mainthread/subthread situation I described above. - Klein Muçi (talk) 14:01, 25 December 2021 (UTC)

I had to manually change the indentation with this edit so we could keep the integrity of the threads. This is where the tool breaks down. And where, if I'd want to continue talking with Tacsipacsi on its own subthread level with the tool I wouldn't be able to do so. Now if we imagine multi subthread levels, that's where things get really heavy and graphical help may be needed. - Klein Muçi (talk) 14:06, 25 December 2021 (UTC)

@Klein Muçi, as you can see in this reply, it is usually possible to get the alignment that you want. In this case, instead of clicking the [reply] button for the most recent comment, I went up to your 13:44, 24 December 2021 comment, and clicked the [reply] button there.

Making it easy to adjust the level is phab:T265750. Whatamidoing (WMF) (talk) 21:39, 4 January 2022 (UTC)

@Whatamidoing (WMF), glad to hear that outdenting is being worked on. In regard to the thread's subject, did you choose to put your reply in the end of the discussion or was it an "accident"? Can you put your answer above a certain comment if you so wish? That's also part of what I meant when I was talking about thread's integrity. - Klein Muçi (talk) 22:08, 4 January 2022 (UTC)

I chose to put that comment at the end. You can use any [reply] button in the discussion, and it will reply in the first (computer-)logical location for the list structure. On desktop, it shows you (approximately) where the comment will end up. On mobile, there's no left–right change (imagine the box trying to get narrow enough for a ::::::::long discussion, but still be wide enough to type your message, when the whole screen is only 10 cm wide), but it should show you the vertical placement. Whatamidoing (WMF) (talk) 00:14, 5 January 2022 (UTC)

@Whatamidoing (WMF), I can swear that I wasn't able to do what you are describing to be possible some days ago which made me describe all that situation above. I tried replying in my talk page to an "old comment" in LaWiki and it automatically put the reply box in the end following the indentation level of the comment before it. Tried that 2-3 times until I gave up and went to the source text editor to put my reply. Maybe it was a momentarily glitch then... - Klein Muçi (talk) 01:28, 5 January 2022 (UTC)

@Whatamidoing (WMF), but... I can't do it even now... I pressed [reply] on your comment on 21:39, 4 January 2022 (UTC) and the reply box still comes in the end of the conversation. How can I put a comment right after it? - Klein Muçi (talk) 01:31, 5 January 2022 (UTC)

You can usually get the left–right alignment by choosing the correct comment to reply to.

For up–down locations, placement opportunities are more restricted. It will always try to put the latest comment as the last item in a "branch". In this case, "last" is defined by the tree-like structure of the "lists" that editors use to visually indent their comments. At the moment, everything under the 21:39 comment belongs to the same "branch" and thus will end up at the bottom of the branch. If you reply to your 14:01 or your 14:06 comment right above, it will place your new comment as last in that branch (just above the 21:39 comment). You will have to use your regular wikitext editor if you want to go "out of order". Whatamidoing (WMF) (talk) 02:09, 5 January 2022 (UTC)

@Whatamidoing (WMF), hmm... I see... I'm not sure how I feel about this. It looks like the tool does understand multithreads but... I don't know, it feels restrictive. Then again, maybe that's for the better in the bigger picture. Any idea why this method was chosen instead of just creating a +1 indentation level reply straight after the chosen comment? I suppose it's for better overall order, no? - Klein Muçi (talk) 02:34, 5 January 2022 (UTC)

Also... Is all this explained somewhere plainly? I was particularly interested in the multithread topic and yet I needed your explicit explanation to understand it. A large number of users may just treat it (read: clicking [reply] and getting the editing box "somewhere else") as a bug if they encounter that situation. - Klein Muçi (talk) 02:48, 5 January 2022 (UTC)

I've talked this through with a couple of people, but I haven't written a central/help page about it. Imagine a conversation with five comments (in chronological order: 1, 2, 3, 4, 5). Comment 4 will be a reply to comment 1, to start a new branch. Comment 5 will reply to 4.

Here's what you get now:

One (the original comment).

:Two (the first reply).

::Three.

:Four (the new branch).

::Five (the last comment).

Here's what "just creating a +1 indentation level reply straight after the chosen comment" would be:

One (the original comment).

:Four (the last comment).

::Five (the last comment).

:Two (the first reply).

::Three.

I suspect that's not what you really want. Whatamidoing (WMF) (talk) 21:08, 7 January 2022 (UTC)

@Whatamidoing (WMF) yes, I know what you mean. Thanks for the detailed example! To be honest, I've seen conversations evolve also in that manner (second example) and maybe in short ones that could be a desirable effect. (?) When conversations start having complex multithread levels though I believe our choices can't do much in helping with the awaiting chaos, whatever those choices are. That's what I was referring with this part above:

... But subthreads (that name on Reddit, reply levels on Facebook) are usually an inevitable component of conversations and with the current infrastructure, if they're allowed to exist, they are bound to get confusing and accidentally merged when the indentation levels with different subthreads or the mainthread start pairing up. That's where other mechanisms should be thought and my first thought was colors, if not other graphical elements. ...

Sure, subsections may help but that requires retroactively editing the conversation many times to create the needed divisions and not let the threads get too much convoluted. If we want to be able to have the conversations evolve without needing active moderation and especially without accessing the source code, I believe we need better tools to preserve threads' integrity. But maybe until then, the current choice is the best we have... - Klein Muçi (talk) 00:15, 8 January 2022 (UTC)

I think that we will always want multiple options. I think we're going to want chronological order more often than other orders, but imagine, e.g., someone asking a not-quite-so-innocent question. Even if the discussion is still relatively long, someone might want to jump in at the very beginning to post something like "See also the previous four times he's already asked this question here, here, here, and here". (But maybe that's just me, and everyone else is nicer than that? ;-) ) Whatamidoing (WMF) (talk) 02:24, 8 January 2022 (UTC)

@Whatamidoing (WMF), hmm.... Well then, going too far into speculation now but how about automatic thread highlighting + dropdown menu that gives you "moderator options" like "add comment at top", "create subsection", etc. ? Reconceptualizating some already established VE elements as parts of the reply tool specifically dedicated to discussions and talk pages?

Take everything I just wrote with a grain of salt. I just went into brainstorming after your last comment. - Klein Muçi (talk) 02:40, 8 January 2022 (UTC)

I don't remember hearing the team talk about making a ===New subsection===. That's another for the list... Whatamidoing (WMF) (talk) 17:25, 19 January 2022 (UTC)

@Whatamidoing (WMF), speaking of creating a new subsection, what about starting a conversation in an existing subsection? In many cases you'll have a certain specific section titled "Discussion", below an often explanatory section, dedicated to, well, discussion. But you can't really start a discussion there using the reply tool. You can only reply to others if someone has already started it, or you'll be forced to use the source code editor. I just had to do precisely that on a subsection in the Community Wishlist here. - Klein Muçi (talk) 00:37, 20 January 2022 (UTC)

Yes, you're right. The [reply] tool requires a pre-existing comment where you want your comment to end up. Whatamidoing (WMF) (talk) 18:26, 21 January 2022 (UTC)

@Whatamidoing (WMF) If we start progressing towards the subsection idea, it wouldn't be bad progressing from "reply tool" to "discussion tool". Creating and working with new sections (even new talk pages themselves) is already pretty "visual", only subsections require you to go to the "source direction" now. - Klein Muçi (talk) 22:38, 21 January 2022 (UTC)

Mobile mock ups

We've got some updated images, as animated gifs, so I'm pinging the previous folks (@Wedrho, Klein Muçi, Tacsipacsi, ProcrastinatingReader, Guy Macon, Izno – feel free to ping others) to take a closer look.

This one is called "Mobile Full". It provides more information and takes up more space on the page:

This second one is called "Mobile Limited". It provides less information, and doesn't take up as much space on the page:

It's the usual question: What's good, what's bad, which do you think will work best? Whatamidoing (WMF) (talk) 20:20, 1 February 2022 (UTC)

I vote for the first option. It looks good as it is, don't really have any bad comments in regard to it. - Klein Muçi (talk) 22:38, 1 February 2022 (UTC)

The second option is better. How many people contributed and how many edits there are in a section is not important. Snævar (talk) 16:39, 25 April 2022 (UTC)

Stop using brackets for buttons

Using brackets to signify buttons like the [ reply ] and [ edit source ] buttons is ugly. We should use quiet or default OOUI buttons with icons instead. Lectrician1 (talk) 18:45, 2 February 2022 (UTC)

@Lectrician1, do you think that the "edit source" buttons on the talk page should match the "edit source" buttons in the articles? Whatamidoing (WMF) (talk) 04:53, 7 February 2022 (UTC)

Kind of? I don't want the blue gradient thing though. That's also ugly.

I specifically want this with an edit icon. It should also probably be right-aligned to the left of the subscribe button.

The subscribe button should look like this with a bell icon. The reply button should also be a blue progressive button. Lectrician1 (talk) 11:02, 7 February 2022 (UTC)

What we have now for the ==Section heading== looks a bit like this:

 

Heading 2   [ edit source ]                                          [ subscribe ]

Hello. User:Example (talk) 12:00, 7 February 2022 UTC [ reply ]

    Hello to you, @Example. User:User (talk) 13:00, 7 February 2022 UTC [ reply ]

 

(only with the [subscribe] button all the way to the side).

Do you want it to look more like this?

 

Heading 2                                      Edit source Subscribe

Hello. User:Example (talk) 12:00, 7 February 2022 UTC reply

    Hello to you, @Example. User:User (talk) 13:00, 7 February 2022 UTC reply

 

Is that approximately the idea you have, @Lectrician1? Whatamidoing (WMF) (talk) 21:41, 7 February 2022 (UTC)

Yes, but I think the edit source button should be normal (black) and the subscribe button progressive (blue) because subscribing is often done much more than source editing.

I personally think the reply button is a bit too big and should maybe be a quiet button (without the background) like the current edit source button is. Or, if that also is too big, maybe just use an individual icon like speechBubbleAdd or redo? Lectrician1 (talk) 22:57, 7 February 2022 (UTC)

If you'd like to try out an icon for a while, then this message at the English Wikipedia has information about a userscript that will let you change the existing label to any thing you would like. Whatamidoing (WMF) (talk) 01:33, 9 February 2022 (UTC)

Topic Container Design Feedback: Lectrician1

For topic containers, I prefer Exploration 2A the best because it shows all of the header functionality. I don't like it being hidden in a "more options menu" since the link, subscribing, and editing are all important features. They should only be collapsed when there is not enough horizontal width to accommodate them.

I think the Subscribe button in 2A should have the icon and the label and not just the Icon.

I think the dropdown menu should use the OOUI dropdown instead of what is shown in the model. Lectrician1 (talk) 18:51, 2 February 2022 (UTC)

@Lectrician1, on a talk page with multiple discussions, would you rather see them all collapsed or all un-collapsed initially? Whatamidoing (WMF) (talk) 04:55, 7 February 2022 (UTC)

@Whatamidoing (WMF) I would like to see them collapsed but show about 5 lines or less of the initial message of the topic with the rest hidden.

Typically you cannot infer the intentions of a writer of a topic just from the title itself but you can from the first few lines. You don't want to show the entire first message because some can be very long. Therefore, about 5 lines, for both mobile and desktop screen widths (even though it will be less content on mobile), should be sufficient at conveying to readers what a topic is about while maintaining an efficient use of space.

Having the ability to adjust the number of preview lines shown, and whether to hide the rest of the initial message or show it at all (collapsed), should be adjustable in user preferences. Lectrician1 (talk) 10:56, 7 February 2022 (UTC)

@JKlein (WMF), have you considered a partially collapsed approach? Whatamidoing (WMF) (talk) 21:45, 7 February 2022 (UTC)

I should add here that one of the problems with collapsing anything is that it means ⌘ Command+F in-page searching doesn't work. Whatamidoing (WMF) (talk) 01:33, 9 February 2022 (UTC)

@Whatamidoing (WMF) Would it if you built a page-based finder that overrides the browser-based one? Lectrician1 (talk) 01:41, 9 February 2022 (UTC)

hi @Lectrician1 – a a questions about the feedback you shared above...

They should only be collapsed when there is not enough horizontal width to accommodate them.

Would it be accurate for me to understand the above as you saying that you think the actions associated with a discussion (e.g. editing it, subscribing to it, copying a link to it) should not be collapsed if there is room to accommodate them? Were you referring to the content of discussions themselves? Something else?

...I know that you and @Whatamidoing (WMF) have been talking more about collapsing the discussion sections themselves, tho I wanted to make sure I was accurately understanding the original feedback you shared. PPelberg (WMF) (talk) 19:41, 11 February 2022 (UTC)

Yes, I was referring to the action buttons. Actually, just disregard me saying what I did about them being collapsed. What I meant is that I didn't want "collapsed" like in the dropdown "more options" button in Exploration 3.

I would not like the section to be collapsed like in 2A and instead what I suggested above.

About the actions again, I actually like the "Last edit yesterday" label in Exploration 1 and I think the Subscribe button should have an icon and label so that users know what the bell does. Lectrician1 (talk) 20:50, 11 February 2022 (UTC)

Feedback: New talk page designs

Mockups are ready for the changes designed to make it easier for people to understand and use talk pages on desktop and mobile. We would value hearing what you all think.

Below is the information you will need to review the designs and share feedback about them.

• 
  Proposed design for mobile wikitext talk pages.
• 
  An annotated mockup showing the proposed design for mobile wikitext talk pages (landing page view).
• 
  An annotated mockup showing the proposed design for mobile wikitext talk pages (individual discussion view).
• 
  Proposed design for desktop wikitext talk pages.
• 
  An annotated mockup showing the proposed design for desktop wikitext talk pages.

PPelberg (WMF) (talk) 18:49, 22 April 2022 (UTC)

Reviewing the designs

The mockups in the gallery above show how wikitext talk pages, on desktop and mobile, are likely to appear to people who have the Usability Improvement setting enabled.

Sharing feedback

Once you have reviewed the designs and you are ready to share what you think of them, please add a new topic to this talk page by doing the following:

1. Click the "Add topic" button at the top of this page
2. Name this new topic: "Design Feedback: YOUR USERNAME"
3. Write your answers to these questions:
   1. What concerns do these designs bring to your mind?
   2. What questions do these designs bring to your mind?
   3. What do you wish was different about the designs?
   4. ✅ That's it!

The Editing Team is eager to hear what you think of the designs. PPelberg (WMF) (talk) 18:52, 22 April 2022 (UTC)

As an senior contributor, I look at each discussion once, see if other senior contributors have the issue covered and leave it alone if so. If not, I check if I can be of use, and ping others if they can give a better answer. Should the discussion lead to an consensus then I actively participate in it regardless of the criteria above. So, activity level is not important, it is more of an flowchart. I would not even use that information in an RFC.

As far as the design goes, it is really Flow-esque, and we all know how that ended. We use talk pages more like an forum than social sites. phpBB mobile design is fine, once you have ignored all the colors on the site, a cleaner look of that would be better. Information of what sections have not been responded to at all is important, but not the number of replies, e.g. anything above 1 comment is not important. By making sections, that have not been replied to, known to senior contributors we are reducing the risk of messages not being answered, and that is a good thing, especially for junior contributors. --Snævar (talk) 16:39, 25 April 2022 (UTC)

@Snævar, what kind of talk pages do you use the most (for example, article talk pages vs Teahouse vs noticeboards)? Whatamidoing (WMF) (talk) 04:23, 5 May 2022 (UTC)

Mostly article talk pages, secondly talk pages in other namespaces, and then noticeboards. Snævar (talk) 22:42, 6 May 2022 (UTC)

hi @Snævar – the feedback you shared is precisely the kind of input @Whatamidoing (WMF) and I are looking for. A couple of follow up questions/comments in response...

1. How do you currently go about deciding whether ...other senior contributors have the issue covered.?
2. Can you share what you think is leading you to describe the designs as "Flow-esque"? E.g. Are there specific aspects of the way these designs look that is leading you to see similarities to Flow? Do the similarities you're seeing between Flow and these designs have less to do with how the two experiences look and more to do with what you envision using both to be like? Something else? I know bringing language to these kinds of questions can be difficult; whatever you can share will be helpful!
3. Intuitively, I'd think that being able to easily see the number of people participating in a discussion and the number of comments that have been posted would be helpful to identifying ...what sections have not been responded to at all.... Tho, it sounds like the intuition I have is NOT accurate for you. Can you share a bit more here: why do you think being able to see the number of people participating in a discussion and the number of comments that have been posted within it would NOT help you know whether a topic has not yet received a response? PPelberg (WMF) (talk) 00:29, 7 May 2022 (UTC)

Prototype Ready

A prototype is ready for you all to try the talk page visual changes.

These changes are designed to make it easier for people to understand and use talk pages on desktop and mobile devices.

Below is the information you will need to:

• Try the prototype
• Share feedback about the prototype

Of course, if any questions emerge as you trying out the prototype, please add them here so that @Whatamidoing (WMF) and I can offer guidance. PPelberg (WMF) (talk) 23:22, 19 May 2022 (UTC)

I'm pinging some people who have offered valuable feedback and insight throughout the Talk pages project as way of inviting them to try the new prototype for the proposed new talk page design.

@Klein Muçi, @Izno, @Wakelamp, @Guy Macon, @Geraki, @Nick Moyes, @GhostInTheMachine, @Ottawahitech, @Lectrician1, @MichaelMaggs, @Tol, @Strainu, @Omotecho, @Valereee, @Matěj Suchánek, @LittleGun, @Pelagic, @RoySmith, @Evolution and evolvability, @Levivich, @আফতাবুজ্জামান, @Hgzh, @PerfektesChaos, @Patriccck, @Ad Huikeshoven, @MarcoAurelio. PPelberg (WMF) (talk) 23:58, 19 May 2022 (UTC)

Thanks for pinging me @PPelberg (WMF), but I find participating on this wiki way too cumbersome. If you want feedback from actual users you may consider the Village pump at WQ- https://en.wikiquote.org/wiki/Wikiquote:Village_pump

BTW I noticed I hve a preview box here but no edit summary? Ottawahitech (talk) 14:35, 20 May 2022 (UTC)

Try the Prototype

1. Visit this article talk page or this user talk page on the special prototype wiki.
2. Find the discussion that has been edited most recently.
3. Find the discussion that has the most people participating in it.
4. Find the discussion with the most comments.
5. Scroll back to the discussion you identified in "Step 4." Figure out how you would do the following:
   1. Post a reply in the discussion.
   2. Edit the reply you posted.
6. Next, start a discussion about a new topic.
7. ✅ You are now ready to share your feedback.

PPelberg (WMF) (talk) 23:31, 19 May 2022 (UTC)

Share Feedback

1. Start a new section on this talk page
2. Set the topic title to Feedback: YOUR USERNAME
3. Write answers to these questions:
   1. Did you use mobile device or a laptop to test the prototype?
   2. What did you find unexpected about the prototype?
   3. Which steps in the "Try the Prototype" section did you find difficult to complete?
   4. What do you like about the prototype?
   5. What do you wish was different about the prototype?
   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.
4. Click the blue "Add topic" button.
5. ✅ You are done! Thank you!

PPelberg (WMF) (talk) 23:31, 19 May 2022 (UTC)

Feedback: Klein Muçi

Following the steps to gather information was rather easy but the grayed out stats weren't the first thing that caught your eye, you had to look for them, and this made accomplishing those tasks a bit annoying. I'm not sure if users will need to accomplish the same set of tasks IRL, for example, to scan a full discussion page for stats such as number of commenters, which discussion had the most recent discussion, etc. so maybe it's alright; If they do have though, making them stand out a bit would be good but I'm not sure how exactly. Maybe by having a small grey line below them? Overall I was surprised by the design because it looked too "mobile-ish" (I was using a laptop). I'm not sure if that's a good thing or not but the blue reply link kinda created a small blue sea. Also maybe the arrow is excessive. The text and icons size when starting a new discussion seemed enormous. I did like the added information. When I read "Edit the reply you posted." I thought maybe we were finally able to edit certain comments but apparently that isn't possible yet. I tried the "old school" way with section editing and it worked out as normally. I was kinda hoping to have tooltips after hovering over the 3 stat icons or maybe even have them behave as buttons. My idea was that clicking the one for last comment would send you to the last comment, clicking the one for users/persons (what do we really want to use there?) would show their names wikilinked (up until 10 people, let's say) and clicking on the one related to the number of comments could maybe collapse and uncollapse the conversation, if that option would be possible. - Klein Muçi (talk) 00:32, 20 May 2022 (UTC)

I appreciate you trying out the prototype and sharing this feedback with us, @Klein Muçi. Responses / follow up questions for you below...

I'm not sure if that's a good thing or not but the blue reply link kinda created a small blue sea.

Assuming it's accurate for me to understand the above as meaning the new "Reply" buttons stood out to you more than before, a follow up question for you: did you find the "Reply" buttons being more prominent inhibited you? And if so, how?

The text and icons size when starting a new discussion seemed enormous.

Can you say more here? Are you referring to the blue Add topic button that appears in "sticky header" that appears at the top of the page when you scroll down? Something else?

I did like the added information.

By "added information" are you referring to the information (e.g. last comment, number of comments, etc.) that appears beneath each discussion's/section's title?

I was kinda hoping to have tooltips after hovering over the 3 stat icons or maybe even have them behave as buttons.

Interesting idea! If the stat icons were to behave as you described, can you share how you might use them? Asked another way: how can you imagine yourself benefiting from the stat icons behaving in the way you described? PPelberg (WMF) (talk) 00:47, 27 May 2022 (UTC)

1. Yes, it made reading the discussion harder because all your attention was gravitated towards the blue sea.
2. I'm referring to the placeholder text Title and Description and the formatting icons + link and mentioning ones. They seemed to me way bigger than the usual ones around other Wikimedia sites. Maybe it is because of the PatchDemo wiki, maybe I'm mistaken and they're actually the same.
3. Yes, exactly that.
4. I think I did? The last comment one would serve as a quick "get me to the bottom" button, the users one would show who was actually taking part in that discussion and the number of discussion ones would serve as a collapse/uncollapse button for discussions. These steps would make navigating discussions in general easier I believe. You come into a page, scan the titles fast, collapse one (if it is collapsed) that interests you, see when was the last comment added, if it was recent or not, see who were the users that took part in it and press the button to immediately jump in the end of the discussion to read a bit and maybe take part in it. - Klein Muçi (talk) 12:56, 27 May 2022 (UTC)

   Tracked in Phabricator
   Task T269954
   

   Tracked in Phabricator
   Task T309751
   

   Tracked in Phabricator
   Task T309752
   

   Yes, it made reading the discussion harder because all your attention was gravitated towards the blue sea.

   Understood. Now that you've named this, I can be mindful about whether other people experience the Reply buttons similarly to how you've described them above.

   I'm referring to the placeholder text Title and Description and the formatting icons + link and mentioning ones. They seemed to me way bigger than the usual ones around other Wikimedia sites.

   Interesting. I've asked the team whether we've made any changes that might've impacted the size of these icons and the placeholder text.

   The last comment one would serve as a quick "get me to the bottom" button...

   I see. Nice idea. Here is a ticket for this: T309751

   ...the users one would show who was actually taking part in that discussion

   Another interesting idea. Does the "Story" section of T309752 resonate with you?

   Asked another way: do you think the "Story" section of T309752 accurately describes the way you would imagine yourself using this functionality were it to be implemented?

   ...the number of discussion ones would serve as a collapse/uncollapse button for discussions.

   Understood. Here is a ticket for this idea of being able to collapse/expand sections T269954 PPelberg (WMF) (talk) 00:52, 2 June 2022 (UTC)

   T309752 looks fine (and so does T309751) but I am kinda uncertain about T269954, the meta part. It seems to me that the overall idea of the collapse/expand function is used to provide a similar experience with the mobile version where the collapse/expand part is mostly used for readability reasons. This is not exactly what I had in mind. For starters, I'm not sure how that mobile function works with reply notification emails. Every time I get an email about a reply somewhere, when I click the link to see the said reply on a mobile device, I get sent to the discussion page where all discussions are collapsed and... That's it. The discussion (topic) doesn't get autofocused, expanded or the reply shown. Maybe I'm just impatient enough and if I would wait a bit the page would eventually "load" and do what I described above but after some seconds, I always end up either switching to the desktop view, or go looking for the needed reply manually, by manually expanding the discussion I know it should be in and looking at its bottom. Overall, unfortunately, I'm not very fond of the whole mobile experience and what I described above is definitely not an experience I would like to also import on the desktop version.

   What I really had in mind was something similar to the current system that we have here on MediaWiki. Discussions get collapsed if they're over/resolved. They are left expanded if they're ongoing. You can collapse/expand them manually but that only happens for you in that moment. Everyone else looking at the page, or even you after refreshing the page, will still see them unchanged. The only way to change them is to mark them as resolved or ongoing (active). This way we can go in a page and the attention will be reserved only for the "open/active" discussions and we can focus on resolving them. So, to recap, the collapse/expand function shouldn't be a user preference for readability reasons but a way of quickly understanding what is already resolved and what needs more attention to be resolved.

   In that aspect, these questions arise:

   1. Can all discussions everywhere eventually get "resolved" somehow? Are there discussions that are ingrainedly supposed to be forever without a conclusion and the "resolved" part wouldn't make much sense in them? (I believe most, if not all, discussions can be considered "over" somehow - and subsequently allow for their collapse - if enough time has passed, even if not really "resolved".)
   2. Should we change the TOCs in talk pages to quickly show what discussions are active and what are over? (I believe that we should and in that way we can quickly jump to the open discussions through the table of content to try and resolve them as well.)
   3. How would this impact archiving in general? (I believe collapsing resolved/finished discussions is a kind of "archiving step" on itself so maybe most bots would need to be changed to allow for slower archiving times if "getting lost in the text" - through the collapse function - will be harder. They would also need to be changed to look out only for the date of the "Resolved" discussions to archive instead of looking out for the date of all the discussions in general.) Klein Muçi (talk) 11:02, 2 June 2022 (UTC)

   @PPelberg (WMF), sorry for ping. I just thought that maybe my last comment may have escaped your notice. I was thinking of adding a link to that comment in the aforementioned phab-task but I thought maybe we can discuss it here first and you can provide a summary there instead of the whole comment. Maybe the details I discuss about are not important at this phase of development. I just wanted to make sure that this comment gets read though because I think there is a big difference in what I'm suggesting and what task T269954 is currently about. - Klein Muçi (talk) 23:49, 3 June 2022 (UTC)

Feedback: LittleGun

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

Laptop device.

2. What did you find unexpected about the prototype?

I noted the new reply arrow and reply linktext.

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

None, but I suck at reading instructions, so I did not follow them before I started to edit on the test page. When I did follow the instructions I discovered I had not taken any otice to the greyed "stats".

4. What do you like about the prototype?

The more prominent "reply link" may be a good feature. I thought the "[reply]" text was prominent, now I dont see it anymore.

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

In Swedish Wikipedia we have an "Add topic" link at the last section header, next to "[edit source]". That is very handy, I hardly found the link now, using this default scheme.

I would like to be able to edit individual replies, rather tan a whole section.

(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 I think it would work on all discussion pages, including "Wikipedia: " pages. The stats is nothing I have been missing really. I am sure some users will see it as an nuisance.

-- LittleGun (talk) 05:51, 20 May 2022 (UTC)

Tracked in Phabricator
Task T309465

Tracked in Phabricator
Task T245225

Thank you for trying out the prototype and sharing this feedback, @LittleGun. Some comments/questions in response below...

In Swedish Wikipedia we have an "Add topic" link at the last section header, next to "[edit source]". That is very handy, I hardly found the link now, using this default scheme.

Understood! Here is a ticket for introducing an "Add Topic" button of some kind that is noticeable and available regardless of where people are on a talk page: phab:T309465

I would like to be able to edit individual replies, rather tan a whole section.

We hear you. Here is the ticket where we are tracking this new feature: phab:T245225

I should note: implementing the ability for people to edit a specific comment is blocked on some more involved technical work that the Editing Team has not yet prioritized. PPelberg (WMF) (talk) 01:18, 2 June 2022 (UTC)

Thank you! LittleGun (talk) 02:22, 2 June 2022 (UTC)

Feedback: New "Add Topic" Button Design

Designs for an additional "Add topic" button on desktop talk pages are ready and we would value hearing what you all think about them.

These changes are designed to make it easier for people to notice and access the "Add Topic" button in cases where they do not have access to the new site-wide sticky header and the additional "Add Topic" button that now appears within it.

Below is the information you will need to:

• Share feedback about the design
• See the design

The designs you see below are inspired by ideas projects like cs.wiki, en.wiki, fi.wiki, and fr.wiki have implemented to make it easier for people to identify and access the "Add topic" / "New section" link, especially on longer pages.

I'm inviting @Ad Huikeshoven, @Akoopal, @Awesome Aasim, @Julle, @Matěj Suchánek, and @Vojtěch Veselý, to share feedback about these designs as they were observant enough to make the Editing Team aware of this issue early in the Talk Pages Project.^{[1][2][3][4][5]} PPelberg (WMF) (talk) 21:46, 22 August 2022 (UTC)

Share feedback

1. Create a new section on this talk page
2. Set the section heading's subject to: Feedback: YOUR USERNAME
3. Share what you think about the designs. E.g. What do you like about the designs? What do you wish were different about the designs? In what cases can you imagine these designs causing issues?

See the design

Skin	Proposed Design
Vector (2022)
Legacy Vector

PPelberg (WMF) (talk) 21:51, 22 August 2022 (UTC)