边飞边画：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 作为包注册表的角色，我们开始尝试“块”的概念，以唤起一个由许多小部分组成的系统。
也正是在那时，一个反转图（ambigram）的想法浮现在脑海中；也就是说，一个可以旋转 180° 仍然保持相同形状的标志（“J”变成小写“r”，反之亦然）；这是一种设计上的暗示，意指无论如何，都可以将包添加到你的项目中。
你可能认出了上面的 JSR 最终标志，但有趣的是，当时这些想法都不是为了成为最终标志。标志的设计师（同时也是该项目开发人员之一）Josh Collinsworth 这样说道
最终成为 JSR 官方标志的概念最初只是一个匆忙的草图。我尝试了许多想法，从我设计学院时期的项目中汲取灵感，只是为了探索一些可能性。
碰巧的是，工程师们决定将这个标志用作占位符，并且他们极力支持它。我最初不愿将其加冕为优胜者，因为我仍然认为它只是一个快速概念草图。但我们越是习惯它，就越觉得它的简洁直观恰好非常适合这个项目。
于是我们有了标志……但我们需要回到调色板来完善一切，最终我们将最初的深棕色换成了更具辨识度的蓝色。
最终，我们确定了一个简洁的方案，它受到了最易识别的 JavaScript 语言标志的启发，并且足够“非 Deno 化”。
扩展标志的影响力
标志定稿后，我们的下一步是将其设计原则贯穿整个 JSR 界面。标志不仅仅是一个视觉元素；它为产品的整体外观和感觉定下了基调。我们希望 JSR 应用给人的感觉是连贯的，并且让任何通过会议、社交媒体或我们的文档熟悉该标志的人都能立即识别出来。
我们首先将标志的元素融入到页面的各个部分，从主页的英雄背景开始，最终逐步建立一套统一的调色板来设计其余的界面，从而帮助我们最重要的功能脱颖而出。
构建主页标题背景
老实说：搜索框很有用，但它并不是很有趣。我们希望 JSR 主页能有一些视觉上引人注目的东西；毕竟，那是许多人对 JSR 的第一印象。
我们探索了一系列选项，但最终选择了一个轻量级的开源 canvas 库，名为 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-300 背景上的 jsr-cyan-700 文本。这在我们的当前系统中并不一定成立，因此在构建新组件时，我们必须依赖手动对比度可访问性检查。一个标准化的系统将使外部贡献者更容易上手。
应用精炼的调色板
当需要将调色板应用于 JSR 时，我花了一些时间思考 JSR 包页面在 JavaScript 生态系统中可能扮演的角色。我们希望 JSR 上的包页面感觉就像可以是包的官方主页，让工程师们无需为每个包构建一次性的营销和文档网站，同时仍然为用户提供他们所需的所有信息，以便他们做出有关如何使用其代码的明智决策。
如果我们希望作者能够将这些包页面作为他们项目的主页（JSR 会自动生成你的文档），我们就必须确保包内链接的任何子页面仍然感觉像 JSR，这意味着即使在子页面上也要保持一致的品牌形象。直接链接到你包中的文件应该与链接到函数或你的 JSR 分数的体验保持一致。
构建精炼的调色板后，我仔细检查了包页面，并使用我们的新调色板应用了一致的边框颜色、字体颜色、高亮和链接样式，确保无论你访问哪个页面，都感觉像是 JSR 的一部分。在手动编辑了几次以找出需要转换为新调色板中颜色的实例后，我能够编写一些简单的正则表达式来匹配整个项目中待转换的实例。随着数十项更改排队待处理，我能够在 VSCode 中点击一个非常令人满意的“全部替换”按钮，并体验整个网站焕然一新的外观和感觉。
邀请社区贡献
虽然 JSR 的种子是由 Deno 团队播下的，但我们始终希望它能在社区的呵护下成长。我们很高兴看到开源贡献者在最初几个月为 JSR 带来了许多出色的增补。这些贡献范围从虽小但必要的错误修复（例如修复表格渲染和处理空状态），到有趣的增强功能（例如标志动画的随机化），甚至包括与我们团队的功能协作（例如为我们的包页面添加开放图谱协议支持），以帮助包作者更轻松地分享他们的内容。
我们很乐意听取您的意见，了解我们可以做些什么来让贡献变得更容易。加入我们的 Discord 或通过电子邮件 design@deno.com 联系我们，分享我们如何能让您更轻松地做出贡献。
接下来
探索整体品牌的设计决策——从标志到如何将其转化为网站——这仅仅是个开始。
在接下来的文章中，我们将深入探讨包和文档页面背后的设计过程——特别是如何设计一个可重用、灵活的设计系统，以适应所有类型的 deno doc 输出。敬请期待！