是的,对于不想使用 Hub 的每个独立社区,您目前都需要转向 iOS 通知白名单应用程序。
但这已经能满足很多需求了。
这同样也不是 Discourse/CDCK 的问题。生态系统中存在这个选项。
Discord 不必担心定制实例或品牌重塑,Discourse 给了您这种自由,但这也使得部署社区特定应用程序的难度增加。
各有利弊。
给 Tim 打个电话骚扰他…… ![]()
是的,对于不想使用 Hub 的每个独立社区,您目前都需要转向 iOS 通知白名单应用程序。
但这已经能满足很多需求了。
这同样也不是 Discourse/CDCK 的问题。生态系统中存在这个选项。
Discord 不必担心定制实例或品牌重塑,Discourse 给了您这种自由,但这也使得部署社区特定应用程序的难度增加。
各有利弊。
给 Tim 打个电话骚扰他…… ![]()
对于 99.9% 的社群所有者来说,这在时间和精力以及金钱方面都不是一个选项。
在 Discord 上,任何 15 岁的在校学生都可以在 3 分钟内建立一个社群,包括为所有朋友提供手机应用通知,而且没有任何成本,他们的朋友也不需要下载额外的应用程序。
是的,我确实了解并理解这里所有的技术背景,而且我知道这很难解决。但这仍然让许多人望而却步。他们只想让它能用,而这在 Discord 上更容易实现。
我认为问题出在苹果,这很简单。
所有这些用户都不在乎他们需要联系谁,无论是 Tim、Jeff 还是 Jason。他们不在乎这是谁的错。他们想要一个可行的解决方案。
我不是在指责任何人(而且我完全知道如果有人应该被指责,那一定是 Tim
),我只是在解释为什么人们在移动体验方面更喜欢 Discord 而不是 Discourse。
当然可以,但漠不关心也无法解决这个问题。依我看,这实际上是市场滥用问题。我相信欧盟可能会先一步采取行动,但国会现在似乎更加警醒了。人们需要向他们的代表投诉。
这绝对是 Discord 应用的一个有效优势,我百分之百同意。
![]()
![]()
我需要时间思考,然后再给出更多回应,而不仅仅是表达对这个话题的深深感激,但我会做的,但这只是一个开始。
Discourse,移动优先?我以为不是。也许现在是这样,但以前是吗?
某些功能或页面布局在移动设备上并非最佳。
例如,分类页面(依我之见…)需要改进,图像查看器也是如此;你甚至无法左右滑动来浏览多张图像。
嗯……好的,我会更加有意识地注意,并尝试详细说明是什么让我对这两种情况感觉如此不同。
另外,我之前错过了有非官方移动应用这件事。
为移动而生,为触屏而生
Discourse 是为高分辨率触摸设备设计的,内置了移动布局。您可以在您选择的浏览器中,通过笔记本电脑、平板电脑和手机阅读或发帖,或者使用我们的 Discourse iOS 应用 和 Discourse Android 应用。
来自 Discourse features | Discourse - Civilized Discussion
作为不同网络工具的管理员,我印象深刻的是,当我早上醒来,懒洋洋地躺在床上,查看可疑垃圾邮件或标记新主题时,(让我们继续市场推广
)触手可及的完整功能集。或者在停车后、到达办公桌前更新我的宠物项目网站。这些都是真实的情况。 ![]()
我再次检查了 Discourse Hub 应用。它仍然是标题所说的,一个供使用多个 Discourse 实例的用户使用的中心。一旦用户点击一个实例,他们就会 100% 进入他们的浏览器。
Discord 的应用涵盖了所有的移动用户体验,没有任何退出到浏览器的操作。
我认为它们不能相提并论?
在哪里可以找到这个白名单应用?我很乐意尝试一下。
它也是基于 webview 的,但不同之处在于您拥有一个独特的品牌应用程序,该应用程序在 AppStore 中进行营销。需要有人知道他们在做什么,因为设置、配置和维护相当复杂。
我非常喜欢 Hub 和白名单应用程序。
坦白说,我不认为这篇帖子的想法有道理。
像 Discord 这样流行的聊天平台正在将长篇讨论方法融入其核心产品,Discourse 将如何保持作为一种可行的替代方案?只是好奇……
我的理解是……Discord 正试图通过借鉴市面上最好的开源项目之一的透明开发周期中有用的想法来保持其受欢迎的平台地位。Discord 确实感受到了一些发展的压力,但这并不意味着它们比 Discourse 更优越,除了受欢迎程度之外。
现实情况是,主要的专有平台在设计上是停滞不前的。它们的目标是保持庞大。大到不能倒。最终,这些平台会消亡。
Discourse 提供什么?
简单的答案:开放开发,以及对封闭和匿名开放社区的平等访问。Discourse 是一个成熟的论坛产品,它与 Discord 深度集成:机器人、通知、聊天跨帖,应有尽有。而且它还能做更多!任何人都可以参与进来。而且,如果你愿意,可以完全放弃 Discord 集成,迁移到未来不可避免会取代它的任何平台集成。
Discord 将继续保持其原样,一个对 Mumble 的更精美的改进版。它拥有庞大的社区。那些想看看论坛和聊天应用程序正在公开开发哪些令人兴奋的功能的人,会想继续关注 Discourse。你只需要浏览一下 meta,然后根据自己的需要设置 Discourse(无论是否集成 Discord)。
Discourse 难道没有通过增加聊天功能来应对改进的压力吗?难道任何企业不都必须改变才能保持相关性和竞争力吗?这难道不是与你下面说 Discord “刻意停滞不前”的说法相矛盾吗?![]()
“刻意停滞不前”是什么意思?Discord 自从最初作为一款专注于游戏的聊天应用程序以来,已经发生了很大的变化,并且仍在继续显著发展。虽然它们的商业模式与 Discourse 不同,但它们都仍然是企业,它们都仍然想盈利,并且,嗯,变得更大。它们都获得了外部融资来实现这一目标,只是 Discord 筹集的资金比 Discourse 多了一个数量级。
而且,Discourse 本身不就是取代了那些旧的、“大到不能倒”的论坛平台,那些平台“消亡”了吗?它通过比它们做得更好来做到这一点。通过理解旧平台在哪些方面做得不够好并加以改进。
论坛和聊天作为沟通方式的分离正变得越来越尴尬,因此 Discord 和 Discourse 都在努力解决这个问题。这是好事。但我绝对希望 CDCK 认真对待 Discord 试图涉足其论坛领域的努力。这才是它们保持竞争力并继续为我们所有人提供多年来享受的优秀平台的方式。而不是通过将竞争对手斥为“刻意停滞不前”,并期望它们仅仅通过“坚持下去”和足够长的时间就能消亡。
我见过“keyword forum”,谷歌一下你会发现一样的东西。
问任何一个大型聊天版主他们有什么问题,你会得到很多很多的答案。聊天在某些方面很棒,我没有早点接受快车道/慢车道模式是我的错,但它在记忆、组织和保留方面也很糟糕——因此,任何聊天版主都会抱怨同样的问题一遍又一遍地被问到,而且人们期望有一个私人管家在他们输入问题时像喂食一样把答案喂给他们……帮助吸血鬼。
人们确实说过 Slack 是沟通的未来。他们在这方面错了,但他们是对的,聊天正在成为比我预想的更为主流的“社区”模式……但我们正在努力,这很好地展示了快车道/慢车道模式的顺畅集成 cc @JammyDodger
聊天是进行头脑风暴、点燃讨论之火的绝佳场所……并能顺畅地从慢车道过渡到快车道……从为被遗忘而设计的短期记忆,过渡到为我们未来的自己保存的长期记忆。
我仍然觉得进行一对一的功能比较忽略了 Discourse 和 Discord 之间的主要区别。Discord 正在构建一个生态系统、一个共享平台,而要在 Discord 上建立社区的主要原因是你的潜在成员已经在那里了。当你使用 Discourse 时,你是在为你的社区建立一个独立的专用空间。Discourse 的集线器应用程序并未提供集成的平台体验。
因此,对于所有尚未拥有大量成员基础的社区(由于产品或服务),使用 Discourse 的难点在于吸引成员回访并让他们保持了解。这就是为什么聊天在 Discourse 中真正发挥作用的时候,似乎是你已经度过了难关,并且成功吸引了足够多的定期签到的成员。
使 Discourse 在与 Discord 等生态系统方法竞争时更具优势的是易于理解和定制的成员参与设置和功能。根据我的经验,这对于社区经理来说非常复杂且困难。例如,反复有反馈称 Discourse 开箱即用的外观不够现代化。但你是否尝试过让摘要看起来现代化?我希望有人能纠正我,但我发现这几乎不可能或成本过高。
这不仅仅是外观问题,而是关于何时发送消息以及发送给谁的一般调整,这些都没有以直观简单的方式提供。要构建自定义通知策略,你目前需要到处查找,从设置到群组再到标签和类别。
对我来说,如果 Discourse 能够提供一个更简单、更直观、更可定制的成员参与解决方案,那么与社区生态系统相比,它将得到最大的改进。
您有认为现代化的 UI 示例吗?我昨天刚向某人推荐了 Discourse,_因为_它的界面很现代化,但我已经 40 多岁了,我想知道我是否错过了某种趋势。 ![]()
我想到了另一件有助于讨论的事情。与一个应用程序相比,您可以在浏览器中获得所有相同的功能。使用 Discord,您无法自动更新您的状态以显示您正在玩什么,也无法自动移至 AFK VC,可能还有其他一些我想不到的功能。
这可能经常是事实,但绝对不总是如此。事实上,我很想知道它经常是事实。就我自己而言,我曾参与过无数个社区的早期阶段,它们都在问自己“Discord?Discourse?两者都要?”(以及考虑过的其他平台选项),但我一次也记不起有人说过“嗯,Discord 已经有很多用户了”或“我们的许多用户已经在 Discord 上了”。
这些社区涵盖了各种活动,从早期创业公司的应用程序社区,到 YouTube 频道的“扩展”社区,再到一个开源协作项目。在每种情况下选择 Discord 的主要因素是:
因此,我认为再次将 Discord 和 Discourse 视为采取不同方法并因此服务于不同市场/受众/目的将是一个错误。这可能会忽视 Discourse 持续采用和成功的非常真实的潜在挑战。我意识到这并不是你所说的,但你提出的一些观点似乎迎合了那些我认为其他人也表达过的观点。
我同意这一点……
但绝对不是这样。聊天本身就是回访的原因,聊天是“粘性的”。当然,你需要一定的临界质量,以便能够足够快地为新成员提供足够的回应,让他们觉得充满活力并值得回访。但这正是社区建设者所做的,他们可以在同一个空间中使用实时聊天选项非常有效地做到这一点。
我绝对同意这一点,这需要变得更容易。话虽如此,如果其他一些主要问题——尤其是价格/托管复杂性以及移动体验(通知、iOS)——没有得到解决,我不知道这是否足够。
你们需要做一些能解决大型聊天版主的问题的事情,还是做一些更专注、能利用 Discourse 的优势来实现一些特殊但更具体的功能?从功能角度来看,我不太清楚 Discourse(应该)最擅长什么。可自行托管当然是一项功能。我想起了 Hypothes.is 和 Genius。他们曾有宏大的抱负,要注释一切,但只有在缩小了关注范围后才变得最强大(Hypothesis 专注于学者;Genius 专注于歌词)。我想 Discourse 已经多年来为自己做出了决定,最适合技术和消费者社区的需求。我最感兴趣的是将 Discourse 用于学术目的,而且许多设计决策似乎是为 FAQ 论坛设计的。
这甚至不是关于“聊天”。聊天不再是像以前那样的软件类别,也不是“论坛”或“社交媒体”(它们正在融合,使得区分的误导性大于实际意义)。利用这一点是 Discord 如此出色的原因:
https://www.protocol.com/discord
是的。人们讨厌 Facebook 和其他旧的社交媒体,但仍然不情愿地回到那里,因为聊天(通常是年长的家庭成员或很久以前的熟人)。
我想知道 Discourse 聊天是否可以进行修改以达到这个目的?例如,每次聊天在设定的时间后被删除,或者每个频道只保留最后十条消息?这将迫使对话者做出一个决定——这是可以随意丢弃的闲聊,还是我们可能想要保留的东西?
在公司层面,我们不会使用 Discourse 聊天,因为托管要求会带来一些法律上的雷区:
对我来说,这可以有两种可能的、不同的侧重点。
诚然,一个站点可以兼顾两者,但我认为将它们分开或至少使用类别进行隔离是有意义的。
你能详细说明一下吗?不一定非要同意我的想法。
我的主要 Discourse 站点是为 SWI-Prolog 准备的。
我不想让这个变成公开的题外话,所以如果你愿意,可以随时给我发私信。