也许措辞不那么理想。请替换为“相当长”——这个讨论串本身就符合。
在嵌套视图中，您会得到：
如果有人稍后回复了该嵌套讨论中的早期评论，我们会得到：
如果我必须从一个有60条评论的讨论中向上滚动，我该如何找到那个新帖子？
我是在回应您关于不理解缩进如何使事情变得更困难的评论。缩进是使嵌套排序在某种程度上起作用的必要功能。至少对我来说，问题在于排序本身。
You shouldn’t need to, because a new post notification should direct the user to it, like Threaded discussion is ultimately too complex to survive on the public Internet? - #62 by Sailsman63 does to your comment.
As an example, every time I receive a message via e-mail about a new notification on Reddit, I merely click the button to take me to the comment, rather than trawl through thousands of comments manually.
Would you elaborate on this?
Do you mean that because the sorting is necessarily applied to each hierarchy individually, it produces problems like a file manager can cause:
You’ve a list of files, and want to sort them by modification date to find some old logs. However, because these logs are in a directory of multiple file types (some irrelevant) they’re grouped by type (which is alphabetical) meaning that although they’re generally chronological, the chance for something new to be at the bottom is non-0.
You’ve a list of music. You want to remove some songs you don’t like, but you can’t order them by rating, because too many have identical ratings. You’ve grouped them by rating consequently, and have ordered them by access date, so that you use when you last accessed them as a determiner, too. However, this means that some seriously old songs are missed even if you rated them highly when you were young.
I understand that, but I can’t think of a solution. Discourse implements the sole alternative that I’ve considered, but (of course) I consider it inferior due Threaded discussion is ultimately too complex to survive on the public Internet? - #61 by vel.
你不需要这样做，因为新帖子的通知应该会引导用户找到它，就像 Threaded discussion is ultimately too complex to survive on the public Internet? - #62 by Sailsman63 指向你的评论一样。
举个例子，每次我在Reddit上收到关于新通知的电子邮件时，我只需点击按钮即可转到该评论，而不是手动浏览成千上万条评论。
你能详细说明一下吗？
你的意思是，因为排序必然应用于每个层级，所以会产生文件管理器可能导致的问题：
你有一系列文件，想按修改日期排序以查找一些旧日志。但是，由于这些日志位于一个包含多种文件类型（有些不相关）的目录中，它们会按类型（按字母顺序）分组，这意味着虽然它们总体上是按时间顺序排列的，但新文件出现在底部的几率并非为0。
你有一系列音乐。你想删除一些你不喜欢的歌曲，但你无法按评分排序，因为有太多歌曲的评分相同。因此，你按评分将它们分组，并按访问日期排序，以便使用你上次访问它们的时间作为决定因素。然而，这意味着即使你年轻时给它们打了高分，一些非常老的歌曲也会被遗漏。
我明白这一点，但我无法想到一个解决方案。Discourse实现了我考虑过的唯一替代方案，但（当然）我认为它不如 Threaded discussion is ultimately too complex to survive on the public Internet? - #61 by vel
显而易见的解决方案是使用 blink 标签。并将其设置为尽可能闪烁。也许让它循环显示所有颜色。
<blink> 标签已弃用，通常不推荐使用，因为它对可访问性不利。
摘自该维基百科文章中有关可访问性问题的部分：
Neither of those.
“话题”是一场对话，一次思想的交锋或一轮想法，每一轮都源于之前的内容。在我们交流思想时，我们有意识和无意识地受到所有个体评论的影响，即使我们没有直接回复它们。我们的理解会发生变化，我们会获得新的信息或观点来整合。
将一连串的直接回复视为独立于其余讨论的想法，这是根本错误的。
如果一组回复确实与其余讨论的流程脱节，以至于将其孤立地看待会更有益，那么它就是被分解成自己的顶级话题的绝佳候选。
这就是为什么时间顺序对于阅读和写作都很重要。举个具体的例子，我们在这里的来回交流最终会在像 Reddit 这样的平台上形成一个回复树，不是吗？然而，它们并不能真正独立存在。
恰如其分的是，正是这个过程——观察讨论的展开，包括我没有直接回应的部分，并思考我为什么会这样做——使我能够阐明和完善之前强烈的直觉反应。一个线程模型会剥夺我的这种体验。
I can confidently state that I am unaffected by text which I see whilst scrolling but do not read. To purport otherwise is nonsensical - if the brain does not deliberately comprehend and then commit observed text to memory, it is not stored and consequently unable to affect the reader. Billboards which you pass on the highway but do not read do not affect you.
For me, as long as a discussion about a topic is logically segmented, whether it is arbitrarily designated as a “topic” or “response” has no effect upon me. Think of a filesystem - it is a simple hierarchy of objects, and yet entirely comprehensible and traversable:
A hierarchical conversation should not differ (except that each comment is more frequently multi-line).
Regardless, that’s a rather unsubstantiated opinion, even considering what supposed evidence that you’ve provided:
The example (if I’m correctly identifying the example as the <details>-encompassed section) which you’ve provided doesn’t appear to demonstrate that. However, I understand what you mean, because it’s quite simple to consider a situation in which a threaded response contextually depends upon what it responds to.
However, why do you state this? I ask because all that it appears to demonstrate is that some threads should not be separated into new topics, irrespective of their relevance to the original topic.
I’ve no idea of what you mean by this. It’s too vague.
@Firepup650 和 @vel，Discourse 似乎已经解决了那个问题。只需访问一个指向过去回复的 URI，例如 Threaded discussion is ultimately too complex to survive on the public Internet? - #54 by rokejulianlockhart
这是一个玩笑。blink 标签被过度使用且分散注意力，最终导致试图以此吸引人们注意的网站被人们抛弃（参见广告的过度使用，参见 SNL 的 More cowbell 小品）。
Imgur 采用分层讨论模式，他们通过限制评论长度来规避一些问题。我认为限制是 128 个字符或 256 个字符。新的回复会动态弹出，回复的通知会发送到收件箱并链接回讨论，而且不会丢失任何内容。在 4 或 5 层深度时，它们会加载一个新页面（这不是我喜欢的解决方案）。
他们在平台上还有其他用户体验问题，但分层讨论模型弊大于利。所有评论最初都是折叠的，所以当你看到一个新帖子时，你会看到帖子下方清晰的评论列表，可以轻松阅读和查看，然后可以深入了解讨论（无需重新加载，也不会丢失位置）。
更新：
我并不是建议限制讨论内容长度，而是描述 Imgur 上的该选项如何使分层讨论更具可读性，并建议在分层模型中将其作为一种选项。
@vel，考虑到我在无数 Discourse 实例上看到的频繁的、冗长且极其有用的回复，我确信仅仅为了添加线程而采取这样的解决方案是不值得的。我宁愿进行平铺式讨论，也不愿内容受到限制。
我不知道你如何将我的帖子引述成这样被截断了。 “详细信息”（标记为“警告”）中的内容描述了一个侧面讨论，该讨论可能/可能应该被分离出来，因为它确实与整体对话无关。引述版本似乎重新排序了内容并颠倒了我的意思。
好的，我将尝试更详细地说明并一起解决这两个问题。我断言，持续的对话无法以分层的方式在逻辑上进行分割。
到目前为止，我们之间的来回交流包括帖子
56、57、59、62、63、66、67 和现在的 71。在线程模型中，这些将是它们自己的小树。
然而，这种观点是不准确的。我的帖子 62 的呈现受到了 Vel 的 61 的影响，以及对其的进一步思考，还有 Piffy 的观察，
引导我达到了目前的立场。当然，还有其他影响，但这些是我所知道的最直接的影响。
如果你注意到我提出的论点即使在这个相当短的时间内也在演变，你是正确的。随着我整合对话的各个部分，我调整和完善了我的想法。如果我必须通过线程界面来处理，树状结构本身会将我引入一个回音室，在那里只有我们两个人，思想的交叉授粉将永远不会发生。
如果你是以这种方式对待在线讨论——快速滚动到下一个直接回复，而不至少略读中间的材料来吸收其要点——我将恭敬地建议你：
我可能会推测，这种行为至少部分是由于线程讨论模型教给你的。我怀疑这就是你得到 Reddit 线程的原因，其中：
@Sailsman63，你提出了一个非常好的观点，我实际上倾向于一遍又一遍地重复，当（是的，我会经常使用这个类比）与人们讨论文件系统时——直接的层次结构很少足以展示复杂的关系。
我认为你为 Discourse 提供了充分的证据，证明它既需要一个更强大的通用关系机制，也需要独立的、可扩展的视图模型。具体来说：
在撰写新回复时，允许一个人选择多个评论标记为已回复。这意味着用户不必在评论中标记多个人，如果他们正在回复多个评论，并确保客观地传达他们正在回复的内容。
然后，这可以由用户选择的视图模型（平面、线程、适用于那种整天盯着关系数据库看的人的类似 MermaidJS 的关系图）来消费。
平面视图仅在回复指示标题中显示多个头像。
线程视图将基于响应者指定的“主要”评论（不是理想的解决方案，但直观）。
类似 Mermaid 的视图（星形？）将提供一个关于哪些主题似乎最重要的概述，然后允许用户选择一个评论并切换到上述标准视图之一。
同意吗？
这取决于对话。在这样的主题中，必须考虑所有背景。然而，在一个关于技术问题的帖子中，该问题已经演变成多人之间的讨论，就像现在这样，要求总结或评论特定部分，而无需考虑其余部分。
一切都是成本效益分析。我没有无限的时间。
它当然受到了影响，确实如此。
“另一方面，Discourse 明确地专注于对话，而线性是为了尝试强制执行该原则而施加的约束。”
进一步阐述这一点，这就是真实对话的结构：
主题 A → 问题 → 回答 → 新问题分支到主题 B
题外话 → 交叉引用主题 C → 进一步探讨
上下文循环回到主题 A
鉴于线性讨论的层级性质，例如初始框架变得僵化，限制了后续的讨论，而且任何与之意见不合的代价都很高，因此与真实讨论不同，很少有人会迭代地质疑/完善顶部/父问题/主题。
此外，我认为这种线性的自上而下的层级结构阻碍了整体思维，其本质上是还原论的，使得难以看到大局（尤其是在社会科学等主观领域），而无层级、非线性的、由水平和垂直卡片组成的集合则能够自下而上地思考，使不同观点的上下文连贯成为可能，从而产生同理心。
我一直是扁平化和线索式讨论论坛的长期用户。我在 Facebook 上运营一个拥有 15K 用户的群组，对他们的线索系统非常熟悉。阅读这个话题，我觉得人们没有清晰地思考扁平化与线索式讨论的问题。
首先，这些组织话题回复的方法绝不是互斥的！线索式讨论只是信息的一种视图。Discourse 拥有关于哪些帖子是回复的信息，可以构建回复的线索式视图。从原则上讲，没有理由不能简单地提供一个界面，让读者可以选择任何话题的扁平视图或线索视图，并在阅读时更改该视图。因此，在事先决定一种信息组织方式的问题上进行讨论是愚蠢的。
其次，我认为如果我们问一百万人更喜欢扁平化还是线索式讨论，超过 80% 的人会选择线索式。听到那些坚持扁平化讨论的 20% 的人无视大多数用户的意愿是令人反感的，而解决办法实际上只是一个简单的用户界面选择，正如我已经描述的那样。
第三，线索式讨论在长回复列表中提供的价值是帮助人们节省时间。仅一个用例就可以说明问题。假设我们正在讨论在饮食中使用益生元纤维来促进特定细菌物种在人体微生物组中的生长。一位来自澳大利亚的用户问道：“我在澳大利亚哪里可以买到这个？”这引发了一个包含 50 条来自澳大利亚和亚洲用户的回复的子线索。我不是澳大利亚人。我对这个子线索不感兴趣。为什么要强迫我阅读那 50 条回复呢？线索化提供了一个方便的用户界面，让我可以绕过不相关的子话题，将时间集中在我关心的内容上。
诚然，这些信息本可以以一个链接话题的形式开始。版主也可以将信息移到一个新话题中。但这通常不会发生。在我的论坛上，我几乎没有时间回复用户。我绝对没有时间花一整天的时间来微观管理每个用户所产生的每一个想法的结构。
我希望在未来的某一天，Discourse 能够停止轻视那些想要线索式讨论的 80% 的用户，而是投入开发一个允许每个人做出选择的用户界面。
是否有现有的讨论系统可以做到这一点？我很想了解一下。
从扁平视图切换到嵌套视图可能不难（您允许新线程生成），但从嵌套视图切换到扁平视图似乎会引入大量问题……您如何按时间顺序对回复进行排序并跟上引用？在两个回复之间可能会有 1000 个不相关的帖子……那个扁平视图可能很难使用。讨论系统的类型决定了讨论发生的方式，我认为它们根本不是可以互换的。
我们可以找到说他们更喜欢几乎任何事物的庞大群体……我们不能同时为所有这些人构建。
在扁平系统中，这些内容应该被移到一个标题为：“在澳大利亚哪里可以买到益生元纤维？”的新主题中（并可能进行标记），因为它与原始主题的关联性很弱。这也将使在搜索中找到类似查询变得更容易。
我认为让一个关于益生元的大主题包含无数关于它们的衍生问题是不明智的，对吗？
嵌套讨论通常存在于基于时间的动态中，几乎没有版主或组织工具。这是设计使然，它使对话的风险更低、生命周期更短，并且对提供这些服务的平台来说更省心。这也是为什么在嵌套系统中，您会看到相同的问题每周都会被问到一遍又一遍。关于嵌套的这次讨论已经将近 10 年了！
Facebook 的线程并非旨在构建可搜索的、持久的知识库……这对 Facebook 来说没问题。
这其中没有贬低的意思，您将一个设计选择描述为性格缺陷，这是不公平的讨论方式。
这个决定源于优先考虑集体“社区”而不是个人一对一的讨论。当专注于单一讨论主题时，扁平讨论表现出色，并使每个人都朝着同一个方向前进。您可以沿着一条线索到达目的地。
嵌套有其用途，但正如您所说，它们被用来隐藏讨论。毫不奇怪，线程经常会转向长篇的一对一讨论或辩论，因为其他所有人都忽略它。
扁平系统需要考虑整个主题，并需要一些管理和问题处理……或者在没有版主的情况下，接受每个人都必须跟上所有的曲折。它优先考虑讨论的质量而不是广度。
从线程视图切换到平面视图时，您会按时间顺序对平面视图进行排序。是的，那将允许不相关的子线程插入到平面视图中。这与您现在的情况没什么不同。
假设有 4 个人同时在两个独立的帖子里讨论事情……通过将它们扁平化，你实际上得到了两个相互交织但可能不相关的独立对话。这将很难跟进。
将这 4 个人从一开始就置于一个扁平的讨论中，他们更有可能互相回应，并且在主题上保持更接近，因为他们别无选择，只能一起看到发生的一切。从我的角度来看，到那时你就得到了一个完全不同的对话。
我完全不同意“平铺的回复视图会导致人们避免在隐式子主题中回复”的前提。在我的例子中，澳大利亚和亚洲用户会直接穿过你的平铺回复视图，并拥有他们想要的子主题，无论他们周围的其他子主题是什么。
这就是当前界面存在的问题：要求版主观察每一次对话，然后决定何时（或是否）将讨论分离到一个新主题中非常困难，而且即使发生，也容易产生分歧。使用分层讨论，这个问题根本不存在！
theadminzone.com/threads/is-there-a-forum-software-that-has-a-threaded-view.154403/#post-1182217 [3] [4] ↩︎
access-programmers.co.uk/forums/threads/which-view-do-you-use-flat-or-threaded.86730/#post-386100 ↩︎
xenforo.com/community/threads/will-xenforo-ever-adopt-threaded-comment-structures-like-reddit.205394/page-4#post-1695501 ↩︎
theadminzone.com/threads/is-there-a-forum-software-that-has-a-threaded-view.154403/#post-1189037 ↩︎
感谢您提供的参考资料！
目标是不仅仅依靠版主，对吧？这是一个每个人都应该参与维护的共享空间……人们应该学会将不相关的话题开到别处，而版主应该树立榜样，而不是必须做所有的事情。
我认为，期望版主看不到线程内发生的一切，有点像是大型社交网络用来不进行管理的借口？他们希望最糟糕的内容只是被埋在没人看到的帖子中……所以这不一定是解决方案，而只是一个不同的问题。
不完全是——其他用户会观察并标记需要版主处理。或者他们自己就有权限这样做。当它运转良好时，这可能是一种美妙的社区魔力！
确实如此。但巨大的权衡是，用户需要付出大量的精力才能真正读完整个主题。
我说的是展开主题、阅读它、决定它是否相关、将来努力再次找到它等等。
嘿，Discourse 中的聊天有主题。它非常适合那些永远不会被重温的短暂的复杂聊天。如果你愿意，可以通过那种方式获得满足感。
