Add thread lines to visually indicate which toot is being replied to #19570
Comments
|
I do like this solution in that it's extremely quick to implement - it requires very few changes to the existing UI. I'm curious if there's been previous discussion on hiding threads like Twitter does - as in replies to a reply aren't shown in the main thread, you have to click on the first reply to see further replies? It's a branching model of viewing replies where only two layers of branches are ever shown at one time, instead of the flat, linear approach that Mastodon takes. Both approaches have benefits - the Mastodon approach favours small scale engagement when there are only a few replies, but becomes super unwieldy (both visually, and on resources when you have to load all posts) once you get a post with many replies. I'm trying to imagine a post with 100 direct comments plus further replies, without threading and without visual thread lines. That's a nightmare! I will note that with linear threading, it's super odd to me that you can click onto a reply. Especially coming from Twitter. The only benefit added by being able to click onto a single reply as far as I can tell, is that you can see the URL for that one reply. Yes, you also only see replies to that reply, but with thread lines you could see that anyway without having to click onto the reply. It took me a some very confused minutes of clicking around posts to figure this out. Thread lines would have helped a lot. Anyway, so long as Mastodon keeps the linear approach (which is fine), thread lines are a must-have. |
|
Yes please. An alternative would be to just indent all replies (and second and 3rd order replies..) to replies of the current toot by 1em or so. That would visually separate direct replies, so it's easier to follow sub-threads. However, neither of these options work well for visually impaired people.. Perhaps another option might be to add a heavy break above every direct reply (I guess there is a screen reader friendly way to do something like this?) Also it would be very nice to have the (default on, I think) option to truncate reply chains at a depth of 3 replies, with a "Read more of this thread" link to load more. |
|
@gsuberland Question about the proposal. Suppose Dee replies to Alice before Bob does, so Alice has gotten two replies. How is this visualized? If you just connect them all with a line, then it's ambiguous whether Bob replied to Alice or Dee. (If someone else then replied to Dee it's even worse.) I'm not sure whether it's possible to represent the threads in a linear fashion. Another nice-to-have here would be folding - a way to minimize a potentially long subthread you're not interested in. Off-topic: does anyone know if Mastodon works with any bounty program for fixing specific issues? I'd be happy to add a small bounty to this and several others. |
|
@afontenot It's not possible to show all threads linearly because branching occurs as soon as people reply to more than one reply (if I understand what you're asking ...). I went a bit crazy and decided to compare birdsite and Mastodon threading, and lay out possible changes. See my Penpot file here. It's not done, I didn't actually get time to make mockups. The simplest is of course to do as @gsuberland suggested, which maintains all existing threading functionality but makes visual changes for clarity. I'd suggest doing that first, and limiting the scope of the changes in this issue to that. Agree? However if people like the benefits of other threading models (see the ones I proposed in my file) then we can continue that conversation. Best to move it to a new issue, though. If someone doesn't do it before me I'll make try and make some pixel-perfect mockups of @gsuberland 's suggestions at some point soon. Would be wonderful if there are existing design files somewhere so I don't have to inspect CSS values in my browser :/ Anyone know if those exist? |
|
@afontenot There wouldn't be lines back to the focused post, since it's inherent that every reply you can see must be in relation to that post. There would only be lines to indicate "threads" below the focused tweet. Think of it as measuring reply depth. The post you currently have focused is at depth 0. Every direct reply to that post is at depth 1. Every reply to a reply is depth 2. Thread lines would be drawn starting from depth 1 |
|
@gsuberland Sorry, I'm still not quite following. I'm talking about a situation like the following (please forgive my horrible mockup):
Here there's a third level reply: Dee thanks Alice for answering her question. But Bob has also replied to Dee. Is his reply to her depth-1 post or her depth-3 post? Answer: he replied to her depth-1 post. How is this to be visualized? The only options I can think of are:
|
|
How about something like this?
The indentation allows the threads to be readable. Obviously it doesn't work beyond a point, but given this indentation (about 10px), you could easily deal with threads up to a depth of 5 or so without losing much real estate. Threads of depht 5 or more should probably be truncated with a "read more" link anyway, but I guess that's best left for a separate issue. Also it screws with the spacing of the button at the bottom of the toot, but I'm sure there are ways to work around that (e.g. just shift all of them left 50px). And it's not pretty, but it wouldn't be hard to make it so. This is approximately what Reddit's web UI does, and it's very readable there, where multiple deep branching threads are common place.. |
|
I agree that it is very difficult to follow conversations on Mastodon and figure out who is replying to who. I pulled up this random post in my feed that had a lot of replies. Using the web dev console I simply added a left margin to indent and a left border to connect, giving a visual indicator (I blurred out all the specifics, which only highlights how useful this would be. Without even being able to see the actual @ mentions you can still clearly see nested replies):
Some of those replies @ mentioned more than one person above in the thread, but I indented and connected them based on only the FIRST @ and ignored the additional ones. I'd implement this with either the Stylus extension or userContent.css for myself at least, except the HTML elements have no way to discern their level. They are all just I took a look at Reddit's code to see how they are doing it and it's also all just |
|
@kmhcreative I strongly agree that indenting is the preferable solution to this issue. I think, however, that other ideas are being considered here because this option was previously considered and rejected by @Gargron: #279
The above bug was closed as "unfixable". |
|
@afontenot - that looks like @Gargon was replying to a proposal similar to what you posted above. A "tree structure" would be what @naught101 posted above. Indenting with or without a connecting line is the only logical solution, as is ignoring all but the first mention. If you didn't want to ignore the rest of the mentions (based on that thread I modded) either any given person was talking to the OP, or they're talking to someone who replied to the OP, or they're talking to both of them, or multiple people who replied, or someone that hadn't joined the conversation. Duplicating posts so they coexist in multiple sub-threads is a possible solution (so if they replied mentioning three other people, their post would be duplicated under each person they replied to). Indentation would still be a useful visual cue. Nested unordered lists would still be a better structural cue for accessibility (and styling). The only other way I can think of to try and indicate those complex connections would be displaying posts as a web of nodes+edges (like a network map), which would be a pretty weird social media feed. |
|
I'd prefer to not have indenting, I find it visually disruptive. How would it work on advanced view? The columns are tiny as it is without you forcing content into an even smaller width. If you're really set on indenting then you'll find the implementation discussion from Pleroma interesting. See it in action here. Those lines hurt my eyes. Back to thread lines without indenting: advanced view is also a problem even without indenting. How would you do it? The indenting makes the post text area too small, and introduces too much white space (people are already complaining about loss of information density in advanced view #19487 ). There's plenty of room on simple view and mobile. This is just through editing CSS in my browser but an example of how moving the content over to make room for thread lines looks just fine (IMHO) on simple view, and mobile looks much the same. I didn't add thread lines but I'm sure you can imagine: |
Could you share the CSS for this @kmhcreative ? would make a useful userstyle in the interim |
|
@naught101 - sorry, I can't. If I could just apply it as a user style I would, but the HTML has no semantic structure to it that would allow you to target replies at different depths. They're all just sibling I was thinking of trying a user script that would do essentially what I did manually. So it would search the DOM for elements with ".status__wrapper-reply" then look inside it for the first ".h-card" mention |
|
@kmhcreative Ah, makes sense - I did have a look myself and was wondering how you'd done it ;) unfortunately I think such a script would fail because of the problems that @afontenot showed in their mock-up (it would not be guaranteed that a user mention would be in reply to the closest reply above). |
|
Something worth pointing out: posts already have a
|
|
Ok, so last night I cobbled together that user script I mentioned. I'll grant it is not perfect, but it at least gives some kind of handle to grab onto by adding a "data-depth" attribute to the It makes a big assumption that the first person someone mentions in their reply is the main person they're addressing, and ignores any other mentions (kind of like if you sent an email to someone and CC'd a bunch of other people). It only looks back upward in the replies until it either finds a user account that matches the mention, reads that reply's depth and increments this new reply one more, or it doesn't find the mentioned person - because they haven't joined the conversation - and stays at a depth of 1. Same goes if the person didn't mention anyone (in which case, logically this is a reply to the detailed status at the top or it wouldn't be in the thread). Does it capture the full breadth and complexity of the interactions? No. But it can make it clearer who is having a side-conversation. That said, Mastodon uses a Content Security Policy which means you can't do a lot of things. For example you can't use javascript to add a For what to put in your user stylesheet, this is what's in mine. I only went down to a depth of "6" because that was the deepest level of replies I saw in testing this. div[data-depth='2']{
margin-left: 20px !important;
border-left: 5px solid red !important;
}
div[data-depth='3']{
margin-left: 40px !important;
border-left: 5px solid green !important;
}
div[data-depth='4']{
margin-left: 60px !important;
border-left: 5px solid blue !important;
}
div[data-depth='5']{
margin-left: 80px !important;
border-left: 5px solid purple !important;
}
div[data-depth='6']{
margin-left: 100px !important;
border-left: 5px solid orange !important;
}As for testing it? Find some public figure who gets a ton of engagement on their toots, open one, look for any replies to replies, run this script and (if your user stylesheet is already loaded) you'll see the replies adopt your threaded styling. Here's the script itself, heavily commented to tell you what each step does. It also gives you console feedback when it runs: var thatURL = ''; // for storing the URL
threadReplies = function(){
// if URL has changed AND has an @ in it we run threading...
if (window.location.href != thatURL && window.location.href.includes('@') ){
thatURL = window.location.href; // update stored URL
console.log('threading function fired');
// Get the author of the detailed status, if there is one
var mainpost = document.querySelectorAll('.detailed-status__wrapper .display-name__account');
var main_author = '';
// proceed ONLY if we actually have a detailed status...
if (mainpost.length > 0){
main_author = mainpost[0].innerHTML;
// Find all the replies to the status
var replies = document.querySelectorAll('.status__wrapper-reply');
// Iterate through the replies
for (var r=0; r < replies.length; r++){
// For starters assume its a direct reply at depth 1
replies[r].parentNode.setAttribute('data-depth','1');
// Find the first mention in the body (if there is one)
var mentions = replies[r].getElementsByClassName('h-card');
var mention1 = '';
if (mentions[0]){ // there is a first mention
mention1 = '@'+mentions[0].getElementsByTagName('a')[0].title;
}
// See if this reply mentions one above it
for (var x=r; x > -1; x--){
// get the account name from a reply above
var account = replies[x].getElementsByClassName('display-name__account')[0].innerText;
// see if the mention matches the account above
// AND it does not match the main author account
// AND it does not match the main author account minus the domain
if (mention1 == account && account != main_author && account != '@'+main_author.split('@')[1] ){
// get the depth of the reply above
var other_depth = parseInt(replies[x].parentNode.getAttribute('data-depth'));
// increment the depth marker by one...
replies[r].parentNode.setAttribute('data-depth', (other_depth+1) );
console.log('mention '+mention1+' in reply# '+r+' matches account '+account+' in reply# '+x+', set depth to '+(other_depth+1));
break; // break out of this loop if we found a match
}
}
}
};
}; // else do nothing
};
threadReplies(); // initial run
setInterval(threadReplies,5000); // poll for URL change |
So, just for clarity, this would fail in the "Bob replies to Dee" case I gave above?
Shouldn't be to hard to have a version of this that runs in e.g. Greasemonkey, which a lot of people are using anyway. You could always set styles directly on the elements via Javascript.
I've done some scripting on the Mastodon interface and found that the frontend is extremely heavy and extremely brittle. Stuff seems to break very easily if you interact with the page too much. I wouldn't necessarily trust a MutationObserver to be able to catch everything, because you never know when the whole page is going to be rewritten thanks to client side navigation. |
|
@afontenot - I think your example above would look like this with my code:
I'm assuming you're saying Bob is replying to Dee's first post, not her second. My script only looks upwards until it finds a post with the same account name as the first mention. Dee's second post satisfies this criteria for Bob's mention. |
|
I want to thank @kmhcreative for the inspiration; I've done my own version of this as a user script. It shows reply depth with 100% accuracy and styles threads using colors but also supports unlimited depth. (The indentation stops at depth 15, the colors continue to help differentiate after that.) You can check it out yourselves here: https://github.com/afontenot/userjs/tree/master/mastodon I'm planning to add a feature to the script that will allow showing / hiding descendants, letting you to skip past sub-threads you're not interested in. Screenshot
|
|
@afontenot This is the kind of stuff I love about GitHub! Too bad there isn't an Advanced option under Mastodon's Preferences with a couple text areas you could just copy and paste a user script and/or user styles into so we wouldn't have to use third-party solution and would apply them regardless of your browser or device. That would be the ultimate for personal customization. |
It's a little glitchy in my tests with long threads on slow instances (notably mastodon.social). Basically the issue seems to be that sometimes the page will take so long to load the reply data from the server that the script will beat it to the punch. It's something I'll try to fix soon if possible. |
|
Guys I appreciate the indenting ideation, but I’ve gotta ask if there’s any point if Eugen will block it anyway (as he’s done once already, apparently)? Don’t want you wasting time on working out a solution that’ll never be used. I’ve gotta say I’m also doubtful that indenting can ever be done in advanced view column width. The display of replies should be consistent across all views (simple, advanced, mobile), so if it doesn’t work on one view then that’s a reason to not do it. |
|
@brendanjones If I'm not mistaken, the only workable solutions offered in this thread so far are
2 and 3 both seem very unfortunate for users who have sufficient horizontal screen space to see an entire conversation. They would result in breaking it up so that you'd have to click multiple times to follow the whole thing (if you started at the top). But I acknowledge that unlimited indenting would work very poorly for advanced view. Maybe the best solution is a compromise (one of the following options):
If there's an alternative to indentation that is sufficiently clear when displaying arbitrarily deep threads, I'm all ears. But as you said,
Eugen's complaint about indentation was
So what's being imagined here is a back-and-forth between two people, each replying to the last reply in the thread. In that case a "linear" presentation is certainly more natural. Of course, if the conversation is public, the first time someone else adds a reply it becomes a tree, and then I start to question whether linear makes sense... I wonder if Eugen got backed into supporting threads on Mastodon because the underlying protocol made it necessary (because anyone can reply to anything, by default). Given the focus on "conversation" it seems something more like Metafilter reply presentation might be more appropriate. (Basically, similar to a traditional web forum or a Github issue.) Maybe indentation would be acceptable to Eugen with a couple of exceptions:
In any case I agree with you @brendanjones that the discussion on threading above is starting to get off topic, since we're working on user-installable scripts to implement this functionality, rather than a fix that would apply to all Mastodon users. |
|
@brendanjones - I don't think it really matters whether or not its implemented in Mastodon itself, so long as we can change it on our end with user scripts and styling. |
|
@kmhcreative I think this definitely needs an official fix. It affects all Mastodon users, not just those who are comfortable or capable of using user scripts. Scripts are much less accessible as well - it's hard to do all the normal accessibility stuff when you're hacking things into the page. Anyway, I've updated my script to hopefully fix the race condition, so it should work on all pages reliably now. I've also added a nice feature that allows you to minimize subthreads, which is extremely convenient for hiding long conversations that you've already read or aren't interested in. I've made an issue on my repo for further chatter about user scripts: afontenot/userjs#1 Interestingly, working on this script led to me discovering a Mastodon bug: #21879 If there's no sign of it being fixed within a few weeks, I'll probably add a workaround for it to the script. |
I've seen that too, and it was doing my head in, but I don't think it's a bug. It's just an extremely confusing rule but I hope doing thread lines would make it less confusing. I'm really busy this week but as soon as I have time I'll create a diagram explaining why that happens, and a proposal for how it would look with thread lines. Sorry, not very useful I know - if someone else has time please go ahead! FYI I'm not against at least exploring restricting reply depth (visually) as a solution, but as I mentioned above I think they're probably out of scope for this issue. As in, I think we can implement thread lines with the existing threading structure, meaning far less changes, technically speaking. If reply-depth restricting (or indenting) are still desired then I think those can (and should) be solved separately. Unless of course we work out that thread lines just do not make sense without reply-depth restrictions, but I don't think that's the case. |
As I understood the issue, the problem that needs to be fixed is that it's not visually clear which post is being replied to. If I'm not mistaken, merely implementing thread lines is not a solution for that problem, because it remains ambiguous in cases with a fork deeper than level 1. Did you have some version of thread lines in mind that would somehow resolve the ambiguity, or do you think it would be worthwhile to implement thread lines even though it doesn't solve the issue? |
|
I haven't checked it out yet but there's apparently threading in Mammoth app, and Metatext also has thread lines already. Both could be inspiration for our implementation.
Given we'd be using the current threading structure I don't think it's possible to remove all ambiguity in the way that thread lines+indenting would do, but I think it's possible to add something like Metatext does which removes some ambiguity. |
This might be true in a conversation between two people, but it is nonsense on the internet in general. Threaded replies are extremely common on most social media platforms, the main exception being old forum formats, and in those formats discussions often become extremely confusing due to the lack of nesting and unclear reply chains, and forums often resort to ugly AF nested quoting, which quickly becomes just as hard to follow when the quotes get big. |
|
I personally would love some form of indented comments. It's hard to follow a conversation with multiple threads as of now, and having some sort of solution to that would improve the experience immensely. |
|
In the current system, posts are in a hierarchical order but I have no way to tell which post was a reply to which other than clicking on each one and see how it reorders the view when that message is highlighted? I don't have a preference for any particular solution, but it very much seems needed to have something to indicate hierarchy. Personally I think even a simple chronological non-hierarchical order would be preferable to what we have now. |
pleroma, discord, and old-style forums and boards do this, yeah. just show all posts, give them a numeric identifier within that thread, and "replies" become metadata linking one post to another
also, you load the entire conversation/thread all at once instead of having only the partial view of posts above.
discord showing a reply as metadata instead of constructing a tree view
on the other hand, if mastodon implements a tree view, it can look to reddit for inspiration. this would probably require paginating contexts in two dimensions, though (#11029) |
|
Signal also does the flat-timeline-with-links thing. It's quite functional for that purpose (group chats). It's great for keeping the most recent info in-view, when detailed reply threads are not often required. The hierarchical threaded layout is much better for navigating information that is intended to be somewhat permanent, and useful in the future, and especially for complex topics where there is lots of nuance that often needs to be explored in tangential threads (that can ideally be ignored to some degree, e.g. via folding). I guess mastodon needs to figure out which one of those things it wants to be more. Either that, or implement both as options, and let different user subcultures choose what ever works best for them? |
|
In my opinion that one line would be sufficient. The line would end when the conversation ends.
There was a multiple line option back in the days and even so it was a bit confusing, it was way better than have no line at all. As stated, right now it's difficult to see who is replying who, because there is no indicators. I find something rather important to improve. In my UI I have shifted avatars to the left and added a line.
However it's just a faux line as we don't have any helper classes or wrappers for conversations, there is no way to break the chain when the conversation stops and new begins. We'd need at least these |
|
I have to admit I'm still confused about how most people want the one line proposal to work. What exactly is a "conversation" on Mastodon? A back and forth between two people that goes on through succeeding replies? In that case, for one line to work, you'd have to hide replies by anyone not part of that conversation, something Mastodon currently doesn't do. This is basically what Twitter does IIRC, and it uses some heuristics to decide whose replies are important and whose can go below the fold. Or is a conversation all the descendant posts of a given reply, regardless if they are "top level" (direct) replies to that reply, or (indirect) replies to a successive reply? If this is what a conversation is, then (a) having a single line only pushes the ambiguity back a level, since you won't be able to distinguish direct replies and indirect replies-to-replies, and (b) you would also have issues with self-replies by thread authors, since these get lifted to the top of the thread instead of being shown in chronological order, burying their natural replies at the bottom - meaning you wouldn't be able to draw lines for them. Personally, given these issues (unless someone can clarify how to solve them), I don't see a workable middle ground between full indentation (I have a 100% working user script implementing this on the Mastodon web client), and simple chronological order, message board style. Actually, I wouldn't mind having the option to toggle between them. |
I think it's a bunch of replies. The conversation stops and another one begins when user answer to poster rather than the people that reply to a poster. It doesn't have to be perfect.
Can you share it? I'm attempting to build this in to my Mastodon instance even though I'm not very experienced in this form of javascript/ruby. |
|
Just so you know I have managed to get it to work by using the changes from this closed pull request and a bit of CSS.
My commits are here. I have not sent a pull request yet because I'm not very experienced with the code + it's not complete CSS-wise. I'm willing to try though but it needs more testing and experimenting with the style part. It should be as minimal as possible in the core. EDIT: I've made improvements, in the screenshots above there were bugs. Look further the comments below in this thread. |
|
@ronilaukkarinen that's a useful example because either your script isn't working, or I'm still misunderstanding what the idea is here. Specifically, the comments shown in the middle of your screenshot have nothing to do with each other. They're all replies to you (the top level post), and only the one by Here's what they look like with my script:
As you can see, the first three comments all get the highest (smallest) level of indentation, because they are all top level replies. If you're looking to implement these features as a patch on top of Mastodon, you might find it helpful to look at some of my comments earlier in this thread, as well as my notes about self-reply hoisting here: #21879 (comment) My userscript is here but I don't think it approximates how you'd want to implement this as someone who has access to the site code. E.g. it makes sense to revert the commit hoisting self-replies (or handle them differently somehow) and also add depth information to the "context" JSON that the server sends, making it trivial for the client side JS to perform the indentation. |
|
@afontenot It had couple of bugs, I have since improved it. Now it works as it should: Long mobile screenshot
Anyway, you get the point. I'm not big fan of indenting/color coding (visually distracting) so separating conversations with lines is sufficient enough for me. That's just my 2 cents. |
|
@ronilaukkarinen So is your proposal that all descendants of a reply share a line, with no way to further disambiguate them? E.g. if you look at the following part of your poll thread, how do you want your reply to be connected to the rest of the subthread? hidden large screenshot
Note that I've hidden several replies (a feature of my script) and that your reply to the sub-thread is not a reply to any of the replies immediately above it. Indentation means that it's visually unambiguous who you are replying to in this situation. To be clear I don't hate this idea or anything, it would certainly be better than the status quo if replies and their descendants were grouped together in this way. I just worry a lot about the edge cases because sometimes even subthreads are large enough to become confusing. |
Yes. With the line and @-reply it's sufficient to separate visually which is which. In my opinion there is no need to further complicate this. I agree with the original issue proposal by @gsuberland.
They are all part of the same discussion therefore they should be linked with a line. No indentation or colors needed. |
|
To everyone who is following this discussion, there's a merged PR #24549 which solves this issue. |
Pitch
Currently, all replies within a thread are visually identical, making it difficult to follow threads that have multiple subthreads.
My proposal is to add indicator lines that tie subthreads together, similarly to how Twitter handles this. In addition, I propose that the separating line between these subthread replies is slightly dimmed to make the break between subthreads clearer.
A rough mockup is as follows:
(note: I probably dimmed the lines a bit too much here)
Motivation
As it stands, one has to correlate the tagged names at the start of a reply against the parent (which may not be the preceding reply) and the reply indicator in order to check which reply matches which. This gets burdensome and confusing when there are lots of replies creating subthreads, especially when people reply to their own replies.
Here's one example of a case where this can be confusing:
The first toot is a reply to OP, but it isn't clear whether the second toot is in reply to the first or a separate reply to the OP. The reply indicator on the first toot indicates that it probably is, but it's also possible that there's another reply that was hidden due to a muted word or something.
With multiple replies, having the indicator show only 0, 1, or 1+ makes it even less clear.
Thread indicators would help avoid this unnecessary cognitive load. They'd also be particularly useful for people with reading impairment, faceblindness, and other cognitive issues.
The text was updated successfully, but these errors were encountered: