前言

哈哈哈哈，最近事情太多了，已经快三个月没更新了，现在也忙的差不多了，咱们更新继续~~

今天给大家分享的是关于如何从零开始搭建 B 端设计规范。

时间转眼即逝，掐指一算，我接触 B 端已有 4 年之久了，当年刚接触的时候，B 端的从业人员比例还是很少的。近两年 B 端越来越火热，无论从设计风格还是产品数量上，都有了很大的提升。

随着 B 端的产品越来越完善，要求设计师的专业性也要越来越强。设计规范作为基础中的基础，是大家都要熟练掌握的技能，我们不仅要会运用各种规范，还要会撰写适合产品的规范。

分享开始，敲黑板~~

一  设计规范的目标

在搭建设计系统之前，我们要想清楚设计规范的目标是什么？使用者是谁？

目标：保持产品风格统一性、提高设计输出效率、减少无效沟通。

使用人群：UI、交互、前端、测试。

二  设计原则

设计规范要符合基本的设计原则，否则你的规范会杂乱无章。这里我总结了 6 条原则供大家参考。

Unity（统一性）：页面风格、色彩、布局等要保持全局统一，不可为了某一功能的美观而去破坏整体性。

Accessibility（易用性）：易用是首要考虑的因素，能一步解决的事情绝不两步。

Proximity（亲密性）：如果信息的关联性强，则他们的距离就要相应的缩短，让他们看起来是一个视觉单元；反之，则距离要加大。要让用户对信息的区域划分一目了然。

Alignment（对齐原则）：在界面中，将元素进行对齐，即符合用户的认知，也可以引导视觉流向，让用户更加流畅的阅读信息。

Contrast（对比原则）：对比是增加视觉效果最有效方法之一，同时也能在不同元素之间建立一种有组织的层次结构，让用户快速识别关键信息。

Repetition（重复原则）：相同的元素在整个界面中不断重复，不仅可以有效降低用户的学习成本，也可以帮助用户识别出这些元素之间的关联性。

三  框架布局

这里一般采用栅格布局。说到栅格，有好多小伙伴又要再回顾一下知识点了。我今天再把栅格知识帮大家复习一遍，如果之前不是很了解栅格的，拿个小本本记下来，要考~~

栅格布局能够适应各种屏幕尺寸及分辨率，确保整体布局的一致性。

栅格建议使用 1、2、3、4、6 切分布局，可以进行多种布局组合，并在整个设计中保持布局的结构的一致性。

页面中一般采用 24 列自适应网格，你可以使用它为各种屏幕尺寸创建灵活的布局。

边距 Margins、列 Columns、间隔 Gutters 分别是什么？

边距 Margins：边距是内容与左右边缘之间的空间。控制台内容区的边距选用 8 的倍数为设定值，一般采用 16/24px 的居多。

需要注意的是：

减去 margin 后，列在页面区域均分，保证每列的宽度是一致的；

在区域有 margin 的情况下，划分列的区域不能包含 margin。

列 Columns：在电脑端列的数量是个常量（24列），每一列宽度的尺寸随屏幕大小进行自适应调整。

间隔 Gutters：间隔是列与列之间的空隙，控制台产品 gutter 使用固定值也要是 8 的倍数，一般采用 16/24px。

需要注意的是：

布局的左右两边的分界线 gutter 可以为 0；

必须保证 column 的宽度是一致的。

边距 Padding：padding 指一个元素的内容和其边界之间的空间，padding 最小值是 4px，然后其余均为 8px 的倍数，建议值为 8/16/24px。

内容区定宽：此场景常用于用户欢迎页、结果页等需要将内容区宽度设置为固定值的页面。此时 column 和 gutter 保持不变，根据页面宽度改变 margin 的值。

四  设计风格

4.1  Color（颜色）

色彩内容主要包含基础色（如品牌色、黑色、白色）和功能色（如链接色、提醒色等）。图表配色为单独的配色体系。

在前期制定颜色规范的时候，精益求精的设定颜色，切忌颜色过多。

颜色的状态色尽量用原色进行转换，设置一个合理的变色公式，让所有颜色的状态色都根据这个公式进行转换。例：

Hover：H不变 S加10 B减5；

Click：H不变 S加20 B减10；

Disable：HSB均不变，不透明度 30%。

在设计规范中，尽量把颜色的色值和 rgba 值都写出来（这里是强迫症患者要标的，因为有时候色值完全一样，但 rgba 数值略有不同，虽然效果一样，但是对于强迫症的你来说，舒服吗？）

状态色有 4 状态色：Normal、Hover、Click、Disable。

在设定图表颜色的时候，要考虑不同的使用样式（柱状图、环形图、饼图等...），同时也要考虑他的延展性，比如你设定 12 个 chart 色值，在使用的时候按着顺序来使用，当超过 12 个后可以为同一个颜色。

4.2  Font（文字）

设定统一的字体规范，使用非衬线字体在各个操作系统下都有最佳展示效果。

首先，要设置一个字体家族，保证产品界面的最优展示。

例如（仅作为展示，不是建议）：font-family: "Chinese Quote", -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", "Helvetica Neue", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";

4.2.1  字号

现在主流的产品中，主体字为 12px / 14px 的居多，可根据自身的产品定位以及用户的习惯进行设定。字号不要出现奇数，否则在一些显示器上会有对不齐像素的状况发生。

4.2.2  行高

行高常规的有两种规范：

字号+8px；

1.5倍 / 2倍 * 字号。

我喜欢用第一种，就是字号大小 + 8px 作为行高的规范。行高是不可被忽略的重要细节之一，因为在算间距的时候，行高是要被算进去的。

4.2.3  字重

字重有很多，但是在真正的产品使用中，字重尽量不要太多种，2~3 种即可。

4.2.4  字体颜色

字体颜色数量建议在 3~4 个，不宜过多，但是每个层级之间区分要大一些。

文本应该保持至少 4.5:1 （基于亮度值计算）的对比度以保持文本清晰；最佳对比度为 7:1。测试对比度的网站：https://contrast-ratio.com

WCAG 2.0 中将颜色对比等级分为 3 种，A级，AA级，AAA级，等级越高意味着颜色的对比度越高，呈现出来的视觉压力越大。

A级：对比度 3:1，是普通观察者可接受的最低对比；

AA级：对比度 4.5:1，是普通视力损失的人可接受的最低对比度；

AAA级：对比度 7:1，是严重视力损失的人可接受的最低对比度。

4.3  icon（图标）

设定统一的图标使用规范，让视觉效果更和谐。

4.3.1  Icon 大小

icon 的常用尺寸有很多，需要注意的是 icon 的大小中，相邻的两个尺寸至少相差 4px，否则你会在后期用的时候会有选择困难症。同时功能 icon 尽量贴边或尽量贴边绘制，保证展现的视觉统一性（操作 icon 除外）。

单独 icon 使用的时候，尽量不要太小，最小值建议为 12px。

4.3.2  Icon 热区

icon 的热区经常被设计师和开发所忽略，本身 icon 的尺寸一般就很小，再加上如果没有设置热区的话，操作体验极差。所以一定一定要设置 icon 的热区，设置的值我建议为 icon 大小的 2倍。例：icon 大小为 14 * 14px，则热区大小为 28 * 28px。

4.4  size（尺寸）

页面内布局间、模块间、模块内的各部件距离。

尺寸大部分规范中都用的是 8 的倍数，不用纠结，直接用就行。我这里有个公式：Sn = 8px * n，n为正整数。特殊：最小支持4px。

五  交互

交互我分为两个方面：交互方式和交互状态。

5.1  交互方式

交互方式指的是对某一个操作所进行的具体行为，比如刷新方式有下拉、上滑、按压点击等方式，这就是所谓的交互方式。交互方式有很多种，没有最优，只有最适合。

交互方式要保持产品的统一性，同类别的交互不可有不同的操作感受。同时交互方式要符合大众的认知习惯，可创新但不可违背潜意识。

随着时代的发展，交互方式也在不断的更新。比如最开始的手机是按键式的，随着大众对屏幕大小的需求不断提升，到了现在的全面屏手机，如果这个时候你再去做当年火爆的按键手机，那你就只能跟市场说拜拜。

总结交互方式的几个关键点：创新、统一、紧跟趋势。

5.2  交互状态

一个完整的产品生态是不会遗漏每一个交互状态的。

同样是做售票的软件，为什么高铁管家就比 12306 做的好呢？是因为高铁管家把很多交互状态友好的做了展现反馈，而不是冰冷的数据吞吐。

同类产品中，每个都有自己独特的交互状态，可能你一直用某个软件的原因只是有个功能的交互状态打动了你，从此你就深深爱上了它。

现在工作中，我们都在讲人效，拼命的去更新迭代，去研发新功能，开拓新产品，往往会忽略交互状态这个点，因为很多时候付出收获比是很低的，但是真正好的产品，这部分是不可或缺的。

交互真的太大了，单独写一篇文章都写不完，这篇我只能抛砖引玉，勾起你的思维，如果有任何要探讨的，欢迎来叨扰。

六  引导

引导分为 5 种：Newbie guide（新手引导）、Steps guide（步骤引导）、Help / Operation guide（帮助/操作引导）、New function guide（新功能引导）、Blank guide（空白页引导）。

6.1  Newbie guide（新手引导）

新手引导是针对新用户的，首次进入产品的时候，我们要着重的把自己产品的亮点以及操作快速的介绍给新用户，让他用最短的时候上手我们的产品。

新手引导要言简意赅，并且如果非必要的话，尽量给用户一个可以直接关闭的按钮，让用户有选择权。我就非常讨厌有一些产品的新手引导，必须走完全部流程后才能关闭，恶心的不行。

6.2  Steps guide（步骤引导）

步骤引导一般用在有固定操作步骤的场景下，指引用户一步一步的完成想要的结果。常规的步骤引导建议在 3~5 步之间为合理。

6.3  Help/Operation guide（帮助/操作引导）

帮助/操作引导的展现方式是比较丰富多彩的，可以是提示语、辅助性文本、tooltips 等等，他的作用就是辅助用户去了解并且知道如何操作这个功能。

这个也是在产品中使用频率最高的，运用好他，可以让你的产品事半功倍。

6.4  New function guide（新功能引导）

他就是常用在新功能上线后，用户第一次登陆相关页面后做的一些引导，目的是为了告诉用户我们做了新东西，你快来试试吧。

6.5  Blank guide（空白页引导）

空白页引导一般用在在缺省页，对用户进行一些操作指引，让无信息的页面变得更有价值。比如百度在一些缺省页上就放了一些关于失踪儿童的信息，就因为做了这个引导，帮助了千万个家庭找到了失散的孩子。

七  组件

组件是设计系统里面最为庞大的东西。组件可以分为了 5 类：

Navigation（导航）

Data Entry（数据录入）

Data Display（数据显示）

Feedback（反馈）

Other（其它）

基本上这几类已经覆盖了多数的组件，下面我把我自己整理的这几类分别都包含哪些组件，以及组件的简单介绍给列出来，快来保存吧。

7.1  Navigation（导航）

Affix（固钉）：将页面元素钉在可视范围。

Breadcrumb（面包屑）：显示当前页面在系统层级结构中的位置，并能向上返回。

Menu（导航菜单）：为页面和功能提供导航的菜单列表。

Pagination（分页）：采用分页的形式分隔长列表，每次只加载一个页面。

Steps（步骤条）：引导用户按照流程完成任务的导航条。

7.2  Data Entry（数据录入）

Checkbox（多选框）：可选择多个。

Radio（单选框）：只可选择一个。

Switch（开关）：开关选择器。

Form（表单）：具有数据收集、校验和提交功能的表单，包含复选框、单选框、输入框、下拉选择框等元素。

Input（输入框）：通过鼠标或键盘输入内容，是最基础的表单域的包装。

Select（选择器）：下拉选择器。

Skeleton（加载占位图）：在需要等待加载内容的位置提供一个占位图。

Time selectors and sliders（日期时间选择过滤器）：当用户需要输入一个时间或日期，可以点击标准输入框，弹出时间面板进行选择。

Transfer（穿梭框）：双栏穿梭选择框。

Upload（上传）：文件选择上传和拖拽上传控件。

7.3  Data Display（数据显示）

Badge（微标）：图标右上角的圆形徽标数字。

Card（卡片）：通用卡片容器。

Collapse（折叠面板）：可以折叠/展开的内容区域。

Popover（气泡卡片）：点击/鼠标移入元素，弹出气泡式的卡片浮层（可操作）。

Tabs（标签页）：选项卡切换组件。

Table（表格）：展示行列数据。

Tag（标签）：进行标记和分类的小标签。

Timeline（时间轴）：垂直展示的时间流信息。

Tooltip（文字提示）：简单的文字提示气泡框。

Tree（树形控件）：文件夹、组织架构、生物分类、国家地区等等，世间万物的大多数结构都是树形结构。使用树控件可以完整展现其中的层级关系，并具有展开收起选择等交互功能。

7.4  Feedback（反馈）

Alert（警告提示）：警告提示，展现需要关注的信息。

Notification（通知提示框）：全局展示通知提醒信息。

Drawer（抽屉）：抽屉从父窗体边缘滑入，覆盖住部分父窗体内容。用户在抽屉内操作时不必离开当前任务，操作完成后，可以平滑地回到到原任务。

Modal（对话框）：模态对话框和非模态对话框。

Progress（进度）：展示操作的当前进度。

Spin（加载）：用于页面和区块的加载中状态。

7.5  Other（其它）

Button（按钮）：按钮用于开始一个即时操作。

chart（图表）：图标数据显示。

Copyright（版权）：版权信息。

Divider（分割线）：区隔内容的分割线。

logo（标志）：logo 的使用。

LocaleProvider（国际化）：为组件内建文案提供统一的国际化支持。

Text link（文字链）：点击有链接跳转的文字。

Scrollbar（滚动条）：在特定界面区域内进行内容的更多展示。

以上组件可根据自己的产品进行增删，把组件规范设计完成后，整个设计规范就完成了 90% 以上，可以算一个比较完整的设计规范了。

总结

每一个设计规范都是有灵魂的，规范是为了更好的做设计，而不是限制设计师双手的枷锁。

设计规范也不是一成不变的，他在落地使用的时候多少都会有问题，需要慢慢的去反复检验规范的合理性，发现不合理的及时更正。

最后，希望本编文章能对看完的你有所帮助，这也是我做分享的初衷，我们下期见。

作者：友设青年
链接：https://www.jianshu.com/p/4752bf2e25bb
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1.1 定义

作为一个B端产品，为了应对公司快速迭代开拓市场和一部分购买者的定制化需求，与此同时还要保障产品间的用户体验一致性，近年来设计规范这一解决方案不断升温，如Salesforce，antdesign、等纷纷推出了自己的设计规范。那么到底什么是设计规范呢？和设计语言、设计原则、组件库等有什么关系呢？

我认为的设计规范是以下的定义：

设计规范由设计原则、设计语言和组件库构成，在设计原则的指导下使用设计语言和组件库创建体验一致的用户界面。

设计原则：即整个设计规范所要遵循的全局规则，为设计提供方向指导。以下给出几个例子：

设计语言：包括色彩，文字、图标等

组件库：分为基础组件（按钮，下拉列表等）及业务组件（商品模块）。

在做设计语言和组件库时，有一个基本原则是，少即是多(less is more)，用尽可能少的样式来实现设计目标，例如按钮提供三种尺寸即可，在适应不同场景需求的同时保证体验的一致性；另一方面，保持克制的设计规范可以进一步减少设计师的决策时间，提高设计效率。

1.2 理论基础-原子设计

1.2.1 什么是原子设计

原子设计是构建设计规范的核心指导理论。2013年，Brad从化学中得到了灵感，创建了原子设计理论。在化学中，所有的物体都是由原子构成，原子构成分子，进而构成宇宙万物。对应到界面中，界面也是如此，所有的元素都是由文字、颜色等最基本的元素构成的。这些基本元素构成组件，组件构成页面。

原子设计概念的提出使得设计规范演变成为了一种更为高效、科学的设计规范，极大的改善了设计师与前端工程师的工作体验。

1.2.2 原子设计系统的五个层次

原子设计包含五个同时工作的阶段，以更慎重和更具层次的方式创建界面设计规范。

原子:原子是构成界面的最小元素，例如颜色、文本、图标、线条。它们在在界面这个维度上不能再被细分。例如图标，本身是可以继续细分的，但是对于界面而言，图标细分得到的元素是没有任何意义的。

分子:原子按照一定的规律组合就构成了分子，它们拥有独特的功能，例如下拉列表，步进器等。

组织:在界面中组织体现为由分子原子组成的模块，例如数据概览的卡片。

模板:在界面中，模板的体现是原型图，是页面的基本形态，可以让我们快速试错，搭建出一个功能良好的整体。

页面:在模板的基础上将占位符更换为真实内容，并进行视觉优化即为页面。

1.3 为什么需要设计规范

1.3.1 软件危机

在讲述设计规范之前，我想先讲述一个互联网史上的真实事件——软件危机。

19世纪80年代，软件的复杂度进一步提升，大规模软件甚至会由由数百万行代码组成，有数以百计的程序员参与其中，抽象语言解放了程序员的生产力和想象力，人们可以像写文学小说一样随意发挥地去写代码。摆在面前的问题是如何高效且可靠地维护与迭代如此庞大的软件。之后C++、Java等我们熟知的面向对象的编程语言诞生了。

面向对象这种模式有一个很重要的特征是封装。这就好比当你在写王者荣耀的代码时，小兵是出现频率较高的模块，你可以提前把王者荣耀里的一个小兵封装成一个代码块，当你需要用到它时，不必重新一行一行写，只需要把它整体调用即可。

纵观软件发展史，20世纪60年代的第一次软件危机创造了“模块”概念；20世纪80年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；模块与对象本质上都是对软件进行拆分与封装，只是对象拆分的粒度更大，维度更高。这点与原子设计的原理不谋而合，从色彩文字等基础元素，到按钮、选择器等基础组件、再到典型模块，也是对大型软件的设计元素不同粒度的拆分与封装。

1.3.2 设计规范的优势

设计层面：解决用户体验一致性，减少设计成本，提高设计效率，使得设计师可以快速承接新需求。沉淀设计资产，使得设计更加持续地输出价值，减少一次性设计，同时使设计师从样式中解放出来，站在更高的层面上来思考业务与体验。

开发层面：与设计规范同步形成研发资产，避免重复造轮子，保证代码质量，降低维护和拓展的成本。

测试层面：避免重复的无意义走查。之前遇到过一个深色模式的需求，尽管只换了颜色，但是测试仍然把所有组件都测试了一遍，加上重复的设计、开发量，导致原本一个很简单的需求，居然花费了12人天的工作量。

产品层面：提高产品迭代与优化效率，降低试错成本。

协作层面：降低不同设计师之间以及设计师与开发工程师之间的沟通成本。

1.4 为什么要自己做设计规范

这个时候可以会有小伙伴问，目前市面上有这么多的第三方设计规范，例如antdesign，element，有必要自己重复造轮子做一遍吗？答案是非常有必要。原因如下：

B端自身的业务性决定了市场上没有万能的设计规范，那些设计规范的组件并不能100%满足我们产品的需求。另外一方面使用封装好的第三方设计规范，在此基础上进行修改，效率很低，适配的复杂度和重新开发相差无几。

大家都在使用第三方设计规范时，产品的同质化便不可避免。为了避免这种情况发生，我们必须要从设计语言开始，设计自己的规范。

那些大厂的成熟的组件库该如何用呢？我认为应该把它当成一个字典，有不会的地方，可以去参考人家的成熟的解决方案。

1.5 设计规范的落地

1.5.1 落不了地的原因

1.设计层面：

a. 组件扩展性弱：有的设计师做出来的组件虽然看着很好，但是实际上使用时，适配效率很低，用组件去扩展和重新做的效率差不多。

b. 脱离业务：大部分时候设计师手中都有任务，于是这个任务就落在了实习生的肩上，但是实习生不了解业务，做出来的是空中楼阁，抛开业务谈设计规范的都是耍流氓。

c. 缺乏开发思维：设计师不了解开发的实现方式，可能会做出来开发较难实现的组件。

2.开发层面

缺少开发资源：设计规范的作用是巨大而缓慢的，不能即时产出很大的价值，另外一方面，设计规范的落地会增加开发工程师很多的工作量，且无法量化收益。这也导致很多时候无法争取到足够的开发资源来做这件事，导致达不到预期的效果。

1.5.2 如何落地

说完了落不了地的原因，那么如何落地呢？我认为要从以下四个方面来推进：

写一份设计规范的价值的提案给领导，争取到足够的开发资源。

借鉴敏捷开发的思想，小步迭代快速推进，将设计规范的覆盖放在每次迭代过程中。

把设计规范的开发交给熟悉业务的设计师来做，通过业务提炼复用率高的典型元素，优先开发，最大化投入产出比。

设计师在做设计规范时，要不断与开发工程师沟通，保证设计规范的还原度。

B端UI界面的视觉设计是一种偏向与排版的设计类型，而其中对于文字的使用更是重中之重。文字包括字体，字重，字号，行高、颜色五个属性。一般情况下，字体采用系统自带的字体（例如苹方、微软雅黑、思源黑体），另外对于B端来说，一般都会有较为重要的数据，这时可以采用特殊字体给与一定的强调，最常用的便是DINpro。还有一点要注意，我们使用的字体一般是基于用户有什么字体，而由于win和Mac默认字体不同，所以要提前预留好字体风格类似的多种字体。并且可以设置多个字体，通过逗号隔开，如果第一个字体用户没有，那么会自动替换成下一个字体。

字号上，精简为主，可以用字重和颜色来表现层级，就不要用字号来体现。淘宝在2019年的改版中便升级了这一点。将原来的11个字体层级缩减至了7个。

行高上，我们目前采用的方案是行高是字体行高为150%字号，取4的倍数。

但是目前会遇到额外间距的问题。

前段时间谷歌发布了新的CSS更新“”leading trim，可能会是之后的行高解决方案。感兴趣的小伙伴可以点击链接了解一下（https://blog.csdn.net/weixin_39781930/article/details/111576051）

字重上，以开发的视角来看的话，包括从100-900的九个字重。一般我们只采用regular、medium、semibold三个字重。

3.1 基本介绍

3.1.1 色彩的作用

B端产品中，颜色不仅仅用来传达品牌调性，更多的是用来传达以下信息：

反馈信息 通过不同的颜色给予信息反馈，例如红色代表错误信息，绿色代表成功信息。

突出层级 通过色彩可以对内容信息进行分层级展示，提高用户读取信息的效率。

表明状态 通过颜色来区分某个事物处于何种状态。

3.1.2 组成

在真实的设计场景中，对色彩的复杂度要求是非常高的。色彩规范应该基本覆盖一套产品对用色的所有场景。

一套完整的色彩规范，包括品牌主色、语义色、中性色。

品牌主色：通常，一套产品只有一个品牌主色，是界面中出现最多的颜色，在需要用色强调而且没有其他要求时，一般都会选择主色，例如tab的选中态，图表的颜色等。

语义色：即功能色，借助人们的对色彩的心理模型，帮助人高效获得信息。例如绿色代表通行、成功，红色代表禁止、错误，橙色代表警告、

中性色：除文字外，中性色还被大量运用在分割线、边框、背景等场景中。

3.1.3 色彩系统的原则

理性的

      我们在选色时，尽可能避免个人的设计风格，减少配色的主观性，理性有逻辑地选色。

可扩展的

      使用这种选色方法可以扩展生成更多的颜色，以适应不同的变化。

和谐的

       色彩规范中的颜色互相搭配使用时，应该是和谐的。

3.2 如何制作色彩规范

在开始制作色彩规范之前，先介绍一下HCL色彩空间。

HCL (Hue-Chroma-Luminance) 与 RGB、HSB一样同属色彩空间的一种，因为最早由国际照明协会 CIE 提出，又被称作 CIELch。

目前大家常用的色彩数值可视化的色彩空间是HSB，设计师可以通过H(色相)，S（饱和度），B（明度）三个数值来量化色彩，实现理性配色。但是传统的HSB色彩空间的缺点是，明度数值是基于计算机元件而言，而非人眼。另外，计算机的明度与人眼感觉到的明度并非线性匹配，这就导致在不同颜色中，即使色相相同，我们感觉到的明度（即感官明度）也是不一致的。而HCL就避免了这个缺点，在HCL中，只要两种颜色的L相同，感官明度就是相同的，HCL可以完美的量化我们对色彩明度的感觉。但是目前主流的设计软件基本上不支持HCL色彩空间配色，因此要借助插件或者网站。这里给大家推荐Figma的一个插件：HCL color。不用figma的小伙伴可以去这个网站http://tristen.ca/hcl-picker/#/hcl/12/1.03/000000/F69877。

3.3 落地

落地分为两个方面：设计方面和开发方面。

3.3.1 设计方面

将颜色生成样式库，并规定设计同事不可以手动调色，只可以从设计规范中取色。

3.3.2 开发方面

在前期与开发同事沟通，将每个颜色定义为一个变量，在代码中不使用具体的色值，而是例如red-100的的色值，这样做的好处是，

在需要替换某个色值时，只需要在底层对变量改变即可实现全局的更改，提高了很多效率。

开发同事完全从库中取色，保证了色彩的准确性，提高了设计稿的落地率。

现实生活中的物体不可完全重叠，当光打过来时，每个物体都会产生阴影。这是我们理解物体的层叠关系的重要依据。依据现实中的这一行为，我们把阴影规范挪到屏幕世界中，使得用户更容易理解我们的系统。阴影规范提供给了我们另一个表达元素区别的维度，不同的阴影清楚地传达了不同的交互状态。某一对象在屏幕中的高度视觉表现为其阴影，阴影越大，高度越高。但是生活中真实的阴影错综复杂，我们不可能也没必要完全复刻，我们只需要能够表达出元素层级即可。与按钮相同，我们将阴影分为三个等级，分别为，S、M、L。

S：突出组件悬停效果，表示可供性。对于这个数据概览卡片来说，鼠标移入移出时阴影的显示与隐藏提供了一个交互可能性，表明它是可以点击交互的。

M：给下拉列表，气泡提示等使用的阴影。因为这些元素是与由底层元素展开而来的，但又不属于底层元素，所以将中等层级的阴影给了这些元素。

L：模态组件阴影。例如弹窗。当弹窗出现时，弹窗位于绝对的最顶层，所以阴影最大。

圆角是用一段与图形两边相切的圆弧替换原来的直角，圆角的大小用圆弧的半径R表示。在界面中运用圆角主要有以下两个好处：

亲和感。我们倾向于“避免尖锐的边缘，因为在自然界中它们可能会构成威胁”。运用圆角矩形能给我们带来亲和感，圆角越大，亲和感越高。

辨识度。相对于没有圆角，人可以更快的辨识圆角矩形。

对于组件库来说，我们可以把组件比喻为积木，而布局则是把积木搭建为各种不同成品的图纸。

6.1 盒子模型

6.1.1 设计师为什么需要了解盒子模型

在介绍布局之前，先介绍一下盒子模型。虽然盒子模型是前端开发中的一个概念，但是了解一些前端知识对我们设计的落地以及与前端的沟通上大有裨益。我们可以带着盒子模型的思维去做设计，这样开发人员拿到设计稿后，更容易了解我们的布局逻辑，降低沟通成本，提高落地率。

6.1.2 盒子模型是什么

盒子（box）模型是开发中经常用到的CSS模型，我们日常所见到的界面都是由一个一个的盒子拼接而成的。打开安卓手机的开发者选项中的显示布局边界，便可以看到手机上的各个盒子的排列；在电脑浏览器打开检查视图，也可以看到每个元素对应的盒子。我们可以理解为开发同事都是先画一个一个的盒子，然后在盒子里填充，也与我们提供的矩形切图相对应。并且盒子间存在嵌套情况，几个小盒子可以作为一个大盒子的内容。

以我们的生活来举例的话，例如我们去买月饼，大盒子里装了四个小盒子，每个小盒子里是一个月饼。

6.1.3 设计师如何利用盒子模型

了解了盒子模型后，我们在设计时，该如何利用呢？

做设计时，对任何元素都尽量用一个矩形给他封装，这样子前端在定位元素和确定间距时可完美实现设计稿的内容。

而前段时间figma更新的auto layout 功能与盒子模型基本完美对应。我们在设计时可以使用这个让开发更容易get我们的设计稿，减少沟通时间。

以标签页为例，我们设计时，不只是画个横线与文字就行了，这样开发无法理解到设计稿，后面还会继续找我们询问触控热区。

6.2 导航

导航将网站的信息架构分组归类展示给用户，方便用户到达想去的界面。

6.2.1 顶部导航

优点:

符合人眼浏览网页的视觉动线，给用户提供更沉浸式的浏览体验。

缺点:

扩展性差:由于顶部空间有限，无法承载太多的菜单项，另外由于水平菜单的特性决定了无法承载太多的层级，当扩展至三个或四个层级时，顶部导航的易用性极差。

通用性较差:同样受空间的限制，菜单项字数被严格限制。

适用产品：

整体结构无论是广度还是深度均较简单且之后不会扩展很多功能的产品。

6.2.2 侧边导航

优点:

扩展性好:侧边导航是以树形控件的方式来表示的，相对于顶部导航，无论是数量和层级，扩展性均较好。

方便寻找:由于纵向浏览无需把每个单个菜单完整浏览，相对水平菜单，定位更快。

缺点:

沉浸感低:由于用户在浏览内容的过程中，不可避免会被左侧常驻的导航栏打断视线流,阅读沉浸感较低。

适用产品：

目前结构不是非常复杂但之后会迭代增加很多功能的产品。

6.2.3 混合导航

优点:

扩展性好:由于增加了-个顶部的一级菜单，扩展性是三者中最好的。

缺点:

交互路径长:除了和侧边导航-样存在沉浸感低的问题，由于每个菜单项都需要点击顶部和侧边两次,操作效率低。

占用空间大:在B端产品中，界面空间寸土寸金，混合导航常驻的两个导航占用了较多的空间。

适用产品：

目前结构已经非常复杂的庞大产品。

6.3 栅格

6.3.1 栅格介绍

6.3.1.1 来源

栅格系统原本来源于平面设计，早在20世纪初，德国、荷兰、瑞士等国的平面设计师们发现通过维持视觉秩序,从而使版面能更加清晰有效地传递信息，二战后这种理念在瑞士得到了良好的发展。有兴趣的小伙伴可以去看下由瑞士设计师大师Josef Miller—Brockmann (约瑟夫.米勒-布罗克曼)所著的《平面设计中的网格系统》一书。

6.3.1.2 优势

高效：将布局标准化，可减少设计决策的时间，让设计师专注于内容.上的设计呈现。

响应式布局:由于web端尺寸多样，使用栅格系统可以做到自适应布局(在面对多个分辨率的系统时，无需设计多套方案，仅需设计一套来适配即可)

美观:提高内容的规律性，让设计更有秩序和节奏感，赋予界面数学逻辑美感，提高用户的阅读和浏览效率,为用户提供更好的体验。

协作:由于栅格系统的可复用性，多个设计师合作时，可以共用-套栅格系统，提升整体布局的统-性。同时也避免了设计与开发的反复确认的情况，使得部门内部与部门间沟通更顺畅。

6.3.3 组成与原理

栅格系统包括页边距，列和水槽。

页边距:指内容区与页面的边距。

列和槽:列是承载内容的容器，水槽是两个列(即内容)之间的间距。在前端视角中列宽是根据百分比而不是固定值定义的。通常说的栅格数就指的列数。水槽越宽，页面留白越多，呼吸感越强。

自适应原理:在网页应用的设计中较为常见的一种响应方式，当屏幕宽度改变时，页边距和水槽宽不变，列宽自适应。

计算公式:以24栅格(即有24列)为例，页面自适应部分总宽度: 24*列宽 +23*水槽宽+2*页边距。

6.4 间距

在设计间距系统中，我们一般会基于8点网格系统和亲密性原理规定几个典型值。例如4,8,(12,)16,24,32……。遇到间距时在这些值中选取合适的即可。另外一般我们会使得大模块的纵向间距与栅格系统中的水槽大小相同。

7.1 图标重要性

当一个界面完全由文本构成时，用户被迫阅读每个文字来找到自己想要的信息。而引入图标后，降低了用户的认知负荷，帮助用户更快导航，提高用户使用产品的效率。另外一方面、设计精致风格统一的图标提高界面的美观度的同时，也为用户带来了连贯一致的使用体验。

7.2 图标规范的内容

尺寸：由于不同形状(三角形，圆形、长方形、正方形)具有不同的视觉大小，仅仅规范图标的大小是不够的，通常我们会设计一套图标keyline，来保证不同的图标具有相同的视觉大小。

填充/描边：一般的系统功能图标采用描边。工作台的常用功能入口一般采用带背景的填充图标，原因是在空间有限的的区域，太多形状会显得杂乱，另一方面面型图标的视觉面积较大，短时间内更加容易识别。

除此之外，还包括圆角、端点、线宽、倾斜角度等其他规范。

7.3 落地

在产品中，图标通常有多种尺寸，我们一般会为每个尺寸的图标各创建一个frame来进行管理，其中，我们会把同一个图标的填充版和描边版创建为一个组件集，这样在调用时可以直接控制图标的填充和描边，在做有选中态和非选中态的组件时尤为方便。

另外，在命名上，我们会用图标的内容为它命名而非表意，例如一个灯泡的图标，我们会直接命名为灯泡而非创意。

7.4 图标库推荐

在这里给大家推荐几个我常用的图标库，在来不及画图标时，可以先用这些迅速建立起一个图标组件库。之后有时间了再慢慢更新为自己的图标。

Iconfont：国内功能很强大且图标内容很丰富的矢量图标库,提供矢量图标下载、在线存储、格式转换等功能。特点是图标非常丰富。

Remixicon：Remix Icon 是一套面向设计师和开发者的开源图标库。质量很高，风格中性大气，因此适用于很多风格的项目，分为“线性图标”和“面型图标”两种风格。相比于 Material Icons，RemixIcon 看起来风格会更统一、简约且精致硬朗一些。

IconPark：这是字节CUX设计团队出品和维护的开源图标库，如今已对外开放使用，特点是图标大小，线宽等多个属性均可设置，自由度较高。

8.1 文案是什么

文案是我们的产品与用户交流的最基础最简单的沟通工具。文案存在于产品的各个地方，例如按钮文案告诉用户按钮的作用，轻提示文案告诉用户反馈结果。对于新用户来说，文案肯定比图标易理解，另外一方面，文案更不容易产生歧义，例如一个图标可以会有多种意思，而文案相对更精确。

8.2 文案规范的重要性

伴随着B端的业务功能的快速迭代，由于设计师、产品经理的水平、文案风格、对文案的重视程度不同，导致系统内部文案积累了很多问题，最明显的问题，同一场景文案不一致，会给用户带来体验的割裂感，增加用户使用产品的认知成本。

而通过构建文案规范，可以规范文案的使用和编写，提高文案的质量，给用户带来连贯一致的使用体验。

8.3 文案撰写的原则

这里给大家介绍一些产品文案通用的一些原则，包括，准确，简洁、用户视角

8.3.1 准确原则

8.3.2 简洁原则

8.3.3 用户视角原则

8.4 落地

一般情况下，文案没有专门的人来负责，国外可能会有“UX Writer” 这样的专门职位来负责，在国内一般会交给体验设计师来负责。

文案规范的落地分为四步：

1.    遍历页面，列出所有的文案

2.    梳理相同或相似场景的文案，将文案归类整理

3.    根据实际情况制定产品文案的原则，并撰写一部分典型场景的文案。

4.    输出文档，包含文案撰写原则及典型场景的文案。

9.1 组件库是什么

组件库相当于乐高的一个个积木，通过组件的拼搭可以迅速搭建出一个页面。通常我们将组件库分为基础组件和业务组件两大类，前者是系统通用组件（图标/按钮/输入框等），后者是由业务决定的相对更复杂的组件模块。而对于B端产品和C端产品，二者的组件库又有些许差异。C端的组件库更追求极致的交互和视觉体验，因此需要考虑视觉、性能、实现、兼容性，另一方面，C端会根据活动、节日切换不同的主题，也要考虑组件视觉上的个性化扩展。对于B端而言，组件库更看重可复用性和稳定性，保证可以支持业务快速迭代。另外B端会涉及到各种各样的数据录入与展示，因此相对更高的要求是大而全，覆盖面广。

9.2 如何做组件库

9.2.1 确定组件库的内容

新产品

对于新产品来说，业务体量较小，较难抽取共性，组件也不全面，因此较好的方式是参考大厂的组件库确定要做哪些组件，它们的相对成熟，参考价值较高。

成熟产品

对于已经成熟的产品来说，我们可以直接遍历页面，穷举出所有用到的组件，除基础组件外，提炼出复用率高的业务组件进行结构化和组件制定。

9.2.2 搭建每个组件

以警告提示（Alert）为例，演示单个组件的建立方法。

   1. 定义组件

       根据业务定义警告提示的使用场景，警告提示用于重要信息的提醒，采用非浮层的方式展现在页面顶部，被动出现，且不会自动关闭。

2. 拆分组件

      这一步是将组件拆分为元件。对警告组件进行拆分后得到如下：

   3. 重组输出

       根据业务场景，我们把各个元件重组为组件，建成组件集，并定义各种组件的使用规则。

9.2.3 输出文档并替换到产品中

在组件库建立完成后，只有在日常设计中真正使用组件库，提高组件库在设计稿中的覆盖率，才能真正达到组件库的效果。这就要求我们要输出一份完整的组件库描述文档，在团队中进行推广，加强设计团队的公用意识。另外，我们还要与开发工程师配合逐步完成现有页面的组件替换。

9.2.4 定期维护组件库

组件库的内容并非一成不变，而是在不断地更新，以保证所包含的组件都是最新和有用的。与其他数据一样，组件也会有增删改。

增：当有新的组件产生时，我们需要通过判断它的拓展性和复用率，以确定是否将它入库。

删：随着产品的不断升级迭代，如果某个组件已经不用或复用率很低时，我们可以考虑是否要将它删除。

改：不可避免的，组件会随着业务而进行升级，我们可以通过数据埋点和A/B test的方式来确定某个组件是否要进行改动。

10.1 PC端设计规范

Ant Design

Ant Design是由蚂蚁集团体验技术部经过大量的项目实践与总结，逐步打磨出来的，基于「自然」、「确定性」、「意义感」、「生长性」四大设计价值观，通过模块化解决方案，降低冗余的生产成本，让设计者专注于更好的用户体验，是非常完整的一套设计规范。

Zent 

Zent是有赞 PC 端 Web UI 规范的 React 实现版本，提供了一整套基础的 UI 组件以及常用的业务组件。通过 Zent，可以快速搭建出风格统一的页面，提升开发效率。目前有 50+ 组件，这些组件都已经在有赞的各类 PC 业务中广泛使用。

Element 

Element是由饿了么公司前端团队开源一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的组件库，提供了配套设计资源。

AT-UI 

AT-UI 是一款基于 Vue 2.x 的前端 UI 组件库，主要用于快速开发 PC 网站产品，在众多的的组件库中，AT-UI 属于视觉风格比较清新的一款。

10.2  移动端设计规范

Vant

Vant 是有赞前端团队开源的移动端组件库，于 2017 年开源，已持续维护 4 年时间。Vant 对内承载了有赞所有核心业务，对外服务十多万开发者，是业界主流的移动端组件库之一。目前 Vant 官方提供了 Vue 2 版本、Vue 3 版本和微信小程序版本。

NutUI-JDL

NutUI-JDL 是一套基于京东物流视觉规范的移动端组件库，包含了36+高质量组件和详尽的文档和实例。

本次的分享到这里就结束了，希望可以对大家有帮助。由于文章字数较多，笔者几经修改，仍不免有疏漏错误之处，如发现错误，请读者于评论区或私信指出，不胜感激。

在快节奏的洪流中，保持设计的初心，做有灵魂的设计。

以上文章来源于MICU设计 ，作者JIN石为KAI

链接：https://www.zcool.com.cn/article/ZMTIxODExMg==.html

作者：混沌小肉团01
链接：https://www.jianshu.com/p/26afb8bf783c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

每天都会去 ProductHunt 看看，这是一个发掘有意思产品的国外平台。

这个平台现在已经成为了用户发现新产品、创业者们获得灵感、投资人们寻找新机会，以及创始人对自己的产品进行推广的最佳去处。

最近一段时间，ProductHunt 平台诞生了很多受欢迎的新产品，这些新产品大都有一个标签：low code。

image

低代码是通过可视化方式创建应用的一种概念，特点是代码量比传统开发少得多，甚至无代码，能显著提升开发效率。而如今，低代码不仅仅局限于软件应用的研发，只要是通过可视化的交互来帮助使用者完成一个作品都属于低代码的范畴。

如果你还不明白低代码是什么概念，可以看一下本文章提及的开源项目。这篇文章盘点了 10 款 GitHub 和码云上最受欢迎的低代码开源项目，记得收藏。

*01. *****快速搭建 H5 页面

鲁班 H5 生成器

鲁班 H5 是基于 Vue2.0 开发的快速生成页面的平台，通过简单的拖拽交互方式即可迅速的完成一个页面的制作，类似 易企秀、Maka、百度 H5 等平台。

左侧是常用的组件，右侧是组件的属性调节界面，中间区域就是编辑和预览区域。鲁班 H5 包含了丰富的组件可以选择，其中包括：

• 雷达图、折线图、柱状图、饼状图、漏斗图

• 图片、评分、表单、文字、地图、视频等

image.png

图标和地图组件

image

折线图组件

image

个人作品低代码平台

这个项目基于 Vue.js 技术栈，平台主页面分为四个部分，分别是工具栏、组件列表、画布、属性区域。将组件拖至画布区域。

用户可以将组件列表的组件拖到画布，对画布上的元素进行编辑。这仅仅是一个 Demo，其余更丰富的组件可以二次开发。

image

image

构建页面可视化编辑器

还有一个页面可视化的 Demo，基于 next.js 构建页面可视化编辑器。整个编辑器的研发逻辑为前端开发组件库，编辑器读取组件完成页面搭建，将页面数据发送至服务端保存。访问页面，从服务端拉取页面数据，前端渲染页面即可。

image

随心秀 react 版 H5 微场景编辑器

编辑器功能：拖拽、缩放、旋转、动画、撤销、重做、组合元素

组件：物料、文本、图片、QQ语言通话、背景、地图、音效、模板、视频、艺术字

image

H5-factory

H5 专题页面可视化编辑工具，拖拽编辑，灵活切换，一键生成 HTML 文件。关于这个开源项目的系统架构设计和组件拆分原则可阅读文章：

https://juejin.cn/post/6844903858401968136

image

image

H5 移动端低代码平台

vue3.x vite2.x vant element-plus H5 移动端低代码平台 lowcode 可视化拖拽 可视化编辑器 visual editor 类似易企秀的H5制作、建站工具、可视化搭建工具

image

*02. *****一个海报生成器

海报编辑器最左侧是组件列表。可以在最左侧选择组件，比如文本、二维码、图片等添加到最中间的画布区域，通过右侧的属性调节面板调节添加组件的样式。

快速：三步完成海报开发工作：启动服务 > 编辑海报 > 生成代码

简单：组件丰富、支持拖拽、复制、所见即所得、下载等功能。

动态：无需更改代码，直接在编辑器修改海报即可获得最新的海报。

image.png

上传头像

image.png

进行预览

image.png

获取代码：点击 代码，可以查看相关的接⼝调⽤代码。

image

*03. *****JEECG BOOT 低代码开发平台

JeecgBoot 是一款基于代码生成器的低代码平台！前后端分离架构 SpringBoot2.x，SpringCloud，Ant Design&Vue，Mybatis-plus，Shiro，JWT，支持微服务。强大的代码生成器让前后端代码一键生成，实现低代码开发!

Online表单开发、Online报表、报表配置能力、在线图表设计、大屏设计、移动配置能力、表单设计器、在线设计流程、流程自动化配置、插件能力（可插拔）等等！

image

[图片上传失败...(image-b7c20e-1626093914733)]

[图片上传失败...(image-64c781-1626093914733)]

*04. *****amis 低代码工具

作者认为：对于大部分常用页面，应该使用最简单的方法来实现，甚至不需要学习前端框架和工具。

amix 就是这么一款低代码工具。它通过 JSON 配置就能生成各种后台页面，极大减少开发成本，甚至可以不需要了解前端。它的独特好处是：

• 不需要懂前端也能能做出专业且复杂的后台界面，这是所有其他前端 UI 库都无法做到的；

• 不受前端技术更新的影响；

• 可以完全使用可视化页面编辑器来制作页面；

image

*05. *****Seezoon Stack

Seezoon Stack 是一款基于当前最前沿的前端和后台实现的低代码开发平台。前端技术栈基于 Vue3 + Vite + Antdv，后端技术栈基于 Spring boot。

它以快速开发为目的，在开发速度和代码结构上做出一定取舍，无论如何，你将看到非常地道的 Java 常用开发框架使用。该项目采用主流开发框架，无论打包、编译、部署都按着大公司的标准完成并不断逐步完善。

image

image

作者：小狐憨憨
链接：https://www.jianshu.com/p/1d09e0ed6fa0
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

LowCode 是高效、高性能的拖拽式低代码开发平台. 也是笔者最近一直在研究的方向, 对于可视化搭建平台的实现方案笔者之前写过很多文章, 这里带大家探索一个新方向——基于自然流布局的可视化搭建平台.

在我们之前实现的 h5-dooring 搭建平台中, 我们采用了网格布局的方式来实现拖拽生成H5页面或者Web app, 其好处就是灵活简单, 用户基本没有任何使用成本, 在前端层也能做一定的横向扩展, 但是存在几个缺陷:

• 实现嵌套组件比较复杂

• 没有层的概念

虽然通过改造可以实现层和嵌套的问题, 最近也在努力往这个方向实现(虽然和设计初衷相驳, dooring的初衷是抹去层和嵌套的概念, 让搭建扁平化和智能化, 所以没有采用自由布局的方案)

image

但是如果一定要实现嵌套和层的功能, 有没有另一种更简单的方案呢? 笔者目前想到了两种解决方案:

• 将智能布局改为自由布局, 即可以采用类似 react-resizable 的这种方案

• 基于自然流来实现, 也就是抹去定位的概念, 完全基于元素在文档的顺序, 层级和定位的选择权交给用户

因为第一种方案笔者在dooring的早期已经实现过一版, 最后弃用采用了网格布局, 所以说我们来探讨一下第二种方案的实现.

基于自然流布局实现拖拽生成页面

自然流布局的好处就是我们不用通过定位的方式来限定元素的位置等信息, 而是以html文档流的方式来布局元素, 并且用户可以灵活的设置元素的层级(layer)和偏移(transform), 接下来我们来看看简单的实现效果.

1. demo效果

image

image

由上图的demo我们可以发现组件在画布中的布局完全是默认的文档流的方式, 所以我们有更灵活的布局实现.

2. 实现思路

具体实现思路主要分以下几个部分:

• 组件区拖拽至画布

• 画布区拖拽

• 组件编辑器和更新机制

第一点和第三点我们在 H5-dooring中已经实现了, 感兴趣的可以看我之前的文章, 我们这里重点来实现画布区拖拽, 也是比较核心的环节.

2.1 H5拖放api基本介绍

拖放（Drag 和 drop）是 HTML5 标准的组成部分, 早已被大多数浏览器支持. 我们目前使用的拖放插件基本上基于 H5 拖放 API 来实现的,  其实实现第一点组件区拖拽至画布我们完全可以用原生来实现, 这里笔者简单来介绍以下.

首先我们来看看一个完整的拖放过程:

1. 首先要设置一个元素可拖放(比如<img draggable="true" />)

2. 设计拖动的时候会发生什么(需要用到ondragstart事件 和 setData(你要传递的数据))

3. 放到何处,也就是目标容器(通常在目标容器上绑定ondragover和ondrop事件)

有了以上3个步骤, 我们就能实现第一点的需求, 笔者写个简单demo来给大家参考一下:

<script type="text/javascript">
  function allowDrop(ev) {
    ev.preventDefault();
  }

  function drag(ev){
    ev.dataTransfer.setData("Text",ev.target.id);
  }

  function drop(ev){
    ev.preventDefault();
    let data=ev.dataTransfer.getData("Text");
    ev.target.appendChild(document.getElementById(data));
  }</script><div id="box" ondrop="drop(event)" ondragover="allowDrop(event)"></div><img id="drag" src="dooring.png" draggable="true" ondragstart="drag(event)" width="336" height="69" />

也就是对应的我们的组件拖放区域, 如下图所示:

image

2.2 画布区拖拽布局实现

因为之前的版本我们采用了网格布局来实现智能拖拽, 由于内部定位机制采用的是绝对定位(absolute), 所以是实现层级和固定组件比较困难, 如果组件的呈现完全脱离了定位的束缚, 我们就可以实现以上的困境了. 所以这里我们调研了一种方案——拖拽排序机制.

自然流布局的规律就是默认情况下html页面是基于dom出现的顺序来排列的, 也就是我们说的堆叠.

image

我们可以遵循这样的设计, 通过排序的方式改变组件的位置从而实现自然流布局的页面搭建.

那么我们再回到上面说的布局问题, 比如说要想实现栅格化布局, 我们只需要定义一个flex容器, 将组件拖拽到容器里就好了, 这样也就解决了嵌套的问题.  同时我们还可以设计嵌套容器的栅格数, 这样就可以实现类似如下的效果:

image

拖拽排序的库我们可以使用:

• sortable

• Vue.Draggable

• react-dnd

还有很多优秀的库, 这里就不一一举例了.

3. 如何实现层级和嵌套

其实在上面的实现思路中我们已经解决了嵌套的问题了, 即提供拖放的容器组件, 利用笔者在上文中介绍的拖放api即可实现. 对于组件层级来说, 因为我们采用的是自然流布局, 所以我们可以轻松的设置元素的定位属性, 比如我们提供一个定位的设置:

image

关于如何设计一个动态的属性编辑器, 笔者之前文章中也就详细的介绍, 大家可以参考:

• 表单编辑器实现(FormEditor)

以上就是自然流布局的基本实现方式, 后续笔者也会在github上同步我们最新的成果.

H5-Dooring编辑器wiki: https://github.com/MrXujiang/h5-Dooring/wiki

最后

觉得有用 ？喜欢就收藏，顺便点个赞吧，你的支持是我最大的鼓励！搜 “趣谈前端”，发现更多有趣的H5游戏, webpack，node，gulp，css3，javascript，nodeJS，canvas数据可视化等前端知识和实战.

作者：趣谈前端_徐小夕
链接：https://www.jianshu.com/p/7b2052d0a74d
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

导语: 低代码(lowcode)平台是近两年讨论比较火热的话题，其通过自动代码生成和可视化编程，使得使用者只需要编写少量代码，即可快速搭建各种应用，满足了很多技术和非技术人员的需求。最近作者也一直在研究低代码相关的产品设计和技术方案，持续完善可视化编辑器H5-Dooring。接下来将围绕低代码平台以及数据源设计来展开分析, 希望对大家有所帮助.

低代码平台解决的问题

低代码平台属于APaaS（应用平台即服务），其解决的是企业内部应用协调和人效成本的问题. 随着计算机技术诸如云服务等的发展, 传统软件服务已无法满足数字化浪潮的压力, 笔者对企业迫切需要解决的问题做了如下总结:

• 企业数据孤岛(应用间数据共享,互通困难)

• 企业定制化需求日益增加(不同行业赋能不同的应用场景, 千“客”千面)

• IT人才供不应求

• 沟通成本,研发成本, 研发周期吃紧

• 产品迭代和响应性迟缓

所以我们迫切需要诸如低代码/零代码这样的方案, 来解决上述问题.

当然lowcode平台很早就已经出现了, 国外的西门子(SAP), 微软, 谷歌已经有非常成熟的方案, 国内也不在少数, 但是形成跨行业通用解决方案, 还有很长的路要走(比如如何解决国内各大平台的小程序搭建化).

其基本流程如下:

image.png

数据源

上面介绍了低代码的基本概念和解决的痛点, 下面我们继续分析一下低代码的组成和数据源设计.

低代码基本包含如下部分:

• 用户端编辑器

• 管理终端

• 数据源

• 页面(应用)管理

• 模版管理

• 组件管理

• 资源库管理(图片, 字体, 自有sdk, 插件等)

• 角色管理(非必需)

如下图所示:

image.png

用户端编辑器部分主要是设计拖拽, 组件渲染相关的技术基建, 这部分笔者在这之前文章中也做过大量分享, 比如智能网格布局拖拽模式, 自然流拖拽搭建模式, 自由布局模式等. 详细可参考源码:

• H5-Dooring | 智能网格拖拽搭建平台

• H5-Stream | 自然流排序搭建平台

• V6.Dooring | 自由布局可视化搭建平台

本文的重心在数据源设计, 接下来我们开始数据源的分析.

什么是数据源呢? 笔者的理解就是 数据的来源，是提供某种所需要数据的母体。在数据源中存储了所有建立数据库连接的信息, 通过提供正确的数据源名称，我们可以找到相应的数据资产。

image.png

低代码的产物, 有纯静态的页面, 也有需要对接动态数据的动态页面, 低代码平台的数据源主要就是为动态页面(业务系统)设计的. 低代码平台使用人员可以选择或者创建数据源, 变量, 函数, 自定义事件等来供页面和组件实现数据对接和页面交互, 通过这种方式可以进一步降低数据对接复杂度并提高研发效能.

image.png

对于数据源的设计, 根据实际的业务需求, 我们可以分为静态数据源和动态数据源. 静态数据源是用户可以通过可视化的方式在低代码平台上创建的, 比如编辑数据表格等.

image.png

动态数据源是指用户可以自定义的请求第三方的数据服务, 组件消费数据源完全是动态调用的, 类似于我们传统开发时使用的ajax请求.

image.png

基于以上的概念, 我来带大家介绍一下

H5-Dooring的数据源实现.

image.png

数据源编辑界面:

image.png

首先Dooring的每个用户都有独立的数据源仓库, 可以配置不同的数据源供组件消费, 数据源会保存在对应的用户下, 用户可以让不同的页面/组件消费数据源.如下:

[数据源模式]

1. 静态数据源实现

静态数据源即用户在平台自己创建的数据源, 我们将此类数据源存放在公共状态中让组件消费, 比如redux或者vuex中, 同时对其进行数据库存储. 具体流程如下:

image.png

从代码层面, 我们只需要把从服务器获取的静态数据源, 存储到客户端全局状态中, 对于用户自己创建的数据源, 我们提供数据库的CURD操作即可.
如下图:

image.png

2. 动态数据源

动态数据源设计需要一套组件数据协定, 需要约定第三方接口遵循低代码平台数据规范来返回数据, 后者手动通过编程的模式来对应字段和组件数据的映射关系.

image.png

具体方案类似于我在可视化组件中实现的第三方数据接入的方案:

image.png

这样, 组件既可以消费静态数据, 也可以动态加载第三方数据, 进而实现了低代码动态页面的搭建.

最后

最近H5-Dooring可视化搭建平台也在持续推迭代, 数据源已基本搭建完成, 后续还会按照更智能化的方向. 一下即是最近的更新日志:

1. 优化编辑器加载性能

2. iframe容器组件添加边框等属性

3. 富文本组件添加背景色配置

4. 修复真机预览时空数据还能显示二维码bug

5. 优化页面高度适配问题, 添加高度适配器

6. 优化组件交互时空链接点击出现message bug

7. 更新dooring文档

国内lowcode平台仍然有很长的路要走, 期待大家一起努力