Introducing nested replies

[markvanlan]

Meaningful conversation happens when everyone in the room has heard each other’s thoughts, and a flat, linear timeline has always been the best way to make that possible on Discourse. But flat doesn’t fit every community. In larger, faster-moving forums, thousands of replies on a single timeline make it impossible for anyone to keep up. That’s why we’ve been cautiously experimenting with a fully nested reply view this year, and we think it’s a great fit for communities that have outgrown the flat format.

What started as an experimental plugin, shifted to a project shipping directly in Discourse. Here is a peek at what a nested topic looks like at the moment:

When a specific post is linked to (from a share link or notification), we have a single-thread view:

Enable it on your site

The site settings to enable this feature are available in the admin interface. Navigate to the “Nested Replies” section to control the feature, default sort modes, max depth, and more.

Roadmap

At the time of writing, it’s early days for nested replies. The roadmap is not fully fleshed out. A few things we know we will do:

• Better mobile experience

• Rethink the topic timeline for nested view. At the moment there is no timeline on topics while in nested replies mode

• Add at least one new ordering mode for posts with age decay, similar to our “Hot” for topic lists.

Limitations

• When nesting is enabled for a category, pre-existing topics stay in flat mode. Each topic can individually toggled from the admin wrench, but there is currently no way to convert an existing category to nested mode.

We’d love your feedback

We need your feedback and experience using this feature to help inform it’s development. If this looks like a good fit for your community, give it a go, and tell us what you and your users think!

[Lilly (Lillian)]

OMG YES. excellent timing too. i am migrating a forum to a new server with 2-container tonight and i can’t wait to turn this one for the new one when regular season and our sports pools begin in a couple weeks. this should be a good test use-case too.
it will be so cool to have the options of both flat and embedded discussion - thank you for this @markvanlan and Team.

should be fun seeing what it breaks too

[Ed_S]

Just to note: when there are new replies in multiple branches of the tree, it looks like the single-thread view only showed me one at a time. I had to revisit several times, with the unread count going down by one each time.

[gilles]

I can’t find the option to enable this feature despite the Discourse update!

I’m self-hosting, so that might be the reason

[Lilly (Lillian)]

@gilles

I’m self-hosting, so that might be the reason

update your Discourse instance, and then go to all site settings and search for “nested”

you can toggle it with topic admin wrench when you make a new topic

you can enable in category settings tab if you want it to be default in a category.

i self host and it is totally working

[gilles]

Thanks for your efficiency

[Richie (Richie Rich)]

@markvanlan

When nesting is enabled for a category, pre-existing topics stay in flat mode. Each topic can individually toggled from the admin wrench, but there is currently no way to convert an existing category to nested mode.

Can existing topics be bulk-changed / updated via the Select Posts > Bulk Actions options?

Or are there any rails console options to bulk-update all existing topics?

[markvanlan]

@Richie

Can existing topics be bulk-changed / updated via the Select Posts > Bulk Actions options?

Yep, toggling is an option for bulk actions

[Richie (Richie Rich)]

Ok, not sure how viable the bulk-toggle might be for categories with tens of thousands of topics. Might rails bulk / batch conversion jobs be option?

And is this reversible? Can a threaded topic be converted back to a flat topic?

[markvanlan]

Yes I do agree with you. This is a limitation for now, and something we will absolutely keep thinking about.

The big reason why I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently. In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.

Basically I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable. We’ll keep thinking about it. The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”

[asc]

Amazing! So happy to see this!

[ToddZ]

@markvanlan

In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.

I always felt the “reply” labels could be more specific – so a while back I used some custom CSS to add context:

screenshot

CSS

/* add text to Reply button for the original post (aka Topic)  */
#post_1 nav.post-controls {
  .actions {
    button.reply {
      span.d-button-label:after {
        // Adding this content after Reply
        content: " to this Topic";
      }
    }
  }
}

/* add text to Reply button for all subsequent posts (I'm calling them comments)  */
nav.post-controls {
  .actions {
    button.reply {
      span.d-button-label:after {
        // Adding this content after Reply
        content: " to this comment";
      }
    }
  }
}

/* add text to blue Reply (to Topic) button appearing at the end of the page */
#topic-footer-buttons {
  .topic-footer-main-buttons {
    button.btn-primary.create {
      span.d-button-label:after {
        // Adding this content after Reply
        content: " to main Topic";
      }
    }
  }
}

[Lilly (Lillian)]

the issue with this solution is it won’t be translated in the UX for members who have a non-english language setting in their preferences

edit: i have solution here:

Reply Button Labels

Summary Translatable topic & post reply button labels Repository https://github.com/Lillinator/reply-button-labels Install Guide How to install a theme or theme component Install this theme component Overview The core Discourse topic and post reply buttons use the same string and it can be a bit unclear to inexperienced users what the different functionalities are: [image] Unfortunately, changing…

[Richie (Richie Rich)]

@markvanlan

I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently

@markvanlan

I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable

Interesting…

Does this suggest it should be tested in our communities in isolation first, before we all pull the trigger and convert every existing topic?

@markvanlan

The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”

That’d work, providing it supported tens of thousands of topics.

But it’d need to be made very clear that there is no coming back from this

---

Will this feature be implemented here on meta first, or on https://try.discourse.org so we can test it outside of our production environments?

[markvanlan]

@Richie

Does this suggest it should be tested in our communities in isolation first, before we all pull the trigger and convert every existing topic?

If it were my community I would test in isolation first. On the other hand we would get more valueable feedback faster by you enabling for your whole community . Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.

@Richie

But it’d need to be made very clear that there is no coming back from this

I guess I sorta accidently answered this part! Enabling nesting simply creates a nested_topic record for each topic in the DB and kicks off a job to calculate reply counts down the ancestry tree. Disabling nesting removes that nested_topic record and you’re back to flat, no issue.

@Richie

Will this feature be implemented here on meta first, or on https://try.discourse.org so we can test it outside of our production environments?

Feel free to play with it in this category:

Nested Replies Testing

[darkpixlz (Pyx)]

Is there a reason that this is only able to be toggled by staff instead of normal users? When I had seen it was coming to Meta I figured that it would have been added to the post type menu but the toggle is hidden behind the staff wrench icon.

I’m not sure if I have a specific use case, I guess I had just figured it would have been implemented the same way post voting was.

[markvanlan]

We don’t want this to be a user’s decision or preference. It’s up to the administers to decide how their site should function. The two paradigms are very different and users shouldn’t be interacting so differently on the same content. That’s our current thought at least.

[eisammy (Sammy)]

Ad blocks do not work well in this structure, and converting topics often triggers a bug where screen items disappear, leaving only the title editable.

[nicolsdennis]

Nice feature! However I’m curious about the Top / New / Old sort more than the nested layout itself. I’ve shipped similar sort controls in my mobile app (a Discourse client) and would love to support this natively than my current method although it works as I’ll show below.

Looking at the source, I can see GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} returns the topic in nested view sorted by the chosen mode. My question: is there any appetite to expose just the sort through the existing /t/{slug}/{topic_id}.json endpoint (e.g. ?sort=top) so flat-view clients can benefit too?

If sort were available on flat view, third-party clients could opt in without adopting the nested view rendering model.

I realize the nested view’s data shape (root posts + lazy children) is what makes server-side sort tractable, and that flat view paginates differently. If a full flat-sort isn’t realistic for performance reasons, even an optional ?sort=top&limit=N would be enough to drive a “highlights” view.

[Kevin7 (Kévin .)]