新浪UED

说说builder,说说我们的团队

by 阿木杉 / 博客,网页重构 / 2009-12-16
说说builder,说说我们的团队

最近一直想着应该写些什么,有关这个职业,这个群体,我们这个团队

我的博客原文地址:http://blog.sina.com.cn/s/blog_3e37de330100fw4r.html

相信很多builder每天都在忙于切图,写代码,调试,被每天枯燥繁琐的工作压的喘不过气来,一天的工作忙完,披星戴月的走出大厦,很多人都会想:应该是这样的吗,我们还能做些什么?

这个话题很大,一时不知道该从哪说起。

————————————————————

我想大家肯定经常听到产品设计师这样的问题:“这样的效果能不能做?”举个例子,“IE6下能不能实现png的半透明效果?”单对这个问题,回答是“能”,但我们直接回答“能做,没问题”就可以了吗?

前段时间新浪博客改版时,我们也被问到这个问题,先不说当时怎么跟产品设计师沟通的,看看最后上线的效果吧,下面这张图:

说说builder,说说我们的团队

针对博文首页的模块,IE6下我们放弃了像IE7等浏览器下表现的半透明效果。

再看这张图:

说说builder,说说我们的团队

同样的产品里,导航区域就是另一种解决方案,我们没有扔掉IE6。

也就是说,我们不像以前那样,回答“没问题”全盘接受产品设计师的想法,费神费力在IE6下实现诸如半透明等那些它并不支持的效果,也不是彻底抛弃IE6用户。而是深入进去,探寻每个细节效果的价值,在不影响功能和可用性的前提下做一个取舍,这样即节省了我们的开发成本,提高了网页执行效率。还让不同的浏览器用户有细微的区别,而这个区别,又让用户有升级系统和浏览器的些许动力,还会从一定意义上推动了行业的进步。

我想这才是我们要做的事情!从我们专业的角度,给产品设计师提出切实可行的建议并付诸实施。

——————————————————————

再回头想下,几乎所有公司一成不变的开发流程,每个岗位都是像流水线工人一样按部就班的工作,最后走完整个新产品路线:

说说builder,说说我们的团队
当然,我们不可能大动干戈的改变整个流水线。而是如何在自己位置上影响到前前后后的岗位。

就像下面这个图,我们的工作的圈子在哪?只是中间一个圈,粉色圈,还是橙色圈……

说说builder,说说我们的团队

也不是说我们要去做产品设计,交互,视觉设计,程序开发,这些工作。而是我们要把自己的眼界放的更大一些,从整体的层面去考虑。

考虑的一多,我们会发现,我们接到一个需求的时候跟以前的眼界就不一样了,拿到一个产品,自然而然会去想,这个专题为什么要做,以后还有后期的需求吗,我是不是应该提前准备些什么。这是我所希望的,也是对我们团队工程师的要求。

举个例子,我们拿到微博客的一个基本设计稿

说说builder,说说我们的团队

虽然这个设计稿很规矩,但如果作为一个产品设计师角度考虑,以后肯定会有很多花哨的东西出来,很明显,有绿就有红,会换皮肤的,这样的话我们在做基础结构的时候就想到了很多,比如有花哨的背景,漂亮的发布框,甚至连主内容区域都会有半透效果。

果然,不出几天,我们看到了另外一个设计稿:

说说builder,说说我们的团队

如果开始不去举一反三,我想到这一步的时候,会崩溃,不光自己的结构要改变,甚至前前后后的设计师,工程师都会因为我们的一个“考虑不周”折腾的团团转,甚至为了时间上的考虑,会无奈放弃一些很好的想法。不过既然我们前面都考虑到了,所以这个没问题。

事情还没完,既然可以设计这么花哨的一个效果,难不成以后会考虑让用户去自定义这些细节?于是我们针对发布框,顶部导航等首屏细节作了一些透明元素的分离,提前把可能开放的自定义元素的功能都提前做一个梳理。果不其然,有天例会,得知近期要开发类似功能。老大问道:“页面这块不会有问题吧,应该有页面结构的改动带来的开发成本吧?”我们的回答呢,“当然不会,因为这块的工作我们已经做完了!”……众人惊叹不已

事情如果这么做,还会担心builder这个岗位不受重视?

——————————————————————

说到这,很多人会问我,难道你的意思就是,让builder转型做产品吗?当然不是,我怎么能忘掉我们的本质工作是技术支持,是写代码……

那我们回到代码上来,有两个问题:我们为什么写代码?第二个问题,我们写的代码给谁看?第一个问题好像废话,但必须得说

先看一个某门户网站重点频道的css截图

说说builder,说说我们的团队

针对一个文字的字体属性,在同一个css文件里面分不同的层级写了三遍,每个都差不多,但又有细微区别。为什么要写这么多代码?敲这么多字符不累么?这应该是门户网站的通病,系统庞大,工程师众多,需求变更频繁,每个工程师接手时都是一头雾水,加新东西的时候,为了保险期间,多写一句也无妨。但集中到一块就囧大了。

再看腾讯CDC“统一用户体验”的一份ppt里的截图

说说builder,说说我们的团队

这些问题我们遇到的也很多,把不同产品设计师的思想,不同工程师写的代码规整到一起,是个难题。作为builder,不可能指望从上而下的出台一个命令强行统一这些,这也不现实,可这个难题必须解决。

我们按照框架、类库的思想作了一些尝试,做了一些切实可行的规范,这些规范不是泛泛而谈的的文档,而是类似定css引入的数量,顺序这样可执行的标准,在一个产品中针对类型的不同把css分为:结构、公共、特有、皮肤等类型。在不同的产品中争取做到前三项的通用性,然后整理成直观的标准样式和代码。

这样不光能解决我们不同工程师之间代码习惯不一致的问题,还能解决不同产品的一致性,甚至在遇到不同的设计思想时,我们可以从统一的角度跟设计师沟通达成一致,设计师想要的是个分页,如果我们已经做好了分页,他们何苦再去设计一个? 这样自然而言的就统一了。我们统一的框架和类库里面还通过栅格化等理论,跟设计师达成一个共识,保证我们结构的通用性。

还有个问题,写的代码给谁看?答案肯定不是网友,他们看的是效果,不是代码,我们的代码是拿给工程师去开发的。那工程师最讨厌什么呢?当然是看的一头雾水的代码!OK,那语义化、模块化的思想自然而然就出来了。

我们在上一个版本的微博开发中,试着做了一个小系统,只提供代码片段,像这样:

说说builder,说说我们的团队

图中的{*person*}是在预览页面时系统中通过php自动调用的,相应的代码放到了另外一个模块库里,这样既方便了工程师取代码,又避免了对html结构不熟悉的工程师拆分合并代码容易产生标签不闭合bug的问题。

产品上线后呢?博客一个版本上线后,我们发现发博文编辑器的速度异常缓慢,揪其原因,发现添加表情的地方时用img配合热区实现的

说说builder,说说我们的团队

单这一个地方,就需要浪费2000多毫秒的执行时间。我们接受开发工程师建议,经过改造,把热区取消,改用css样式来控制表情位置:

说说builder,说说我们的团队

结果博文发布器的加载速度都不用进系统测试,直观的感受就上了一个台阶。

我们还可以通过各种各样的数据分析,分析出我们每次改版,重构节省的图片尺寸,链接数等具体的数据,配合整个产品的流量分析,会惊喜的发现,我们还可以为公司节省这么多真金白银!

说说builder,说说我们的团队

Builder做到这一步,不论从产品、设计、还有开发等各个层面,都应该可以得到认可,体现自己的价值了。

————————————————————

做到这些就够了吗?当然不是,我们还要在这个环境下影响更多的人,我们可以把兼容性的思想分享给更多的人,推动整个标准的统一和升级。把我们我们的框架和类库整理出来,完善文档和交流平台,分享给更多的builder。把我们多年积累的队产品设计的理解贯穿到更多具体的工作中去,节省更多产品升级时的时间和开发和运营成本……

事情繁杂,却富有意义。

文章评论

  1. 雪落 说:

    表示很淡定……

  2. choizhang 说:

    这是篇好文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

* 验证图片 刷新验证码

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>