大家好 — 正在寻求关于如何构建 Discourse 的指导，因为如果我们采用方案一，当有 3 个层级的类别（L1-L2-L3）时，我们将有 1200 个类别，如果我们去掉 L3，则有大约 150 个类别，包含 L1 和 L2。
背景
我们在不同的主题中发布几种内容类型（问题、讨论、操作指南/文章、活动、职位、公告）。例如：
- 主题领域（L1）： 烹饪、摄影
- 子主题（L2）： 意大利菜（烹饪下）、肖像（摄影下）
- 焦点（L3）： 意大利面、酸面包、灯光、构图
我在两种方法之间犹豫不决，希望能得到最佳实践建议。
方法 A（主题 = 类别，内容类型 = 标签）
- 类别
- L1（主题领域）：
cooking、photography
- L2（子主题）：
italian、portrait
- （问题）是否应为“焦点”添加第三级类别（例如，
cooking → italian → pasta）或保持层级较浅，将焦点建模为标签？
- 标签
- 必需的内容类型标签（仅一个）：
question、discussion、how-to、event、job、bulletin
- 可选/必需的焦点标签：
pasta、sourdough、lighting、composition、…
URL 模式（方法 A）
- 预填撰写器（L2 + 类型 + 可选焦点）：
/new-topic?category=cooking/italian&tags=question,pasta
- 按一个标签筛选的类别（例如，“意大利语问题”）：
/c/cooking/italian?tags=question
- 标签交集（AND）（全站范围，例如，“意大利面 + 问题”）：
/tags/intersection/pasta/question
- 类别 + 多标签（使用高级搜索）：
/search?q=category:cooking/italian%20tags:pasta+question
方法 A 的问题
- 推荐的做法是避免第三级类别并将“焦点”保留为标签吗？
- 类别页面仅支持一个
?tags=过滤器（在单类别中需要高级搜索才能进行多标签筛选）是否存在任何陷阱？
方法 B（内容类型 = 类别，主题 = 标签）
- 类别： 顶级（或少数几个）用于问题、讨论、操作指南、活动、职位、公告。
- 标签（三个主题组）：
- 主题领域（例如，
cooking、photography）— 限制一个
- 子主题（例如，
italian、portrait）— 限制一个
- 焦点（例如，
pasta、lighting）— 1 个必需（或可选）
URL 模式（方法 B）
- 预填撰写器（类型类别 + 主题标签）：
/new-topic?category=questions&tags=cooking,italian,pasta
- 按主题浏览类型（例如，意大利语问题）：
/c/questions?tags=italian （多标签 + 类别 → 高级搜索）
- 全站主题交集（独立于类型）：
/tags/intersection/italian/pasta
方法 B 的问题
- 将内容分散到“类型”类别中是否会使主题浏览更加困难？
- 要求每个主题具有多个标签组（主题领域 + 子主题 + 焦点）是否存在任何陷阱？
跨领域问题
- 今天的最佳实践： 保持浅层类别树（1-2 级），并将详细信息推送到标签中？
- 何时需要第三级类别？ 仅用于真正高流量的焦点领域，需要单独的权限/着陆页？
- 功能范围： 如果我们启用已解决/投票，是在方法 A 的主题类别中，还是在方法 B 的“问题”类别中进行范围界定更好？
- 撰写器用户体验： 预填撰写器链接（
/new-topic?category=...&tags=...）仍然是指导作者的首选方式吗？
- 搜索用户体验： 除了高级搜索之外，我们是否应该了解任何用于类别 + 多标签筛选的新模式？
提前感谢您提供建议、示例和“对您有效的经验”！
1 个赞
mcwumbly
(Dave McClure)
2
我认为答案在很大程度上取决于您对社区内不同主题对特定成员的吸引程度的期望。
您是否期望讨论摄影和烹饪的群体之间有很大的重叠？如果是这样，这些不同主题的标签可能效果很好。
或者您是否试图在同一网站上服务多个子社区——一个用于烹饪，一个用于摄影？如果是这样，您可能更喜欢每个子社区一个类别。
我将假设您首先讨论的是一个单一社区，人们可以在其中一起讨论许多主题。
我的建议是先从类似方法 B 的方法开始。
为不同类型的内容设置不同的类别，将使您能够更清晰地表明讨论的类型以及参与者的预期行为。在某些情况下，您可以进一步配置类别以实现这些目的（例如，为问答类别使用已解决插件）。
然后，首先依靠标签来处理主题。这使您可以在存在重叠时自由地将多个标签应用于讨论（烹饪照片！）。
如果将来您发现将某些主题与其他主题更清晰地区分出来很有帮助，您可以使用标签来帮助重新分类。
总的来说，我们建议类别越少越好，尤其是刚开始时，层级越浅越好。默认情况下，我们只支持两级深度。您必须费力才能开启对第三级的支持。
我不知道人们是否会大量使用 URL 来预填充撰写器。我可以想象在某些情况下它很有用，但我建议在发现需要之前将这个想法搁置起来。
关于发现，还有另一个值得查看的页面是 /filter 页面，它可以让您构建更多自定义主题列表，您可以在网站侧边栏中进行配置：Filtering topic lists in Discourse
2 个赞
谢谢您，Mcwumbly。我意识到我之前的问题没有提供完整的背景信息——这有点难以表述。以下是用于说明我们的用例和用户期望的附加背景信息：我们正在以下场景中构建一个论坛：
（仅限美食的细分论坛，用于说明结构）
1) 主题（三级；可以是类别或标签）
- L1 = 菜系 — 意大利菜、加勒比菜、印度菜、墨西哥菜
- L2 = 焦点 — 示例：意大利面（在意大利菜下）、玉米饼（在墨西哥菜下）、chaat / 坦杜里（在印度菜下）
- L3 = 微焦点 — 技术/菜肴/食材，例如：挤压意大利面、馕、瓜希略、低温慢煮
实际使用情况： 大约 70% 的帖子发生在 L2（焦点） 与 L3（微焦点） 的结合处。
• 如果 L3 是一个类别，则主题发布在 L3。（这里有一个重要的注意事项，与 L2 和 L1 相比，我们将拥有名称相当高的 L3 类别）
• 如果 L3 是一个标签，则主题发布在 L2，并附带 L3 标签。
2) 内容类型（横向交叉；可以是类别或标签）
每种主题类型都需要一个独特的编辑器表单：
- 问题 → 问题 • 我尝试过的内容 • 环境 • 预期 vs. 实际
- 操作方法 / 文章 → 前提条件 • 步骤 • 验证 • 注意事项
- 活动 → 开始/结束 • 时区 • 地点/链接 • RSVP
- 职位 → 职位 • 地点/远程 • 要求 • 如何申请
- （加） 讨论
3) 开放性决策（反映企业案例）
- 菜系 / 焦点 / 微焦点 应该是类别（带有标签助手）还是标签（带有浅层类别层）？
- 主题类型应该是类别（方便的每种类型模板）还是标签（将菜系/焦点作为主要的“位置”）？
- 鉴于70% 的活动发生在焦点 + 微焦点，哪个选项能最好地保留强大的焦点着陆页，同时保持 IA 简单？
我们的约束和目标摘要（适用于两个版本）
- 保持导航直观，用户实际花费时间的地方（L2 + L3）……我们仍然需要在此处提供一些上下文（从面包屑或 SEO 的角度参考 L1，无论是在意大利菜还是墨西哥菜中发布帖子）。
- 避免不必要的类别膨胀，但仍为高流量主题提供清晰的“主场”。
- 强制执行每个主题恰好一种内容类型，并支持主题交叉（例如，软件 + 技术领域，或菜系 + 焦点）。
- 确保正确的编辑器表单出现在每种内容类型中，无论类型是建模为类别还是标签。
我们正在寻求关于哪种建模选择（用于主题和内容类型的类别 vs. 标签）最符合这些约束的指导，考虑到大多数参与发生在L2 + L3，并且每种内容类型都有不同的表单。
2 个赞
mcwumbly
(Dave McClure)
4
为了能给你提供最好的答案，我需要了解更多你具体的情况。我想深入了解你的特定主题、社区中的不同用户角色、你对他们的需求和行为有多了解、你是否已经有一个活跃的社区，如果有，它有多大和多活跃等等。
鉴于此，我们当然是在进行泛泛而谈，你得到的建议可能适合你也可能不适合你。
话虽如此，根据你目前分享的信息，我认为我会这样处理：
- 首先，只为用例创建类别（问题、活动等）；使用标签来表示主题。
- 当出现需要自己空间的子社区时，为它们创建一个顶级类别，创建一个顶级的“子社区”类别（名称由你选择），并在其中为每个子社区创建子类别——在这些子类别中，将不包含用例类别。假设这些是新兴的紧密联系的群体之间更自由的讨论，他们可能会一起深入研究某个主题，同时继续在其他顶级类别中贡献。
- 如果这些子社区发展到需要自己的基于用例的类别，则将它们提升为顶级类别，并在其中复制基于用例的子类别（问题、活动等）；将最初的类别嵌套在更通用的顶级类别下，以代表“主要”社区。
- 继续使用标签将所有这些类别中的内容按主题连接起来。
2 个赞
感谢 Mcwumbly 的回复，将他人因素考虑在内以决定方法是合理的。我们已经确定了一种方法，该方法考虑了心智模型流程和讨论建议的工作方式。
2 个赞