manuel
(Manuel Kostka)
1
我很想制作与 Discourse 设计系统保持一致的自定义主题和组件，并以一致且和谐的方式融入应用程序。
仅仅查看核心代码以及样式是如何定义和应用的，我就很难理解并真正把握全局以及设计系统所设想的方向。
我将尝试将这个问题分解为三个主要主题：颜色、排版和间距。
颜色
两年前引入了数值比例来表示某些值。我认为提到过它只是为了补充命名的颜色转换。对于第三种颜色值，现在看起来是这样的：
我在核心的新代码中看到了这两种模型。长期来看，是打算将它们并列使用，还是有不同的设想？
无论如何，难道不应该为所有四种主要颜色值都提供数值比例吗？现在只有主色和第三色有，但第二色和第四色没有。
排版
目前定义了三种不同类型的字体大小递增：
这两年多也没有更新过。新代码中是否应该使用它们？坦白说，我从未触及过乘数定义，因为很难定义实际的最终字体大小。但我也无法理解基础字体定义。定义的比例是：
- 13px - 14px - 15px - 17px - 19px
但当我查看实际字体大小时，默认使用的比例或多或少是：
- 13px - 15px - 17.25px - 22px - 26px
间距
我看到新的元素（如侧边栏）引入了间距的根变量。例如：
这无疑使调整侧边栏布局更加容易。但它并没有转化为任何其他布局元素。另一方面，我没有看到引入基础间距变量，以便在整个应用程序中进行更一致的布局调整。这是否在路线图上？
总体
我很想知道是否有计划朝着更一致、更简单的设计系统发展？
目前似乎有太多不相关且独立的定义，它们使得构建一个具有轻松（和愉悦 
）感的、一致的、有节奏的布局变得非常困难。
我理解这是一个拥有大量不同元素的大型应用程序。然而，我只是在默认的最新列表视图上做了一个小测试：
这是一个使用非常简单的几何级数（2px/4px/8px/16px/32px/64px）选择的所有间距值重建的版本。字体大小仅来自 4 个值：
在设计方面，似乎没有必要在应用程序中拥有如此多的唯一定义？
14 个赞
这是我们一直想做的事情，并且已经逐步分阶段地朝着这个目标努力，但它无法一蹴而就。我们做的每一个改变都可能导致成千上万个网站出现主题回归（我们必须为客户修复其中很多问题），因此做出小的改变需要很长时间。
我们还一直在进行 Ember 现代化改造工作，这也需要修复回归和重构现有主题。这项工作仍在进行中，并且还需要时间来更新所有内容（例如，替换我们的 widget 系统可能就需要 6 个月）。有很多优先事项需要平衡。
除了提高一致性之外，没有其他预期方向。我们曾考虑过解耦基础样式，以便默认的“无主题” Discourse 拥有更少的 CSS（这可能更容易维护主题）……但这只是一个初步的想法。
我认为这些是“按需”添加的，所以我们还没有需要额外的二级/四级比例。我们没有计划删除命名版本，所以未来どちら（两者）都可以使用。
最小/较小/较大/最大的字体大小是用于用户设置的文本大小。大多数情况下，这些不需要更改。
em 比例大致基于经典的排版比例（例如，https://spencermortensen.com/articles/typographic-scale/）。一个更均匀的比例，如 13-15-17-19，不会产生太大的对比度，并且所有内容都会显得很小，除非你有许多步长。在经典比例中，比例之间的差距随着大小的增加而增加，以产生更多的对比度。
基于 em 的比例的理念是，应用程序中的所有内容都可以按比例缩放，并且应用程序的各个部分也可以按比例缩放。所以我可以这样做：
.sidebar-wrapper {
font-size: 20px;
}
并且其中的所有内容都会按比例放大，而无需更改每个单独的字体大小和所有相关的间距。
内部反馈与您的类似，开发人员希望确切地知道他们获得的字体大小，而不管上下文如何，这是该系统的一个缺点。理想情况下，我们不应该担心确切的大小，而可以只说“应该增加一步，因为我希望它更大”，但这种思维模式似乎并不自然。
有一些人希望改用 rem 比例，但如前所述……这可能会因为影响太多现有网站而需要很长时间才能改变。我也更喜欢浏览器默认的 16px 而不是我们的 15px 作为基础，但情况类似（它以前是 14px！所以我们至少已经迈出了一步）。
rem 比例用于已发布帖子内容中的标题，因为使用 em 嵌套标题标签意味着个人可以无限地放大文本并导致布局问题。
是的，这个问题出现过几次……（我听起来像个老生常谈，但……）这必须是一个非常渐进的改变，以避免现有网站出现回归。目前，我们在更新特定区域时，会在其中添加共享变量，这是朝着正确方向迈出的一步。
这些事情发生的速度可以理解为有点令人沮丧，但在 Discourse 的大部分历史中，根本没有全职设计师。在过去的几年里，设计团队已经发展到 7 人（包括专门为客户项目工作的设计师，这些项目大多在公众视线之外），所以希望我们现在能更快地朝着更高的目标迈进。
12 个赞
manuel
(Manuel Kostka)
3
谢谢你的解释 Kris！这真的很有帮助。
所以我的情况只是小范围的。但我有时确实认为，在产品方面改变整体预期会很有帮助。确立 Discourse 的快速发展。
这可能不错，但我认为仍然需要更简单的句柄。模板实在太多了。即使每个模板都有更简单的 CSS，如果我不能以一种协调的方式修改它们，那仍然是很多工作。
这是一个很棒的思维模式。我可能更喜欢精确的尺寸，因为它们更容易应用。比如，有人有一个设计系统，我只需要应用数字，然后看看结果。而否则，我觉得我需要对齐两个系统。比如我需要理解它们各自的特点，并找到它们的共同点。
5 个赞
manuel
(Manuel Kostka)
4
考虑到这一点……我可能会为 Discourse 设计系统构思几种方案。
一个实用的设计系统，包含标准化的原子构建块。我想这总是必要的第一步。
一个抽象了一些高级组件的系统。对于 Discourse，这些可能涉及审核、认可、信息等。
一个在线对话模式的通用系统。类似于 Material Design 等系统的基础范围。
2 个赞
