The “discourse way” of handling such cases is to split the topic and let the folks dive deep to a “sidebar” discussion without affecting the main thread.
The issues with this is that we
split too early, when there is just one possibly offtopic reply, which may or may not lead to the sidebar conversation
do not split enough and let the sidebar discussion dominate the main thread
do not follow the expectation that once folks achieved something in that sidebar discussion, they should show up in the main thread and let everyone know about the outcome
I am wondering is the more clever use of flags might help with this.
I was thinking about this as well. Making a change discussion visibly different from the regular conversation has a huge benefit. There might be other ways to achieve that, than just the nested replies.
Another supplement: Aleksandra’s recent post now again ended up in a notification that triggered me to the right place, and this way, I could now also see Jef’s post (to which she responded) without searching through all threads and all posts
Ironically, now my own recent post is again at the top
I feel this confusing. I end up always to first OP post or just see replied ones. This should be option in user settings to enable or not as for now I don’t want to use this
I agree with all of this. I’m just not sure Discourse’s nested view, in its current implementation, brings the needed added value. If I’m not missing something, nested view fails to show which replies are new or unread. Manually searching for new replies in a topic with several (sub)threads can be time consuming.
But given that this is a rather new proposal from Discourse, I expect new features will be added as to make it a strong alternative to the linear timeline view.
It’s disappointing though that it is not a flippable setting for the user. Sometimes you want to view things w/ threads, something w/o. And different people have different preferences too. So it really should be a toggle.
But after reading this thread, I also realize that in the threaded view, it’s extremely important to have a dense overview of the whole tree and a good view of individual messages without context. The current view here with all messages sort-of blending into each other requires much more effort to read than the usual threaded view in mutt.
Maybe it would be worth to collect the issues / preferences and file an upstream request (not sure how far its intended that we use our contract’s tickets for that? I expect not ). I actually don’t know how far our enterprise contract improves our chances for quick implementation, and some things might be not trivial. But might be worth a shot. After all, a big well known community might consider to replace its mailing list with something Discourse-based, which might be good marketing for them too… Maybe we can get at least a perspective of what and when is realistic. Just a thought
It remains a riddle to me why I sometimes get forwarded to the very post when I have a notification, and sometimes I end up at the topic’s head and have to search myself (not seldomly with the post not being opened by default but hidden by a +) No correlation found yet, and whenever I consider something, it proves later to not be the origin That must definitely on the issue list
@py0xc3 / @bookwar I was poking around Discourse sites with nested replies enabled and stumbled across this topic!
Nested replies is getting some solid usage at this point and I’m not getting a whole lot of feedback after the initial wave of obvious bugs. Always happy to discuss ways we could improve the system or missing features. It’s much easier for me to keep track of conversations if they happen on meta.discourse.org. If you do want to discuss please either post on a topic there or of course create a new one.
Great community here; it’s an absolute joy to stumble across a topic with folks discussing the pros and cons of something I’ve worked on. Thanks for brightening my afternoon
Hi Mark, it’s great to hear from you, and thanks for your work on this
We definitely should stay in touch and indeed bring this to meta.discourse.org .
That said, I’m not sure if I can currently invest too much time to create a useful/effective and comprehensive report that sums up what has been elaborated here. But I think it’s not about if we do it but when the first person finds the time to open a topic at meta.discourse
Supplement: I think we documented that issue before, but for the record, I clicked explicitly on “reply” at Mark’s post. But it still is not in the thread of Mark as response to his post but seems to create a separated/new thread next to Mark’s post, but within the same superordinated thread (that begins with Aleksandra’s post).
In order to work towards opening an expressive upstream topic, I think its useful to start summing up the issues we have collected here:
replies are sometimes presented top down and sometimes button up, sometimes changing after refresh without changing any settings.
even when using the reply button at a specific post, it can occur that the response becomes a separated thread next to the post it is responding to, with both being connected only through the superordinated thread. This can become especially confusing when the response is the next moment above the post it responds because of the separated thread.
When getting notifications for new posts, the notification button sometimes leads to the very post the notification is about, and sometimes just opens the head of the topic: the latter means the user has to search themselves where the new post is, and sometimes its not even opened but hidden by the “+”.
when I respond after a notification brought me to a post (and thus has hidden all other threads to focus on the one I was notified about), and I then respond, I cannot see my own response, but I expect that is another manifest of issue 2) (so, I assume that happens because my response is not part of the thread)
the auto-hiding is considered confusing by some, the suggestion was made this should be manually enabled by the user if they want to. However, we also have feedback that for mailing list folks its confusing all the configuration we have to make → if possible, I would later default whatever they prefer for it, but the possibility to change this default might be useful in any case.
EVERY MOD / SITE-ADMIN / TL3+ WHO CAN: FEEL FREE TO EDIT MY POST AND ADD FURTHER POINTS! (I cannot do wiki posts here)
In addition to the points above, which are all well described, I would touch the scenario of using Discourse via email. The issues below are not necessary specific to nested replies, but having them fixed could provide a better Discourse adoption by those preferring the email communication on various platforms. Here are some issues I’ve noticed:
Not possible (AFAIK) to start a topic by email.
When replying by email, copies of the postings aren’t sent by Discourse as email back to the sender. Useful in threaded views.
Quoting in emails doesn’t provide the same metadata in the posting as when quoting in Discourse’s web interface (e.g. username, topic etc).
The poster’s username (in addition to it’s defined name) is missing in the From field, hence it’s not possible to @-mention someone without actually knowing their username.
I wonder if it makes sense to create two files in our forge repository: one for documenting the email-related issues, and one for the discourse-nested/web-ui-specific issues. I expect both will need separate upstream tickets/topics as its different plugins I assume.
Shall I create the two files in order to jointly work on the two files? Might be easier to review & follow than posts here
Supplement: this time, it worked that I replied to a specific post, and my response is correctly developing the thread I replied to rather than creating a new thread with common root. I cannot verify what correlation is the origin yet (concerning when it works and when not). Also, the issue of my response being hidden when submitting did not occur, so my assumption that it’s just another manifest of the first mentioned issue seems right so far
The proposal makes sense indeed. We’re targeting the same project-specific challenge with both topics, but for Discourse these are probably separate components.
OTOH, having them together for discussion would bring better ideas to the table maybe?
I did some fancy changes to notifications (that could certainly not work quite right). Basically if the notification targets a single post (or multiple posts at the same nested level of the same thread), they point to the single-thread view. This is because nested replies order is variable based on sort order… we don’t have a reliable way to link to a nested post without a thread-specific view.
More “general” notifications like you’re watching a topic and there are 5 new replies, should just take you into the topic. It’s a total PITA to track where those new ones are because you only have the little blue dot.. but that’s how it is.
I actually changed the default so when you create a new topic you are only watching for replies directly to you (top-level or replies to YOUR nested posts). This was to avoid notification messes. Clearly it hasn’t made the usability perfect.
I’m not convinced that nested replies is good for long topics where you care about all the replies (like this one). It’s good for gaming communities where people can go and react to a bunch of hot takes for example. It’s also solid for communities where there are only a few replies per-topic as the nesting makes the topic view a little more compact and it’s easy to see the relationship between posts.
Flat is generally better… we are now re-discussing it be a user-opt-in feature as well so users can choose what they prefer. I had previously taken the stance that it should only be an admin choice but that might have been a bad decision.
Wait… I might have just hit one of those bugs with my reply not being to the right target… testing again. Sorry for mucking up your topic. Have not encountered this before.
Feel free to use this repo as you see fit. Beyond the members of the Discussion FAS group, I added @bookwar@jspaleta@tqcharm as they have been active here. The repo doesn’t lead anywhere, so I can easily add further contributors
The repo has little impact and is not related/integrated anywhere, so I guess its ok I created it, we can delete it at any time. But in case someone wants to object, I CC the @moderators and @trust_level_4
I have not yet had the time to review if it really is what some people had asked for in the other topics about the discourse/mailing-list case (especially with regards to open topics by email), but I thought it’s worth to be documented here, maybe I or someone else finds some time to properly review that and its implications
There is a link in that conversation that points to this doc page, according to which there is a setting (disabled by default), that would allow emailing in to Discourse, including only allowing specific groups, or allowing emailing in to only specific categories, etc.
According to the same documentation, only site admins are allowed to perform the setup.
). I actually don’t know how far our enterprise contract improves our chances for quick implementation, and some things might be not trivial. But might be worth a shot. After all, a big well known community might consider to replace its mailing list with something Discourse-based, which might be good marketing for them too… Maybe we can get at least a perspective of what and when is realistic. Just a thought 
That must definitely on the issue list 
