开发者社区> 问答> 正文

前端从接过设计稿以后, 怎样调整界面?

在做的应用, 交互有点多, 设计给了 PSD, 细节照做遇到挺多问题:

浏览器端的字体和 PS 文件的字体不完全一样的, 而且要考虑其他平台
字体排版, 有的地方说是统一间距来保持整齐, 前端比较控制行高
当字体大小并不一样的时候, 怎么样处理更合适?
设计图并没有前端开发给的那样详细的参数, 怎么应对?
设计图没有考虑清楚屏幕差别和屏幕尺寸, 各种数据导致的界面特例等等问题
渐变和动画等等效果, 在设计图上没有呈现
重用的 CSS 模块并不清晰, 怎样梳理?

展开
收起
a123456678 2016-03-25 16:40:05 3388 0
1 条回答
写回答
取消 提交回答
  • 这个问题只能是泛泛而谈,具体到每一项在实际中都会有更深层次的细节问题需要考究。抛开具体的案例不说,我就谈谈我自己的一些做法。不过有一个前提:对我来说,我自己既是设计师也是前端,所以我做设计的时候会刻意忘记许多平面设计的原则,或者刻意考虑很多前端实践的原则,因此我写代码和我做设计这两件事情对我个人而言其实是一体的。之所以要先讲这个原则,是因为很多人强调“精确到像素的页面实现”,但如果前端工程师自己并不做 UI 设计,想达到这一目标可以说几乎不可能,而且我个人也觉得是没有必要的——如你题目所说,有那么多的变量影响(平台/设备等差异),强求所有的 outcome 都做到“像素级精确”真的有意义吗?倒是“渐进增强”或“平稳退化”更具实践价值。
    字体问题
    让不同的平台显示自身的最佳字体这在技术上是完全可行的,具体请见拙作:Web 中文字体应用指南(请不要在意文中对微软雅黑的评价,纯属个人偏好)

    排版问题
    你的问题描述的不是很清楚,我不太明白“当字体大小不一样时”这个条件和行高之间的对应关系对你来说困惑在哪里?

    仅就行距来说,遵循一个原则就可以:行高用相对单位

    不同的区域可能会显示不同尺寸的字体,但是不要用绝对尺寸来区隔它们,而是要学会使用 rem 和 em。有了这两个单位来控制字体大小,再加上 line-height 采用相对值,那么行高将始终保持在一个统一的,协调的比例。特定的地方如果要改变行高的比例,也不一定非要使用绝对值(绝对值的问题就是不能自适应),如果你使用 Sass/Less/Stylus 这样的预处理工具,可以利用一下各种函数计算出一个相对比例。

    详细参数?
    第三个问题也比较含糊,你所说的“详细参数”,具体是指?

    如果涉及到盒模型,别忘了调整 box-sizing,也别忘了重置各种元素的初始状态(比如用 Normalize),这样可以较好的应对跨平台的尺寸定义。尽量不要在具体的样式定义里写固定值,而是预先初始化一些值作为变量,然后在具体样式中依靠相互关系来写计算值——当然,前提是你可以用预处理器/CSS3 的 calc()(尚未标准化)。关于这一点,请参考一下 Bootstrap 的做法,很典型的范例。

    另外,使用框架(如 Bootstrap)可以在尺寸和布局定义上省下很大的功夫,但是框架在很多精细自定义布局的场景下显得冗余/死板。我倒是推荐使用像 Susy 这样的工具库,相当灵活强大,生成的 CSS 也非常漂亮。

    平台差异
    这是一个大坑,设备碎片化所带来的兼容性处理问题可能永远也无法完美解决。这个话题并不适合在这里铺开来谈,那得说多少啊……我觉得还是和设计师多多沟通才是王道,不要试图用技术来解决本来可以通过沟通而解决的问题。(我在最开始所说的前提主要就是为了表明这一点——我和“自己”沟通没有障碍)

    动态效果
    动态效果即使没有在设计图上呈现,也不代表设计师没有考虑过吧?这事儿你得和设计师沟通啊,确定了有哪些动态效果之后才能考虑工程上的实现以及跨平台的兼容性处理等问题,否则的话你甭做动态效果就好了呗。

    至于确定之后如何做具体的技术实现,我建议不要重复造轮子了,现成的效果库一堆一堆的,直接拿来用吧。当动态效果遇到兼容性问题的时候还可以直接救助于作者或社区。

    CSS 复用/模块化
    这事儿不是设计师需要考虑的,这可是开发者的职责范围。如果设计师在做设计稿的时候还要想办法把样式模块化给梳理出来,那他的负担也太大了点。

    复用/模块化这件事情,如果团队里没有使用框架系统需要从头做起,那我觉得还是不要过早优化为好,有很多抉择不到一定时候是很难明朗化的,所以开发届也一再强调不要过度/过早优化。

    然而很多时候由于项目时间紧压力大,如果没有章法的干活,等到想重构想模块化的时候,就发现代码已经乱的不可收拾了。可怎么办呢?重构本来就是一种无法速成并且迅速见效的技术,高质量的重构需要整个团队的共同努力。你问怎么疏离?这问题可太大了,你叫我怎么回答呢……

    (在这里,我真的歪着脖子想了半天该怎么回答)

    这样吧,分两个情况:

    倘若整个团队只有一个人(或极个别人)来负责复用/模块化,那么这个(些)人就尽可能不要去写具体的样式了,而是把精力集中在审核其他成员提交的代码上,严格控制代码提交的规范和粒度。通过代码审核来分析和设计样式模块化的方案,然后每隔一段时间召集其他成员一起进行一次重构(重构的具体方案取决于之前代码审核的结果)。不断重复这个过程(其实就是快速迭代的思想)。
    如果整个团队都有能力在自己负责的部分做复用/模块化设计,那么在项目开始前先一起讨论一下大致的规则约束。团队可以在一些比较成熟的方案里选择一个,比如 BEM/OOCSS/ACSS/SMACSS 等等,一起学习一下,达成共识。接下来照做就是了,定期的审核与讨论还是需要的,不过就不用太过频繁了(因为大家水平都够高呗)。
    我知道在这个问题上你期望更具体的技术/技巧,但实话说这个话题实在太宽泛了些,很难找个合适的切入点。建议题主还是少一些这样泛泛的问题吧,先挑个方向走进去,碰到具体问题再拿出来大家一起研究研究,这样才比较容易出干货——比如我上面提到的那几个模块化方案,不妨先挑一个试试看再说如何?

    2019-07-17 19:14:40
    赞同 展开评论 打赏
问答分类:
问答标签:
问答地址:
相关产品:
问答排行榜
最热
最新

相关电子书

更多
Vue.js 在前端服务化上的探索与实践 立即下载
阿里文娱大前端技术实践 立即下载
前端代码是怎样智能生成的 立即下载