页面构建的审图与细节

mseed

为专业的页面构建工程师，除了在专业技能上有很高的要求以外，还需要具有一定的对设计图的审稿能力。审图，并非是意味着追求跟PSD一模一样，甚至耗费大量时间截屏跟PSD去“对像素”。在我的理解中，审图是通过对UI设计稿的分析，充分理解UI设计师的意图，再结合UE的交互状态，从中做到真正的“还原设计稿”。
事例一：有取有舍，方是领悟
比如，在这样一张设计稿中

设计师的意图：
这个话题列表的行高19px，每个单条话题下面是有4px边距的。而话题标题与其自身的描述文字之间没有间距。
页面构建工程师的分析过程：
由于该模块对行高的重置，已经“约定”好了，文本规范的行高是18px。通过沟通，设计师认可将本段落的行高由19px改为18px。但这仅限于标题与描述文字之间的行距。而标题与标题之间4像素下边距，从构图上说明了单条话题之间的段落关系，不能一味的用18px行高解决。因为通过我们对设计稿的理解，设计师用这4像素，拉大了标题之间的间距，从视觉上形成了段落感。所以对于重构来讲，这4像素万万不能忽略，不然从视觉呈现的角度，设计师就不能容忍了。所以，有取有舍，方是领悟。
在这个模块的制作中，还发生了一个小插曲。如下图：

设计师的意图：
这是11号的细明体，因为是点缀，又是提示性图片，所以小于前面标题的宋体12号字。
页面构建工程师的分析过程：
起初，重构组的同学在讨论设计稿时，都提议把它们做成活文字，就是宋体12号。彩色圆角块用CSS3写，扩展性特好。因为这个模块是运营团队负责，在未来也更能够满足随时更换文字的需求。万一以后再来个“惊爆”、“头条”啥的呢？每张图都重新切、重新拼么？
但是，站在理解视觉设计的角度，这种小tag讲究的就是精致。如果做成文本文字，虽然面临将来的需求变更时，会有一定程度上的成本，但是与正文区别太小，就突出不了小tag的感觉，也显得没有那么精致了。所以在各种纠结权衡下，我最终选择把它们做成了图片。
事例二：麻烦的CSS写法能换来更好的视觉效果
再举另外一个例子，我们有这样一个模块。

设计师的意图：
头像与名称顶端对齐，微群等级图标与微群名称底部对齐。
页面构建工程师的分析过程：
因为微群等级图标的尺寸是16×16，高于文字本身的高度，为了在各浏览器下都保证这个对齐效果，我采用了这样一种思路。

按视觉稿百分百还原，做出来左图的效果，虽然css代码看起来有点儿麻烦。但是如果怎么简单怎么写，做出来的页面效果，却没有这样做的实际效果好。

事例三：页面构建细节上多处理一点点，用户体验提升一点点
还有这样一个模块：

页面构建工程师的分析过程：
通常遇到这样子的模块，我们会这么划分结构

由于用户头像只有30px正方的大小，所以算来用户名称只能显示2—3个汉字，其实很难让用户直观的区分出这个人究竟是谁。如果通过传统的思路来做，产品和设计估计都不会满意。那么，页面构建的过程中，我们就要想办法扩大用户名称的显示区域。
于是，我采用下面这个切图思路，在不改变HTML结构的情况下，只通过改变css，达到了扩大用户名称显示区域的目的。

给用户头像名称模块定宽，然后利用margin的负数值，让vs向左偏移。盖住部分头像1的区域。最终效果，可以显示4个汉字。
重构组的实习生同学，由于没有项目经验，导师讲什么就是什么，于是一听到导师说“对像素”，就真的去专注于此，万一设计稿本身有些问题，也不会判断一下，结果把自己搞的挺为难。有时候，拍屏静态页面的呈现效果与设计稿去对像素，其实没相差几个像素，但静态页面看着就不跟设计稿感觉不一样。这时候总是需要不断的修改、截屏、对像素、再修改…这样的重复劳动，在快节奏的开发中不但浪费时间，更有可能由于不得要点，在数据的装载后越发“不是那么回事儿”了。还不如静下心来，先去细细的审图，和设计师充分的沟通，有取有舍，聪明判断，然后再去做具体开发，出来的页面不需要这么焦头烂额的打补丁对像素，也许能更好得达到设计师设计的初衷呢。