2016/05/20 iUAP-Design初步规划

[GuoYongfeng]

#2016-05-20 工作日志

基于上次的梳理，大致的思路已经成型，但是就UI框架等具体的落地和一些概念的共同理解，其实这些都没有一个很好的共识。而且，上一次的梳理，更多的是我们站在技术角度的去思考，用什么样的技术元素去实现。所以，这次找到刘鸿溶同学，我们的设计师，一起交流讨论。

1. 关于iUAP Design这个概念

从最早提出，到领导和同事们之间口头的传播，甚至都没有一个明确的认知，到底iUAP Design是一整套的技术的集合，一个集大成者，还是只是一种设计语言，一个通用的设计模式，这是存在疑问的，所以我们带着疑惑去了解Material Design和Ant Design。

Material Design是谷歌推出的全新的设计语言，这种设计语言旨在为手机、平板电脑、台式机和“其他平台”提供更一致、更广泛的“外观和感觉”。过去Google的产品线，每一个都相当的独立，在产品的设计上反映得尤为明显，甚至不必看产品设计，只要看一下Google每款产品的LOGO都能发现许多不同风格的设计。这种混乱难以体现出Google的风格，如果Google的风格不是混乱和无序的话。所以谷歌的想法是让谷歌平台上的开发者掌握这个新框架，从而让所有应用就有统一的外观，就像是苹果向开发者提出的设计原则一样。

好了，到这里，我们对Design就应该有了一个清晰的认知。

再来看Ant Design，Ant Design 是一个致力于提升『用户』和『设计者』使用体验的中台设计语言。蚂蚁金服也是在内部众多产品的研发过程中面临着不同产品风格迥异的困惑。在中台产品的研发过程中，会出现不同的设计规范和实现方式，但其中往往存在很多类似的页面和组件，给设计师和工程师带来很多困扰和重复建设，大大降低了产品的研发效率。经过大量的项目实践和总结而沉淀出一个中台设计语言 Ant Design，就是为了统一中台项目的前端 UI 设计，屏蔽不必要的设计差异和实现成本，解放设计和前端的研发资源。

所以我们对iuap design的定义有两层含义：

• iuap design是由用友网络FED团队打造的前端集成解决方案，为企业应用开发而生，iuap design提供从产品界面设计到前端开发的完整开发生态，可以大大提升设计和开发的效率。
• iuap design是面向互联网企业的 UI 设计语言

2. 大局观

大家在前前后后的讨论中，都有一个基本思想，希望去降低开发成本，提升开发效率，并且建立技术生态，向公司内外推广，帮助更多的技术团队，减轻开发压力，提升产品质量，统一产品外观。

经过讨论，我们明确了这个技术生态的产品维度。假如把我们的产品开发类比为盖房子，而且要盖很多的房子，并且批量盖出的房子速度要快，质量要好，风格要统一，我们应该要怎么做。

1. 房屋设计（房间的大布局） -- 设计规范
2. 房间里需要不同的家具，完成不同的功能 -- 各种组件和插件
3. 需要装修工进行房间的装修 -- 设计师和开发者实现
4. 需要加快装修进度，保证装修质量 -- UI框架
5. 房间内茶桌是什么样的，窗帘是怎么设计的 -- 开发实例
6. 单个房间应该怎么装修，卧室要装修成什么样 -- 典型页面
7. 我们最终需要设计出一个样板房，给其他套房的装修提供一个快速的参考标准。 -- 模板库
8. 样板房有了，但是开发商要建设的一个小区，给一栋楼装修，这是基于不同的样板房集成起来的 -- 优站精选

**前四个选项：**这是我们在UI框架这个层次需要做的事情
**后四个选项：**这是我们在技术生态这个层次来做的事情

3. UI框架

我想，上面的阐述应该是我们后续开发过程中的认知基调，iUAP Design是设计语言，我将会在这个设计语言的指导下，开发实现一个我们的UI框架，这个框架的名字也取名为iUAP Design，当然，我觉得也有些不妥，应该换一个名字，比如iUAPUI，是否会更加合理一些。

在更改之前，继续使用iUAP Design作为我们UI框架的名字，同时也是设计语言。而且，后续还会有这方面的话题讨论，比如我们整个开发生态里面其他技术产品的命名，是否iUAP Design作为整套技术产品的集合，这也有待讨论。

3.1 UE规范

后续如何开发，将由我们的设计师提出完整统一的UE规范，包括交互模式、配色方案、设计原则等等。FED团队负责将这个规范进行框架的实现，这是我们基调。

3.2 全局CSS

• 初始化样式reset
  • html 标签重置
• 全局css样式base
  • 布局
  • 栅格
  • 排版：字体，粗细，类型
• layout.css
  • 不同的导航，导航算是组件还是布局？
  • 页面切割
  • 维度：有无图标，推屏，还是直出

3.3 对控件、组件、插件几个概念的理解

• 控件
  • html+css
  • 不同状态下的样式集合
• 插件
  • js+css
  • 大功能或小功能
• 组件
  • css组件
  • html+css+js 组件库

3.4 CSS基础组件和扩展组件

css组件样式

• 图标字体
  • 合并，基础库（做好），扩展库
  • 统一，提供
• 基础组件样式 默认的（横向的） 优先级 默认 u.base.css
  • navbar navbar-default navbar-inverse
  • 默认提供10个
• 对css组件样式的扩展：样式板（纵向的） u.red.css
  • 什么样的方式
  • 和主题是联动的
  • 每个组件的不同的可能方式）：多少个组件，哪些

框架提供的最终的css样式文件：u.base.css和u.xx.css（比如u.red.css、u.extend.css，这些提供出去的文件是可修改的，也可定制的，是在css层面纵向的扩展，样式板的能力就是在这个层面的）

3.5 基础js插件和扩展js插件

• 基础部分包括我们现有的
• 扩展部分可以为第三方或是业务部门高质量易用的插件

3.6 定制化能力和主题

定制化分为两个层面

1. 资源打包的定制，选择什么样的js插件和css组件进行打包

• 插件的定制。打包方式
• CSS组件级定制
• 颜色变化
• 交互模式
• 样式：形状，大小，尺寸

样式板和主题（定制）是联动的，一起的。或者说，主题其实就是样式板和插件的集合？

4. 基于UI框架的技术生态

基于第二部分大局观的讨论，技术生态的格局和阶梯工作都基本明确，在大方向上是明确的，这里一一讨论稍微细粒度的内容。

但是，我们的共识应该是：技术生态的开展，都要基于我们的UI框架，这是基础。

4.1 小维度：开发实例

开发实例是一些代码片段或是组件的集合，我们提供

4.2 中纬度：典型页面

典型页面

• 单个页面
• 布局维度
• 左树右表等

4.3 大维度：模板库

模板库：含有相关功能的一组页面或多个页面的集合，比如登录注册等合起来是登录模板

4.4 领域维度：优站精选

我们前期可以从这件事情，可以先从这几个产品方向开始：

• 电商
  • 登录注册模板
  • 商品展示模板
  • 404错误
  • 支付模板
  • 再加上设计师的参与
• sass
• 运维类

后续真正完整的优站精选的生态，需要大概能得到以下方面的实现，但还是思路：

• 可以实际看到
• 可以试一试
• 选一个主题风格
• 生成二级域名
• 可以付费或是免费直接代码下载
• 我们打造的是体验式的优站精选
• 我们提供支付渠道和方式
• 我们提供开发教程，比如生成gif动画教程也是一个很不错的方式
• 这是一个对客户的商业价值
• 我们可以让设计师和开发者都参与到这个平台上面来

5. 如何开发

这么大的规划，如果按部就班，先框架后生态的开发，后者依赖前者的方式。很显然，这样的开发模式会比较笨拙，有了依赖后，开发不能一次性见到成效，而且需要一个很长的周期才能开发我们的成果。

所以，应该从另一个维度来进行思考，从纵向的维度来思考。

1. 我们先开发核心的组件和控件
2. 有了这个以后组成一些开发实例，立马可用
3. 用部分开发实例加上主题风格，形成几个经典页面
4. 几个经典页面的集合，就是一个模板库

这样纵向的从某几个组件到模板，形成一个开发任务，每个阶段都需要有产出。

6. 推进

• 部门全体封闭开发两周，包括我们的设计师，结果导向：UI框架产出1.0版本。
• 各位手中需要支持的事情需要同步进行，比如解决BUG，但除此之后所有精力应该在1.0版本的框架上。