Experimenting with a way of avoiding deeply nested comment threads
One of the difficulties with a nested/tree commenting system is finding a way to deal with threads that get very "deep", when people continue replying back and forth under the same threads. The deep threads end up getting indented very far, and this looks bad, can be hard to follow, and wastes a ton of space (especially on smaller screens like phones).
I'm not a huge fan of any of the ways that I've seen other sites try to handle this, so I've been trying to figure out if there might be any other possibilities that would work well. I've noticed that in most of the cases where a thread gets very deep, a lot of the depth comes from back-and-forth replies, where there's only one comment on each "level". So I'm testing a method that will flatten those sections out and just put a note on each comment that it's a direct reply to the comment above it.
Specifically, the current method (which is now live), works like this: if a comment is at least 4 levels deep and only has a single reply, don't indent the reply any further. Instead, keep the reply at the same indentation and add a note at the top of it indicating that it's a reply to the above comment.
I managed to implement this entirely through CSS, by writing what's probably the worst best chunk of CSS (really, SASS) of my life, which I want to show off here. If you don't know CSS and can't read this, trust me, you're better off:
.comment:not([data-comment-depth="0"]):not([data-comment-depth="1"]):not([data-comment-depth="2"]):not([data-comment-depth="3"]) {
&[data-comment-replies="1"] {
& > .comment-tree-replies {
margin-left: -1px; // compensate for border
& > .comment-tree-item > .comment > .comment-itself {
& > .comment-text::before,
& > header > .is-comment-deleted::before,
& > header > .is-comment-removed::before {
content: "(Reply to above comment)";
font-size: 0.6rem;
font-style: italic;
margin-right: 0.2rem;
}
}
}
}
}
One of the really interesting things about implementing this entirely in CSS is that we can easily change what level it happens at based on screen size. So I have it set to always start at depth >= 4 right now to help with testing and deciding whether it works well or not, but if we decide to keep it I could easily change the threshold to higher on desktop and keep it lower on smaller screens.
As an example of how it works, the previous ~tildes.official thread works really well. @Amarok and @cfabbro had a long discussion about music metadata that went very deep. The thread ends up 16 levels deep, but this new change makes it so that it only indents by 5 levels instead of 16. Here's a comparison between how the end of the thread looks on my phone: before this change vs. after this change (yes, something's not quite right with the indentation lines yet).
Let me know what you think. I'm mostly concerned that this might make it a little harder to follow long threads since the information from the indentation is lost, but I think we need to test it out in real threads for a while to see if that actually ends up being significant or just takes a bit of getting used to.
That's some magical CSS. I expect you'll be cursing your past-self within three months. Should be interesting!
How would you feel about using a dotted left-border on those comments, to make it more clear they're not a part of the regular nesting? You're probably right that it's just a matter of getting used to it, but I think that would make it easier to follow at a glance.
edit: Offloading some of the logic of selecting single-nested comments into HTML classes would probably make the whole thing a lot more maintainable.
I agree that a non-text visual cue seems essential for something like this. Some sort of color or thickness variation on the border outline could work as well.
The more I see this change, the less I like it. It's confusing. I'm losing track of which comments are replying to which comments. It's especially confusing because alignment behaviour is inconsistent within threads: some comments are indented and some aren't. Switching from one behaviour to another mid-thread is doing my head in.
I think another visual indicator would fix this. As @Wex said, dotted line would be ideal for this. Especially if the line would affect both parent and the replying post itself (so the ones that are marked now and parent of those comments). This would clarify which comments belong together, so when another thread appears, there would be another visual indicator, which would really help (as right now the only way to notice this is the missing label, which is pretty hard to notice). It’s hard to decide which comments are replying to what right now IMO.
I’ll try it on local tildes instance in the evening to see if it helps.
gotta agree here, personally. another website i use (daily kos) does this beyond a certain level of indent for its comments as well, and it's equally confusing as shit there when threads get long enough to hit max the indent point. i've read comments on that site for like two years, and it's never gotten less confusing there (and it has an indicator of which replies are going to who where usernames are which tildes currently lacks), so i don't think it's going to really work here either. i think the most elegant solution for now is just to set the indent point later since tildes is small enough that most threads wouldn't go further than like... 8 or 9 levels deep? but at least personally, i don't think that it's the long term solution.
Are there any particular threads you found it confusing in?
I'm definitely not sold on it either, but I'm not sure yet if it's from "this is bad" or just "I'm not used to this yet". It's definitely weird and I'm not sure, but it only affects pretty deep threads overall.
I've also got it starting at a pretty low nesting level right now (4), and it could definitely be moved quite a bit higher so it would be more rare (especially on larger screens).
I haven't been participating in many multi-level threads in the past 24 hours. This is the main one I've been looking at. But, basically, it's confusing in any thread where I see it in action.
And, I don't think this is a matter of getting used to it. There's a fundamental inconsistency here in the way comments are treated within a thread which I'll always get confused by. Some comments in a thread which appear to be siblings are actually siblings (both are replying to the same parent), but other comments in the same thread which appear to be siblings are actually parent and child (one is replying to the other). I'm continually having to do a double-take on this.
Is it possible to make this feature respond to the screen a thread is being viewed on? Could it do more flattening on smaller and/or portrait-oriented screens, and less or no flattening on larger and/or landscape-oriented screens? I know there are other aspects of the user interface which respond to the type of screen being used. Could this feature work similarly?
Yes, I mentioned that in the post. It definitely starts at a very low nesting level right now, but I did that deliberately so it would show up more often to help with testing. Right now it starts happening at depth 4, but in reality it probably doesn't need to start happening on a large (desktop/laptop) screen until more like level 20-25. Those would be very rare.
I actually deleted a comment I made in this thread and reposted it because I thought I had replied to the wrong person.
Then, when the new comment looked the same as the old comment... it occurred to me that maybe I had replied to the right person in the first place.
I've done some thinking on this after seeing it for a bit and I'm realizing that almost none of these back-and-forths actually build or develop on a discussion and just seem to devolve into people talking past each other. Maybe the better move would be to just cap threads once they cross a certain threshold where it gives each participant a notice that "This is your last response to this thread so wrap up what you want to say."
Or maybe the more simple fix would be to just stop pinging the inbox after you get past, like, 6 chains of replies.
The other visual thing you can do is, instead of indenting the text just add a stripe to the left of the post. Each level down is an extra stripe.
unless it was somehow context sensitive, i feel like capping the number of replies people can have to each other in a given thread is just going to stifle discussion when there's nothing inherently bad about long back-and-forths or long conversations. also, it kinda assumes people can't have long conversations in good faith, which seems a bit much to me.
If there is value there, it would probably make more sense to either open it up as its own topic or to take it to DMs. Nobody reads stuff nested that deeply into a comment thread generally so it's not adding much value to anyone.
This is basically how civility gets enforced in moderated discussion forums. Eventually a mod steps in and says "Drop it."
But, again, like @alyaza says, this assumes that deeply nested comments are inherently bad. There's nothing wrong with comments going 20-deep in a thread.
And don't assume noone reads them - I do! (Sometimes, depending what's being discussed.) Also, here on Tildes, there's an option for people to have the latest comments in a thread highlighted, or only the latest comments displayed. People with these options selected are likely to see new comments even when they're 20 levels deep.
What’s the over/under on bad to good here? My money is on the ratio being pretty poor. And it can only get worse as eternal September kicks in.
Like I said, if the convo is actually worth having, I’d argue it’s worth spinning off into a new discussion topic. In this case a function to paste all comments in the chain to make a new topic would be preferable.
i would argue the opposite actually: it'll probably get better and more justifiable with time. right now, there aren't enough people for there to be many threads that go that deep, meaning that mostly it occurs when people are involved in arguments. over time, as more people get here, though, i think you'll see it become increasingly mundane and not-especially out of the ordinary because there will simply be more people who can carry conversations of that length.
so basically a split feature, like most traditional forums have? that would be neat, but i think it'd be a long-term goal at best since moderators would likely be needed to execute it properly, and there's not really any indication that the manpower will exist for that any time soon.
Yeah a slit topic feature is more like what I’m talking about. I think as the user base grows you hit the Eternal September problem and you can’t rely on good socialization and reputational concerns to keep people civil so the long threads become more likely to be toxic. On a lot of the political subreddits, basically anything further than 4 or 5 comments deep is a total mess. The toxic members of the communities know nobody reads that deep and the trolls start getting more abusive once they’re folded in. It becomes a bit of a sport for them to keep baiting people to respond.
A lot of them definitely go that way, but I disagree in general and wouldn't want to artificially limit how deep threads could go because of it. For example, the example I gave in the post itself of the back-and-forth about music metadata is a perfectly fine discussion.
I think we can consider other related things though, like (as mentioned a few times before) we should probably make it so that threads don't "bump" from deep conversations between the same two users. Right now it's mostly a problem because those long bickering threads basically get shoved in front of everyone else due to the Activity sort.
I've just noticed a quirk in this. When I reply to a comment in one of these deeply nested threads, my comment is initially indented, which is slightly confusing. When I refresh the screen, my new comment falls into line, but that initial indentation makes it look like I've started a new sub-thread.
Good god, this is what that css selector compiles to:
I like it, but I think the only thing that might need changing is the positioning of the
(Reply to above comment), which IMO should potentially go above the comment box rather than inside it. The reason I think that is because the switch from nested to flat comments is rather jarring when not explained immediately, especially when a bunch of other "expected" info above the next comment (username, timestamp, link, parent) is the first thing you see.Edit: Attaching unique ID#s to comments and directly referencing which ID# the replies are to (similar to how Chan boards operate), might also help steer people's expectations and make it easier to follow these flattened threads as well. And a unique ID is already attached to each comment in the form of its HTML anchor anyways (e.g. this comment is #comment-32j8) ... so merely exposing them and referencing them openly probably wouldn't be a difficult change.
edit2: Some other distinct visual indication might also help when the transition happens too. E.g. A slight colour change for flattened replies in the comment header or border.
edit3: Another option is, in the minimize icon on (reply to above) comments, maybe switch it from
[-]to[↑]? It's only a minor change but given it's the very first thing people see when looking at the next comment they are reading, it would be kinda perfect. A slight colour change on the minimize icon border might be good too.The reason I decided to put it inside the comment text is that that's the only place I feel confident that the viewer will actually look at. Personally, I find that I skip over the header with the username/time a lot of the time when I'm reading a conversation, because I may not care very much about the information in there. I'm open to moving it somewhere else or doing something completely different if we can find a good option though.
After a few days of use, when there are both child and sibling comments on the same indentation level, it still is a little difficult to figure out exactly who is replying to who.
Perhaps this feature could be used in conjunction with alternating background colours per comment level?
See here for an example.
That way the comments on even and odd levels would have different colours and be a little more easily differentiated when they are being flattened.
I think the color change does make it obvious at a glance, that's a good solution.
The new CSS doesn't behave entirely properly when comments have a coloured border; the reduced padding before inlined replies gets lost, so there's almost no visual distinction between child and sibling comments.
https://i.imgur.com/IqrUHxK_d.png?maxwidth=9999
It might need some additional work, but I like the concept.
I think that there should be a visual cue that is distinct from the comment's content, that lets the user instantly recognize which parent the child comment belongs to.
Example that I whipped up with my amazing photoshop skills: https://i.imgur.com/hOOXjel.png
I agree. Some sort of obvious visual – rather than written – connection to the parent comment is necessary to make the system effective.
I've tried to sit with this for a while and give it a fair shot because I appreciate change and recognize that things like this need time, but I'm pretty certain that I pretty severely dislike it on desktop. It's very hard to follow and unless some brilliant visual distinction is put in (I have no idea what, no ideas I've seen so far seem like adequate solutions), making it so there are two different ways to communicate "this is a reply" with one of them being nearly identical to the way we otherwise communicate "this is not a reply" will always confuse me.
I don't mind keeping it in windows sized like they are on mobile, though. It's not super elegant imo but I absolutely understand the need there.
Yeah, I agree with you. I'll make some changes to it tomorrow.
I just wanted to say that I am really happy that you are experimenting on us. Keep it up please.
box-sizing: border-box?Also, that's a lot of descendant selectors. Do you need that many? It's burdensome. The whole point of CSS is that the styles cascade down the HTML stream.
If you know another way to target only the first comment (without hitting all the other descendants in a tree that keeps going), I'd love to hear it. That's one of the parts I hate the most about it, but I don't know if there's another way.
I like a good challenge.
You want to be able to select only the first reply to the deeply-nested comment, correct?
Yes, and not any further replies that are nested inside it.
You know what? Thanks for the challenge. I enjoyed looking for a solution.
The part that I didn't like – the child selector¹ abudance – you're stuck with, as far as I can tell. However, I was able to reduce the overall selector:
.comment .comment .comment .comment .comment .comment-tree-item:only-child > .comment > .comment-itself > .comment-text::beforeFive
.comments in a row. Looks silly, but works just as well as the cumbersome[data-...]selectors.The idea is: it searches for any
.comment-tree-itemthat is nested in no fewer than four.commentelements (four.comments' worth of nesting + the one being styled), and is an:only-child(meaning it has no other...tree-items in the vicinity – so, the only reply), and prevents cascading of the styling by locking specifically into the descendant comment parts.Tested on several threads. The selector above marks all the same comments that are currently marked with "(Reply to above comment)".
¹ not the descendant selector, which is the whitespace that separates two selectors (
.comment .comment-text); my bad on the namingNot bad. I'm not sure if either is really better than the other for any particular reason, but it's a little shorter than chaining all those
:not([data-comment-depth=...])selectors at least. Thanks for trying, it's tricky.I'm a little upset that you didn't like mine better. It's concise, more readable (the function is more readily apparent), and looks way prettier (if, again, a little silly). You can probably even substitute it in SASS to replace the
.comment * 5with something like[deep-nested-comment].Not that you didn't do a splendid work by getting there with CSS alone. It is a tricky case, and you made it work.
For what it's worth, if I were to make a temporary feature on Tildes, I would've gone with JS. Cycling elements on a relatively-small page is not expensive if all you want is to add a class.
EDIT: wording.
Oh, I meant "better" more from an efficiency perspective. Like, I have no idea if checking multiple not-attr-value selectors is more efficient than multiple levels of descendants like that. It's probably not significant either way.
I agree yours is more readable and will probably change it to that style if we keep it. Do you want to do a merge request for it so it's credited to you in the code?
Not to run my mouth here, so I tested two similar selectors on Steven Souders' CSS Selector Test. The original selector won... by 10ms on a 1k-elements page. "Negligible" is the word of the day.
Don't worry about it. I just want a pat on the back and the sense of pride from doing something good. :D
I agree. CSS is great for layout, but this goes a bit beyond. The layout is dynamically ignoring the structure of the DOM which requires some big hacks. Dynamic content is what JS excels at. Might as well use the best tool for the job.
I'm not sure what you mean, this is entirely a layout change, which is exactly what CSS is for. Nothing is being ignored, the indentation that's being removed was added by CSS in the first place.
Ah, I guess I explained that poorly. This is indeed a layout problem, but the logic in getting there is more programmatic in nature. It's easier to express as conditionals than combining selectors. That's why a programming language seems appropriate.
Does that make more sense?
Yeah, I get where you're coming from. The logic is all just related to the structure of the HTML though, which is how all CSS works. This is a little more complex than most CSS "logic", but it's still conceptually pretty similar: it's looking for elements with particular characteristics nested inside other elements with their own particular characteristics.
I think there would be pros and cons of doing it either way. Doing it in a programming language would simplify the selectors, but would add more complexity if I want to do things like make it start at different depths depending on screen size (which I do).
That's true. You can still read in media queries in JS, but it's more roundabout than doing it in pure CSS.
Either way I'll be curious to see what the final version looks like.
As a side note, having spent a couple days with the change now I do hope there's some further tweaks to the visual aspect. I've found myself confused by the feature a few times already. I suggested a dotted left-border up above, but maybe a delimiter underneath chains would also help. It's easy to miss when the reply type switches from "above" to "left".
edit: Wait, what am I thinking? You can read in the window width directly. No need for media queries.
edit 2: Added delimiter example.
does this work? if so, would make maintaining the depth setting easier
oh, i misinterpreted which part of the style rules y'all were trying to make better. still, i think this does work and is a bit simpler than chaining
:nots...huh. Yes, I don't see why that won't work and is way simpler. I think I was stuck on trying to get the
data-comment-depthanddata-comment-replieschecks to be on the same comment, but it's definitely way simpler to do it this way. Thanks!That right there –
.comment[data-comment-depth="4"]– is a problem. It only captures a single layer of comments – ones that are on depth level 4. The goal is to capture all comments that are depth level 4 or deeper.Right, but all the ones that are deeper are nested inside that one, so since the
repliescheck is now a descendant selector of thedepthone, it should get all of them, right?Just tested. Yes, that's correct. @eeldam, my apologies: I was wrong.
I was able to shorten this selector further:
.comment[data-comment-depth="4"] .comment-tree-item:only-child > .comment > .comment-itself > .comment-text::before. It's 20 symbols shorter than my version and is more readable; I think it's also about as clear in its function.Forgive me if I'm wrong here, but wouldn't a
:first-childor:first-of-typepseudoclass work?That doesn't work here because it ends up affecting all the replies deeper down the same chain. So for example if you have a chain that has 1 reply, then 2 replies below that, you'll end up affecting the subsequent replies as well. I think using the
>child selector is the only way it works to make sure you only affect the single level.I'm a big fan of this idea. One small change you could try other than stylistic changes is to only apply this treatment to comments that have only 1 reply and are the only reply of their parent comment – that way a "flattened" thread will always on its own indent level locally. In other words, all items on a given indent line will either be siblings or be a single flattened conversation. That plus maybe another visual cue might help with some of the confusion
Take a look at this screenshot from this thread. There are two of these streamlined threads, marked with a red arrow in the image, under a single parent post which makes the flow difficult to follow.
This puts both reply threads all at a single indent off the parent with only the subtle (Reply to Above Comment) to distinguish them. The (Reply to Above Comment) without a username makes it very hard to spot where one streamlined thread ends and the next begins.
One way to handle this is to have the first (Reply to Above Comment) indented, like:
I think it looks great, and on my tiny 480x800 screen, it's going to make following longer threads so much more manageable. Thanks!! :)
Why not just reduce the amount of indentation, rather than remove it entirely? Also, you could reduce the thickness/darkness of the lines on the left of each comment, which create the striped effect to the left of a child comment when it's nested 16 layers deep.
The indentation's already pretty small, and reducing it isn't very noticeable and just delays the problem a little. The only way to truly fix it vs. delay it a little more is with zero indentation.
Changing the striping is also pretty difficult. I'm not sure exactly what you're suggesting doing with it, but it's hard to control in general.
This is a damn good start. I like it. <3
That CSS made me smile. Hopefully you can write a macro / function in Sass that can write enough of those :not() clauses based on an argument. I like that it does not require JS.
As for the thing itself, I thought it was not really needed as I read, but when I checked the discussion linked, this is actually really good, a true improvement.
One idea that comes to my mind is that to make the reply-to-above-comment string into a link which when clicked can skip the discussion (i.e. go to next comment sibling to the one that started the back-and-forth chain). That'd probably require JS tho, and it'd be nice if it could indeed scroll without changing the URL hash.
You can just collapse the comment for that, with the "-" button in its top left corner.
I'm not sure what you noticed since I hadn't actually changed anything yet, but I've applied a couple of changes now: https://tildes.net/~tildes.official/cv4/adjustments_to_the_experimental_single_reply_flattening_user_page_sorting_is_now_available
Just looked at some examples, and if possible, the
(Reply to above comment)should go next to where it saysLinkParentThere's probably not really space for it there on mobile, unfortunately.
Shall we start a nested thread here to see it in context?
Sure, why not?
Because you could just go to ~test?
If the top comment gets labeled "off-topic" or even "noise" (which might be a good test anyways), it shouldn't be too annoying, since then the thread will stay near the bottom.
I suppose you're right. I don't see it any demonstration in this thread, besides screencaps.
↑ Huzzah!edit: Dang you, @tomf, your new reply removed my glorious(reply to above comment)! :PThere is the example in another topic that Deimos linked of me and Amarok going back and forth for a dozen replies discussing metadata, like the giant nerds we are... :P But yeah, none in here yet.
Testing responses to lvl 4 inline.
Wait, is this going to be nested.
First tildes shit post thread for functionality testing? Count me in :-)
Always good to be a part of history.
Replying to my own previous reply.
Edit: Deimos is there something weird going around my original comment ? I ask because I swear that when I first loaded Vord’s reply in the thread here, it was collapsed with (Reply to above) and appeared to be a peer to my original comment. This is what I expected to see.
After I added this comment, Vord’s comment was nested again, and this comment is collapsed
Shouldn’t Vord’s comment stay collapsed?
Edit2: Oh, just re-read the spec above, it does make sense and I get the reasoning.
Another special case, replying to the second post that is indented the new way
Hey, a bit off topic, but I just tried to click the
parentlink in my notifications. It loaded the page but it did not scroll to the comment. It used to do so, correct?Here is the link: https://tildes.net/~tildes.official/cjg/experimenting_with_a_way_of_avoiding_deeply_nested_comment_threads#comment-32ko
I am on iOS, but can anyone else verify that scrolling to the comment is broken?
"It is known." ;)
https://gitlab.com/tildes/tildes/issues/412
Thanks for knowing it!
just a test. :)
Bahahahaha!!!! This has now transformed tildes.net from a simple community into a game of Stratego!
I'm curious how this flat threading works when you have say... four or five people in cycling through a healthy discussion on say... the social impact of japanese city pop in the early 80s. :)
edit: this comment bumped the
(Reply to above comment)down two levels from AugustusFerdinand down to KennyTesting responses to lvl 4 inline.
I too wish to see this.