首次Discourse管理员的劝退

我将此作为一个独立的主题发帖,而不是从 Facebook 迁移到活跃支持社区的结构,因为它感觉在另一个层面上:社区建设始于没有人到场之前,即社区建设者(我们姑且这么称呼她)设计社区将如何运作的方式,并在她选择的工具中实施该社区设计:调整设置、添加或删除功能、选择主题、创建类别、考虑成员的入职流程、如何执行版面管理等。

这些设计决策是社区建设者的愿景与工具的可能性之间相互作用的结果,可以说是一种“对话”。引用一句老话:“我们塑造我们的工具,工具也塑造我们。”

目前,这位社区建设者感到非常不知所措和沮丧。我想分享一些关于此的看法。

首先,简单介绍一下我自己。我不是第一次做社区建设者,对基于网络的工具也不陌生。在“人类在线连接”这个领域,我已有 25 年的经验,有时是专业性质,有时不是。我不是开发人员,但我有足够的专业技术知识,以至于我曾管理过自己的服务器,并在早年编写过一些 WordPress 插件。在博客、社交媒体和在线社区成为“热门事物”之前,我就设计并教授过相关课程。我熟悉查阅用户手册来排除任何不正常工作的故障。

我现在运营的主要社区即将成立八周年,拥有 8-9k 成员,分布在三个 Facebook 群组中。它完全不涉及网络或技术。它是为患病猫咪的主人和兽医服务的。它非常活跃、非常健康,而且(不是我说的)管理和版面维护得非常好。有一个 20-30 人的团队参与运营。普通社区成员一旦脱离他们习惯的活动(在 Messenger 上聊天、创建 Facebook 帖子或发表评论),在数字操作上就会感到困难。让他们在手机上填写 Google 表格中的值、保持登录状态,并在帖子中分享表格链接,都是一项挑战。

我这么说不是为了炫耀,而是想明确表明,我可以说是一个非开发人员的 Web 资深用户。而不是某个考虑设置“论坛”或“社区”的随机人士。

尽管我对 Discourse 提供的可能性感到非常兴奋,但我却快要淹没了。我花费了无数个小时在 Meta 上搜索、阅读和发帖。我看了又看设置复选框,直到眼睛都看花了。我对这个平台有足够的了解,可以感觉到哪些功能应该是可行的,但我感觉自己面对的是宜家沙发包装箱里的内容,却没有说明书或工具。所有可能性和选项带来的认知负荷正在扼杀我。一想到我的那些可爱、不擅长数字操作的成员将面对 Discourse 默认设置和外观所提供的众多功能,我就不寒而栗。

那么我在这里做什么呢?如果我的 Facebook 社区运行得这么好,为什么不保持现状呢?因为我从第一天就知道,Facebook 只能在它不可避免的“变糟”(当时我还没有这个词,但我非常清楚这个过程)允许的范围内起作用。多年来,平衡一直倾向于 Facebook。这些年来,天平开始倾斜了。我偶尔会留意替代方案,因为我知道我可能会某天醒来发现群组消失了。但我看到的任何解决方案似乎都无法支持这个社区。

今年夏天,Discourse 进入了我的视野。我注册了一个试用版,花了一周时间尽可能地玩弄它(我的 Facebook 账户被停用占用了试用期的第二周,但那是另一个故事了)。我被震撼了。这是一个可以让我们在 Facebook 上只能梦想的工具。它功能强大、可配置性强、现代且健壮。而且是开源的:我可以自己托管它。几天之内,我就被说服了。我们社区的新家将被称为 Discourse。

我没有改变主意。我仍然看到一个未来,在那里 Discourse 能满足我们所有的需求,我们的社区将在自己的家园中蓬勃发展,摆脱大平台的束缚。但要实现这一目标比我预期的要艰难得多。我真的很挣扎。昨天,我的一位更懂技术的版主登录了我们的 Discourse 安装版来帮我,她对界面和功能的初步反应是困惑。这证实了默认设置离我们需要的还差得很远。

昨晚,我偶然发现了这个主题:Why isn't Discourse more frequently recommended as a "community platform"? @oshyan,他提出了许多对我触动很深的一点。我老实说,像我这样背景和技能的人,在为“普通人”的社区准备 Discourse 时,不应该遇到这么大的困难。我无数次安装和配置带有无数插件的 WordPress 安装而面不改色——当然,WordPress 的复杂性较低,但也不仅仅是这个:在寻找我需要做的事情的“信息架构”方面,有一种感觉,它更像一个迷宫而不是一次有指导的城市观光。

也许我做错了。但是,如果我做错了,那也是尽管我尽了最大的努力去“做对”。我非常感谢 Discourse 的存在。真的。我在 Meta 上发现的响应速度也令人欣慰。我理解,在经营企业或“仅仅”开发工具时,资源永远不足以做所有需要做和希望做的事情。

但是,作为一个热情的用户,感到工具的界面在阻碍(当然不是故意的!)而不是促进社区建设和管理的一个关键部分,这非常令人沮丧。不幸的是,即使是世界上最乐于助人的支持社区(Meta,我看着你!)也无法“修复”这个问题。

在我看来,特别是阅读了上面链接的长篇帖子之后,拥有大量的功能和设置是可以的,这样(真正的)高级用户如果愿意,就可以按照自己的方式来。但我看到 Discourse 缺少的是一个开箱即用的精简配置,它能适用于普通社区建设者和普通非技术性社区。有时少即是多。

当你安装 WordPress 时,只要你有发送电子邮件的技术能力,就可以立即开始写博客,它对有话要说、有读者想读的普通人来说是可用的。如果你愿意,可以调整一些设置,或者如果你是边缘用例或高级用户,可以尽情使用插件和主题。我的 Mac 预设了大多数人适用的设计选择。如果不行,它甚至还有一个命令行和配置文件,勇敢或技术用户可以摆弄。

我意识到我说的可能都不是新鲜事,而且“Discourse”肯定也了解自己的不足并计划解决它们。但我很累、很沮丧、很气馁,而且——无意贬低这里的人有多好、多支持我——我感觉在处理这一切的困难上有点孤单:看,这里有所有这些很棒的指南、Meta 上所有很棒的信息、所有这些设置、主题、组件和插件,可以以这样或那样的方式解决我的问题。但这并不能帮助解决另一个层面的问题:在如此丰富的可能性所组成的这个不熟悉的热带雨林中找到我的方向,这些可能性多到无法在我大脑中找到一个稳定的位置,以及处理一个在需要消除摩擦的地方(当然不是故意的!)反而增加了摩擦的界面。

如果你读到了这里,谢谢你的倾听。我欢迎你对我的经历发表看法,无论你是否经历过或正在经历类似的考验,或者你认为我理解错了重点。

28 个赞

您好,

首先,感谢您清晰而详尽地阐述了您的情况和遇到的挫折。

我认为区分管理员的体验和用户的体验非常重要。在我看来,Discourse 的用户在使用这个平台时遇到的困难并不比使用类似平台时多。然而,管理员的体验确实非常不同。

Discourse 是一个极其强大的平台,但其复杂性也是不容否认的。就我个人而言,我不会将我的经验一概而论:由于二十五年前就开始使用类似的平台,我已经习惯了这类工具及其复杂性。话虽如此,即使作为一名经验丰富的管理员,我也必须承认,在最近几周或几个月里,我感到有点不知所措,这主要是由于更新速度快以及扩展和插件之间出现的冲突。

总结我自己的经验,主要挑战源于快速的更新速度以及组件和插件之间的版本冲突。在我看来,Discourse 的复杂性以及其设置有时令人困惑的性质,在很大程度上是由于这种快速的开发周期,以及该软件是开源的——这是一个巨大的优势,尽管也有一些小的缺点。

6 个赞

哎呀,我甚至还没有遇到那些问题呢!:fearful:

我希望你是对的——尽管在我的情况下,“控制”是 Facebook,人们本来就在用。这也是我这么久以来才考虑从那里迁移的主要原因……

类别和标签的组织方式也是社区成员将面临的架构中一个重要的部分,因此管理员的困难可能会间接影响用户,如果这意味着社区“结构”没有设计得像本可以设计得那么好。

感谢您花时间阅读我的回复并给予回应!

8 个赞

诚然,Facebook 群组和 Discourse(例如)在结构上存在根本性的差异。Discourse 是一个论坛。至少,大多数人是将其用作论坛。我也有点把它用作博客论坛,因为这是可能的。这完全取决于您受众过去的经验。如果您的受众没有使用论坛结构的经验,那么从 Facebook 过来时确实可能成为一个问题,这一点不可否认。如果您的部分受众已经有使用论坛的经验,我不仅仅是说 Discourse,而是所有具有论坛结构,即类别或版块的论坛。这非常不同。他们将能够非常轻松地找到方向。

2 个赞

我建议除非你有明确的目标,否则不要查看其中的大部分内容,然后一步一步来(同时根据需要在这里寻求帮助!)。
你说得对,可能性非常多,而且它们的组织方式可以更好……我们正在努力改进,但这还有很长的路要走。目前的配置选项数量已经超过了任何一个人能够建立心智模型的范围……所以你感到不知所措是很正常的。

我们可以!这里的每一篇帖子都会被 Discourse 的工作人员阅读。在阅读了你上周的帖子后,我开始着手开发一个功能,可以直接通过标签页面添加标签。这是我们多次收到的反馈,所以是时候尝试一下了。

19 个赞

抱歉,您感到沮丧。有很多设置之类的东西。

Discourse 也是如此。您可以立即开始发帖。就像在 WordPress 中一样,您甚至不需要创建类别,只需使用默认的类别即可。如果这正是您想做的,那么它们就差不多了。

我认为我知道您想做的是创建一个猫数据库。那很困难。要在 WordPress 中实现它,您需要创建一个新的帖子类型,而且我不知道还需要什么才能使其中一个属于多个用户并让这些用户拥有多只猫。我会在 WordPress 中为您做这件事收取 10,000 美元(但这只是因为我讨厌 WordPress);我可能会以 1000-2000 美元的价格在 Discourse 中为您做这件事。在没有具备超出发送电子邮件技能的人的情况下,Discourse 和 WordPress 都无法做到这一点。

简单的猫数据库解决方案是创建一个猫类别和一个模板。如果两个人喜欢这只猫,将不会有正式的机制来表明这一点。只需在文本中添加 @katDude 也喜欢这只猫 并告诉 KatDude 关注该主题即可。另一种方法是想办法让人们创建一个带有猫名字的额外帐户,然后您可以 @提及 该用户,但这非常麻烦 (PITA)。

但您真正想要的是一个全新的猫模型,然后您就可以用 :cat: 提及它们,而不是使用 @mention。那会很酷,但这会增加开发成本。

3 个赞

在这个阶段,我确实需要在外观或功能上“修复”很多东西。我认为有一点没有帮助的是,由于我对 Discourse 不够熟悉,我通常不知道我试图实现的目标是由设置控制的,还是在主题(或组件)级别处理的,还是由插件处理的。

很高兴听到这个消息,说实话,我理解这是一个巨大的努力。

就是这个!完全正确。老实说,我并不习惯于面对那些抵制我“心智模型”的情况,这也可能解释了为什么我没有很好地处理这种情况。

哇,听到这个真是太好了。

在阅读了你和其他人的评论后,我可能需要更直白地发布关于我“社区成员体验”层面的问题(我试图实现的目标),而不是在自己做了一半的时候提出更多“技术性”问题。

我也会尝试澄清并分享(以防有帮助)我的思维是如何理解 Discourse 的运作方式的(我的“心智模型”的片段)。

非常感谢您的光临并关注我的困境!

10 个赞

是的!我认为周围确实有几位个人对 Discourse 的方方面面都了如指掌。如果你提出更一般性的问题,他们就能正好帮助你。

你试过 ask.discourse.com 吗?它在这方面也相当不错。

8 个赞

:slightly_smiling_face: 感谢您的理解!

我认为这并不完全正确。这两种工具之间的比较是有限制的,我认为它们在这里有所不同:WordPress 作为一个博客工具,主要设计用于撰写博客文章。而 Discourse 的设计目的是容纳一个社区。社区动态比博客的作者-读者关系复杂得多。

当然,我可以用默认设置向我的成员开放我的 Discourse 社区,但说实话,他们能坚持足够长的时间以至于真正形成社区的可能性很小。而我可以在我的原始 WordPress 安装中写一篇又一篇的博客文章,一段时间后我将拥有一个非常好的博客可以展示给人们,即使没有人经常访问它。

实际上,这并不是我的烦恼之一。在某个类别中拥有“猫咪文件”是一个完全可行的选择(是我们今天使用 Google 表格的扩展,每个猫咪一个)。

我的烦恼是这样的事情:

  • 无法轻松地玩弄类别结构和属性并“看到”结果(Canapin 启动的可视化界面模型显然正是需要的那种东西)
  • 无法轻松识别哪些控件控制着主题、类别列表、导航、各种小部件和无处不在的按钮的视觉布局的某些方面
  • 徽章:太多了,我是完全取消它们,还是只取消一部分,取消哪些,在“鼓励的推动”和可能被视为“无用/令人困惑的通知”之间取得什么样的平衡才算好?
  • 通知和提醒:应用内、电子邮件……同样,在一个刚刚起步的 Discourse 实例中不到 24 小时,我的版主今天早上收到的第一条评论就是关于她收件箱中有多少封电子邮件的——我认为电子邮件集成/通知是一种资产,但如何才能达到一个好的平衡,以免人们仅仅因为感到被垃圾邮件轰炸而逃离?
  • 自定义用户字段不如我预期的那样工作:我添加了几个,以为以后可以修改,但我没有找到在当前个人资料中填写这些添加的字段的位置,这让我想知道“稍后修改”可能是一个糟糕的计算(或者也许我没有找到我个人资料中的那些自定义用户字段,那么我们的普通成员将如何找到它们?)
  • 成员入职:在 Facebook 上,我们会发布一系列帖子来“推动”新成员沿着“学习旅程”照顾他们的猫。这是一项巨大的时间消耗,非常麻烦。我确信 Discourse 可以实现自动化(我已经看了一些)。我们是通过消息而不是帖子来做这件事吗?我需要采取哪些步骤才能启动一个像样的“自动回复器”之类的东西?一旦有了东西并且人们进入了 Discourse 社区,调整入职流程的难易程度如何(参见类别)?
  • 用户角色和权限:在 Facebook 上,我们有版主和协助者,并且版主团队被组织成具有特定任务的小团队。一些人负责分类新用户并发布欢迎帖子。一些人负责内容审核。一些人管理初学者小组。一些人指导协助者。一些人负责准备成员列表以供我们定期发布的入职帖子使用。我们一直觉得 Facebook 上非常严格的用户角色限制了我们,而 Discourse 将使我们能够以不同的方式做事。但是如何做呢?再次,有“设计”(哪些角色、群组和权限以及谁去哪里)和“在系统中的实现”(实际调整群组、设置、成员列表……)。我们目前的组织如何运作或与内置的信任级别发生冲突?进展标准对我们的社区有任何意义吗?
  • 群组文档:它们似乎可以作为“已发布页面”工作,但我需要弄清楚如何正确设置标题级别以与现有文档大致匹配。我如何管理导入/迁移?手动复制粘贴,还是有自动化的方法?我不知道的太多了,所以不知道自己不知道什么。视频也是一样:我需要将大约 70 个视频上传到 Youtube,然后为每个视频创建一个主题:是值得寻找自动化解决方案,还是我们手动完成?我不知道。
  • ……
  • 这种类型的事情 :face_with_peeking_eye:(我还没有开始谈论人工智能集成,这也是我对 Discourse 如此兴奋的原因之一……)

也许我正在迁移一个已经成熟的社区的事实也增加了我的烦恼:这与从零开始,并有机会让社区文化与容纳它的工具共生发展是完全不同的事情。

8 个赞

我试过,之前(八月份试用 Discourse 时)试了很多。现在少多了,我得说。我经常发现自己被引导到 Meta 上的主题,但我不确定信息是否仍然有效,或者帖子太长,在读到一半之前我就感到不知所措了。我也对聊天机器人“兔子洞”保持警惕(我倾向于很快就陷进去)。但也许我应该再试一次。

我一定会这么做的,谢谢你的鼓励!

6 个赞

那不一样。你说你可以启动 WordPress 并发布一些内容。我说的是你可以启动 Discourse 并发布一些内容。创建一个人们会留恋的博客也比发布一些内容要复杂。也许这个类比不恰当。

而且,作为一个靠 Discourse 谋生了将近十年,却连 WordPress 最简单的任务都做不来的人,我可能不是一个好的咨询对象!

但说实话,你清单上的所有事情都相当难(弄清楚特定的人想要多少邮件?如果版主对收到通知感到恼火,你可能需要一个新的版主——如果他们尽职尽责并一直在线,他们就不会收到太多通知,因为他们会在浏览器中看到它们,但他们很容易调整这个设置,而且对于一个新的论坛来说,默认设置是发送大量邮件,以便人们知道网站存在,而很多事情之所以困难,是因为它们本身就是难题,而不是因为 Discourse 让它们变得困难。

自动提醒?在正确的时间?那相当难。

那是我的拿手好戏!但即使你能够访问数据(而且我相当确定,在你弄清楚如何从 Facebook 抓取数据之前,你是无法访问的,而且那甚至合法吗?),它仍然很复杂。我现在正在清理一个烂摊子,这是因为有人在迁移中做得不好,惹恼了所有用户。

是的!那要难得多。每个人都有自己的期望,即使是对某个系统感到非常不满的地方,如果它们缺失了,人们也会生气!

所以,虽然我可能对 Discourse 存在不理性的防御心理,而且有些事情本可以更简单,但在我看来,你试图做的大部分事情本身就很困难,无论你试图配置的是哪个平台。

5 个赞

我的类比的本意并非如此:它更多的是“这个工具开箱即用时,能否足够好地完成你需要的工作”(WordPress:博客;Discourse:社区)。不过,是的,这个类比有局限性,我们可以深入探讨它的不足之处!

:joy:

当然无法知道确切数量。但是什么样的设置能让最多的人满意/能容忍呢?是的——这正是用户研究提供的信息(不幸的是,我没有资源在我的社区上进行研究,我需要凭猜测来判断)。

她没有生气,她只是指出了这一点。而且正如你所说,她提到需要修改她的通知设置。但我们的“普通用户”不会去修改。

这就是问题所在:根据我版主的初步反馈,很明显,该设置对我们的用户群来说会过于“具有侵入性/淹没性”。

我绝对没有否认它们是难题。但是,一个界面可以让处理难题变得更容易或更难。Discourse 没有向我(或者我没有看到)提供一个清晰、易懂的关于这种行为(发送电子邮件)在我社区中的表现。我看到一长串设置;我需要一些更像“用户故事”的东西。我欣赏设置名称和值下方的描述,但除非我已经对 Discourse 的这一方面的工作原理有一个清晰的心理映像(就像你凭借丰富的经验肯定做到了那样),否则我很难理解这些设置各自的作用。告诉我这个设置如何影响我成员使用工具的体验,然后问我想选择哪种场景或替代方案:这样才有效。

仅供参考,我们的所有文档都在 Google Docs 中,而不是 Facebook(好奇的人可以看这里),而且所有来自 Facebook 的视频帖子确实已经被抓取了,无论是否合法。如果我过于关注这方面,我就不会运营一个社区,在这个社区里我们告诉人们该给猫注射多少胰岛素了 :sweat_smile:——老实说,关于 Facebook,我不会对拿走本应属于我们的内容有任何顾虑。

没关系,我理解——我认为 Discourse 是一个能让人充满热情的工具,这很棒。这是一笔财富 :slight_smile:

非常感谢你的评论和反馈!

7 个赞

但是一旦用户多一些,就不会那么啰嗦了。Understanding and managing bootstrap mode – 它实际上是开箱即用的设置方式,会向新用户(他们可能像你的版主一样更有耐心)发送大量的电子邮件,如果你自己不设法更改设置,它会自动缓和下来。

哦,那真是太好了!一个聪明人,也许是一个聪明人,在一些工具和 https://ask.discourse.com/ 的帮助下,可能能够将它们强行导入到 Docs 插件中。

同意,而且我认为他们在界面方面做得相当不错。请务必学习如何使用设置的搜索功能——你几乎不需要查看它们的列表。只需在搜索框中盲目输入内容——它会搜索所有这些设置的名称、描述和值。这太棒了。

编辑:

是的,我并不是想暗示你的挫折不是真实的或无效的,只是我不清楚要采取哪些可行的步骤来解决这些问题。

5 个赞

除了这些,我只想感谢您分享您的故事并描述您的挫败感。

一个好的结果是您能建立一个成功的 Discourse 社区。一个更棒的结果是 Discourse 得到调整,让这段旅程更容易。

对我自己而言,我尽可能少地做修改,并且不是立即地,只添加了一个主题组件。我的目标受众相对技术化,这对我有利,但我知道至少有一个聪明的人对界面感到困惑。

我想我的方法是:不要试图重建你以前拥有的东西,而是要建立一个适合你社区的东西。我想要相对低的摩擦力,并且我希望人们能够找到他们想要的东西并做出贡献。

我极简主义方法的一部分是使用很少的分类,并且一开始不担心标签。新发帖人遇到的一个摩擦点是选择哪个分类,所以第一个分类总是一个“万能”分类,我明确表示版主可以根据需要重新分类。

我试验了默认视图,首页可以是分类列表或最新帖子列表。我只尝试了这两个,并且不止一次地切换过。

我唯一添加的是 Topic List Previews

主题组件,它允许您自定义 Discourse 中许多主题列表的布局,从根本上增加了缩略图预览和摘要。

这样做的好处是为列表中的每个主题添加了文本片段和图像缩略图,使主题列表更具吸引力,也更具自明性。

9 个赞

我非常理解一开始被所有设置搞得不知所措的感觉。

我想要提醒大家的是,不要让“完美”成为“良好”的敌人——不存在完美的设置,随着您的社区稳定下来,事情总会需要随着时间进行调整。它将始终处于轻微的变动之中。而且很有可能,设计设置所花费的大部分时间都会在上线后被抛诸脑后,因为用户会开始向您提供反馈(我对此深有体会!)。

对我们的社区有帮助的一件事是拥有一组测试用户(beta testers)。他们有自己的群组,有自己的版块,并且有一个专门用于测试组件的主题。多年来,他们提供了很多很好的反馈,并且能够发现我没有想到的潜在陷阱或问题。

我认为,先用一个最小可行产品(minimum viable product)开始会有极大的帮助。随着您从用户那里获得反馈,您可以根据需要进行调整,添加或删除插件/组件,或添加/删除版块等。您不必一开始就拥有一个完全成熟的版块树,您可以随着时间的推移学习什么有效。如果您感到紧张,可以在完全启动之前邀请一些用户过来,让他们先熟悉一下并获得他们的反馈——让熟悉 Discourse 的用户参与进来也会有助于过渡。

所有这些都允许您的社区帮助决定您的 Discourse 实例的风格,让他们在其中有发言权,这使他们能够感觉与它更加紧密相连。

9 个赞

我能问一下,你为什么要用自己的硬件来托管这么小的团体吗?如果你觉得安装和配置 Discourse 很难,那么谁又有精力去做 24x7 的工作来确保电脑不会被从头到脚地黑掉呢?我具有计算机安全背景,我可以诚实地说,除非我运行的东西能保证每年至少有 100 万美元的收入,否则我绝不会托管自己的服务器。

为你个人博客实施时承担这种风险是一回事。当有 8000 人信任你来保护他们的身份时,那就是完全不同的级别了。当黑客窃取你的用户数据库,然后开始发送声称来自你的网络钓鱼邮件时,你打算怎么办?对于那些重复使用密码的人来说,如果被盗的密码在某个保留着他们毕生积蓄的经纪网站上有效,你又该怎么说呢?为什么要承担这种风险呢?

妥善保护计算机并持续监控它每年要花费数十万美元。那些选择自己做这件事的人通常是程序员和安全专业人士,对他们来说,这既是工作也是一种爱好。每月向 Discourse 支付 20 美元,让他们监控安全日志、进行备份和升级,这很便宜。

顺便说一下,我对你开始的任何关于你 FB 账户被暂停的帖子很感兴趣。我在 FB 上运营一个 15K 用户的群组,他们将我的账户暂停了三周。在这三周内,我在 FB 上的所有内容都消失了,使我们的群组陷入完全的混乱。仅此事件就让我意识到,FB 是一个精神错乱、失控的人工智能,它会随机地无故暂停人们,而他们解决此类错误的后端系统完全是失灵的。

1 个赞

谢谢!是的,我绝对是“求完美而误了良好”的忠实信徒。不过我得说,Discourse 管理界面呈现事物的方式很容易让人陷入“完美”的陷阱。

今天早上思考这个问题时,我在问自己,什么能帮助我这个新管理员朝着“足够好”的设置方向努力。对我来说,缺少的是在作为社区建设者需要考虑的不同“维度”中清晰的层级和优先级的概念。也许这个存在但我还没找到,但也许可以提供一个高级别的“清单”,列出构成社区的功能和特性,让我可以标明哪些对我来说重要,哪些不重要,然后为我提供一套相对预先打包好的设置集合来实施。

举个例子来阐明我的想法(也许我需要更多思考,并在另一个帖子中发展这个想法)。在全新安装时,我可能会有一个清单,询问社区的各个方面对我来说有多重要:

  • 使用标签或分类(或两者)来构建内容
  • 允许成员通过聊天进行互动
  • 视觉设计

写到这里我意识到这不是很清楚,我需要更多思考才能以一种易于理解的方式来阐述我的想法。我认为我脑海中想的是一种设置向导,它使用“用户故事”(使用引号是因为可能不完全是这样)而不是技术设置来与我交流,并帮助我将它们转化为设置。也许甚至可以有一个人工智能聊天机器人,它可以帮助解析我的自然语言解释,旨在指导我并让我专注于我需要开始的这个“简单配置”,并且它可以访问设置或为我调出它们。我想 Ask Discourse 已经做了一些这方面的工作……

(好的,我会再想想,稍后回来!)

我一直打算这样做——然而,我的困难在于考虑到我社区的性质和需求,如何才能达到这个最小可行社区平台。我确实喜欢你关于测试人员的想法,它在我脑海中没有那么清晰地形成——以及拥有一个专门的主题来测试新组件,这是我没有想到的做法。

我认为带来很大压力的一个因素是,我知道在离开 Facebook 时会遇到很多阻力,对于很多成员来说,他们踏入“新 Discourse 社区”的头几分钟将决定成败。所以我确实必须确保最小可行社区不会造成比 Facebook 更高的入门和使用障碍,否则用户会进来、看一看,然后留在 Facebook 上,这对我的迁移目标没有帮助。

Facebook 上的社区运作良好且高效。它背后也有很多复杂性,才能为我们的成员提供这种体验。我们还面临着压力,那就是我们有时需要处理成员宠物的生死攸关的情况。主题非常敏感,与即时的现实后果密切相关。所以这也是我考虑的因素。如果参与社区的技术方面对我们的成员来说门槛太高,动物就会受苦甚至死亡——当然不是全部,但这是最终结果。我们将易于参与社区的基准定为 Facebook。

明确地说,如果我上面关于我们角色的说法让任何人感到担忧:我知道我们不能“拯救所有人”:sweat_smile:,而且宠物主人有兽医。但我们是这个小众疾病的法语区资源——包括对许多兽医来说,他们将客户推荐给我们,他们自己也加入我们的社区。我们不仅仅是一个“共同兴趣”社区,这没什么不好,或者说任何社区,无论其主题是什么,都不会对成员的生活产生真正重要的影响。我也意识到这影响了我对作为社区建设者/创始人/管理者所持有的角色和责任的看法。(所以我们不要陷入任何跑题的讨论:我有心理治疗师😅,而且我已经在与这个社区的牵连和责任以及该放手什么的问题进行了八年的相当成功的斗争了🫣。)

非常感谢你友好而周到的信息,它帮助我更清楚地认识到到目前为止我的“管理员体验”中缺少了什么,并给了我一些想法来绕过它并以不同的方式实现它🤗

5 个赞

所以,我认为这更多地不是一个拥有恰当功能的问题,而是一个组织问题

我的意思是,你基本上需要制定一个活动来吸引你的用户过来。我之前提到过让一些受信任的用户先加入并进行测试,然后再向全社区发布。你真的应该寻找你的有机领导者和社区拥护者,那些可以成为热情的欢迎队伍的人。让他们进来测试你的设置,给他们一些谈资,让他们去“接种”你的用户,让他们对迁移感到兴奋。让这个小组在准备好发布时成为欢迎队伍。

拥有一个强大的新手操作指南是我会非常非常关注的事情——事实上,我可能会把这件事放在几乎所有事情之上。特别是,你需要一些类似表格的东西,向用户展示如何在 Discourse 中做他们在 Facebook 上习惯做的事情。一个操作指南将非常有帮助。如果你的用户技术水平较低,可以考虑录制一些关于如何做他们在 Facebook 上习惯做的特定事情的短视频。你提到电子邮件是潜在的摩擦点之一——这正是需要在操作指南中包含的内容。与其试图预测他们对电子邮件的反应,不如引导他们了解如何自行设置通知,从而减轻你为每个用户考虑如何使其完美的精神负担。

老实说,我会花更少的时间在诸如按标签还是类别组织内容之类的事情上,而会非常专注于让第一印象尽可能好。你总是可以(而且总是会)随着时间的推移进行调整,但你只有一次欢迎他们的机会。如果用户受到真诚而热情的欢迎,他们通常愿意忽略一些粗糙的边缘。

如果你心中有一个发布日期,请计划一些在此之前发布的预告片,宣传你可以在 Discourse 上做的所有很酷的事情(碰巧是你在 Facebook 上不能做的事情)——在做这件事时,你不应该贬低 Facebook,我建议将其集中在 Discourse 的优点上,而不是 Facebook 的缺点上,但要展示他们可以期待的那些事情。让他们对迁移感到兴奋。而且,如果你还没有一个发布日期,最好有一个,这样你就可以倒推计划和宣传。

一旦你发布,让你的欢迎队伍对经常使用 Facebook 的用户进行一些跟进——他们是否掌握了?他们需要帮助吗?找出那些热情并享受新体验的用户,并鼓励他们传播这种能量。

你可能会遇到一些用户……我不知道更好的说法,但会因为这次迁移而抱怨的用户,只是实实在在的“负能量满满者”。尽你所能立即消除这种态度——这类用户是本应令人兴奋的事情的巨大情绪破坏者,并可能将其他用户也拖垮。让你的欢迎队伍准备好私下处理这些人的问题,或者至少平息他们的抱怨。你可能根本没有这样的用户,我不知道!但老实说,在我做过的每一次迁移中,总会至少有一个。

我从你的帖子中得到的感觉是(如果我理解错了请原谅),也许坐下来与一个有知识的人谈谈你的需求并指导你完成设置过程会有帮助?我知道这对我来说在感觉设置信息过载时非常有帮助——有时进行对话会更容易。

你为你的社区创建这个空间所付出的思考和关怀非常值得称赞!

5 个赞

对,也不全对——两者之间有明确的分离吗?功能和工具可以促进或阻碍组织工作。根据我使用的电子邮件客户端或日历,由于工具的功能,我“管理”电子邮件或日历的难易程度会有所不同。

当我想要在一个工具中实现一个“组织理念”时,无论它是什么工具,如果我尝试实现时发现的设置对我这个用户来说不是不言自明的、可以找到的,那么它就会使组织工作更加困难。

是的,这正在进行中,这不是我正在努力解决的问题。我老实说认为我对我的社区“人员迁移”挑战的理解以及我对此的愿景在现阶段是“足够好”的。我的问题一方面在于弄清楚如何将我的想法转化为设置/配置,以便在工具端实现它们,另一方面在于未能清晰地了解工具的功能以及如何允许我通过反复试验来完善我的想法,而不会遇到太大的阻力。

我非常感谢你关于迁移的实用建议,这确实是处理事情的正确方法,但我已经在做了。

你说得对——这就是我试图在这里“利用”社区的方式。它在一定程度上有效,但在其他时候有点令人沮丧(并且让我非常认真地思考我的社区中的新成员有时会是什么感觉!),因为结果是更多的信息、更多的选择,甚至会产生一种“问题在我”的感觉,当我表示我发现某些事情很复杂,或者我未能充分传达我遇到的问题的确切性质时。(当然,也许问题在某种程度上确实在我,当然。)

与“Discourse 专家”一对一地讨论或担心实施问题,确实会很棒。在我看来,作为一个十年前或二十年前在博客领域扮演过这种角色的人,这是一项咨询工作,除非你有幸在你的社交网络中有一个愿意帮忙的人,作为回报是一顿美餐。但在他们缺席的情况下,这不就是在线支持社区存在的目的吗?:sweat_smile:

(请随时,如果有人读到这个并受到启发……但老实说,我不会要求一个我不认识的人做这件事……)

谢谢!!

4 个赞

我想我们之间存在误解,除非 VPN 云服务器算作“我自己的硬件”?

那么你基本上是在说,没有深厚计算机安全背景的人不应该自己托管 Discourse 吗?

对我来说,要么你误解了我在做什么,要么你对有资格自己托管的人设置了“要求”,这几乎排除了所有没有经营规模化企业的人。根据我在 Meta 的经历,我没有觉得这就是所有自托管者的画像——或者是我完全在自欺欺人?

请放心,如果 20 美元/月的方案足以满足我社区的需求,我就不会自己托管了。

看起来和我经历的完全一样!你可以从我的博客上用这篇文章开始了解……阅读愉快 :sweat_smile:

4 个赞