mastodon
mastodon copied to clipboard
mastodon
Add thread lines to visually indicate which toot is being replied to
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.
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:
- Use one line on every sub-thread of a level-1 reply. In other words, don't disambiguate more than one level at a time. Sounds not very useful, IMO.
- Use indenting to show subthreads. This is what most sites that have threading do. (Offhand, I can't think of a site that uses a tree structure for comment relationships and doesn't visualize that with indenting, unless it hides subthreads like Twitter.) But it's not shown in your mockup and I think some people think it's a bad idea for Mastodon specifically?
- Start hiding all level 3+ subthreads, like Twitter does (inconsistently); I really hate this because it means much more navigation. But it would fix the ambiguity.
- Use an additional line for each subthread level. This is a bit messy visually and I have a hard time parsing it, but it does disambiguate. I think that's maybe what you mean by the following statement, so it's what I show in the mockup above:
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
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 <div tabindex="-1"> siblings so there's nothing to hook into with CSS that would differentiate a reply that is one level deep from one that is three levels deep. These would either have to be tagged with a data- attribute indicating depth or, ideally, probably in nested <ul> elements with each reply an <li>. The latter would be preferable for accessibility reasons because it would create structural relationships between the replies.
I took a look at Reddit's code to see how they are doing it and it's also all just <div> containers. When the page is rendered it appears to be inserting generated class names and inline style attributes to do the indenting and thread lines. Seems to me nested unordered lists would be much, much simpler.
@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: https://github.com/mastodon/mastodon/issues/279
The alternative proposal of rendering in a tree structure, I think, is the wrong approach, because the natural flow of a conversation is a deep chain of replies, rather than one post with many replies. In those circumstances, tree rendering would look very messy and the posts would become very narrow.
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 https://github.com/mastodon/mastodon/issues/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:
added a left margin to indent and a left border to connect, giving a visual indicator
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 <div> containers with nothing differentiating reply depth in relation to any other reply. Either the DIVs need a "data-depth" attribute or each reply needs to be an <li> and depth created with nested <ul> elements.
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 <span>, and then look at the nearest sibling reply above it for a matching ".display-name__account" innerHTML, and insert a className or attribute to create the depth hook for restyling it. But I haven't yet got any further than identifying which class names to query. Cloning and replacing the replies container node would probably be faster, but wouldn't work because it would strip off all the event listeners. Of course a user script would have to be implemented through a browser extension/add-on, pretty sure no browser lets you run them natively anymore.
@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 data-id="<longnumber>" attribute. I wonder if someone put in a pull request to add a data-reply-id attribute to identify the post being replied to, if such a request would be accepted. It would be an important move in several respects:
- It would move us in the direction of having a real, site-wide fix for this for all users. (I'm not dead set on the indenting approach. I recognize it has downsides, but I'm also relatively sure I've not seen any solution offered that is sufficiently clear and doesn't require some degree of indenting.)
- It would allow sufficiently enterprising users to build user scripts that use indenting or some other approach to clarify reply structure until this can be fixed.
- It's a simpler solution than using semantic nesting in that it wouldn't require changing any CSS styles and wouldn't lock us in to a tree structure for posts in the future.
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 <div> that can be used for styling purposes. I'm not sure how useful this actually is in practice, so maybe it's just a proof of concept.
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 <style> block with your custom styling, you have to do it either with an extension like Stylus or with a user stylesheet. You can't even add new rules manually in the developer console. It also wouldn't let me do self-running functions because they're treated as an eval operation. I tested this by copying and pasting it into my developer console. To run this all the time you'd need to do it through a browser extension that lets you run user scripts (or turn this script into a webExtension). It's set up to do polling with a setInterval because no listeners I tried would work. Even though the URL and DOM content changes no event listeners like "popstate" or "readyStateChange" would trigger. I didn't try "MutationObserver" but if that works it would probably be a better approach than polling, though I'm not sure which is the best element to observe for changes. So I went with the simplest approach of just checking the URL at regular intervals to see if it has changed and if we're on a detailed status with replies or not.
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
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
So, just for clarity, this would fail in the "Bob replies to Dee" case I gave above?
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
<style>block with your custom styling, you have to do it either with an extension like Stylus or with a user stylesheet. You can't even add new rules manually in the developer console. It also wouldn't let me do self-running functions because they're treated as an eval operation. I tested this by copying and pasting it into my developer console. To run this all the time you'd need to do it through a browser extension that lets you run user scripts (or turn this script into a webExtension).
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 didn't try "MutationObserver" but if that works it would probably be a better approach than polling, though I'm not sure which is the best element to observe for changes.
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 NICE! Just tried out your script on some very long threads, worked like a charm for most of them, but occasionally would fail to run. Not sure if that's a setTimeout() issue or not. I ran locationChanged() manually from the console and the replies threaded, so it wasn't anything on the page interfering.
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.
Just tried out your script on some very long threads, worked like a charm for most of them, but occasionally would fail to run. Not sure if that's a setTimeout() issue or not. I ran locationChanged() manually from the console and the replies threaded, so it wasn't anything on the page interfering.
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
- Indented threads
- Restricting depth to level 1
- Restricting depth to level 2, with the visual clarification ("thread lines") suggested by @gsuberland
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):
- Indented threads for "normal" view by default. Option (3) for advanced view, with the option to also use option (3) for normal view.
- Indented threads for everyone (by default), but depth is restricted to e.g. level 3 when in advanced view, to avoid too much indentation. Both sets of users get the option to switch to (3) style presentation.
If there's an alternative to indentation that is sufficiently clear when displaying arbitrarily deep threads, I'm all ears. But as you said,
It's not possible to show all threads linearly because branching occurs as soon as people reply to more than one reply
Eugen's complaint about indentation was
the natural flow of a conversation is a deep chain of replies, rather than one post with many replies. In those circumstances, tree rendering would look very messy and the posts would become very narrow.
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:
- Threads that contain no branching structure can be "flattened" with some distinctive styling to make the reply structure obvious.
- Posts that are only visible to select accounts are always flattened - maybe even chronological?
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: https://github.com/afontenot/userjs/issues/1
Interestingly, working on this script led to me discovering a Mastodon bug: https://github.com/mastodon/mastodon/issues/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.
Interestingly, working on this script led to me discovering a Mastodon bug: https://github.com/mastodon/mastodon/issues/21879
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.
FYI I'm not against at least exploring restricting reply depth (visually) as a solution, but as I mentioned https://github.com/mastodon/mastodon/issues/19570#issuecomment-1327770713 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.
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.
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?
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.
the natural flow of a conversation is a deep chain of replies, rather than one post with many replies.
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.
