# 轻量级桌面应用程序用于Discourse的可行性有多大，是否能提高用户参与度和/或通知意识？ **URL:** \ **Category:** Feature\ **Created:** [2024 年3 月 28 日 16:32 UTC](https://meta.discourse.org/t/how-viable-is-a-lightweight-desktop-app-for-discourse-and-could-it-improve-engagement-and-or-notification-awareness/301373 "2024-03-28T16:32:00Z")\ **Posts on this page:** 1\ **Showing post:** 3
作者： ![Tris20](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tris20/32/264639_2.png) [@Tris20](https://meta.discourse.org/u/Tris20)\ 发布日期： [2024 年4 月 2 日 12:02 UTC](https://meta.discourse.org/t/how-viable-is-a-lightweight-desktop-app-for-discourse-and-could-it-improve-engagement-and-or-notification-awareness/301373/3 "2024-04-02T12:02:38Z")
> [@mcwumbly](#): > > 已经对 Discourse 的 Electron 应用（尤其是聊天部分）进行了一些实验。所以做这样的事情是可行的，但还没有尝试过完全考虑维护这样一个面向广大用户群体的应用意味着什么。 很高兴听到过去已经对此进行过调查，特别是使用 Electron，尽管我估计要正确地开发和维护它将是一项相当大的工程。 > [@mcwumbly](#): > > 在这种情况下，我认为人们很可能会选择聊天。 这是真的，但不幸的是，我们使用的是 MSTeams，而且我认为我们不能使用 Discourse Chat：我们鼓励用户在 Discourse 上共享客户项目之间的信息，但这需要严格审核——客户 A 不能了解客户 B 的秘密武器，反之亦然。通过使用聊天，我们模糊了 Discourse 中这种行为预期，并将好的信息从平台的共享/开放部分转移到完全私有的对话中。即使是“将对话从聊天转移到主题”的功能也可能无济于事——人们在工作环境中会急于处理下一件事，而且他们中的许多人永远不会学会使用此功能。 > [@mcwumbly](#): > > 如果能将该讨论的_链接_直接放入聊天中呢？ > > 我认为这就是关键所在。将讨论从电子邮件转移到 Discourse。那么 MS Teams 就_更好了_，因为你可以轻松地链接到这些对话，而无需处理所有其他麻烦。 这完全正确，而且值得庆幸的是，这并没有花费太多精力。 但是，我们如何解决信息朝相反方向流动的问题呢？在 MSTeams 中提出的问题不会产生链接，也不会被广播，而是会丢失在 Microsoft 的以太网中。用户知道他们的收件人会立即收到通知。在 Discourse 中则不是这样。即使有电子邮件通知，这些通知也会与其他消息混合，并且通常会被过滤到一个文件夹中。这种即时性是这些问题在 MSTeams 而不是 Discourse 中提出的一个关键原因。 > [@mcwumbly](#): > > 好的，是的，其中一些_文档_可能也最好在 Discourse 上讨论。根据我的经验，这是一种更难的转变。有帮助的一件事是，从文档复制/粘贴到 Discourse 的效果相当好。让人们在文档中起草，但如果他们的期望是文档需要_讨论_，就将其复制/粘贴到 Discourse 中，并在那里讨论其快照。 我可以证明这是一个好流程。它取得了不错的成功，特别是当我们能够将这些主题与具有相同 Markdown 风格的其他平台（如 Gitlab）同步时。 > [@mcwumbly](#): > > - [https://works.hashicorp.com/articles/standard-communication-tools](https://works.hashicorp.com/articles/standard-communication-tools) > - [https://handbook.gitlab.com/handbook/communication/](https://handbook.gitlab.com/handbook/communication/) 感谢您提供这些指南作为参考。我们内部的流程一直很混乱，仍然不明确。平台太多，厨师也太多。我会将这些作为好的例子提出来。 > [@mcwumbly](#): > > 我倾向于将此标题重命名为完全关于“为什么”，并将其移至 #Community，但会先让您考虑一下这个想法。 如果您觉得它更适合那个方向，我很乐意您将其移动。对我们来说，关键问题是伟大的长期对话丢失在 MSTeams 中。虽然我们可以继续坚持在 Discourse 中提出这些问题，但“为什么”的一部分是 MSTeams 的即时性。这是 Discourse 目前正在输掉的一点，我认为这是一个巨大的遗憾。我看不出我们会用 Discourse 聊天取代 MSTeams，所以我认为需要有另一种技术层面的竞争方式。 就“什么”而言，桌面应用程序可能是一个前进的方向，但我可以看到这需要付出很多努力，而且真的值得付出这些努力吗？可能不值得。 另一方面，我的搜索引导我找到了一些通知多路复用器/中心。也许值得关注这些项目以供将来集成？我怀疑理想的解决方案是能够集中所有这些通知的单一平台，类似于 Discourse Hub 如何集中用户的 Discourse 通知。 我花了 3-4 分钟看了以下选项。不知道你们是否已经研究过它们以提供集成？像这样的东西有意义吗？ [https://novu.co/](https://novu.co/) - 看似有希望，但我找不到支持的平台列表 [Pushover: Applications and Plugins](https://pushover.net/apps) - 不确定企业是否会接受 [GitHub - notifo-io/notifo: Multi channel notification service for collaboration tools, e-commerce, news service and more.](https://github.com/notifo-io/notifo) 看起来相当不错，[Web 界面](https://app.notifo.io/) 看起来相当流畅且易于使用。 --- _[View the full topic](https://meta.discourse.org/t/how-viable-is-a-lightweight-desktop-app-for-discourse-and-could-it-improve-engagement-and-or-notification-awareness/301373)._