边飞行边绘制飞机：JSR 设计
自从我们在 Ryan 在 DevWorld 2024 上宣布 JSR 的几周前，悄悄地开源 JSR 代码仓库以来，已经大约六个月了。从那时起，我们很高兴看到社区拥抱 JSR，收到了来自 Deno 以外的 35 位以上贡献者的 240 多项额外贡献（这甚至还没算上添加到注册表的数万个包）。
从第一次提交开始，我们就希望 JSR 成为社区可以参与其中的一部分，帮助推动功能开发和界面改进。但是，作为一名设计师，我不太确定 JSR 会是什么样子。
在开放环境中设计并邀请外部贡献需要放下自我。看到人们与您“未完成”的作品互动可能会让人感到不舒服，但一旦适应，这个过程可能会非常有益。看到 JSR 在过去几个月中的发展令人兴奋，我想稍微揭开我们最初的起点，以及我们希望 JSR UI 走向何方的幕布。
选择徽标
到 2023 年 7 月，我们放弃了内部代号“registry3”，并确定了名称“JSR”。最初，我们除了一个名字什么都没有，所以我们从徽标开始。我们（作为设计师）当时对这个项目并没有真正了解太多，除了我们正在构建一个旨在对所有 JavaScript 用户而不仅仅是 Deno 用户有用的注册表。我们从 Chris Williams 无处不在的非官方 JavaScript 徽标中获得了一些初步灵感。
最初的一个建议是采用那个标志性的徽标，然后在某个地方挤入一个 R。但是经过一番实验后，我们很快意识到这不是正确的方法。
这些想法都没有真正让人感觉是对的。首先，生态系统中已经有很多“JS”徽标的变体，使得独特性成为一个挑战。此外：我们不想冒险给人 JSR 像是某种仓促的附加组件，或 JavaScript 扩展包的印象；我们希望它拥有自己的视觉身份。
因此，我们开始探索其他选择。从 JSR 作为包注册表的角色出发，我们开始尝试“块”的概念，以唤起一个由许多较小部分组成的系统。
那时，我们想到了双向图的概念；也就是说，一个可以旋转 180° 并且仍然是相同形状的徽标（“J”变成小写“r”，反之亦然）；这是一种设计上的致敬，即无论包如何适应，都可以将其添加到您的项目中。
您可能认出上面的最终 JSR 徽标，但有趣的是，当时这些想法都不是最终徽标。徽标的设计者（也是该项目的开发人员之一）Josh Collinsworth 这样说
最终成为 JSR 官方徽标的概念最初只是一个匆忙的草图。我当时正在尝试很多想法，从我在设计学院期间做过的项目中汲取灵感，只是为了探索一些可能性。
碰巧的是，这个徽标是工程师们决定用作占位符的徽标，并且他们支持它。我最初不愿意将其加冕为获胜者，因为我仍然认为它只是一个快速的概念草图。但是，我们与它相处的时间越长，就越觉得它直接的简洁性实际上非常适合这个项目。
所以我们有了我们的徽标……但是我们需要回到调色板来完成工作，最终将最初的深棕色换成了更具特色的蓝色。
最终，我们选择了既简单，又受到 JavaScript 语言最易识别的徽标的启发，并且足够“非 Deno”的东西。
扩展徽标的影响力
在最终确定徽标后，我们的下一步是将徽标的设计原则贯穿整个 JSR 界面。徽标不仅仅是一个视觉元素；它为产品的整体外观和感觉定下了基调。我们希望 JSR 应用程序对任何熟悉会议、社交媒体或文档中的徽标的人来说都感觉连贯且易于识别。
我们首先将徽标的元素集成到页面的各个部分，从主页的 hero 背景开始，最终转向构建一致的调色板来为界面的其余部分设置样式，这可以帮助我们最重要的功能脱颖而出。
构建主页标题背景
说实话：搜索框很有用，但不是很吸引人。我们希望 JSR 主页在视觉上具有引人注目的东西；毕竟，这是许多人对 JSR 的第一印象。
我们探索了一系列选项，但我们最终确定的答案是一个轻量级的开源 canvas 库，名为 particles.js。如果您点击进去，很有可能您会认出它；几年前，当 Internet Explorer 还在时，它在 Web 上非常流行。（该项目可以追溯到 2014-2015 年。）
当然，当使用（曾经）流行的库时，总是存在看起来像模仿者或过时的风险。但是使用 particles.js 感觉不像是在追随现代潮流，而更像是以复古风格复兴经典。尤其如此，因为 particles.js 提供了颜色、形状、速度、交互性等多种选项，这意味着我们可以使我们的实现具有独特的特色。
最终结果是一个有趣的效果，它将 JSR 品牌和方块主题联系起来，并融入了一些有趣的小互动。此外，它的性能非常出色，加载的 JavaScript 不到 10kB 延迟。（但是，我们应该注意：我们确实对该库进行了一些小的更改，以允许我们将配置对象直接传递到源代码中，而不是获取和解析 JSON 文件，以便尽可能减少移动部件的数量。）
从徽标构建调色板
当我们开始构建 JSR 时，我们不希望开发人员感觉他们必须等待视觉设计决策的制定，才能构建新功能。我们选择了一些我们感到舒适的标准 Tailwind CSS 颜色，知道我们以后可以通过修改 Tailwind 配置中的调色板或添加其他颜色并在所有相关的 Tailwind 颜色类上执行全局查找/替换来替换它们。
从徽标中获得灵感，我提取了黄色和深青色，并使用名为 UIColors 的 SaaS 设计工具开始基于这些颜色构建调色板。
标准的 Tailwind 调色板通常包括大约 11 种颜色变量的变体，从“50”表示最浅的变体到“950”表示最深的变体。UIColors 会最佳猜测您呈现为锚点颜色的颜色应该在刻度上的哪个位置，从而允许您锁定锚点颜色并调整周围调色板的亮度、饱和度和色调。我们在 JSR 徽标中使用的黄色恰好位于刻度的中间，将成为 jsr-yellow-400，而青色则位于刻度的末尾，为 jsr-cyan-950。
然后，我根据我对颜色在实践中可能如何使用的想法，对刻度进行了细微调整，使其朝该方向偏移。我没有预料到会在界面中使用大量的黄色，因为如果您在打算使其可访问的文本上使用黄色，它通常必须呈现棕色调。认识到黄色主要用作强调色，我调整了它的色调并提亮了刻度的较浅端。对于青色刻度，我也提高了亮度，以便我可以将刻度较低端的许多颜色用于边框和强调色，而不会分散内容的注意力。这种方法使我们能够用青色阴影替换最初的灰色调，在为应用程序添加更多个性的同时，使其与整体 JSR 品牌保持一致。
这可能不会是我们最后一次改进调色板，在全局配置中定义它们使未来的更改变得简单明了。
当前调色板遇到的问题之一是，您必须对哪些色调彼此兼容以及它们应该在何处使用有一定的感觉。许多智能设计系统会以这样一种方式构建其颜色标记，即设计师始终可以相信，当相邻使用时，相隔 3 或 4 步的阴影将提供可访问的对比度——例如 jsr-cyan-700 文本在 jsr-cyan-300 背景上。这在我们当前的系统中不一定是正确的，因此我们在构建新组件时必须依赖手动对比度可访问性检查。标准化的系统将使外部贡献者更容易一些。
应用改进后的调色板
当需要将调色板应用于 JSR 时，我花了一些时间思考 JSR 包页面可能在 JavaScript 生态系统中发挥的作用。我们希望 JSR 上的包页面感觉像是包的官方主页，从而使工程师们无需为他们的每个包构建一次性的营销和文档站点，同时仍然为他们的用户提供他们需要的所有信息，以便就如何使用他们的代码做出明智的决定。
如果我们希望作者能够将这些包页面视为他们项目的主页（JSR 自动生成您的文档），我们必须确保包中链接的任何子页面仍然感觉像是 JSR，这意味着即使在子页面上也要保持一致的品牌标识。将某人直接链接到您包中的文件应该感觉与将某人链接到函数或您的 JSR 分数的体验相关联。
在构建了改进后的调色板之后，我梳理了包页面，并使用我们的新调色板应用了一致的边框颜色、字体颜色、高亮和链接样式，确保无论您在哪里着陆，都感觉像是 JSR。在进行了一些手动编辑以确定哪些颜色需要转换为新调色板中的颜色之后，我能够编写一些简单的正则表达式来匹配整个项目中需要转换的实例。随着数十个更改排队，我能够在 VSCode 中点击非常令人满意的“全部替换”按钮，并在整个站点上体验全新的外观和感觉。
邀请社区贡献
虽然 JSR 的种子是由 Deno 团队播种的，但我们一直希望它能在社区的关怀下成长。我们很高兴看到开源贡献者在最初几个月内为 JSR 做了很多出色的补充。这些贡献范围从小的但必要的错误修复（如修复表格渲染和解决空状态）到有趣的增强功能（如随机化徽标动画），甚至与我们团队进行功能协作（如在我们的包页面中添加open graph 协议支持，以帮助包作者更轻松地共享他们的内容）。
我们很乐意听取您的意见，了解我们可以做些什么来使贡献更容易。加入我们的 Discord 或通过电子邮件 [email protected] 与我们联系，分享我们如何才能使您更容易贡献。
下一步是什么
探索整体品牌的设计决策——从徽标到它如何转化为网站——仅仅是开始。
在即将发布的文章中，我们将更深入地探讨包和文档页面背后的设计过程——特别是提出一个可重用的、灵活的设计系统，以适应各种 deno doc 输出。敬请期待！