边飞边画：JSR 的设计理念

大约六个月前，我们在 悄无声息地开源 JSR 代码库，这比 Ryan 在 DevWorld 2024 上宣布它 早了几个星期。从那时起，我们很高兴看到社区拥抱 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 应用程序能让人感觉协调一致，并能被任何熟悉从会议、社交媒体或我们的文档中了解到该徽标的人立即识别出来。

我们首先将徽标的元素整合到页面的各个部分，从首页英雄背景开始，最终开始构建一个一致的调色板来为界面的其他部分进行样式设置，这可以帮助我们的最重要功能脱颖而出。

构建首页页眉背景

说实话：搜索框很有用，但并不有趣。我们希望 JSR 首页在视觉上引人注目；毕竟，这是许多人对 JSR 的第一印象。

我们探索了一系列选项，但最终确定的答案是一个轻量级的开源画布库，名为 particles.js。如果你点击它，很有可能你认得它；几年前，它在网络上非常流行，当时 Internet Explorer 还在使用。 (该项目可以追溯到 2014-2015 年。)

当然，在使用一个（曾经）流行的库时，总是存在看起来像是在模仿，或者过时的风险。但使用 particles.js 更像是重现经典，而不是追随现代潮流。尤其是因为 particles.js 为颜色、形状、速度、交互性等提供了广泛的选项，这意味着我们可以让我们的实现独具特色。

最终的结果是一个有趣的效果，它与 JSR 品牌和盒子主题都相关，并内置了一些有趣的交互性。此外，它运行起来也非常流畅，加载的 JavaScript 不到 10 kB。 (我们应该注意：我们确实对该库做了一些小的更改，以便我们能够 将配置对象直接传递到源代码中，而不是获取和解析 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 做出了许多很棒的贡献。这些贡献从小的但必要的错误修复，例如修复表格渲染和解决空状态，到有趣的增强，例如随机化徽标动画，甚至与我们团队的特性协作，例如添加开放图谱协议支持到我们的包页面，以帮助包作者更容易地分享其内容。

我们非常希望收到你的反馈，了解我们如何才能让贡献变得更容易。加入我们的 Discord或通过电子邮件[email protected]联系我们，分享如何使贡献对你来说更容易。

下一步

探索整体品牌的設計決策——從徽標到如何在網站上呈現——僅僅是開始。

在接下來的文章中，我們將深入探討設計包和文檔頁面的過程——特別是設計一個可重用、靈活的設計系統，以適應所有類型的deno doc輸出。敬請期待！