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

也许措辞不那么理想。请替换为“相当长”——这个讨论串本身就符合。

在嵌套视图中,您会得到:

  • 帖子
    • 回复
    • 回复
      • 子回复
      • 子回复
        • 反驳
      • 子回复
    • 回复
      • 子回复

如果有人稍后回复了该嵌套讨论中的早期评论,我们会得到:

  • 帖子
    • 回复
      • 新的子回复
    • 回复
      • 子回复
      • 子回复
        • 反驳
      • 子回复
    • 回复
      • 子回复

如果我必须从一个有60条评论的讨论中向上滚动,我该如何找到那个新帖子?


我是在回应您关于不理解缩进如何使事情变得更困难的评论。缩进是使嵌套排序在某种程度上起作用的必要功能。至少对我来说,问题在于排序本身。

2 个赞

@Sailsman63,

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:

  1. 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.

  2. 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.

@Sailsman63,

你不需要这样做,因为新帖子的通知应该会引导用户找到它,就像 Threaded discussion is ultimately too complex to survive on the public Internet? - #62 by Sailsman63 指向你的评论一样。

举个例子,每次我在Reddit上收到关于新通知的电子邮件时,我只需点击按钮即可转到该评论,而不是手动浏览成千上万条评论。

你能详细说明一下吗?

你的意思是,因为排序必然应用于每个层级,所以会产生文件管理器可能导致的问题:

  1. 你有一系列文件,想按修改日期排序以查找一些旧日志。但是,由于这些日志位于一个包含多种文件类型(有些不相关)的目录中,它们会按类型(按字母顺序)分组,这意味着虽然它们总体上是按时间顺序排列的,但新文件出现在底部的几率并非为0。

  2. 你有一系列音乐。你想删除一些你不喜欢的歌曲,但你无法按评分排序,因为有太多歌曲的评分相同。因此,你按评分将它们分组,并按访问日期排序,以便使用你上次访问它们的时间作为决定因素。然而,这意味着即使你年轻时给它们打了高分,一些非常老的歌曲也会被遗漏。

我明白这一点,但我无法想到一个解决方案。Discourse实现了我考虑过的唯一替代方案,但(当然)我认为它不如 Threaded discussion is ultimately too complex to survive on the public Internet? - #61 by vel

2 个赞

显而易见的解决方案是使用 blink 标签。并将其设置为尽可能闪烁。也许让它循环显示所有颜色。

<blink> 标签已弃用,通常不推荐使用,因为它对可访问性不利。

摘自该维基百科文章中有关可访问性问题的部分:

1 个赞

Neither of those.

“话题”是一场对话,一次思想的交锋或一轮想法,每一轮都源于之前的内容。在我们交流思想时,我们有意识和无意识地受到所有个体评论的影响,即使我们没有直接回复它们。我们的理解会发生变化,我们会获得新的信息或观点来整合。

将一连串的直接回复视为独立于其余讨论的想法,这是根本错误的。

Caveat

如果一组回复确实与其余讨论的流程脱节,以至于将其孤立地看待会更有益,那么它就是被分解成自己的顶级话题的绝佳候选。

这就是为什么时间顺序对于阅读和写作都很重要。举个具体的例子,我们在这里的来回交流最终会在像 Reddit 这样的平台上形成一个回复树,不是吗?然而,它们并不能真正独立存在。

  • 如果你只阅读那个回复字符串,而没有中间帖子的上下文,它听起来确实是无稽之谈、不连贯的——而且可能比我预期的更尖刻。
  • 如果我必须根据之前的直接回复进行写作,我们可能在一两条评论后就停止交流了,或者最糟糕的是,开始互相谩骂。

恰如其分的是,正是这个过程——观察讨论的展开,包括我没有直接回应的部分,并思考我为什么会这样做——使我能够阐明和完善之前强烈的直觉反应。一个线程模型会剥夺我的这种体验。

3 个赞

@Sailsman63,

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.

1 个赞

@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 上的该选项如何使分层讨论更具可读性,并建议在分层模型中将其作为一种选项。

2 个赞

@vel,考虑到我在无数 Discourse 实例上看到的频繁的、冗长且极其有用的回复,我确信仅仅为了添加线程而采取这样的解决方案是不值得的。我宁愿进行平铺式讨论,也不愿内容受到限制。

2 个赞

我不知道你如何将我的帖子引述成这样被截断了。 “详细信息”(标记为“警告”)中的内容描述了一个侧面讨论,该讨论可能/可能应该被分离出来,因为它确实与整体对话无关。引述版本似乎重新排序了内容并颠倒了我的意思。


好的,我将尝试更详细地说明并一起解决这两个问题。我断言,持续的对话无法以分层的方式在逻辑上进行分割。

到目前为止,我们之间的来回交流包括帖子
56575962636667 和现在的 71。在线程模型中,这些将是它们自己的小树。

然而,这种观点是不准确的。我的帖子 62 的呈现受到了 Vel 的 61 的影响,以及对其的进一步思考,还有 Piffy 的观察,

引导我达到了目前的立场。当然,还有其他影响,但这些是我所知道的最直接的影响。

如果你注意到我提出的论点即使在这个相当短的时间内也在演变,你是正确的。随着我整合对话的各个部分,我调整和完善了我的想法。如果我必须通过线程界面来处理,树状结构本身会将我引入一个回音室,在那里只有我们两个人,思想的交叉授粉将永远不会发生。


如果你是以这种方式对待在线讨论——快速滚动到下一个直接回复,而不至少略读中间的材料来吸收其要点——我将恭敬地建议你:

  • 剥夺了自己对已发生对话更细致、更广泛的看法。
  • 在有多人同时参与的情况下,剥夺了对话中其他人获得一个考虑到已说过内容的合理回应。

我可能会推测,这种行为至少部分是由于线程讨论模型教给你的。我怀疑这就是你得到 Reddit 线程的原因,其中:

  • 同一个评论被不同的用户在多个地方重复。
  • 一个有见地的观察从未得到回应,因此对讨论没有影响,因为它被埋在线程的 2 或 3 层深处,而该线程由于其第一个帖子不够吸引人而没有得到太多关注。
2 个赞

@Sailsman63,你提出了一个非常好的观点,我实际上倾向于一遍又一遍地重复,当(是的,我会经常使用这个类比)与人们讨论文件系统时——直接的层次结构很少足以展示复杂的关系。

我认为你为 Discourse 提供了充分的证据,证明它既需要一个更强大的通用关系机制,也需要独立的、可扩展的视图模型。具体来说:

  1. 在撰写新回复时,允许一个人选择多个评论标记为已回复。这意味着用户不必在评论中标记多个人,如果他们正在回复多个评论,并确保客观地传达他们正在回复的内容。

  2. 然后,这可以由用户选择的视图模型(平面、线程、适用于那种整天盯着关系数据库看的人的类似 MermaidJS 的关系图)来消费。

    1. 平面视图仅在回复指示标题中显示多个头像。

    2. 线程视图将基于响应者指定的“主要”评论(不是理想的解决方案,但直观)。

    3. 类似 Mermaid 的视图(星形?)将提供一个关于哪些主题似乎最重要​​的概述,然后允许用户选择一个评论并切换到上述标准视图之一。

同意吗?


这取决于对话。在这样的主题中,必须考虑所有背景。然而,在一个关于技术问题的帖子中,该问题已经演变成多人之间的讨论,就像现在这样,要求总结或评论特定部分,而无需考虑其余部分。

一切都是成本效益分析。我没有无限的时间。

它当然受到了影响,确实如此。

3 个赞

“另一方面,Discourse 明确地专注于对话,而线性是为了尝试强制执行该原则而施加的约束。”

进一步阐述这一点,这就是真实对话的结构:

主题 A → 问题 → 回答 → 新问题分支到主题 B
:down_right_arrow: 题外话 → 交叉引用主题 C → 进一步探讨
:down_right_arrow: 上下文循环回到主题 A

鉴于线性讨论的层级性质,例如初始框架变得僵化,限制了后续的讨论,而且任何与之意见不合的代价都很高,因此与真实讨论不同,很少有人会迭代地质疑/完善顶部/父问题/主题。

此外,我认为这种线性的自上而下的层级结构阻碍了整体思维,其本质上是还原论的,使得难以看到大局(尤其是在社会科学等主观领域),而无层级、非线性的、由水平和垂直卡片组成的集合则能够自下而上地思考,使不同观点的上下文连贯成为可能,从而产生同理心。

1 个赞