Forgive me, what do you mean by ‘threaded’ versus ‘flat’. By ‘threaded’ do you mean ‘nested’? What do you mean by ‘repetition’ and ‘replies duplicated’?
It’s just a case where the CSS fix is much simpler than adding yet another setting
a.reply-to-tab, nav.post-controls .show-replies {
display: none;
}
Threaded is also called nested or tree by some. It’s where the responses are directly grouped under the posts to which they respond rather than in a straight chronological time line where posts are placed by the time they were posted regardless of what they are responding to. It’s what us old guys cut our teeth on (FWIW I’m just shy of 60). Threading started falling out of favor 15-20 years or so.
The expanded reply function in Discourse duplicates posts in a thread when the feature is triggered. For example when I expand the replies under a post I get the replies that were made directly to that post (as opposed to using the reply button at the bottom of the thread). The posts that are displayed in the expanded reply mode are also displayed where they would normally be in the chronological listing. This doesn’t serve the user well because they don’t know if they have read that post until, well, they read or start to read it again. As the feature currently operates I don’t see it as an effective UX design.
There isn’t any threading or nesting present, it’s just an added view to provide the context to a series of posts without scrolling, the topic and replies themselves are completely flat.
Easier for the devs to code but not necessarily for the users to use. Particularly when those users are small time hobby forum operators that don’t know what CSS is let alone be able to edit them. I haven’t seen it mentioned in any of the docs. Without a clear mention of this ability it’s not likely users would know about it. If I weren’t here I wouldn’t have known about it. It’s far from being any sort of urgent issue but it’s the kind of detail that separates the great apps from the really great apps.
Sure, but I think that applies to pretty much every UI element, if you go back far enough pretty much all of the buttons here are going to be new to someone. Adding buttons to toggle visibility of everything in the interface would create a more complex UI for everyone, not to mention lots of weird edge cases for testing.
Discourse isn’t trying to be the forum software of the past decade, it’s pretty much the opposite.
I don’t think it’s unreasonable to ask site owners to learn basic CSS to set things as hidden if they dislike them. Either that, or prepare some robust user guidance to educate your users on the new widgets and gadgets.
Why upgrade to something like Discourse, only to file all the corners off? It’s going to be harder to support and maintain than it would be to stick to older software.
This is just a difference of opinion. The Discourse team is of the opinion that inline reply expansion is useful, you’re of the opinion that it’s not.
We’re happy to listen to your thoughts and even help you out, but it’s not a priority for us to add a setting for it at the moment. If other site admins (especially customers) complain about the feature, it could become a priority. Let’s try to stop this conversation from getting too far off track
In this case it’s an unexpected result that I don’t think adds the the user experience. It’s also unique to Discourse compared to any message/forum software that I’ve seen or used. Saying that it’s easier to code or that the software users should learn some sort of specific coding skill set are valid in and of themselves but doesn’t support a use case for double posts. I think the relevant question is how the display of double posts benefit the user.
Please take my comments in the spirit intended as someone that is offering a perspective having done it for real, at scale, that may see it differently. It’s all well and fine that the decisions were made. Projects make the decisions they make. That’s why Solaris is destined to be a museum piece (I think a good argument could be made that it already is) and Linux rules the internet. This isn’t a persecution of any of the methods implemented. It’s an observation from using the product.
I notice some defensiveness not in this thread in particular but through out when there is a question about approaches or an opinion contrary to how the software functions or devs think it should function is expressed. You folks don’t have to justify or defend your positions. Citing the reasoning is great but at the end of the day the project is going to do what it’s going to do. The more input you have from people outside the project the better it will be. Even if you don’t act on it.
Thinking a feature should be implemented a certain way by no means indicates I think the feature isn’t useful and didn’t indicate such in the post. I’m asking the reasoning behind thinking that repeating the posts is a good idea. Those repeating posts are an artifact of a feature implementation. I do think having a feature toggle is a good idea (and provided reasons for such) but as I stated in the previous posts the CCS hack is a clever way to implement it.
We think the feature, as implemented, makes a lot of sense for a very mild hybrid of flat and threaded. Very few people complain about it, except you. We practice complaint driven development here – if dozens of our paying customers start telling us it’s a problem, we’ll be sure to take note.
That is currently… not the case.