Techie-Micheal wrote:I know this is off-topic, but if someone could please explain to me [why] hash-bangs are used instead of hash
What a perfect use for a threaded view! I swear I didn't bribe Techie-Micheal, nor Phil, nor /a3 above. Since I'm not particularly interested in this branch of the conversation, a threaded view would have been great. I could see the hash-bang issue deviating from the topic I'm interested in, and skip over it (maybe by collapsing its branch a-la-reddit).
The point I'm trying to make is that we live in an information-overflow era, and any measure that helps manage the deluge of information and the process of digging through it in search for a nugget of knowledge, is valuable.
To respond to Steve's excellent arguments (the best I've seen so far; wish there were a Like/+1/Reputation button):
Pony99CA wrote:I've used Disqus and it's OK. However, it probably does threading because it doesn't support quoting. Even in a threaded system, quoting is still necessary if you want to make it clear which piece of a post you're addressing.
Agree that quoting is still necessary, even in a threaded system.
The reason Disqus does threading is, I believe, that blog/news comments tend to be way less expository than forum posts such as this. Replying to shorter comments reduces the importance of quoting, because what a user would quote, would most often be the entire comment of the user they reply to. I believe removing quoting was a design decision from Disqus, given the nature of comments (closer to tweets rather than blog posts).
On the other hand, a threaded topic is a superset of a flat topic, because you could always render the threaded topic with an indent of 0 for all posts, and you get the flat view.
First, as a math major, I wouldn't call either a superset. They both show the exact same content, just in a different order and perhaps with different formatting.
Also, removing the indent does not make it "flat"; it just makes it look
Appreciate the language correction
What I meant was that a flat view is a particular case of a threaded view, and I omitted to mention the difference in sort order:
Pony99CA wrote:The biggest difference between threaded and flat views is the post ordering, not the indenting. By default, in phpBB's flat system, posts are sorted by date (ascending), although you can also sort by other keys and in descending order. in a conversational/threaded view, the root posts may be sorted by date (ascending), but the branches and leaves aren't. Within a given root post, each level may be sorted by date (ascending), but merely removing the indent won't change the default ordering.
And that's the biggest problem that I have with threaded views. The post ordering makes it more difficult to find just the newest items. You have to scan the whole tree to find them. Yes, you can add a view that only shows new items (but without quoting you won't have context) or you can somehow flag the new items, perhaps with color, borders, highlighting, etc., but you still have to scan the whole tree.
Reddit faces exactly this challenge when it renders your inbox of reply notifications. For each reply, there is a "context" link that displays the reply and walks back the parent nodes up to the root comment (example
Let's say a threaded view would highlight or put a border around new messages, and maybe collapse the read nodes between (but not including) each new post and its read root (entirely new branches would be shown fully expanded). How a user who wants to monitor a thread handles new items depends on their goals:
- those like me, who are only interested in specific branches of the discussion, will skip new posts in uninteresting branches. With thee classic flat system, skipping those posts requires skimming over them, so a threaded view wins time.
- those who want to monitor everything will read all the new posts, skipping from highlighted new post to highlighted new post, over read posts. But: this type of visual skipping to the next item of a particular style (highlight, border etc.) is way faster than the actual skimming through text in the previous case.
It could be argued that there are two distinct use cases, thus warranting a per-user, UCP, option. If one view had to be forced, from a utilitarian standpoint aiming to minimize time spent traversing uninteresting information, I would enforce a threaded view, unless the users who want to monitor everything outnumbered those who cared only about specific branches by a factor greater than text skimming speed
(1500wpm?) divided by average speed of searching for the next highlighted post
As for context: if the new items need context, then, aside from what's already quoted from the replied-to post (if anything):
- in the threaded view context will be right there, one click away (if read parent nodes are collapsed). It might be interesting to display the immediate read parent of a new post anyway, so that context is readily visible without an extra click.
- in the flat view, there is no extra context. New posts are simply at the end. If there's no quoting, the context situation is even worse.
Pony99CA wrote:Also, as Lumpy mentioned, you have the indenting vs. scrolling problem. If people keep replying to replies, you either indent so far that horizontal scrolling is necessary or you have to reset or freeze your indents at a certain level, which makes it look like the posts aren't threaded properly.
In the case of freezing the indent, we have the advantages of threaded view, the general case, up to where we freeze the indent. After that, we revert to the particular case of a flat view. A fully-flat view is no better off.
Anyway, there is a more elegant solution to excessive indenting: partially outdenting the branch. Here's an example from a MediaWiki talk page
- search for "31", then scroll down half a page.
Pony99CA wrote:Furthermore, unless you display the whole tree on one page, pagination becomes more difficult. If you want to display 20 posts per page, you could end up starting a new page way over on the right side due to indenting (even if that page only contains posts at that level).
That's exactly what mwForum does (example
), and it seems to work pretty well. If you follow from the previous page, you have the mental context of where you left off. If you somehow (say, after a search) end up on a page that starts way over on the right side, the first post should either have a link to its parent, or pull the parent in dynamically (with the parent having the same kind of link or pulling in option). This is an improvement I'd like to see in mwForum.
dandv wrote:Users can also just reply to the whole thread rather than to an individual message, so they can choose "flat" even in a threaded system.
Unless all users choose to "post flat" or there's an option to view flat, that's not true. They're just posting flat.
Not sure I understand this objection; let me clarify: imagine there is a "reply" button next to each post, and also a "quick reply" type of text area at the bottom of the page. Replying using the latter means replying "flat". This is, indeed, posting
flat, which is different from choosing a flat view.
I come to this debate with a user's experience, and no investment in one system or another.
Your first paragraph seems to contradict that.
What I meant is that I haven't implemented, or deployed, a threaded system that I'd have to defend. I've only used both systems and got to see the advantages and shortcomings of each.
Pony99CA wrote:As a former developer and user experience person myself, I don't have a problem offering a threaded view as an option selectable from the UCP. In fact, from a database view, it might only require one or two new columns -- a "parent" post ID and possibly a level counter (to make things faster). The parent ID would be useful without threading -- it would allow making the QUOTE attribution a real link to the quoted post, which is useful when somebody has trimmed a quote (like I often do).
Adding a link to the parent would be useful indeed, if you trim a quote, or if the same person said more or less (human memory is fuzzy) the same thing in the quote in two or more posts. I've seen this feature in some forum engines.
Pony99CA wrote:The harder part would come trying to implement the view, as you can't just use a simple SQL statement to sort posts. There might also be other "gotchas", like what happens if you delete a "root" post or merge two topics, but I'm just considering the basic view problem right now.
What I hope with this debate is to have the possibility of threaded views seriously considered. I've seen the requirement many times, and there is clearly a market share for it. I've been reviewing about 20 OSS forum engines over the past week, and besides reddit (huge system requirements) and slashcode (apparently not actively maintained any more), only Drupal comes close with a threaded view, though Michelle Cox, the author of the Advanced Forum module, hates threaded views, admits that the jump links are likely to be wrong, and that she had never tested the module with threaded views.
At this point in my quest for an OSS threaded forum engine with clean URLs
, it looks like phpBB is the best choice because at least some people here are considering the idea of threaded views. The other strong candidate, MyBB, will ditch even the rudiment of a threaded view
that they have (which probably won't be missed, given how bad it is).