后台系统规范设计心得（原创理论）(2)

定义维度：控件描述、控件示意及尺寸、是否用户反馈、设计理念、控件应用。

你爱，或者不爱
规范就在那里
有增无减

2. 框架规范

在第一步完成了控件基础后，第二步的问题就是如何运用该控件？让控件在场景中发挥作用，窜连出整个操作流程。这种目的之下，我们所要做的就是制定结构和规则，就如同用这些控件做成建筑物一般，这就是框架规范的作用。

在设定框架时，我们要考虑到以下几点问题：

2.1不同的流程与场景

由于业务场景不同，流程也不一样，那么如何定义页面，和页面基础内容块？

这里不妨假设流程中遇到的4种基本场景——>创建，查询，编辑，详情，回馈

这四类页面，运用的基础控件类型也不一样，通过这4类我们可以窜连基本的业务流程。

a. 创建编辑

创建和编辑都是对基础数据的输入和修改，这个界面用到最多的就是imput,表单，还有链接。从屏幕上划分为三列式。含有大量的操作验证和操作提示块。

b. 查询

查询页面主要使用的是条件输入操作和查看表单的功能，需要界面操作区和反馈区清晰明确，因此在框架上为两大区域，保证他稳定使用的习惯。另外考虑各种导出和查看的链接。

c. 弹出页面

弹出页面的大小只占整个页面大小的三分之一，这样信息流不会太大，构造结构也不复杂。

d. 信息反馈

在完成一个页面操作后及时反馈操作结果，这里的元素主要是：操作结果+语气词+建议动作。以及相关链接。所以对文字架构和展示有个限定，并配合一定的信息的icon.

2.2 操作

不同于大框架，这个弹出页面所承载的作用是保持当页信息比对下进行弹出操作，因此，操作会简单直接，操作数量保持3，到4次操作内。然后在回到主页持续操作其它。

a. 详情页面

详情页面是所有操作情况的明细。是流程的结果，所以它模块分类会比较清楚，主要是文字和数字构成，信息层次基本是2-3级。分类也控制在4-5类内，信息过多，会有收起展开的功能，来控制信息量过多对传到和寻找造成的麻烦。

b. 不同的显示器分辨率

考虑最常用的1028，和最基础的1024。把最常用的量归结为一屏幕三个控件加上判断和验证和控件组合，考虑特殊运用。场景中最可能出现的数据和控件发生结果在操作页面时，用户最关心数据，所以要考虑在界面中如何理顺他们的层次。如何对当页反馈的信息占用的位置和变化进行规范。比方说查找和携带搜索过来的数据展示，还有上传，在当页显示数据的展示分类。这些排版规则，既要考虑到信息传达的清晰，也要考虑到信息量的大小。

2.3 数字化栅格化整个体系，易于着地

栅格化体系之所以在web端这么适用，也是因为信息和版块过多时，在前端的环节易于分块进行分割，保持页面的舒畅和整齐。以5，或者10为单位，基本适用于任何的排列和切割，无论场景，控件，数据元素多么复杂，都能用一定的单位计算其尺度大小，顺利排列得下。形成一定的稳定架构。