Threaded discussion is ultimately too complex to survive on the public Internet?

In 2012, Jeff’ wrote that he thought “threaded discussion is ultimately too complex to survive on the public Internet.”

Since it’s been nearly another 6 years, I was wondering if he still saw flat threads as the wave of the future, considering threaded conversations continue to be used by the largest and fastest growing social sites(Facebook, Imgur, Reddit)?

Given the apparent acceptance, perhaps even preference, of threaded design by these hundreds of millions of users, would he now be willing to consider incorporating threaded design into Discourse?

It seems that at the very least, this makes pragmatic business sense, since threaded conversations are now what the majority of people are used to using.

3 个赞

No, I would not. For the record I am not against one (and only one) level of threading, but even that causes temporal and spatial problems with the discussion.

Also, are Imgur (?) , Reddit, and Facebook really discussion systems?

  • Reddit is a “post the funniest thing and vote to get it sorted above the others” system. Putting aside threading, the voting is probably as damaging to discussion as anything else, given that it re-orders the discussion. Good luck posting a reply to the fifth top level reply by votes and having anyone see it… ever.

  • Imgur is even more explicitly an amusement system given the focus on images. Race to post the funniest thing. Not that there is anything wrong with that, of course, but discussion is not in any way the goal. Odd to include it in this list.

  • Facebook is more akin to a commenting system than a discussion system. While I have been linked to interesting Reddit comments before, many times – that is a valid metric of “it is producing at least some interesting discussion artifacts” – I can’t recall a single time anyone has ever pointed me to a discussion on Facebook. Maybe that is because unlike Reddit, 99% of the discussion it produces are private and visible only to people in those conversations?

It is valid to ask “where is discussion happening today”, but it is also valid to distinguish between actual discussion and (the equivalent of) YouTube comments.

Also have you seen how Reddit is collapsing pretty much all older discussions for anons by default? That is not an argument in favor of threading to the nth degree…

15 个赞

It is almost impossible to read a discussion on Facebook. I regularly stop reading discussions I find interesting because so much and so many of the messages require anther click to see them. I have even seen tweets truncated on Facebook. It’s simply not designed for people to even read what’s there.

15 个赞

暂且不论线程化,投票机制对讨论的破坏性恐怕不亚于其他任何因素,因为它会重新排序讨论内容。试想一下,你试图回复按投票数排在第五位的顶层回复,却几乎永远无人能看到你的回复……

我只是在想,为什么不能通过启用多级线程化,同时让评论排序默认按时间顺序(按新排序)来解决这个问题?这难道不会有助于抵消投票带来的负面影响吗?

我对 Discourse 平台上人们对线程化评论的强烈反对感到十分困惑。感觉就像我只是来参加讨论,却尚未意识到“线程化讨论谋杀了某个婴儿”之类的严重罪行似的。这到底有什么大不了的?

对我而言,这让回溯某些信息或话题变得容易得多。我可以筛选评论,找到与我兴趣相关的部分。

当然,如果我热爱这场讨论,我会阅读全部内容;但通常情况下,Discourse 上扁平化的讨论线程让我感到不堪重负。试图与他人进行讨论,并理解他们的评论在整个线程脉络中的位置,真的让人倍感压力。

当我能够轻松地将评论最小化(我认为目前还没有一种直观的方式来最小化那些我不关心重读、因为它们在我看来对讨论毫无价值的回复,而我只想专注于某人的回复)并继续浏览下一条,同时跳过所有对已最小化评论的回复时,整个讨论的布局就显得更加井然有序,因为这些回复与点击该线程的原因并无太大关联。

5 个赞

如果你真的需要完全支持线程讨论的功能,Discourse 并不适合你,我建议选用其他免费的开源工具。

4 个赞

我完全理解这些观点,也同意多级线程讨论确实有其用武之地。思考两者的区别时,我觉得嵌套/线程式讨论(例如我体验过的某些 Reddit 子版块和 Hacker News)的最佳使用场景,往往是“许多个人对某件事做出反应”,而非“一群人共同进行对话”。这固然很好,但通常会导致回复高度碎片化,因此能够轻松阅读某些部分并折叠/跳过其他部分就显得尤为重要。

而 Discourse 则明确以对话为核心,其线性结构是一种约束,旨在贯彻这一原则。我们可以将这种结构想象成一群人在派对上聊天。人们可以随时间加入或离开这个圈子(甚至几周后加入),但它本质上仍是一场单一的对话,按时间顺序展开。

一个重要的考量点是,这两种不同的互动模式在管理方式上遵循截然不同的范式。对于 Reddit 或 HN 这类平台,版主的主要焦点通常是确保贡献者不违反规则。而在 Discourse 中,版主对塑造对话结构拥有高度的控制权。

举个例子,当讨论开始严重跑题时,版主通常会将该跑题内容的帖子拆分出来,创建为新话题,以保持原话题的聚焦。此外,如果某讨论中的帖子引发了良好但关联性不强的想法,用户甚至可以使用“作为链接话题回复”的功能。

作为版主,还有许多其他方法可以帮助管理讨论,例如为话题重命名以使其标题更具描述性、关闭变得陈旧或无关的话题、删除损害对话质量的个别帖子等。

Discourse 确实被用于各种场景,有时也会出现难以追踪的巨型话题。对话难免会偶尔变得混乱。但我认为,至少在旨在促进良好对话方面,保持内容的适度聚焦是有益的。理想情况下,不应出现太多你想阅读某个话题却发现其中充斥着大量需要跳过的干扰内容的情况!

13 个赞

说得好;这个问题也可以通过在脑海中将

  • 我需要很多线程

替换为

  • 我需要很多相关主题

来回答。这在 Discourse 中不仅完全支持,甚至受到鼓励。想要 20 个不同的分支话题?那就创建 20 个相关主题并尽情发挥吧。

区别在于,主题拥有唯一的 URL 和标题,有助于人们找到他们所需的内容。相比之下,高度线程化的对话就像一个无法搜索、混乱不堪的意大利面球。

16 个赞

感谢你的分享。在我发表第一条评论后,我偶然读到 @codinghorror 的一篇博文,进一步阐述了这个问题,而大家的回复也非常有帮助,帮助我理解了起初让我感到困惑的教条!

我承认,我真正习惯的格式更像是 Reddit 或 Facebook。这些平台塑造了我对群体讨论/评论的理解,毫无疑问,这也是为什么我发现这种扁平化、严格按时间顺序排列的讨论形式如此令人不适。

正因如此,在 Reddit(暂且不说 Facebook,请原谅我的粗口)上,我从未觉得错过了自己真正感兴趣的主题帖中的任何要点。我学会了以某种系统化的方式阅读帖子的各个子线程,通过折叠内容来清除视觉干扰,以便专注于下一个我想深入思考的话题。

然而,如果阅读子线程是我获取信息的唯一方式,那我肯定会错过很多内容。不过,我尽量在使用的每个工具中都利用搜索功能,Discourse 也不例外。

我认为我们的平台希望社区不仅仅是讨论的场所,因为 Discourse 具备许多功能,让我们有理由相信,它也能在很大程度上成为用户和团队的任务管理/项目管理工具套件。

相关信息很多,但组织工作是一项巨大的任务,而一条混乱不堪的线程可能只是其中的一个方面。

由于我对此还不太熟悉,而且社区本身也比较新,我认为我们尚未充分利用手头各种工具来实现既定目标,也尚未将其打造成一个让所有新用户都感到愉悦且易于使用的平台。

感谢大家提供的信息和启发!

9 个赞

难道不能通过彻底重新设计用户界面来解决线程讨论的问题吗?
比如,看看右侧的空白区域。所有线程讨论都可以移到右侧并利用这片空白。或者采用其他创新方式,让用户只需简单点击几下就能返回主讨论。

2 个赞

但“线程化讨论问题”其实已经被 Discourse 解决了。

我很感激 Discourse 团队没有提供线程功能。

5 个赞

我认为问题已经解决了,这源于我之前对讨论帖“应该”如何呈现的理解(基于我独特的心理模型)。

不过,我确实感谢你指出了讨论区右侧的空白区域。我一直在琢磨,Discourse 的界面究竟有什么特点,让我觉得阅读自上次离开后发生的内容像是一项沉重而令人不安的任务。需要滚动太多次,而真正“精彩”的评论却寥寥无几,还夹杂在漫长的滚动中。

我想,如果我能定制一个主题,专门优化评论卡片的设计并减少视觉空间的浪费,或许就能解决这个问题。我喜欢它目前看起来并不刺眼,但从某种意义上说,它依然有些令人不安,因为我在第一眼 glance 时无法获得足够的视觉上下文。

什么空白空间?我目前使用的是移动设备,整个宽度都被充分利用了。

我见过一些基于“缩进”的线程模型,但它们从未很好地处理水平空间的减少。

再加上,新帖子可能会在垂直间距的任何位置出现。只有在所有讨论尘埃落定后才真正具有可读性,更不用说隔了一段时间再回来追赶进度了。

3 个赞

从哲学角度来看,线程讨论非常重要。

有时,最好的讨论来自一个随机的网络喷子。他的一些观点比原帖作者更好,而且每个人都想深入挖掘他的帖子,胜过其他任何内容。

无法在界面美观的系统中实现这一点,是一个技术问题,而像所有其他技术问题一样,它最终会被解决。

2 个赞

由于其本质(高噪音、缺乏焦点),冗长而热烈的讨论很难被总结和整理。

为了使讨论富有成效,需要做到以下几点:

  1. 降低其热烈程度,通过制定正式或非正式的规则(在 Discourse 中,这是通过 20 字符限制实现的;在 GitHub 中,这是通过工程文化实现的)。
  2. 提高其焦点。可以通过将其与可识别的项目关联来实现:例如一条帖子、一段文档或一个缺陷……
  3. 缩短其长度。可以通过确保上述项目范围有限或具有时效性来实现。
1 个赞

如果你想要的是冗长的讨论,其中大部分内容毫无价值,只有一篇帖子值得一读,那你还是留在 Reddit 吧。

6 个赞

你总是可以通过点击第一篇文章下方的 总结此话题 按钮来总结长篇讨论(假设你从顶部开始进入,如果是你从未见过的话题,那正是你进入的位置)。

不过,默认情况下,只有当讨论有 50 条或更多回复时,该按钮才会出现。它会将讨论缩减为互动最多(如点赞、回复、阅读等)的 10% 的帖子。因此,一个有 100 条回复的话题在按下该按钮后会变成只有 10 条回复的话题

请注意,Reddit 现在在你以未注册用户身份进入旧版 Reddit 话题时,会 默认 进行此类总结,如下所示:

你也可以通过点击或轻触某用户的头像并按下 筛选 按钮,轻松在长篇话题中筛选出该特定用户的讨论,这样你就只会看到该用户一个人的帖子。

10 个赞

抱歉打扰这个旧帖,但我有一点补充。

就我自己而言,对于我自己的社区,我非常喜欢扁平化的讨论模式。不过,在向他人推荐 Discourse 时,嵌套式讨论的话题往往会浮出水面。

我认识的一位朋友对嵌套式讨论模式(仅限一级嵌套)已有良好的使用经验。他们社区的理念是:首帖相当于一个引子或真实经历分享,一级回复拥有各自的标题,并由此展开受引子启发的实际讨论,而二级回复则如同讨论中的常规消息。这种模式非常契合他们的需求。

我希望向他们推荐 Discourse,让他们也能受益于其出色的用户体验、帖子编辑器、慢速模式、草稿功能以及强大的管理特性。我甚至愿意亲自为他们搭建论坛,但难点在于,这位朋友对这种讨论模式有着成熟且经过验证的经验,并不想改变现状。目前他们使用的是经过修改以充当论坛功能的博客软件,但该方案在功能和稳定性方面已逐渐显露疲态,且从一开始在维护方面就不是一个好的选择。

说了这么多,主要是为了解释我的使用场景。我认为,允许在帖子评论中设置一级嵌套将是一个很好的(可选)功能。我理解目前尚无对应的用户体验设计,因此实现起来会相当复杂。这只是一个长期建议,但我认为这对于某些类型的讨论和社区会非常有用。

8 个赞

这种情况其实已经存在了:如果用户点击的是某条帖子的“回复”按钮,而不是主题的回复按钮,就会发生嵌套。之后,你可以点击帖子右上角的图标来查看相关的回复(底部会显示类似“部分回复已隐藏”的提示)。

编辑:也许它只是隐藏了那两条相关帖子之间的回复。这不是我常用的功能,所以我可能说错了。

3 个赞

抱歉——这和我说的不是同一个模型,也不是等同的模型。

正如我所说,我喜欢当前的模型,但它可能不适合所有社区,我已经给出了详细的用例说明了原因。

3 个赞

4 个帖子被拆分到一个新主题:高亮回复作为链接主题功能