在互联网产品的研发过程中,页面的视觉恢复是一个非常重要的步骤,通常是一个有很多问题的环节。如果在这个链接中没有有效地发现和解决一些细节,那么在后续过程中解决这些问题的成本将呈指数级增长。
所以今天我们来梳理一下前端工程师本身和上下游角色之间容易遇到的常见问题。
设计师
设计师是接近产品体验的人,但专业从事艺术行业,设计师往往更注重视觉表现,容易犯一些美丽的错误:
1,以原生APP的体验类比H5页面设计
众所周知,原生APP体验非常流畅,界面也非常华丽,所以设计侧也试图出身APP接近体验。但现实往往很残酷,很多APP的体验换到H5.实现是可怕的,比如一个包含复杂操作的浮层,可以说是各种低端机器的漏洞。所以这里,建议设计师可以多比照其他H设计网站的性能,而不是经常比较APP的体验。
2.设计稿处于状态
是的,设计草案通常反映了所有的状态。而前端开发人员往往要考虑各种溢出状态,多个超出、折叠、开放等。这些情况大多不会反映在设计草案中,通常需要在开发过程中确认细节,这是浪费时间。
3.活字使用非系统字体
所谓活字,就是直接以文字的形式显示在页面上,而不是用图片模拟的文字。对于这部分字体,我们通常使用系统字体中的一个,不会因为几个特殊字体而加载一套中文字体文件。如果是英文字体,也可以考虑高级浏览器下的自定义字体,但也要考虑优雅降级和字体版权。所以老板问:毛和设计稿不一样吗?我们只能说没有这个字体。...这里建议,即使是设计稿,活字也要用系统字体,否则就是坑,看起来好看,实现不了。
4.版本不清楚
设计的手稿通常是一段时间的规划功能,然后与产品确认。产品通常会说,这不是第一个,那不是第一个。但当真正删除时,所有这些间距调整、颜色背景影响等,或与设计师确认。所以如果可能的话,每个需求都应该只突出变化部分,而不是一个大而完整的手稿。
5.这个应该这样切
关于这个问题,我已经无法吐槽了。这个页面真的不是切出来的。你说这么切那么切,你给我看吗?显然是滚出来的~
前端开发
前端开发,又称页面仔、切图仔,在还原设计的过程中,容易遇到更多的问题:
不考虑溢出
这里有一个基本的溢出规则,即只要是动态输出内容或用户输入,就必须考虑溢出状态的显示。文本溢出、列表溢出等。当获得设计草案并确认布局时,确认各种溢出状态。
2.不分析设计稿析设计稿
作为一个新手,在获得设计草案后,他经常想快速编写代码,因为编写代码有乐趣。众所周知,页面结构的分析与程序架构一样重要。只有通过彻底的分析,我们才能考虑到各种情况和一些需求变化。所谓磨刀不误砍柴工,必须先做结构分析。
3.不考虑增删元素的状态
稍大一点的公司往往有多个平行的需求,所以设计草案可能有先进的部分,或由于各种原因无法实现的功能。作为一名合格的前端工程师,在实现页面时,即使删除了可能的部分,也不会对页面产生很大的影响。
不考虑可维护性
为了应对需求变化,尽应需求变化的地方。例如,调整多层的宽度,增加一层icon等等。举个简单的例子,比如框架中间有一个中间按钮,很多新手直接用margin-left这样,如果调整外框的宽度,就可以定位margin-left值得调整。虽然调整宽度并不麻烦,但当开发大型复杂页面时,这些联动的小变化就足以杀死人。
5.不要仔细看设计稿
常见的错误是设计草案上有一个框架,但颜色太浅,看不见。或者设计草案没有框架,由于迭代风格,添加了深色背景,忽略了框架没有被删除。另一种情况是,设计草案上的色块覆盖了边线,但没有覆盖,导致那部分看起来凹陷。
6,看出1px没那么难
很多新人觉得对齐1px差距太难了,听起来有点挑剔。但想想看,如果你是一个设计师,努力制作一个设计草案,到处都对,你不会感到不舒服吗?事实上,只要你仔细看,再加上一些练习,几乎一眼就能看到几乎像素。真的感觉不确定,你可以截图PS放大内部,然后用参考线进行比较。
7.不考虑可扩展性
大多数时候,我检查页面恢复,只是添加更多的项目,填写更多的文本来尝试,但很多人不能通过这个水平。添加一个项目,要么在多行时没有设置下边距,要么更多的边界改变,要么在项目的结尾设置一个单独的风格。添加文本,直接出去破坏结构。
好了,吐槽这么多大家肯定够了。相信大家在工作过程中都会遇到各种细节,还有一些问题一遍又一遍的遇到,比如突然急着跑来跑去:这个页面怎么乱?~~~答:ctrl0,你放大了...So,你有什么要吐槽的吗?