2023年一个好用的智能栅格工具是如何诞生的

一个好用的智能栅格工具是如何诞生的？今日想和大家共享一下智能栅格工具的整个设计开发的过程，并从中感受到设计的「穿透力」。

什么是穿透力？穿透意味着打破界限，从表面到内核，从表象到本质。需要把一个点打穿打透，需要的不仅仅是一个乌托邦的幻象，更多需要深化到realworld当中，感知更多的限制、连接。

一、初版方案与实现思路

经过初步争论后的第一版设计基本可以作为demo开发，但是存在一个不明确的地方就是居中按钮。

这个方案的设计完全借鉴了Sketch的布局界面，但是sketch的这个居中按钮其实挺令人匪夷所思的，往往不知如何使用。

经过一番争论后，我们全都认为这个按钮应当放在栅格总宽边上，表示需要对栅格进行调整。同时为了便于预览，最好给栅格预览区加上相应的宽度值，大致如下：

以上是我们作为设计师的视角，经过两轮争论，得出来的设计结果。到这一步，我们都可以认为这个版本算是一个合格的栅格工具。

然后我作为工具的实现方，我预备先大致明确开发挨次。在这个窗口的实现上从易到难，应当为：静态栅格实现-栅格响应实现。

所以我打算开发挨次是这样：

静态栅格预览渲染-栅格参数面板-栅格动态响应-生成栅格。

二、静态栅格：栅格生成公式解析

绘制静态栅格包含两部分工作，第一部分是左右布局的栅格，其次部分是居中布局的栅格。

我的思路是先确定一下左右布局和居中布局的计算公式，然后在实现的时候就可以有清楚的实现手段了。

在纸上一通演算，我突然发觉左右布局和居中布局的计算公式其实是不一样的：

左右布局：画板宽度A=左侧偏移宽度L+两侧间距M2+栅格总宽G居中布局：画板宽度A=两侧间距M2+栅格总宽G

乍一看好像两者没什么区分呀？不就是左侧偏移距离L在居中布局的时候变为0了吗？为啥不统一成一个呢？

从公式里去看，背后的缘由是这样：

针对左右布局的栅格，我们需要去调整A、L、M、G四个值，然后调整一个转变其他值；

而在居中模式下，我们只需要去调整A、M和G三个值（由于L变成了0）。所以由于公式上少了一个L，所以我们不必要也不应当在居中模式下，让L这个参数消失。

或许从程序员视角来说，统一成一个更加便于开发。但是从设计师的角度来看，这其实对设计的带来了新的启示：

我们不应当用一个居中按钮去实现栅格居中的效果，而应当采纳不同的模式区分不同的布局类型。

所以在实现这个参数面板的时候，我们选择了使用选择器的方式呈现不同的布局模式，同时在居中布局下去掉了【侧边栏宽】这个参数。

到这个时候，我们再去对比Sketch的栅格布局面板，已经能够感知到明显不同了。而这一步，只是由于深化了一下布局栅格的计算规章带来的。

这是第一层，设计穿透了栅格布局计算公式。

三、智能栅格：动态响应规章设计

当时步完成上述的栅格显示，下一步就是要允许用户自定义栅格参数。这就马上带来了一个问题：修改栅格公式中的某个参数，其余参数应当如何相应？

事实上，在上一部分讲到的栅格计算公式只是一个简化版本。由于我们没有绽开栅格宽度的计算公式。完整的计算公式应当是这样（以左右布局为例）：

画板宽度A=左侧偏移宽度L+两侧间距M2+栅格列数L栅格宽度W+（栅格列数L1）*栅格槽宽T

假如照着这个公式去思索，我想是个人头都要大了，一个参数变化，需要考虑其他5个参数的相应。其实我在第一步分析公式的时候，就是这么列的，结果就是很难往下推动开发，公式太过简单，不知道如何算。

所以我又回过头来思索了下栅格修改的场景，发觉修改画板、偏移宽度等总宽值时，用户对栅格内部的状态不会太关注。所以针对总宽的参数，我们就应当使用这样两个公式：

左右布局：画板宽度A=左侧偏移宽度L+两侧间距M2+栅格总宽G居中布局：画板宽度A=两侧间距M2+栅格总宽G

再结合栅格修改时设计师的设计意图推断，我从中总结了7条规章：

在左右边距模式下：

修改画板宽度A时，往往盼望栅格总宽G变化，即A⬆️~G⬆️；修改左侧偏移宽度L时,往往盼望栅格总宽G变化，即L⬆️~G⬇️；.(更多的就不列了)到这一步，我只是理清晰了总宽类参数响应规章，但是还没有对栅格内部的参数进行分析。接下来就需要对栅格总宽的计算公式进行下钻分析。

栅格总宽G=栅格列数L栅格宽度W+（栅格列数L1）栅格槽宽T

根据同样的思路，我得出了4条规章：

修改栅格总宽G时，往往盼望栅格宽度W变化，即G⬆️~W⬆️；修改栅格列数L时，往往盼望栅格宽度W变化，即L⬆️~W⬇️；修改栅格槽宽T时，往往盼望栅格宽度W变化，即T⬆️~W⬇️；设计师几乎不会去主动修改栅格宽度；当总结完以上11条规章时，在设计端上我有两个新的认知：

修改布局和修改栅格应当分两个部分分别呈现；不必给出修改栅格宽度W的配置项。所以在设计端最终的配置参数呈现如下（基本验证了其次版设计方案的正确性）

而将上述这11条规章结合起来，并通过代码实现后，栅格就具有了智能动态响应的效果。由于这11条规章直接来源于设计师的认知阅历，可以基本保证用户的使用体验如丝般顺滑，仿佛背后不存在设计一样。

这是其次层，设计穿透了栅格变更的响应规章。

一个小插曲：在最初的时候（大约是Microwave0.3.1），我走进了一个误区，在栅格总宽变化时，让栅格宽度和栅格槽宽等比缩放。结果带来的问题就是：每次修改完栅格总宽后，都需要人为手动地重新修改一遍栅格槽宽。由于我对响应规章推断出错，导致使用体验存在不必要的冗余操作，这就是一个规章考虑不周的典型反例。

四、栅格生成：简洁与易用的妥协与平衡

利用Sketch的JSAPI，我很快就实现了栅格的创建。如下左图所示，是不是看上去特别简洁？但是你有没有看出其中的问题？

问题就是：这些智能栅格其实是由一堆图层组成的。而在Sketch中，大家也知道，一旦成组之后，这些栅格图层就失去了特别重要的力量：吸附。一旦没了吸附，这个栅格工具就失去了大部分的意义。假如需要吸附，那么必需将这个组打散，这就会导致画板中平白无故会多出20+的栅格图层。

这个时候，你觉得应当怎么做？是为了简洁，忍痛割掉栅格吸附的力量？还是为了吸附的力量牺牲图层上的简洁？

综合考量，我给原来很简洁的面板多加了一个【吸附模式】切换器，打开这个模式后，不会对栅格图层进行编组，从而保持原有的吸附力量。通过这样曲折的方式了解决Sketch的这个问题。（这里又要骂一句辣鸡的Sketch了）

这是第三层，设计穿透了Sketch的力量，绕过了已有的限制。

PS：在后来的迭代过程中，我发觉了更上游的解决方案，所以后来又把这个模式取消了。

五、智能适配：栅格基础力量的升华

其实在完成上述那些功能之后，我自己感觉这个栅格工具已经接近“击穿”的状态，好像没有更多更大快的地方可以优化了。但是，我仍旧感觉到这个智能栅格工具并没有那么“智能”，仿佛围绕了这个“智能”做了许多许多的工作，但是就是还有一层纸挡在那边，没有捅破。

于是我与几位同学进行沟通，其中一位同学的一句话间把这层纸捅破了：“要是这个栅格能够帮我自动去匹配上栅格就好了。”我突然想到前端工程中很重要的一个力量是lint，即校验与自动修复代码中的空格、标点等错误。

瞬间我的心中豁然开朗。栅格是什么？是布局的规范，同样应当也是校验与修复工具。一个合格的栅格工具，除了前面基础的栅格生成、修改、校验（相当于Sketch的吸附），也应当供应自动修复的力量。于是我连夜把这个功能实现了出来。

这个力量的实现并不简单，甚至特别简洁（用了不到30分钟），但是对于整个栅格工具却是升华般的存在。

这是最终一层，设计穿透了平台的力量枷锁，带来了工具质的飞跃。

在小组周会上演示这个功能时，大家都不约而同地鼓起掌来，足以证明这个力量有多被认可。

六、一点总结和感想

1.设计的穿透力

越接近底层，需要把握和了解的东西也越多，但另一方面，也带来了足够大的优化空间。如何全面分析和全部相关的限制条件，在这些限制条件下找出设计上的最优解法，我认为这就是设计的穿透力。

2.工具与思维限制

工具不会限制人们的思索，但会潜移默化的影响人们思索的模式。——前电脑时代的建筑图纸是什么样的？是怎么画成的？

曾经在知乎看到过上面这一句话，现在再复盘这个工具的设计开发过程中，我对这句话又有了更深化的体会。

由于Sketch只有吸附功能，所以在设计和开发的时候，我就完全被Sketch已有的力量牵着鼻子走，为了「吸附」功能，绕弯路实现了吸附模式，而没有去往上一层去思索出「适配」的力量。

事实上，在前端工程中，早已有ESLint、Prettier等自动约束和修正的工具。但是在设计侧好像一切都在刀耕火种时代，工具链的贫瘠导致无法孕育出工程化的思想。

这种时候，打破思想限制的最有效的方式，就是多获得不同领域的信息输入。很有可能当前领域的问题，在其他领域已经有成熟的解决方案了。所以我也愈发感觉到沟通的必要性。

3.设计工程化

所谓设计工程化需要的是类似前端工程中一样的lint工具，能够对大到颜色、字体、字号，小到图层命名进行相应的约束与自动修复。

同时，工程化这个概念，也不应当靠大家喊出来、逼出来的。而是顺应时代的进展，自然而然的事情。TechUI周会结束的时候，有人