我刚想到的另一个想法——既然您可以为群组设置默认通知设置，我想知道是否也可以在此处设置侧边栏默认设置。
只是尝试任何方法，以便侧边栏在某种程度上与通知设置保持一致。
抱歉打扰您，只是觉得这些功能集似乎应该以某种方式相关联。
在与 @nathank 的自定义主页合作之际，我在此重新提起此事。我想知道大家是否还有兴趣，或者我是否应该走自定义路线（这也没问题）。
我的 Discourse 乌托邦是：
- 当前的侧边栏类别 + 侧边栏标签反映跟踪。这可以缩小当前的复杂性。
…因此，例如，您加入一个组后，其跟踪和侧边栏配置可能会被更改，该组可能包含某些标签/类别的内置跟踪。表面上看，这是一件好事。 - 允许用户将默认主屏幕设置为反映“兴趣”。
这可能是我独特的用例。但我欢迎大家来挑出逻辑中的漏洞。
2 个赞
我认为这将是绝妙的，并且能很好地将现有功能联系起来。
目前，我手动强制某些组的用户（通过 Rails 控制台）在侧边栏中显示他们感兴趣的子类别 - 否则，除非他们收到通知，否则他们根本找不到它们。
我不太确定这一点，因为它在人们有多个兴趣时会变得棘手 - 随着我们网站的发展，这种情况已经发生，并且极大地限制了它的实用性。
1 个赞
嘿，我要1个，2个里面选1个。现在让我们恳求船员让它发生吧。
1 个赞
Bump：想知道 Discourse 的代表们是否会重新考虑这个问题？我可以走自定义路线，但这似乎非常复杂和混乱（而且如果 Discourse 重新考虑，可能是不必要的）。
嘿 @ncaming215，这仍然不在我们任何列表的顶端。
我们有很多想做的事情来让 Discourse 对新用户更简单，所以我当然理解这里的反馈，即这个空间值得在这方面进行更仔细的审视。
目前，我们更多地关注这个大方向的其他领域，以改善注册、编辑器和通知等领域的一般用户体验。不过，你仍然可以像以前一样，以合理的节奏不时地顶一下这个帖子来查看。
2 个赞
谢谢你，戴夫。
我经营了一个在线论坛大约 25 年了，我的全职工作是一家 YC 初创公司。所以，只是提供我的一点看法：
- 除非我们使用扩展的 Lexical（这在 Rails 中可能吗？）作为编辑器，否则这似乎很有价值，但并非必不可少。我认为 我的论坛 的规模可能值得您观察，但新用户从未抱怨过撰写帖子。
- 注册：很高兴听到这个消息，目前的注册从用户体验/集成角度来看都很笨拙。
- 通知：我很想看看你们会怎么做，但对我来说，这与我关于侧边栏和跟踪的观点息息相关。
因此，借此机会（是的，我又要向团队推销了）：侧边栏目前只是一个工具——一个快捷方式——用于导航。仅此而已。如果它明天消失了，用户/管理员将像往常一样继续使用。在这方面，它只是另一个用户体验层。就像通往同一目的地的额外入口一样。
但如果侧边栏同时支持通知和跟踪呢？ 
突然之间，跟踪（以及由此产生的通知）就不再深埋在偏好设置的多层中了。它就在用户面前。在他们浏览时无缝调整。
（未来，人工智能可以帮助调整用户的跟踪偏好，例如，一个工程师多次访问同一个网站以获取 TypeScript 主题，但懒得调整他的/她的偏好——网站会自动为他们调整。但这留待以后再说……）。
总之，我的观点是：用户正在浏览比以往任何时候都多的网站/应用程序。他们不像管理员那样使用网站。他们没有时间/耐心去弄清楚如何在网站不断发展的情况下管理他们的偏好。他们也不应该因为调整侧边栏与他们的账户偏好设置毫无关系而感到困惑。我们应该为他们简化这种体验！
好了，推销完毕。
无论如何，我都很喜欢这个团队以及他们在这里所做的一切。~
3 个赞
我应该补充一点，我最近有一位用户（是的，是的，一个人的焦点小组）抱怨说他们无法调整跟踪偏好设置——结果发现，他们试图使用侧边栏！）。但我怀疑这个人并不孤单。
1 个赞
我完全同意这个建议的功能将显著改善 Discourse 的用户体验。
我的用户（即使是精通技术的使用者）在当前的通知控件方面也遇到了困难。在我看来，在用户界面的第一层嵌入一个有效的概览将是改变游戏规则的。
3 个赞