Discourse has been an Ember app since day one.
It’s just changing some of the structures and standardising on Ember Components.
Allow me:
5 Likes
I just had an idea, it’s still rough but wanted to put it out so that I don’t develop it too much without input from others.
What if Discourse could have a way to give people threaded discussion until the replies hit a certain threshold and then it either forced people to reply with a linked topic or strongly suggested they did?
For me it can become a question of what Discourse wants to be…if it wants to be purely long-form, focused conversations, then the current mode seems to work well. However, if it wants to be a community platform with events and user directories and people interacting with each other, then I think it might benefit from adding the short-form, almost small-talk interactions.
An example
I automatically post my podcast episodes to my discourse (lowercase intentionally to genericize it, not sure the company would like that lol) and while some episodes are 5-10 minutes, some are over 3 hours.
For a three-hour podcast, I imagine it will be near impossible for people to have a focused discussion on it, because some will want to comment on 00:06:00 and others are 01:34:24 and others on 02:33:50. Many of the comments might be short, like quoting a part of the transcript and saying “wow I never thought of that” or quoting another part and saying “I strongly disagree with this” or simply just wanting to heart or 100% different parts.
I believe these small comments can bring a lot of value to a community, not only in making it easier for people to contribute but for also seeding discussions. Maybe I see the “I strongly disagree with this” and want to continue, and if I want to continue, maybe I’m a little heated and want to go in more depth. And then they respond in more depth. That’s when I think the threading gets unwieldy.
But what if, at that point, the software says, “Hey, start a linked topic to go deeper on this” or something?
Small talk vs long form
I think threaded discussion does the small talk well and I think linear discussion does the long form well, and I think it might be really hard for the FBs, IGs, HNs, Reddits, and others of the threaded world to create the linear discussion, maybe easier for the linear ones like Discourse to add initial threading and then split into linear if it gets too long. Actually, I believe Facebook has a maximum nesting level and then makes the conversation linear as well.
I don’t know, maybe Slack tried this and failed lol.
Any thoughts on this?
1 Like
Isn’t that how Discourse works? Small talk can be threaded in chat, and long-form discussion can take place in topics.
If someone starts in chat, yes, but not if someone starts with something like a blog post that has nested comments below it.
I think the starting point I’m suggesting would be more like how a Facebook post or Instagram post works, or maybe even like a post on reddit, whereas I think the one you’re suggesting might be more like a Whatsapp group or other group chat where there is a steady stream of conversation, often around a group name or maybe a very high-level topic area.
So maybe what I’m suggesting is less like Slack, because Slack seems more like the group chat just with the higher-level topic areas, not a topic as specific as a post.
1 Like
I think that maybe just adding (back?) a reply-as-linked-topic button next to reply under each post might help some of these desires for threading. A thread (new topic) is useful only if you want say stuff that’s interesting to only some people in the conversation will want to follow.
The other piece, though, might be to leave behind some kind of link or hint that the thread/new topic happened. We have that now, but not in the place where the new topic split off.
So if there was a linked topic in response to a post, there’d be a link to is just under the reply icon toolbar and not just the one that’s under the OP but exactly like that
5 Likes
I think I said it up-thread. If you’re trying to keep up with an active discussion, threading is a nightmare. You can never tell if you’ve seen the whole thing, or are maybe missing something of import. Threading is only usable for completed, archived discussions. I do think that every “reply to post” needs to be displayed in the UI, even if you are replying to the post directly above (last time I checked, this was an option in settings, defaulted to “off”)
2 Likes
I’ve used reddit and other communities that had threaded discussion and it worked fine for me. I didn’t like having to load another page to keep reading a discussion and some of them did that after a few levels. And I didn’t like having to horizontal scroll when they got too deep. And I didn’t like them getting too small when they got to many levels. But there are options to solve that. We have more experience now.
But 2 billion people a month use reddit and 1.4 billion of them use the comment system. I don’t see them complaining about it.
I’ve used Discourse for tech support and it’s worked great! But I’d like to have a discussion forum and that’s where I really enjoy the threaded discussions that other communities have and I want that option with Discourse. As I’ve mentioned before, I’ll help where possible.
2 Likes
That’s part of my plan for using Discourse to power a comment system. If there’s an indication that a reply to a comment (as opposed to a reply to the article as a whole) has spawned a new discussion, the people involved will be prompted to move the discussion to a new topic on the forum. The logic for what indicates a new discussion has started can be really basic. For example, after two direct replies to a post, the next time someone clicks the post’s “Reply” button, a link will be displayed above the post editor that makes it easy for them to start a new topic. The other participants in the “thread” will be invited to the new topic.
For this case, the comments will be generated on a website, just like a normal comment system. The related discussions will only occur on Discourse, but be linked to from the website’s comments.
3 Likes
And all of these are things that make threading very difficult for me. Death of a thousand cuts here.
What is the solution for the primary issue: In a threaded model, I have to periodically have to scroll back through the entire discussion to make sure I haven’t missed anything?
I Admin/mod a small FOSS community (3 consistent-ish users including myself, as well as about 6 more that sometimes chime in, plus occasional drive-bys) that runs on a threaded platform. The number of times that I miss something on a discussion that is less than a full page long has really turned me off of the whole thing.
Reddit survives on it’s massive momentum and low barrier to entry. Its reading experience is the armpit of the internet.
2 Likes
That’s your opinion and that’s fine. I do like threading. And I believe I can address the things that users don’t like.
If the plugin API has support to do threading I will work on adding it in a plugin and offer the plugin free (if I have funding support upfront if needed) or offer it at sale if it needs financial support. I don’t know the API at this time. I’ve done open source and free products before and some times they have a cost to build or maintain.
That’s fair. You could have a “Notify me of updates to this thread” option. There are creative solutions that are out there. As a software developer, I hear those things often from one side of the table and have to come up with solutions on the other side of the table. But I don’t throw out the whole app because some parts have poor user experience. I find ways to upgrade that experience. Maybe, maybe threads aren’t the answer and maybe there’s another answer out there but for me, in my humble opinion, the single topic design of Discourse doesn’t always work as well as I’d like on the multiple answer multiple comment discussions found on communities like reddit.
The new chat threads seem to want to address that but they are flat discussions like on YouTube and I heard they aren’t saved. In YouTube after a few chat thread comments it’s not easy to follow. So they are not an answer for me.
In reddit or wherever a topic is presented and multiple discussions form around it. Sending those discussions into separate page loading posts are not easy to read in my opinion (load page, read, go back and reload past page - lose place, load new thread post, read, go back and repeat).
1 Like
You mean a separate notification for each reply to the thread? The problem isn’t that I don’t know that there are new posts, it’s that I don’t know where they are. If there are more than one, I only see one/the one closest to the bottom.
Threaded content isn’t used everywhere because it facilities good discussion. It’s used because it turns a discussion into modular parts that can be sorted and hidden at the whims of a recommendation algorithm. And that’s a necessary requirement that allows a singular human user to interact with platforms that have massive amounts of content.
It works when you expect to only view a piece of content one time, letting you dig as deep as you want. But it’s complicated to untangle a web of discussions if you’re reopening and catching up on the same topic over and over, as you would in the setting of Discourse
2 Likes
@piffy, it’s not for me, though. I’ve never found interacting with a threaded discussion more difficult than the opposite, whereas interacting with flat ones is cognitively difficult for me the moment that the conversation topic differs and/or more than 2 people interact.
2 Likes
My point was more about revisiting the same discussion. Assume there are 12 new replies. For a flat discussion there’s a single point you need to return to and you can read all 12 of them. For threaded discussions, there could be 12 unique conversational threads with replies and you have to reestablish the context of each before reading the new reply.
Either way, the goal should be to optimize for good discussion, not necessarily cognitive simplicity. After all, the most cognitively easy option is to not read the discussion at all.
2 Likes
I find that easier. I don’t understand how mere indentation would make it more difficult to read rather than less. I indent every heading of my documents, for instance, like Revision - Stack Overflow demonstrates.
That’s a Logical extreme - Wikipedia. It’s irrelevant. Cognitive difficulty, like any other attribute discussed here, has a non-negligible Benefit–cost ratio - Wikipedia, so it should be considered in earnest like any other attribute. I don’t understand why you would mention that.
2 Likes
It’s not about the indentation. It’s about the fact that one of those replies is on page 2 of an 8 page discussion. How do you know that you need to end up back up there, and how do you stand the time to page/scroll to that location?
1 Like
If you’re going to link simple concepts from wikipedia, you should at least read the page yourself because it explains why a logical extreme is a useful rhetorical device. The point is that a good discussion will require some amount of cognitive load so it shouldn’t be the primary variable to optimize. It’s also very subjective because I find nested discussions much harder to follow than a single linear one personally.
The primary question is whether or not better discussions emerge from a flat format or a threaded one. I don’t know the answer but my impression is that because a threaded discussion typically gives you a narrow and engineered view of a topic and is hard to revisit, that overall the quality of the discussion is affected. But it’s a necessary trade-off that large platforms have to take which is why you see it everywhere.
It’s not a useful logical device, hence the reference to the explanation. Also, I subsequently explained why it wasn’t useful, so why are you asking for an explanation?
Had you clarified that previously, I wouldn’t have mentioned it. I agree, although since nobody purported otherwise, I still don’t understand the relevance.
I don’t believe that that is the primary issue to be resolved, because it doesn’t matter if the user can choose whether to view the thread flat or threaded - each user chooses based upon their personal preference. All responses are threaded beneath the GUI (that’s why there’s a “Reply” feature on responses as well as an otherwise duplicate blue one at the bottom of the thread) so it’s merely a matter of exposing this to the user.
What 8-page discussion do you refer to? If you’re describing a hypothetical threaded and paged discussion, the way to remediate that problem is by merely not paging the thread.
What’s not about indentation?
1 Like
For the record, I’m not against anyone making a plugin to do threading or expand the available options. I actually think the amount of community Discourse plugins is much sparser than it should be.
What I am doing is agreeing on principle with the post referenced in the OP and also I don’t think that threaded discussions should be a core idea that the main Discourse team should invest time into.
This is partly what I like. In the front of written material there are the outlines:
- topic
- header
- subitem
- header
- subitem
- header
- subitem
- header
it’s organized. you can get an overall view and find what you’re looking for easily.
to me, the existing flaws with threaded discussion are usability / ux issues.
- reloading the page
- losing your place
- finding or being notified of new comments
- deep threads (less space to read)
these aren’t difficult to fix:
- don’t reload, open up a dialog window or fetch the data
- don’t reload and you don’t lose your place
- load new comments dynamically or use visual indicators (bold rows)
- decrease indent as you increase in depth, or set max depths
indeed. it wouldn’t be a replacement to already great community experience but a complementary addition that users can switch between (or enabled optionally)
1 Like