啊……话题,这个神秘的、期待已久的功能,为我们带来了结构化的承诺。
它们是什么,它们做什么?
话题是在主聊天频道并行进行的范围限定的对话。
通过回复一条消息……
……你将 自动 开始一个新话题。
话题以多种方式显示,以帮助你和他人一起深入探讨。
频道中的话题指示器可帮助你了解其中的情况
所有回复都整齐地隐藏在专门的话题面板中,取而代之的是一个闪亮的新话题指示器。显示了参与者、回复计数和最后一条回复,让你一窥其中的情况,以帮助你决定是否要深入探讨该主题。
在关注频道的同时在侧边聊天
进入一个话题并进行你通常进行的任何操作,同时还能关注主聊天中的情况。查看主聊天话题指示器实时更新最新信息。
回复一个话题或手动跟踪它以查看未读回复指示器:
查看你参与的所有话题
话题索引提供了一种方便的方式来查看你参与过的所有话题。对上周的讨论有了新的论点?现在你可以直接回到其中!你可以在频道右上角访问它,在那里你会看到未读话题的总数指示器。
在话题列表中,你将看到自上次访问以来每个话题有多少未读回复的指示器,以及最后一条回复的时间戳:
话题能为你做什么?
你是否曾觉得无法跟上一个繁忙的聊天频道中同时发生的 4 场不同对话,并且只是 最希望 有一种方法来给混乱带来秩序?
这正是话题可以帮助解决的问题。
这就像在主聊天派对中举办迷你聊天派对!你可以像蹦床公园一样跳进不同的房间,从一个话题跳到另一个话题。哇!
话题为你带来:
组织 - 就特定主题进行分组对话,使讨论保持专注和受控
情境化 - 立即了解最新情况,无需在主消息流中拼凑所有相关消息
整理 - 像 Marie Kondo 一样整理你的频道;这个能带来快乐。
如何获得它们?
网站管理员可以在创建频道时启用话题:
或者通过频道设置对现有频道进行设置:
讲述你的想法
幕后还有更多想法,但目前就这些基础知识!一些想法包括:
改进跨频道的话题发现
在频道和话题之间移动消息
与论坛主题更紧密地集成
向频道广播消息
以及更多
你喜欢吗?我们很想听听!
你有疑问 、想法 或反馈 ?请在下方留言。
54 个赞
这可能是我读过的对讨论串聊天最棒的描述了。 干得好,@chapoi 。
感谢你和团队实现了这个功能。我们这周会在社区里试用一下,并分享反馈。
16 个赞
Firepup650
(Firepup Sixfifty)
2023 年7 月 5 日 17:20
4
想法:能够批量关闭新主题
在我们的主聊天频道上启用主题后,我们立即飙升至 99+ 个打开的主题,我发现只能通过阅读来关闭它们。像我们处理通知一样,有一个批量关闭按钮会很好。
11 个赞
另一个想法:让帖子在最后回复后的一段时间(1 天、3 天、1 周)后消失,或提供自定义选项以避免混乱:
原因:这很容易在聊天频道中造成帖子混乱。因此,在最后回复和一段时间后自动删除它们将有助于清理聊天。
说真的,这都是什么乱七八糟的?
此外,这个新功能让我想起了 Discord 中实现的一个功能:
8 个赞
twofoursixeight:
说真的,这是什么鬼?
这是有效的反馈。
我认为当人们理解了“帖子串”(threads)的概念后,情况会有所改善,而不是像现在这样,所有的回复都变成了帖子串,而人们在创建回复时并没有考虑到帖子串。在这种情况下,回复就会变得混乱不堪。我很想知道一周后,当人们有意识地使用帖子串时,你是否还会觉得混乱的体验依然存在。
请告诉我们?
10 个赞
在很多情况下,似乎主题(threads)使得复兴或引用旧的讨论变得更加困难。
此外,它们使得在移动设备上使用 Discourse 聊天更加困难。
7 个赞
Firepup650
(Firepup Sixfifty)
2023 年7 月 5 日 22:45
8
主意:将现有回复保留为回复,只将新回复移至线程。
这可以帮助防止在启用时,一些现有回复变成混乱的线程,同时仍能提供线程的未来优势。
6 个赞
martin
(Martin Brennan)
2023 年7 月 5 日 23:40
9
Firepup Sixfifty:
Upon enabling threads on our main chat channel, we immediately spiked to 99+ open threads, and I found that you can only dismiss them by reading them. A bulk dismiss button like we have for notifications would be nice.
We hear you, this was an oversight on my part. I think maybe when you enable threads for a channel, we just need to automatically go back and mark the old threads as read.
We actually already have a Shift+Escape shortcut to mark all channels read – maybe we can also do a similar shortcut on the threads list to mark all threads as read.
Sorry but this is not possible, the replies have been making threads in the background for months now as part of this transition and to make it easier to switch between threads enabled/threads disabled in a channel. However when we fix the issue with old threads being unread when you turn it on for a channel this should not be an issue.
This is a good idea and we have discussed something like this already; I agree that generally it’s not too useful to see threads from months ago. Keep in mind this is V1 and we will be doing more improvements over the coming months.
Also the thread list will be improved very soon to have more detail.
9 个赞
sunjam
(james.network)
2023 年7 月 6 日 01:09
10
令人兴奋,未来聊天中或许可以搭配Matrix支持 。
6 个赞
Firepup650
(Firepup Sixfifty)
2023 年7 月 6 日 02:40
11
啊,我不知道!
说到这个,任何移动用户界面都可以访问那个键盘快捷键吗?
7 个赞
martin
(Martin Brennan)
2023 年7 月 6 日 06:25
12
我刚刚合并了一个针对此问题的修复程序。当您为某个频道启用主题时,我们会排队一个后台作业来将所有现有主题标记为已读:
main ← issue/mark-threads-read-when-threading-enabled-in-channel
opened 02:58AM - 06 Jul 23 UTC
Since we create threads in the background regardless of whether
threading is en… abled for a channel, we get the unexpected behaviour
of everyone having a lot of unread threads when threading is enabled
for the channel.
To counteract this, when the admin enables threads for a channel
we can just run a high priority background job to mark all threads
as read in the channel for all users, so they are essentially
starting from a clean slate.
一旦此修复程序在您的站点上部署,如果您已经为某个频道启用了主题,只需禁用它然后再次启用它,问题就会得到解决。
11 个赞
想象一下,有人发送了一条消息。该消息会吸引评论,这些评论存储在一个线程中。现在,如果我想专门回复线程中的某条评论,该怎么办?如果人们看不到我是在专门回复那条评论,我的回复将毫无意义。您是否考虑过这些场景?是否有计划在线程中引入回复(不是说它们会扩展成新线程,而是仅仅有一个视觉指示表明这是对上方消息的回复)?
6 个赞
mcwumbly
(Dave McClure)
2023 年7 月 9 日 02:14
14
我们确实考虑过,但决定首先以简洁性为目标,不同时支持这两个概念。
根据我们目前的观察,虽然有些情况下这可能会有帮助,但这种情况相对较少,而且人们也发现通过添加“@”来区分信息在这些情况下效果很好。
另一个曾多次提出的想法是在聊天中支持引用回复。我们出于类似的原因尚未采纳,但有时我确实希望它存在(我也会尝试使用 > 来解决这个问题,但我发现很少有人会这样做,所以我认为如果我们希望鼓励这种行为,就需要提供更强的引用回复支持)。
9 个赞
这是一个绝佳的机会来解决我在迄今为止使用过的所有平台上的聊天群组中一直存在的一个巨大问题。无论某个对话串是否包含有用信息,问题的普遍性在于:如何防止一个大群组内的人员子群组用只有该子群组感兴趣的评论来淹没其他人(假设常见的情况是零散的主题或闲聊,不值得拥有自己的频道)。一种初步的解决方法是强制聊天中的每条评论都定义它是普通评论还是对另一条评论的回复,这正是 Reddit 所做的(你不能不指定你在回复什么)。但在一个大群组中,Reddit 很快就会变成一个混乱、难以追踪的对话,所以折衷的办法是只允许一级嵌套回复,并结合 WhatsApp 那样的简单“回复”方式。一堆嵌套回复会让聊天难以追踪和阅读,所以与其将对话隐藏在每个嵌套回复中,不如将“嵌套回复”与“回复”动态结合起来,从而实现“分组 ”:评论可以根据它们回复的对象在聊天中进行分组(如果用户不关心,就不会向他们发送通知)。例如:
A - “评论 1”
B - “评论 2”
C - “回复评论 1”
A - “回复评论 2”
B - “回复评论 1”
这将在聊天中显示为:
A - “评论 1”
C - “回复评论 1”(A 会收到回复通知)
B - “回复评论 1”(A 会收到回复通知)
B - “评论 2”
A - “回复评论 2”(B 会收到回复通知)
可以有一个视觉提示,表明哪些评论属于一个分组(尽管在同一分组内没有视觉区分),让用户能够快速跳过那些他们不感兴趣的零散分组,一旦他们进入某个分组,就不会再被他们已经离开的分组或可能在下面的分组打扰(无论是视觉上还是通过通知)。
2 个赞
一些反馈。
我很喜欢 Threads 的体验。设计和实现都非常清晰简洁。
有一点我不确定,那就是当有人回复我的 Threads,或者至少是我参与过的 Threads 时。我感觉好像会错过回复,除非我主动回去查看。
我看到当我发起一个聊天时,“跟踪”是默认在该 Threads 上设置的,但我从未在有人回复时在侧边栏看到新回复的计数。我应该在那里看到它吗?或者我应该在其他地方看到我没注意到的计数吗?
啊哈,我刚刚在 Threads 图标上方的右上角发现了它。
也许在侧边栏中包含这个计数指示器也会很有帮助,因为那里是我查看是否有新内容的首选位置,无论是新帖子,还是现在通过/在 Threads 中的回复。
编辑:我主要在全屏模式下使用聊天,而不是迷你模式。也许 Threads 计数和侧边栏之间的“距离”与我感觉两者之间的认知脱节有关。
7 个赞
j.jaffeux
(Joffrey Jaffeux)
2023 年7 月 11 日 11:13
17
侧边栏中的某个指示器即将推出 它不会显示计数,但即使在回复中,您也能知道此频道中有活动发生。\n\n请继续提供反馈,我们正在积极构建此功能,并且会阅读所有反馈。
13 个赞
Dave McClure:
虽然在某些情况下可能有用,但它们相当罕见
在我们的论坛中,聊天主要用于非正式的闲聊,偶尔开开玩笑。这实际上是我所指的使用场景,虽然@提及功能可用,但如果你想开玩笑的话,它有点不合适
Dave McClure:
如果我们希望鼓励这种行为
有人可能会说,进行非正式的对话是良好的社区凝聚力体验,而且企业客户(我推测是您观察的主要来源)在他们的 Discourse 实例中可能不太需要闲聊,这并不奇怪,但我明白我可能是错的。
另外,我们的用户喜欢帖子串。
8 个赞
我看到你们大多数人都喜欢在聊天中使用帖子。我能否至少建议你们考虑一下我提到的这种分组方法,以便在聊天中自动识别明显应该是帖子的内容,即使它最初没有被定义为帖子?如果你们的体验不是这样,请纠正我,但我看到很多评论说“这应该是一个帖子”,仅仅是因为很难判断一个随机的对话何时需要它自己的帖子。我认为简单的分组将始终处理好这个问题,而无需担心。
4 个赞
Bug 报告:新帖子以及可能帖子的回复在现有聊天中不可见,除非强制刷新。这可能(并且已经)导致用户出现问题。
3 个赞