咨询热线:00-8813511
详细信息
当前位置: 首页 > 产品中心

产品中心

PRODUCT
详细信息
当前位置:首页 > 产品中心

一个好用的智能栅格工具是如何诞生的?
发布时间:2021-12-02 05:11:09   作者:乐鱼体育棋牌   来源:乐鱼体育平台进入
  • 产品介绍

  编辑导读:产品设计的穿透力怎么表现?穿透意味着打破界限,从表面到内核,从表象到本质。需要把一个点打穿打透,需要的不仅仅是一个乌托邦的幻象,更多需要深入到 real world 当中,感知更多的限制、连接。本文以智能栅格工具的设计开发为例,来看看怎么表达设计的穿透力。

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

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

  然后我作为工具的实现方,我准备先大致明确开发顺序。在这个窗口的实现上从易到难,应该为:静态栅格实现 ->

  栅格响应实现。

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

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

  而在居中模式下,我们只需要去调整 A、M 和 G 三个值(因为 L 变成了 0 )。所以由于公式上少了一个 L,所以我们不必要也不应该在居中模式下,让 L 这个参数出现。

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

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

  当初步完成上述的栅格显示,下一步就是要允许用户自定义栅格参数。这就立即带来了一个问题:修改栅格公式中的某个参数,其余参数应该如何相应?

  事实上,在上一部分讲到的栅格计算公式只是一个简化版本。因为我们没有展开栅格宽度的计算公式。完整的计算公式应该是这样(以左右布局为例):

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

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

  到这一步,我只是理清楚了总宽类参数响应规则,但是还没有对栅格内部的参数进行分析。接下来就需要对栅格总宽的计算公式进行下钻分析。

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

  利用 Sketch 的 JS API,我很快就实现了栅格的创建。如下左图所示,是不是看上去非常简洁?但是你有没有看出其中的问题?

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

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

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

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

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

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

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

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

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

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

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

  同时,工程化这个概念,也不应该靠大家喊出来、逼出来的。而是顺应时代的发展,自然而然的事情。TechUI 周会结束的时候,有人跟我说, 我之前觉得栅格没有什么用,但是你这个东西一出来,就立马觉得栅格好有用。 我想这就是所谓的自然发生吧。

  我们需要的真的是自由画布吗?至少从栅格这个工具来说,完全的自由反而是降低效率。如果能够给出一定的限制,反而会使得我们的设计效率提升。因为我们不必要关心三等分的组件,每一等分的具体值是多少,我们只需要关系是正确的三分了即可。所以限制不一定降低效率,有目的的限制反而能够提升效率。


上一页:光辉城市发布数字孪生系统构建平台助力智慧建筑数字孪生系统成本降低90%
下一页:RM凭借单对以太网系统引领智能建筑趋势