[认知篇-第1期] 产品该不该了解组件库？

小小鲁班
1,569 阅读10分钟

文章将会尝试解答如下三个问题？

  • 产品该不该了解组件库？
  • 为何产品、设计师同学需要了解 前端同学 用的 组件库 ？
  • 设计师同学定义的设计规范与 组件库之间的关系？

先说答案：

  • 应该了解
  • 具体请耐心阅读下文

产品、设计师同学需要了解什么呢？

在决定做设计稿、PRD，确定具体交互规范、功能交互之前，可以找前端同学问下：

  • 选用的组件库是什么？
  • 这个组件库背后的设计团队
  • 有没有对外输出 Sketch/Sketch 文件？（据我所知，国内的 饿了么UED、蚂蚁金服UED 会产出：设计规范 + Sketch + 组件库）
  • 特别是在你们项目已经采用一些组件库或者框架的前提下，最好提前沟通。否则可能会出现：开发会抗拒你设计的新的东西
    1. 大家毕竟不想从头开始做。一个新的设计规范，很可能意味着其不成熟，可能设计规范说的很明白的，比如对表格的每一行的高度都有说明，但苦逼的是，没有人写代码去落地，导致空有理论，长时间处于空中楼阁状态
    2. 这也是开发最抵触的地方：社区没有人去落地，最终可能是开发自己去落地；但在大环境下，需求都比较着急上线，无论你采用什么设计规范，只要最终项目能够按期上线即可，所以也请设计师/产品同学多多理解开发同学吧
    3. 毕竟双方的编辑成本不同：产品同学在Axure上一个小时做的，可能开发们，要做两三天，而且还要考虑很多实际的交互问题，和后端工程师的数据交互，异常情况处理等等问题，还有就是代码的扩展性等等问题 😂

了解组件库的好处

从上面的文章可以看出来：组件库是对UI、交互设计，甚至相似业务逻辑，在遵循了统一的规范的基础上，做的封装

  1. 提高审美
  2. (协作)有助于了解前端工程师们日常工作，提高沟通效率
  3. (通用)避免天马行空，了解通用交互的设计（能风靡+被众多公司采用，也是有原因的）
  4. (通用)扩展组件的使用边界，在不同的业务场景使用，可以有效扩展组件能力边界 + 考验其设计是否通用
  5. (统一)UI、交互保持统一，可以有效降低业务对系统的学习成本，辅助其快速上手
  6. (借力)通用性业务场景，可以复用社区已有组件生态，亦可借鉴他人优秀的思路 + 交互设计。

不了解的不了解的小弊端：

  • 都2020年了，大家也了解下，当代 UI 设计风格吧，PRD 偶尔还会出现类似如下风格的UI组件

共建组件库的收益

技术层

  • 减少 B 端业务重复代码、重复轮子
  • 减少组内信息不畅，促进沟通、交流
  • 积累通用组件开发经验，探索最佳实践，打造更精致的交互+业务组件
  • 形成技术+文档沉淀

业务层

  • 包容差异，统一交互，探索共性
  • 统一常见业务场景的 PC 端交互，降低业务同学学习成本，快速上手

团队层面

  • 前后端、测试、产品、设计共建
  • 提高沟通效率，减少信息不对等
  • 请各位同学多多安利：“看看你们的组件库里面有没有这个组件？前端业务组件库能支持吗？”
  • 我们的很多业务组件，都是测试同学在测试阶段，使用的时候，提了很多非常棒的建议，比如：多选互斥组件等

前置知识：

  • 组件：前端同学说的组件，一般对应 设计师同学说的 Sketch 组件，产品同学说的 Axure 元件，测试同学说的 控件。
  • 下文所说的组件、控件、元件：

    • 指具备可交互能力的基本单位，页面由基本组件组合而成（即：基础组件 -> 复杂组件 -> 模块 -> 页面），参考：原子设计

    • 比如：按钮、表格、下拉菜单、分页组件、日期选择器等

    • 对工程师、设计师来说，做小东西是划算的，这样比较灵活 + 复用性比较强，能够应对更多的场景

    • 说白了：这样能够提高工作效率，方便扩展，也能够满足绝大部分需求

  • 组件库：组件的集合

  • 前端同学开发语言通常为：JavaScript + CSS + HTML

  • 其中：

    1. JavaScript

    负责交互、业务逻辑，相应用户的操作（比如点击列表中某一项的删除操作 -> 页面多了一个确认删除弹框 -> 向服务端发送删除请求 -> 删除成功 -> 刷新列表数据）

    1. CSS

    负责样式、动效果，用来负责装饰页面是否美观（弹窗大小、UI样式）

    1. HTML

    用来负责页面整体结构（比如 导航菜单是放在左侧还是顶部、上下布局 or 左右布局）

  • 类比人体的话

    1. JavaScript -> 机理功能：根据大脑的指令，做出相应的行为 + 反馈
    2. CSS -> 皮肤
    3. HTML-> 骨架

我们先来个通俗的理解

看看上面三者在日常工作的应用

  1. 前端同学的日常工作：对接业务需求、写业务代码、对接后端同学、测试、上线。日复一日，有点类似种地的感觉(码农 哈哈哈哈哈，你为什笑的这么开心😓)

  2. 种地需要工具对吧，比如锄头、铁锹、拖拉机等等。很少看到有人拿着生铁疙瘩(JavaScript)去种地，原因很简单：效率太低。即使给这个铁疙瘩包了很漂亮的锡纸（CSS），效率还是很低。

  3. 人群中有一些聪明绝顶的家伙（😂），想了些办法，把这些生铁疙瘩（JavaScript），进行了炼化，把他们做成了 熟铁（Vue、React 等开发框架）

  4. 于是又有人用这些熟铁，做成了各种零部件、大小型农具（组件）

    1. 车灯（按钮）
    2. 座椅（表格）
    3. 发动机（轮播图）
    4. 轮子（日期选择器）
    5. 锄头
    6. 铁锹

  5. 把这些零件拼接在一起，就成了拖拉机、汽车、收割机 ，极大提高了生产效率。这里的拖拉机、汽车，其实可以映射到大家的日常工作中使用的组件、元件等：

    1. 设计师同学，在 sketch、figma 中用各种组件，做的 CRM 管理后台、广告投放后台、营销后台、运满满App 的设计稿
    2. 产品同学，在 Axure 中使用 元件库的元件做的 CRM 管理后台、广告投放后台、营销后台、运满满App等对应的原型图
    3. 前端同学，在 前端工程项目中，使用

    注意上述提到的 组件、元件，其实对应的是一个可组合、复用的基本单位（原子设计），对应不同岗位同学来说，虽然使用的场景对应的软件不同（Axure、Sketch、Chrome），但在 UI、交互上应该是一致的

前端组件库的演进过程

  • 以Twitter两位大佬开发Bootstrap(号称是世界上最流行的前端框架)举例。

  • 在开发需求的过程中，这两位大佬发现Twitter页面上很多地方有样式 + 交互/功能 相似的组件

  • 举几个组件类似的栗子🌰

    1. 样式 类似的控件

      • 按钮（编辑按钮、删除按钮、文字按钮）
      • 卡片
      • 导航条等等，这些都是相对偏静态的

    2. 交互 类似的控件

      • 弹窗（modal）
      • 表格
      • 下拉菜单
      • 轮播图

  • 以上这些组件，在长期的项目演进迭代过程中，Twitter的两位同学发现，这些东东都可以进行抽象、规范、统一，整到一个地方

  • 于是他们把不同平台、需求中的弹框、表格、下拉菜单、轮播图的样式和交互进行尽量统一，经过迭代和演进。有一天，有一个叫Bootstrap(号称是世界上最流行的前端组件库) 的东东问世了

不过 BootStrap 是用 jQuery开发的，有点跟不上时代的节奏了，但是其思路、交互、文档都非常值得学习 + 借鉴

常见的设计规范/组件库

设计规范

Boostrap 其实本身是一个包含了设计规范的组件库，下面列举的是常见的设计复返

  1. material design
  2. bootstrap
  3. element
  4. ant design
  5. sales force

更多设计规范，请参见awesome-design-systems

聊聊设计规范 和 组件库 之间的关系

  1. 前端说的组件库

    是指在各大Design System的指导下，借助前端框架进行开发落地的产物（在马克思主义的引导下，进行社会主义建设）

    • Design System === 前端UI 的设计规范（上文介绍的）
    • 前端框架，现在多数指的是 Vue、React、Angular 这三个主流开发框架了

  2. 组件库以及开发者生态

    • 比如国内使用 Vue、React 的公司、开发者比较多，也就代表着其对应的开发者众多，众人拾柴火焰高
    • 也就是说，基于《这些开发语言 + 某个设计规范》的组件库会更完善，有了bug，fix 的效率也更高

日常工作

在使用Sketch(设计师)、Axure(产品)，开发业务需求 Coding(前端)的时候，你的同事可能会问你:

“Hi，你的按钮、下拉菜单做的不错，我遇到类似的业务/交互场景了，能分享给我吗？”

于是你就把它存成一个组件分享给你的同事了，后来，你同事有点不想整了，直接和你说：

“你还能把按钮、轮播图、表格、下拉菜单、日期选择器、导航条 都分享给我啊？”

你和他说

“阿西吧，奶茶拿来！”

“上面提到的组件/元件/控件，其实都是非常基础、通用、不带业务场景的组件/元件/控件”

有一天，他和你说，你能帮我做(写)一个CRM 员工选择的组件/控件吗？

“可以的，可以针对 CRM 的业务场景，基于已有的基础下拉菜单 做一个符合 CRM 场景的员工搜索组件”

从上面的对话中，我们很容易发现，有同学在做基础组件（和具体业务无关，可跨业务场景复用）的开发，有一部分同学在基于基础组件做特定业务场景的开发

开发基础组件其实比开发业务组件更需要人员、精力、时间的投入，原因如下：

  • 考虑跨业务场景使用，需要设计的通用性、兼容性
  • 面向使用者较多，需要提供简洁、易上手的文档，以及文档的持久更新维护
  • 考虑组件的长久可维护性
  • Bug Fix 之后的多场景回归测试
  • 等等 说这么多，就是为了强调基础的重要性！越基础越重要

完结撒花 🎉🎉🎉🎉🎉

avatar
文章
阅读
粉丝