Tris20
2024 年3 月 28 日 16:32
1
这是对今天 AMA 中一个问题的跟进。David 回答得非常好，并且肯定理解这个问题的出发点。一旦 AMA 视频公开，我就会将其链接到此话题。
最初的问题是：
MSTeams 是一个独立的应用程序，会在开始栏上闪烁通知。它主导了我们公司的沟通，因为它——对所有用户来说，它都只需点击一下即可访问，并立即通知他们新信息。是否有考虑制作某种形式的 Discourse 独立应用程序，或提供此类桌面通知功能？
为了更具体一点，重要的是“为什么”而不是“是什么”。这里的“为什么”如下：
想象一个大公司，有多个沟通渠道：Teams、Outlook、Discourse、Sharepoint，以及更多。
想象你是一个忙碌的人，想联系某人或某个团队来处理某事。
你会：他们的 开始栏上立即收到一个警报，它会闪烁橙色直到他们回复。
我绝对不是在提倡橙色闪烁，但我确实看到我们正在将大量内容流失到 MSTeams。这正是我想要解决的问题，我认为通知系统可能是我们正在丢失的一个环节。
存在必要的摩擦：
但也有额外的 摩擦，这是桌面应用程序所没有的：
考虑 使用 Discourse - 它能提供帮助吗？决定 使用 Discourse - 值得付出努力吗？多久才能有人看到我的话题？打开浏览器
访问网站
登录
请注意，对于 MSTeams，思考和决定过程并不存在。对我来说，只需点击一个按钮即可轻松完成：我立即就可以开始提问。
在接收方这边，也很难知道何时有通知。Teams 会告诉我开始栏上有多少条未读消息，所以我总是知道是否有新消息。使用 Discourse，我需要访问网站或打开标签页，然后才能注意到。
我认为，甚至不需要一个完整的桌面应用程序，也许可以做一个类似于移动应用程序的桌面版本，帮助你更好地管理你的 Discourse 通知。
最终，我们只需要一个能让 Discourse 对所有用户来说始终只需点击一下即可访问，并且无需点击即可知道是否有值得关注的内容的东西。
也许已经存在一些可以作为良好替代品的东西？
5 个赞
mcwumbly
2024 年3 月 29 日 01:25
2
也很乐意在此处讨论
我们对 Discourse 的 Electron 应用（尤其是聊天部分）进行了一些实验。因此，做这样的事情是可行的，但还没有尝试过能够充分考虑为广大用户维护此类应用意味着什么的方案。
我认为你关于通知的猜测是正确的，但我不确定这是否是这里的主要问题。
在这种情况下，我认为人们很可能会选择聊天。我们在 Discourse 中也使用聊天来做同样的事情。你很忙，你在事情的间隙，你有一个问题并想得到快速的答案。输入一个等待着你的框，进入一个你可以看到“很多人正在输入”并且可以得到回答的空间，要容易得多。
我可能会关注其他场景。你提到了这些混合在一起的其他工具：
Outlook 那个。有人发了一封邮件。他们忘记抄送那个人，有人回复添加了他们。这又发生了几次。哦，这个主题上的人太多了。有人回复并删除了大部分抄送列表。下一个回复的人没有意识到不是所有人都还在关注。
唉，我们还是改用 Teams 吧。
“嘿，关于那个邮件线程……”
砰，讨论又出现了一个分支。
如果你能直接在聊天中发布那个讨论的_链接_会怎么样？
我认为这就是关键所在。将讨论从电子邮件转移到 Discourse。然后 MS Teams 会_更好_，因为你可以轻松地链接到那些对话，而无需处理所有其他麻烦。
当然，聊天中也有一些对话，放在 Discourse 中会更好，但这更难推动，正如你所描述的。但我相信你已经在其他工具中也看到了这一点。
“嘿，这个线程有点长了。我们能先把它总结成一个文档吗？”
好的，这是一个不错的步骤。这是一个信号，表明人们愿意在需要时进行异步交流。
然后会发生什么？
文档中的评论线程有多长？你怎么找到正确的那个？
好的，是的，其中一些_文档_可能也最好在 Discourse 中讨论。根据我的经验，这更难实现。有一件事有帮助，那就是从文档复制/粘贴到 Discourse 效果相当好。让人们在文档中起草，但如果期望是文档需要被_讨论_，就将其复制/粘贴到 Discourse 中，并在那里讨论其快照。
这就是我尝试解决这个问题的方式。寻找人们会看到更多价值的场景，并尝试围绕它们制定一种“剧本”。
我喜欢在 Discourse 工作，因为我们几乎只使用 Discourse 来处理过去我需要结合使用多种工具才能完成的所有事情。但现有的公司不是空白的画布，它们已经使用的工具不会轻易被取代。新工具需要能够与现有工具共存。
定义何时使用何种工具的指南可能是有必要的。
以下是我过去遇到的一些例子，人们试图公开地规划这类事情（这两个例子都没有包含 Discourse，但我认为这个想法仍然适用）：
Tristan:
更具体地说，重要的是“为什么”，而不是“什么”。
我想把这个标题改为关于“为什么”的所有内容，并将其移至 Community
5 个赞
Tris20
2024 年4 月 2 日 12:02
3
很高兴听到过去已经对此进行过调查，特别是使用 Electron，尽管我估计要正确地开发和维护它将是一项相当大的工程。
Dave McClure:
在这种情况下，我认为人们很可能会选择聊天。
这是真的，但不幸的是，我们使用的是 MSTeams，而且我认为我们不能使用 Discourse Chat：我们鼓励用户在 Discourse 上共享客户项目之间的信息，但这需要严格审核——客户 A 不能了解客户 B 的秘密武器，反之亦然。通过使用聊天，我们模糊了 Discourse 中这种行为预期，并将好的信息从平台的共享/开放部分转移到完全私有的对话中。即使是“将对话从聊天转移到主题”的功能也可能无济于事——人们在工作环境中会急于处理下一件事，而且他们中的许多人永远不会学会使用此功能。
这完全正确，而且值得庆幸的是，这并没有花费太多精力。
但是，我们如何解决信息朝相反方向流动的问题呢？在 MSTeams 中提出的问题不会产生链接，也不会被广播，而是会丢失在 Microsoft 的以太网中。用户知道他们的收件人会立即收到通知。在 Discourse 中则不是这样。即使有电子邮件通知，这些通知也会与其他消息混合，并且通常会被过滤到一个文件夹中。这种即时性是这些问题在 MSTeams 而不是 Discourse 中提出的一个关键原因。
我可以证明这是一个好流程。它取得了不错的成功，特别是当我们能够将这些主题与具有相同 Markdown 风格的其他平台（如 Gitlab）同步时。
Dave McClure:
感谢您提供这些指南作为参考。我们内部的流程一直很混乱，仍然不明确。平台太多，厨师也太多。我会将这些作为好的例子提出来。
如果您觉得它更适合那个方向，我很乐意您将其移动。对我们来说，关键问题是伟大的长期对话丢失在 MSTeams 中。虽然我们可以继续坚持在 Discourse 中提出这些问题，但“为什么”的一部分是 MSTeams 的即时性。这是 Discourse 目前正在输掉的一点，我认为这是一个巨大的遗憾。我看不出我们会用 Discourse 聊天取代 MSTeams，所以我认为需要有另一种技术层面的竞争方式。
就“什么”而言，桌面应用程序可能是一个前进的方向，但我可以看到这需要付出很多努力，而且真的值得付出这些努力吗？可能不值得。
另一方面，我的搜索引导我找到了一些通知多路复用器/中心。也许值得关注这些项目以供将来集成？我怀疑理想的解决方案是能够集中所有这些通知的单一平台，类似于 Discourse Hub 如何集中用户的 Discourse 通知。
我花了 3-4 分钟看了以下选项。不知道你们是否已经研究过它们以提供集成？像这样的东西有意义吗？
https://novu.co/ - 看似有希望，但我找不到支持的平台列表Pushover: Applications and Plugins - 不确定企业是否会接受GitHub - notifo-io/notifo: Multi channel notification service for collaboration tools, e-commerce, news service and more. 看起来相当不错，Web 界面 看起来相当流畅且易于使用。
1 个赞
您是否已在 Windows 上将 Discourse Web 应用安装为 PWA？它将在任务栏图标上显示通知编号徽章。此功能开箱即用。
3 个赞
Tris20
2024 年4 月 2 日 12:56
5
这是一个非常好的建议。我会试几周看看效果如何。有一个缺点是它只有一个标签页——至少在 Chrome 中是这样。但对于监控通知的这种用例来说，它仍然是一个很好的改进。
对于其他想尝试的人来说，在 Chrome 中，点击 URL 栏中书签星号旁边的桌面图标。
1 个赞
是的，将此与在特定类别上观看第一篇帖子结合起来，可能有助于您收到有关您感兴趣的新主题的未读提醒。
2 个赞
Tris20
2024 年4 月 10 日 13:11
9
使用了一周，仍然很喜欢。我一直在公司推广它，并预计它将对响应时间产生非常积极的影响。
供参考，它适用于：
这是一个关于如何使用 Edge 设置此功能的快速视频。为了方便起见，我将其设置为在启动时运行。
这里还有一篇带有图片的 Chrome 指南：Implement Badging API - #11 by Tris20
1 个赞
Tristan您好。不确定这么久之后是否还有帮助，但我正在为Discourse社区开发一个桌面客户端。由于这是一个非常新的应用程序，如果您能看看并给出您的看法，我将不胜感激。
4 个赞
