前端UI交互 - 中后台系统

前言：界面布局原则，这个属于UI专业的范畴，作为非专业人士，在此不谈专业性质的内容，只聊一下个人开发过程中遇到的、总结的一些布局情况

1 统一原则

这个原则比较大，每个系统、ui库都会要求自身统一。在此讲一下项目中最需要关注的统一地方

1.1 界面主布局的统一

目前大部分的中后台系统，是如上图布局的，头部与左侧菜单，基本上初始化之后不会有内容的变动，常规的内容操作，都是在主操作区域内
这样，就会要求Main模块内部布局的统一，padding统一、字号统一（14px）

1.2 组件库样式的重写统一

例如element ui，做的已经足够优秀，但是在使用的时候，也会发现需要补充一些样式

table组件，重写表头样式
dialog组件，重写标题header、底部操作栏footer的样式

上面两个常见的场景，直接在项目的公用样式文件（如base.scss）中写就好，做到项目内统一

2 紧凑原则

中后台系统，与toC系统的不同是，内容尽量紧凑，需要展示尽量多的内容

2.1 统一组件大小模式为small

因为需要紧凑，这样使用element ui组件的话，就不能使用普通的size模式了，我们的系统统一成了small模式，个别系统还统一成了mini大小模式

2.2 重写组件尺寸，变的更小

统一完了组件尺寸之后，发现还有一些可以压缩空间的地方，于是UI同学专门出了一个规范，我们在组件大小统一的基础上，重写了常用组件的尺寸、padding、margin，使其变得更加紧凑

重写表格尺寸，间距更小
重写form item尺寸，表单更紧凑。并重写input、select等组件尺寸
重写按钮尺寸，在统一高度的情况下，最小宽度统一

2.3 重写form表单校验的交互

使校验信息，不再单独占据一行

2.4 表格数据展示 30条

之前用户的表格数据展示，默认为20条，10条太少，30条有点多，一个界面放不开
现在在做项目的表格数据要求，统一为30条，因为前端表格尺寸进行了重写，30条也可以放的下

3 自适应原则

自适应原则并不适用于所有的场景，如下为几个经典的自适应场景

3.1 列表头部搜索表单

列表上方的搜索表单，布局使用组件库自带的栅格布局方式，具体form组件宽度可随浏览器自适应

3.2 列表宽度自适应

无需将列表的每个字段自适应宽度，而是考虑界面过宽或者过窄的情况

界面比较窄的时候，需要开启横向滚动条，而不能把列宽压缩到很小
界面很宽的时候，需要有至少一个自适应宽度的字段列，将表格宽度撑开占满，不能出现列表宽度留白的情况

3.3 图表等组件自适应

此处主要为宽度自适应，以echarts为例，在之前的版本中，图表的宽度不能依据外层元素的宽度自适应，需要手动调用一下，使组件可以自适应

4 最常用信息恒定展示原则

简单来说，就是重要的信息，做吸顶、吸底操作，保证一直其一直在界面视野之中

4.1 顶部菜单吸顶

这个目前是公认的交互方式，顶部菜单除了菜单之外，还包含了用户信息、系统退出等重要的操作内容

4.2 步骤条吸顶

常见的按步骤操作，步骤条吸顶为了使用户明确的知道自己属于哪个步骤

4.3 列表翻页信息吸底

列表翻页信息都是放在界面底部，正常如果将每页信息放置太多的话，界面会出现上下滚动条，如果不做额外处理的话，翻页信息需要滚动到界面最下面才能看的到

5 总结

实际上界面布局的原则更多更专业，此文大体描述几个重要的思想，便于后面的UI交互，有基础的理论依据