致力于 MightyNet UI 设计系统

随着 MightyNet 网络应用程序的发展，支持 Mighty Action Heroes 的功能越来越多，因此需要具有一致的界面设计和基于模块化组件的架构。 作为这个过程的一部分，我想分享一些关于什么是设计系统的想法，为什么你可能需要一个系统，以及为什么我们觉得现在是将这些实践付诸实践的好时机。 我还将简要介绍我们在将现有设计语言改编为我们自己的设计语言时遇到的一些挑战。 我希望这将帮助您了解拥有统一界面的重要性，它如何创建一致、可预测的用户体验，以及它对前端开发的重要性。

设计系统本质上是一个 一组视觉规则和指南，用于确定您的应用程序的外观和感觉。 它类似于品牌指南，因为它是一份文件，列出了您的应用程序的外观和感觉的注意事项。 我个人也是原子设计原则的粉丝，该原则将设计过程构建为创建单独的组件——你的设计指南的原子——然后可以用来创建更复杂的组件、布局，并最终创建页面； 分子、细胞、器官和器官系统，如果你愿意的话。

从发展的角度来看，以这种方式思考也很有帮助。 一般来说，在开发 React 应用程序和 Web 应用程序时，组件驱动的架构是去严格的——它最大限度地提高了 DRY-ness*，创建了关于如何实现组件的单一事实来源，以便在需要时该过程相对轻松 进行更改或升级，并且它创建了一个抽象，因此您作为工程师在构建页面布局或应用程序功能时不必担心各个组件。

* DRY — 或 Don 't Repeat Yourself 是编程的基本原则之一。 通常，重复代码意味着您没有考虑过您的应用程序在做什么，因此没有正确构建它，或者您的团队没有就正确的项目结构进行沟通。 尽管尽了最大努力，还是会发生这种情况：设计产品是一个不完美的过程。 它需要在不确定性和灵活性与时间线和优先级的艰难决定之间取得平衡。

设计系统需要大量工作，这通常是为什么它对小型应用程序或一次性应用程序并不总是有意义的原因 项目或着陆页。 但是，如果您知道您将长期致力于大型应用程序，那么越早将设计系统付诸实践越好。 设计系统可以是自适应的，就像代码库一样。 设计系统可能有等同于规则相互冲突的错误，或者设计违反其系统规则的区域。 让开发团队与 UI/UX 团队密切合作有助于解决许多此类问题，因为如果使用从该系统构建的组件，它们通常会在实施过程中浮出水面。

处理过度组件化：在实施过程的早期，看起来设计系统的阻碍多于它的帮助。 感觉代码库过度组件化，我们在流程的早期创建了比规则更多的例外。 对此没有通用的答案，在 Mighty Bear 中，我们在一段时间内如何最好地构建组件之间摇摆不定——创建它们，当它们变得太乱时取消创建它们，然后重新创建它们。 这是正常的，我认为长期坚持下去很重要，尤其是当你知道你的应用程序会变得更大更复杂的时候。 在将不一致写入代码之前将其暴露出来也很有帮助，这样您就可以重新审视您的决定是否有意义。

使用 Tailwind 设置样式：在之前的项目中，我参与过 ，我使用了各种 CSS 策略和方法。 使用 Bootstrap、Foundation 或语义 UI 是为应用程序获得一致和干净外观的快速简便方法。 对于更关心功能而不是形式并且只想要有用的东西的开发人员来说，这非常有用。 我认为这是一个共同选择的设计系统。 对于更多定制项目，我还编写了自定义 CSS 或 SASS 代码，或者采用了模块化方法。 这样做有好处：滚动您自己的样式确实可以完全自定义，但通常会带来一些麻烦，例如自动前缀、浏览器支持、多边形填充。 在 Mighty Bear，我们使用的是 Tailwind，这意味着我们在大多数情况下不必直接处理 CSS，但更接近于自己动手，而不是像 Bootstrap 这样的 CSS 框架。 您基本上可以随心所欲地做事。

### Putting it into practiceDesign systems are a lot of work, which is usually why it doesn’t always make sense for small applications, or one-off projects or landing pages. However, if you know you’re going to be working on a large application long-term, the earlier you can put a design system into practice the better. A design system can be adaptive, much like a code base. Design systems can have the equivalent of bugs, where rules conflict with each other, or areas where a design is breaking the rules of its system. Having the development team work closely with the UI/UX team helps resolve a lot of these issues, since they usually surface during implementation if using components built from that system.**Dealing with over-componentisation:** Early on into the implementation process, it may seem like the design system is getting in the way more than it’s helping. It can feel like the codebase is over-componentised and we’re creating more exceptions than rules early on in the process. There’s no universal answer for this, and at Mighty Bear we vacillated between how best to structure components for a while - creating them, uncreating them when they got too messy and then creating them again. This is normal, and I think long-term it’s important to stick with it, especially if you know your application is going to get bigger and more complex. It’s also helpful to have your inconsistency laid bare before you have it in code, so that you can revisit whether your decisions make sense.**Styling using Tailwind:** In previous projects I have worked on, I have used various CSS strategies and approaches. Using a Bootstrap, Foundation, or a Semantic UI is a quick and easy way to get a consistent and clean look for an application. It’s great for developers who care more about function than form, and just want something that works. I think of it a co-opting a design system. For more bespoke projects, I have also written custom CSS or SASS code or gone for a modular approach. There are benefits to this: rolling your own styles does make it fully customisable, but usually come with their own hassles like auto-prefixing, browser support, poly-fills. At Mighty Bear we’re using Tailwind, which does mean we don’t have to deal with CSS directly for the most part, but is closer to rolling your own than it is to a CSS framework like Bootstrap. You’re essentially free to do as you please.

MightyNet 网络应用程序从旧的 Windows 95–98 界面中汲取了很多视觉设计线索（我觉得写这个词很痛苦） 和 80 年代风格的合成波色彩，让人回想起俗气动作片的鼎盛时期。 设计系统不能只是批量调整。 需要考虑的事实是，它不再是 90 年代了，首先是：

• 响应能力：Windows 95 必须以 4:3 的比例与一台 CRT 显示器竞争 比率。 现代网站必须在从 iPhone SE 到超宽 8K 显示屏以及介于两者之间的所有内容上看起来都很好。 你不能再为一个屏幕设计了。 设计必须是自适应的。
• 触摸灵敏度和手势界面：在桌面界面中，您只能进行悬停、单击和滚动。 悬停不适用于触摸界面，这意味着采用触敏方式来呈现悬停信息非常重要。 考虑到触摸灵敏度还意味着可触摸目标也需要足够大，以便在触摸设备上按下。
• 可访问性：已经付出了更多的努力来使网络更易于访问 色盲、部分或完全视力障碍等残障人士的地方。 这些条件意味着必须遵守某些标准，即使它们在设计系统中不一定具有类似的表示
• 约定：现代网络有一些值得遵守的设计约定——页面顶部的导航栏、超链接、非重叠内容。 这意味着需要在整体调整界面机制（多个重叠窗口、窗口菜单、上下文菜单、任务栏和开始菜单）和坚持传统的 Web 界面设计之间取得平衡。 在这种情况下，要记住的指导原则是风格不应妨碍功能。 用户不应该对如何导航您的应用程序感到困惑 — 您希望将导航的认知负荷保持在最低限度，以便他们可以专注于他们想要/需要使用您的应用程序的目的。

• 局限性与风格选择：旧的 Windows 操作系统利用现有技术尽力而为。 例如，他们使用字体提示来提高较小字体的可读性，这使他们的排版具有一定的外观和感觉。 当实现类似的东西时，认识到我们想要在模拟它必须处理的问题方面走多远也很重要。 在我们的例子中，我们选择了一种现代字体，它克服了很多技术限制，同时在视觉上仍然回到了那种审美。

归根结底，设计是视觉问题的解决。 对于遵循简单规则集的问题，采用逻辑一致的方法很重要。 设计系统是该过程的产物。 一个合乎逻辑、经过深思熟虑的系统是前端开发的真正资产，因为作为开发人员，我们正在将这些设计规则编入……代码。 设计越简洁、越优雅、经过深思熟虑，您的代码库就会越简洁（希望如此！）。 在接下来的几个月里，我希望能够分享更多关于我们如何解决这些问题的信息，以及我们在 MightyNet 视觉语言方面取得的进展。 到那时，我希望这有助于阐明为什么拥有一个系统可能对您的应用程序是一项有价值的投资。

提交网络推广需求，免费获取报价和周期：