Talk:Talk pages project/Usability

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)

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 ✅ 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 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 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 []  [] 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 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 ) 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:
 * "Start a new topic" on this talk page
 * Name this new topic: "Topic Container Design Feedback: YOUR USERNAME"
 * Write answers to these questions
 * What you appreciate about these design explorations?
 * What do you wish were different about these design explorations?
 * 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)
 * , 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)
 * 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)
 * 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 (, , and    and being absent in others ,   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)
 * 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)

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 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:
 * "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. or any other kind of Mystery Meat Navigation. Also see.

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 Farm-Fresh_comment_white.png ? I believe it counts the number of comments in that ==Section==. Whatamidoing (WMF) (talk) 21:12, 4 January 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:
 * 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".
 * 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).
 * 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 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:
 * Here's what "just creating a +1 indentation level reply straight after the chosen comment" would be:
 * 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)
 * Here's what "just creating a +1 indentation level reply straight after the chosen comment" would be:
 * 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)
 * Here's what "just creating a +1 indentation level reply straight after the chosen comment" would be:
 * 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 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 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 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)
 * 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)