为什么不更经常推荐Discourse作为"社区平台"?

我认为他们确实这样做了,推荐了 Mailgun。我希望有一个傻瓜指南来使用 SES,因为它便宜 10 倍。

我也不同意上面关于 Meta 不是 Discourse 好广告的评论。首先要看的就是软件的实际运行情况。

也许整个 VPS/“droplet”的要求会让一些人望而却步。我使用共享服务器已经十多年了,才明白非托管 VPS 总体上也很容易使用。

2 个赞

“也许整个VPS/“droplet”的要求会让一些人望而却步。我使用共享服务器已经十多年了,才明白非托管VPS总体上会和它一样简单。”

这正是我想要表达的意思。在过去,你可能只需要通过Cpanel添加Discourse,但现在却更加麻烦。如果能像集成到DO的 marketplace 应用那样,或者类似的东西,就能降低门槛,让它回到过去那种可以花很少的钱在共享服务器上运行论坛的好日子。

3 个赞

但我们不想被绑定到单一供应商。

我偏爱 Scaleway,其他人偏爱 Hetzner,还有人偏爱 Linode……

如果你想要这种级别的简单性,也许你_真正_想要的是一个托管服务提供商?

2 个赞

这并非我个人想要的,最初的建议是为了让自托管更容易。我后来又查看了文档,发现它们比我最初设置时要好一些,但确实比一些同类应用程序要难。让它更容易打包给人们将有助于他们入门。

4 个赞

曾有几个人来 Meta 询问是否有专门使用 Discourse 的社区、论坛和公司目录。他们被引导至 Discourse.com,该网站展示了使用 Discourse 的主要公司和社区,并注明有些公司/社区不希望被“宣传”。我有一个托管的私人论坛,我属于这一类。 :slightly_smiling_face:

1 个赞

所以人们愿意讨论猫、政治、狗、烘焙、拳击和烘焙,只要平台是 Discourse?我很难相信这一点。

但即使我一直在寻找 Discourse 论坛,也是因为我想在启动 VPs 之前看看它是什么样的。

频繁地坚持认为安装/设置过程和/或用户界面并不复杂,争论用户体验,或者普遍要求某人证明他们的经验和观点,都表明了我之前试图阐述的那些问题。这也是我有时对这个社区感到厌烦的(少数)原因之一,这让我非常沮丧。

如果有人是 Discourse 的管理员(或用户),他们花时间来到这里告诉社区“我设置 Discourse 的经验比我认为应该的要困难”,请听他们说,首先要接受他们的经验是有效的。是的,这是他们的个人意见,而且要求他们具体说明困难之处是合理的。但这不应该被呈现为需要这个人证明他们的观点和经验与他人相比的合理性。即使无法或没有提供具体细节,报告本身,用户的主观经验也是重要的

软件开发者的工作是努力理解用户的痛点。用户的工作不是要知道他们为什么会有这种感觉并将其传达给开发者。这是软件开发的一个基本挑战,有无数的文章和轶事讲述了它的困难。许多备受尊敬的科技行业人士(例如史蒂夫·乔布斯)甚至认为用户甚至不知道自己想要什么,所以直接询问他们不一定是最好的方法。但即使是这样,大多数用户(包括管理员)也不是 UI/UX 专家,因此他们识别和描述所遇到问题的能力可能有限。

即使一个用户拥有专业知识来帮助他们做出更有效的错误报告,这也需要花费大量的时间和精力来详细说明他们遇到的问题。这就是为什么要做用户研究,为什么它们很有用,以及为什么通常的方法只是观察一个人执行任务,而不是让他们展示某个特定问题,更不用说描述它。

我认为认识到人们以前使用过其他看起来相似的(对用户/管理员而言,非编码者)工具也很重要。现在许多建立社区的人都有过搭建 PHP 应用程序的经验,甚至可能搭建过像 PHPBB 这样的论坛。相比之下,Discourse 的设置就相对复杂了。当然,PHP 和 PHPBB 本身的设置都有一些不理想的方面,也有例如它使用的邮件设置不如 Discourse、Rails 等原因。但这些信息(不仅仅是如何设置 Discourse,而是为什么它比其他一些系统更难以及这些权衡是什么)在任何地方都没有得到很好的解释,这也是让潜在用户望而却步的一部分原因。

最后,关于安装的简易性、文档以及自托管是否不是一个“受推荐的路径”,值得看看 Discourse.org 主页近几年的变化。这是 2021 年的样子:Discourse.org 在 web.archive.org 上的 2021 年存档

请注意,通过 Github 进行自安装的引用不仅在页面上位置更高,而且包含直接链接,而在当前网站上,在首次提及开源的地方没有链接,并且“安装”一词从未被使用过。因此,对于任何不一定已经知道 Github 链接就是安装链接(并且那里有指导安装的文档,而 Discourse 网站其他地方都没有提到)的人来说,这是一个微妙但值得注意的因素,会阻止他们调查自托管。

免费开源与开发某个 OS 项目的实体的利润之间的紧张关系是一个根本性的问题,所以我理解这些变化。但对我来说,很明显 OS/免费/自托管正在被淡化,在我看来,这表明它是一个不太“受推荐的路径”,仅供参考。

12 个赞

公平地说——我认为这是一个很好的提醒。

那么,请尽管提问吧!

让我们具体说明安装的哪个部分很困难,以及如何改进这些说明或改进工作流程来构建新的实例。

(我猜这可能应该在 Installation 中单独开一个主题?)

话虽如此——我不好意思说 :blush:,早在 2017 年我接管我的第一个 Discourse 论坛时,我没有任何 Linux 服务器经验(尽管我当时有一些 Unix 培训和工作经验,所以命令对我来说并不陌生)。

然而,总的来说,这对我来说是一次重要的学习之旅,但我很享受。我把关闭知识差距的责任推给了自己,当然,这也得到了这个网站社区的帮助。

在我看来,如果你把它做得太“容易”,那么当以后出现问题时(这些问题通常是由于糟糕的选择而自找的,因为软件和服务器通常都非常健壮),你就会很容易垮掉,因为你没有学到足够多的关于如何以及为什么(但话说回来,问题大多数时候都应该被视为学习更多东西的机会!)。

6 个赞

这并非出于任何商业目的而明确淡化这一点,我们仍然认为任何 Discourse 安装都是好事,无论我们是否直接获得报酬。我们很有可能会根据这些反馈再次添加一个链接。

12 个赞

也许吧,但对我来说,这有点(无疑是无意的)精英主义,即“我以(更)艰难的方式做到了,我认为这对我有好处,因此每个人都应该这样做,因为这对他们也有好处。”作为一个在 PHP 自托管领域摸爬滚打了数十年,最终才开始尝试 Discourse 自托管的人,我可以告诉你,大多数 PHP 工具的自托管安装和维护更容易,但有有用的学习时刻,有时你不得不进行故障排除或深入研究配置甚至代码(就像 Discourse 有时那样)。

事实上,我在使用 SMF、Wordpress 和许多其他 PHP 工具期间学到的一切,绝对为我提供了足够自信和知识来艰难地完成 Discourse Docker 的安装,即使如此,我有时也会发现自己对着控制台中的一个晦涩的错误消息苦思冥想一个小时左右,才能让我的实例重新运行起来。但关键是,我进入 Discourse 自托管领域,得益于我在 PHP 自托管中学到的东西,而那个学习曲线无疑比 Discourse 的学习曲线要平缓得多。在 CDCK 和整个社区试图推广和发展 Discourse 作为平台时,这一点值得牢记。简而言之:我很高兴设置 Discourse 帮助你学习了在其他地方有用且适用的技能,但在我看来,仍然有价值的是尝试让这个过程对人们来说变得越来越容易(在合理的范围内)。

很高兴听到这个消息,我希望你们能这样做!我认为一些细微的调整可以更好地平衡,一方面概述了真正即插即用的托管选项,另一方面清楚地表明 Discourse 也是免费且(在某种程度上)易于自托管的,并且可以在 Github 上找到安装文件和说明。作为另一个例子,许多其他开源项目在其主导航菜单中都有直接指向文档的链接,这些文档通常包含安装部分。 Discourse.org 上缺乏这一点(而且“入门”链接在我看来根本没有提到自托管,只是假设你已经有一个 Discourse 实例)使得更清楚地说明如何根据需要进行自托管变得更加重要。

3 个赞

嗯……一点也不是,更像是一种愿意为自己缺乏知识并需要改进它承担责任的意愿,同时谦虚地认识到,我正在免费受益于他人的辛勤工作。

3 个赞

我认为 Discourse 的安装难度或易用性与此话题关系不大。现实情况是,可能只有千分之一或万分之一的 Discourse 用户需要学习如何安装它。此外,还有付费选项,所以如果价格合适,安装论坛没有任何学习的义务。

当人们想要寻找或建立一个社区时,普通用户不会想“哪个平台最适合与我的兴趣社区交流?”他们只会使用他们已知的平台。这就是为什么在我的爱好领域,99% 以上的讨论和互动都发生在 Facebook/Instagram/Reddit/Discord 的组合上。这对我来说也有些遗憾,因为通常我在这些网站上看到的互动质量远不如我在 Discourse 论坛上获得的活跃度(我可能有些偏见 :slight_smile: 但我确实是这么认为的)。

这是互联网活动日益集中在少数几个超大型平台上的一个更大(而且(可以说)有问题)的趋势。我不能真正责怪 Discourse 在这场战斗中失败,因为这是一场竞争,而对手拥有多出几个数量级的资源和工程师。话虽如此,Discourse 总能做得更好。

人们倾向于使用他们已经知道的东西,而人们并不知道 Discourse。这是因为他们要么从未用过 Discourse,要么在不知情的情况下用过它。在我看来,应该优化的首要指标是将访问者转化为用户。Discourse 论坛相对于许多其他平台的一个优势是它具有天然的搜索引擎可发现性。例如,在我自己设置论坛之前,我没有注意到我通过 Google 搜索访问了多少 Discourse 论坛。现在我时时刻刻都在注意到。说实话,我以前从未加入过一个通过 Google 搜索找到的论坛(我想除了这个元论坛)。我想说的是,你需要最大限度地让用户真正有意识地使用该平台。那些使用并喜欢该平台的用户最终会推荐它。

至于具体是什么阻碍了 Discourse 发挥其潜力?这是一个难题。我同意那个推高了此帖子的帖子的观点,即用户界面是一个重要因素。用户界面之所以复杂,是因为该软件非常灵活和成熟,这很好。但这种灵活性也可以更好地用于定制用户体验,以匹配用户的经验水平,如上所述。或者开发其他的入门工具或激励系统,鼓励网站访问者进行互动和加入。还有一种观点认为论坛是过时的平台,是给老年人用的(我经常听到这个说法)。尽管这更多是看法而非现实,但很难克服。

既然提到了,我想做个题外话。这完全是我个人的看法,但我认为整个聊天系统都是臃肿软件。它与直接消息系统令人困惑地重复,而且最后一个人需要的是另一种直接发送消息的方式。它是一个劣于 Slack 和 Discord 客户端的替代品。这很可惜,因为我同意聊天和论坛是互补的理念。但没有人会离开 Discord 来 Discourse 上聊天。这是一个错失的机会,因为如果将 Discord 集成作为优先事项而不是替代品,你将为熟悉 Discord 的人([大量人群])提供一个轻松的入口,让他们接触到 Discourse。这是一个非常边缘化的观点,但也是我在写这些东西时想到的。

13 个赞

嗯,作为这个主题的发起人,我至少可以肯定地说,这并不正确;事实上,这几乎与我最初的意图完全相反。我提到的第一个帖子和 Twitter 上的讨论串是关于那些想要建立新社区(即寻找社区平台)的人,他们考虑 Discourse 的频率或认真程度不如我认为的,考虑到其功能和优势。后来关于用户体验等的讨论与管理员可能决定不使用 Discourse 建立新社区的原因有关(例如,“它看起来不够现代”,或“人们认为它太复杂”),但安装/设置/管理员体验的考虑也是如此。作为几个社区的现任管理员,以及更多社区的前任管理员,这些无疑是我参与设置的任何社区的首要考虑因素。

也许不是,但恰恰相反(人们离开 Discourse 去 Discord)绝对是,而且这对于 Discourse 来说也是一个潜在的问题。我绝对认为开发集成聊天功能符合该平台的最佳利益,因为聊天是当今主要的通信媒介,并且是 Discourse 核心交互方式的竞争对手。任何重视聊天以及 Discourse 其他优势(尤其是开源和数据所有权)的人都不会受益于 Discord 集成(不开源、不自托管、无数据所有权),因此,符合 Discourse 模型和精神的聊天功能再次符合我的看法。

5 个赞

这是一次很棒的讨论。我们当然清楚,用户体验的复杂性(无论是对网站管理员还是社区成员而言)是我们面临的挑战(并且已经面临了一段时间)。

正如大家所提到的,我们有一些目标有时会相互冲突——我们希望 Discourse 具有高度的可配置性和可定制性,通过这样做,我们将极大的控制权交给了每个社区的管理员,让他们来定义其成员的用户体验。同时,我们希望新用户能够轻松理解,但我们也发现,有经验的用户希望在个性化自己的体验方面拥有相当大的控制权。

我们有很多工作要做,但我们正将相当多的精力集中在这些问题上。在上一版本中,我们特别在网站设置体验方面付出了一些努力。对于即将发布的版本,我们关注的重点是更广泛地改进管理员体验以及平台的扩展性。

后者是一个与本次对话相关的有趣工作。一方面,可以说它可能通过实现更多定制来进一步增加复杂性。但我们的目标也是能够定义更适合特定用例的主题,甚至提供更简单的默认体验,同时保持现有网站的向后兼容性。例如,这将为更认真地考虑以下想法打开大门:CDCK should develop new default Discourse themes on a regular basis to keep it looking current

我不想在这个话题中过多地深入开发流程,但既然提到了,我认为也值得一提的是,随着我们过去几年的发展,Discourse 现在还包括了产品经理和设计师,他们与开发人员一起致力于所有这些工作。

至于我们如何在网站上定位开源,这是我们一直在讨论的事情。随着我们推出基础计划以及试图更坦诚地说明我们企业计划所提供的内容,该网站一直处于一种变动之中。这里有许多选项,我们正试图引导人们选择最适合他们的选项。我同意它在某种程度上被忽略了,并且应该更容易被发现。它目前在我们定价页面的常见问题解答部分,但这本身可能会改变,因为定价本身可能不是选择自托管的主要原因。

有很多事情要做!

再次感谢,我真的很享受在这里的讨论,并很高兴看到一个一年多前开始的讨论如何焕发新的生命。这正是我个人最喜欢这个平台的一点。

17 个赞

这就是为什么许多创作者使用 Facebook、Patreon 或 Substack。开始使用只需要点击五次。而且有这么多人使用这些平台,新人很容易上手。

如果 Discourse 希望创作者使用该平台来建立社区,我认为有 \u003c1% 的人想学习编码。他们只想让它正常工作,让他们的用户喜欢它,并加速他们的增长。

5 个赞

我的意思是,当然,尽可能降低安装门槛总是更好的。但我真的不认为这是问题的关键。我认为,一个人推荐一个平台更多是基于他们作为用户的体验,而不是其他任何因素。或者至少,普通用户体验 Discourse 的人数将远远多于运行它的人数。

基本上,我提倡自下而上的方法。让普通用户爱上 Discourse,让他们为平台代言,这才是更好的目标,而不是试图说服少数决策者,让他们相信他们的社区会喜欢这个他们从未听说过、用户也不熟悉的平台。如果社区提供了足够的动力,很多人愿意投入时间和精力来建立基于 Discourse 的社区。

我也不想过多贬低聊天功能。我很感激它对我来说是免费的,并且投入了大量的工作和时间。我只是不确定它解决了什么问题,而我不能轻松地[并且更有效地]用 Discord 来解决。如果数据所有权是某人的优先事项,我可以理解关于数据所有权的论点。但同样的逻辑也可以用来支持将任何软件克隆到 Discourse 中。

这并不能阻止人们迁移到 Discord,因为它只是一个劣质产品。事实上,我关闭了我网站上的公开聊天,因为这与我们的 Discord 重复了。我的管理团队实际上专门使用 Discord 来讨论论坛上的管理问题,尽管我们在论坛上有一个工作人员频道。我知道这只是我的个人经历,这完全是我的个人观点,所以我只能谈论我的经历。我更希望看到精力投入到构建令人兴奋的功能,让论坛体验更好,而不是试图做许多其他公司已经在成功做的事情,而且做得更糟。

5 个赞

这次讨论有很多很好的观点,我担心其中很多都会被忽略。我认为现在有几个不同的讨论线。我想知道是否可以开始一些新的、重点明确的讨论线:

  • 失败的用户故事 - 关于论坛用户因为 Discourse 的功能或设计而不再使用的轶事。
  • 管理员故事 - 关于选择 Discourse 后最初一两周在理解、安装、配置方面遇到的困难的轶事。
  • 错误功能故事 - 关于用户界面混乱或模糊、存在但未被发现的功能等的轶事。

如前所述,人们真的想听听那些选择了其他平台而拒绝了 Discourse 的人,那些因为不适应 Discourse 而离开社区的用户,以及那些为自己的社区选择了 Discourse 但后来后悔的人的意见。

至于产品经理、臃肿和康威定律,我认为有值得吸取的教训。如果你奖励产品经理发布功能,或者因为一小部分人想要某个功能而添加它,你就会得到复杂性和令人费解的选项。如果你衡量构建时间、安装时间或在最小服务器上的性能,你可能会控制住这些问题。所以,要关注你衡量或激励的东西。

我认为展示 Discourse 在六种不同用途下的安装实例将是一个绝佳的主意。Meta 不是一个展示,单一实例也不是一个展示。

在 Meta 上,创始人或高级开发人员发表粗鲁或不屑评论的问题,现在可能已经有所改善——希望已经吸取了教训。但对我来说,这是一个负面因素。

作为一个案例研究,我认为 Vintage Computer Federation 以前是一个 vbulletin 网站,经历了一个相当公开的选择 XenForo 和 Discourse 的过程,包括会员投票和反馈,现在已经转向 XenForo。这是一个失败的实验。(我当时不在那里,也没有去寻找那时的讨论。但我在搜索“discourse”时偶然发现了这个失败的实验。如果我搜索“forum”,我就会得到成功的后续。)

6 个赞

我喜欢 Coding Horror 的方法,即使我不同意他的观点!正如所发生的那样,它通常是为了避免这里抱怨的功能蔓延。

有趣的是,XenForo 在我的手机上出现了与 Discourse 在 A2HS 应用(但不是 Hub 应用)上相同的标题闪烁问题。

1 个赞

很高兴听到你正在积极关注此事。我曾读过一篇关于关闭 Windows 计算机的各种方法的博客文章。可能是这篇下一篇文章 提供了一个可能的(组织上的)原因。

4 个赞

感谢您深思熟虑且富有洞察力的评论。总的来说,这里重新燃起的活动以及 CDCK 团队的响应令人鼓舞。我知道解决所有这些问题有多么困难,但知道您非常了解它们并尽力解决它们,我们不胜感激。

同时也要感谢所有近期为该主题做出贡献的人!有很多有趣的讨论和观点。最终,我认为最艰巨的挑战之一是与那些虽然了解 Discourse 但却未选择它的人,或者那些甚至不知道它的人建立联系。这些“错失的销售”(可以说是,因为有些可能是自托管)的洞察力对任何企业来说都是最重要的,但实际上很难获得。我们在这里表达了许多可能有所帮助的有趣想法,但实际征求这些用户/管理员体验的基本挑战,很可能是最大的瓶颈。

无论如何,我对 Discourse 的未来比开始这个话题时更有信心。(并不是说我曾对其感到绝望,只是有点担心 :sweat_smile:

8 个赞