gassim
(Al-Gassim Sharaf Addin)
1
您好！
我确信无法创建子类别下的子类别（如果我错了，请纠正我），但我认为创建这个主题帖子是为了再次确认，同时也想了解其他人是否也有此需求。
可能有人认为拥有第三级子类别不是一个好主意，因为会员需要导航的层级太多；但同时，在一个父类别下拥有许多子类别也可能不是一个好主意，特别是如果您想让父类别保持“可用”。
例如，假设我们有以下内容：
- → Development (开发)
- → App Development (应用开发)
- → Android app development (安卓应用开发)
但如果我们考虑添加第三级子类别呢：
例如，假设我们有以下内容：
| Category (类别) |
Sub Category (子类别) |
Third Level Category (第三级类别) |
use (用途) |
| Development (开发) |
|
|
包含主要的开发主题，例如一般软件功能讨论以及路线图等，以及包含所有子类别的公告 |
|
App Development (应用开发) |
|
包含专门针对 Web 应用开发的主题 |
|
|
Using the API (使用 API) |
包含专门针对 API 的指南和主题 |
|
|
Community Apps (社区应用) |
一个专门为构建应用的会员准备的类别（需要批准，每个应用一个主题帖） |
|
|
Core Apps (核心应用) |
一个专门为核心 Web 应用准备的类别 |
|
Android app development (安卓应用开发) |
|
包含专门针对安卓的主题 |
|
|
Main Android app (主要安卓应用) |
包含专门针对主要（官方）安卓应用的主题 |
|
|
Android SDK (安卓 SDK) |
包含专门针对安卓 SDK 的主题 |
嗯，一个有力的论点是使用子类别下的标签，这也可以，但让我们尝试另一个用例，这个用例之所以需要，是因为类别提供了标签不具备的功能（不仅仅是导航）：
- → Connect (连接)
- → 2024-Event (2024-活动)
- → 2023-Event (2023-活动)
- → 2022-Event (2022-活动)
- → [Language] Community ([语言] 社区)
- → [Language] Community ([语言] 社区)
- → …[Language] Community3 ([语言] 社区3)
- → Marketplace (市场)
- → Forum Feedback (论坛反馈)
相反，我可以这样组织：
- → Connect (连接)
- → Events (活动)
- → 2024-Event (2024-活动)
- → 2023-Event (2023-活动)
- → 2022-Event (2022-活动)
- → Communities [Language, Language, Language…] (社区 [语言, 语言, 语言…])
- → [Language] Community ([语言] 社区)
- → …[Language] Community3 ([语言] 社区3)
- → Marketplace (市场)
- → Forum Feedback (论坛反馈)
但为什么要为第三级类别使用类别而不是标签？
- 访问权限：例如，如果我想根据已回复活动（20xx-活动）的人员来限制对主题的访问。
- 可见性：类别具有更高的可见性，例如添加描述、图片和选择布局。
- 设置：类别有一些标签没有的设置。
- 减少混乱：拥有第三级子类别将有助于保持主子类别的可见性。
这些只是一些想法，但我很想听听您的意见。您如何看待第三级子类别？您是否有其他可能对此有帮助的用例？或者您认为即使“技术上”可行，但从用户体验的角度来看，它可能不适合论坛？
提前感谢您分享您的想法和经验。
3 个赞
Moin
2
9 个赞
gassim
(Al-Gassim Sharaf Addin)
3
好的！谢谢！
知道现在“技术上”可行了，我更想知道我是否应该这样做。我希望听到其他人对嵌套超过二级分类的看法。
谢谢！
1 个赞
Jagster
(Jakke Lehtonen)
4
然后，您将拥有适用于多个类别的多平台开发。此时，您深入的类别结构将中断。
这并非精简。这完全是相反的情况 
2 个赞
gassim
(Al-Gassim Sharaf Addin)
5
也许可以，但那样的话，我可以添加一个“多平台开发”子类别。
关于主题/内容本身，我试图为三级类别提供一个示例。您是否有适合三级类别的示例？
谢谢！
1 个赞
Canapin
(Coin-coin le Canapin)
6
您计划在论坛中设置多少个顶级类别？
您设想只有 2 个顶级类别，一个用于开发相关内容，另一个用于社区相关讨论吗？
2 个赞
gassim
(Al-Gassim Sharaf Addin)
7
您好 @Canapin
感谢您的关注并加入讨论。虽然我不想“个性化”，但我很乐意分享我们目前的实施情况。我们的论坛已经有 10 个公开的顶级类别（https://community.dhis2.org/categories.json）
这是不可能的，因为话题多种多样，用例也十分广泛。我们需要将不同的主题分成不同的类别/标签，以便我们跟踪并将其维护为一个管理良好的知识库。
2 个赞
Bas
(Bas van Leeuwen)
8
我强烈建议从你能忍受的最少类别和组织开始。
你的用户在分类主题的分类法上花费的时间会比你希望的少得多，这就是社区管理者的生活。这本书之所以是绝对的经典是有原因的：Don't Make Me Think - Wikipedia
我认为它们通常是不需要的，在大多数情况下对社区是有害的。它们之所以需要通过隐藏的网站设置才能解锁，是有原因的。
我一直着迷于Jeff在2014年的类比：
我经常把 Discourse 描述成一个有趣的晚宴。
把分类想象成房间，主题想象成桌子，回复想象成谈话。你作为晚宴组织者的目标是创办一家成功的餐厅。
不要在你的餐厅里设置太多的房间，这会让地方显得死气沉沉、空空荡荡。
6 个赞
@gassim，我看了您的网站，似乎您还没有实现三级子类别，我一直在考虑在我的一个网站上实现它。
您还没有实现它们的原因是什么？
基本上，我不是要维护多个论坛，而是想将它们结合起来，其中一些一级类别将是我原本会在单独的论坛中拥有的内容。例如，Jim Kleiber Show（我的播客）、emōkō（我的情感格斗武术）等等。
我理解的是“不要建太多餐厅，否则它们都会死气沉沉、空空荡荡，最好是有一个餐厅，里面有不同的迷你餐厅，由共同的基础设施提供动力。”
我想知道大家对这个修改过的类比和三级类别理由的看法。
1 个赞
gassim
(Al-Gassim Sharaf Addin)
10
您好！
我一直犹豫是否要激活隐藏的设置来测试它。这并非必需，更多的是一个想法，用于测试社区内的特定群体，所以根据收到的反馈，它没有被优先考虑。
如果我这样做，我一定会考虑@Bas和其他人的见解。我同意让人们需要浏览太多页面才能到达最终目的地不是一个好主意；然而，如果某个特定的主题/课程或活动需要有自己的“分类”（而不是标签），那么我认为这仍然是一个好主意。
另一方面，我想先测试一下这个选项，看看它是否适用于我们的用例：Custom Homepage for Groups
我不想为“新成员”使用第三级子分类，因为他们还在学习社区并试图找到方向，但比如说，第三级子分类是为“餐厅里的人”准备的，他们想要特定的菜肴，并希望利用这个空间进行独特的内部设计……等等 
听起来很有趣！是的，我同意为同一群人管理多个论坛不是一个好主意，就像拥有第一级分类供人们探索和交流一样。
我认为这两种比喻都很有趣，并且蕴含着智慧，但感觉它们是在处理两种不同的场景。你仍然可以应用这个概念，不要“在你的迷你餐厅里放太多房间”！
我仍然认为，总的来说，我同意不给社区成员太多导航/思考选项以参与其中是很重要的，但同时，我认为在某些情况下，三级分类实际上是合理的。
1 个赞
我感谢您的回复
如果人们只通过分类页面浏览论坛，那么过多的房间选项对我来说是有意义的。当我来到 Meta 时，我很少使用分类页面。如果主话题页面上的话题筛选选项更好，我将更少地访问各个分类页面。
我认为 Discourse 上这个“所有话题”信息流的好处是，人们不必像通过雅虎那样通过目录的方式来浏览论坛，而是可以同时拥有雅虎和谷歌（甚至可以说 Facebook Newsfeed）的浏览方式。
但也许仅仅是许多分类的出现就让人们不知所措？或者我们只是好奇的生物，想点击左边的所有分类按钮？
我还不确定该怎么做，很高兴有一个公开反思和对话的空间。
2 个赞