最近，看到了Ghost的这篇文章，颇有收获。

      在平常中，我们将PSD设计稿转为Web页面的过程称为代码实现，很多时候，我们会通俗的认为这仅仅是切图，输出的过程，但实际上，除了切图，写html外，性能的优化、结构化和语义化、搜索引擎的优化、是否能通过W3C标准验证和JS的实现等等，这些要点，都是网页重构过程中是必须考虑的地方，页面重构不仅仅等同于切图。

原文：

      做为一个专职的页面重构者，我们从事的工作简单的说就是“将设计稿转换成WEB页面”，这一过程可以很简单到直接把PSD从PS里导出成网页；也可复杂到需要考虑页面中每个标签的使用，考虑“页面性能”。以“前端工程师”为目标的同学可能会不愿承认将页面重构这块分出来，但随着工种的细分，加上页面重构本身的专业性，独立为一个职业也不是不可能，至少我现在从事的就是一个专职的职位。如果你觉得一个前端工程师必须去画设计稿，可以不理会下面的内容。

      单纯的页面重构，所涉及到的工作内容一般是“分析设计稿=>切图=>写HTML和CSS”，虽然看起来很少，但要做好这份工作，绝非所想的那么容易。原因很简单：工作内容单一，在时间和工作量上必会很苛刻，往往跟设计师的工作时间是3:1，即设计师给三天的时间，制作只给一天的时间完成；在这种工作强度下，很多人都是靠着对这份工作的喜爱在维持着，一旦工作热情消失，很容易就会变得枯燥，保持热情也成了重构工作者（也许是所有参加工作的人）应该具备的能力。

      跟“前端工程师”所要求的有所不同，“页面重构”虽然也是“前端工程师”的一个范畴，在职业化中，对专职的页面重构者，要求当然也更高。不单是做出页面，而是做出好页面。又引出另一个话题，“何为好页面？”，一般包括下面几点：

1. 结构完整，可通过标准验证
2. 标签语义化，结构合理
3. 充分考虑到页面在站点中的“作用和重要性”，并对其进行有针对性的优化

      很多同学多少都遇到过方向不明，不知道自己应该提高些什么，我们可以从“分析设计稿=>切图=>写HTML和CSS”这个工作内容，针对每一点提出一些要求，以方便我们分析自己的能力水平，为继续提高确定个方向：

一，设计稿的分析

      设计稿的分析是指对设计稿如何制作成页面的分析，即哪一块的内容可以做为公共的部分、哪一块的内容结构可以如何实现等。对设计稿的分析能力可以划分成下面的几个阶段：

1. 能分清设计稿中的公共与私有的部分
2. 在1的基础上对各部分的实现方式有一个初步的方案（包括如何切图、写结构、写样式）
3. 在1的基础上，准确的给出各部分的实现方案（包括如何切图、写结构、写样式）
4. 在3的基础上，能同时考虑方案的扩展性、复用性及页面性能（包括如何切图、写结构、写样式）
5. 在4的基础上，考虑整站的结构分布（包括文件分布、目录结构）

      上面这些都是在还没开始动手制作之前所要做的。

二，切图

      切图是指将设计稿切成便于制作成页面的图片。都有个误区，觉得切图就是把图片切出来，其实并不完全是这样，还包括把切出来的图片合并到一起，怎么切、从哪切才能将性能最大化，说“切图是一门艺术”完全不为过。切图也可以划分成几个阶段：

1. 切成所需要的图片（如何将需要的部分切出来）
2. 在1的基础上，对切出来的图片进行一些优化（包括压缩文件大小、选择图片类型）
3. 在2的基础上，规划切出来的图片（包括文件分布）
4. 在3的基础上，考虑整体的性能（包括合并图片、压缩文件大小）

HTML和CSS的编写

      HTML和CSS的编写是指将上面完成的内容，通过HTML和CSS的编写，将设计稿转换成WEB页面最重要的一块，也是我们所要重点掌握的内容，把它们放在一起，是因为它们相互的关联性太强，HTML的写法会影响到CSS的写法，它又可以划分成下面几个阶段：

1. 还原设计稿视觉效果，并通过标准验证（HTML）
2. 在1的基础上，实现多浏览器的兼容（HTML）
3. 在2的基础上，标签语义化（HTML）
4. 在3的基础上，选择较优的实现方式（包括模块化结构，方便程序脚本使用，HTML和CSS）
5. 在4的基础上，考虑到扩展性、复用性和可维护性（HTML和CSS）
6. 在5的基础上，考虑到整站的样式分布（包括如何实现分布）
7. 在6的基础上，样式写法的优化（包括技巧的应用）

      是对所遇到问题的解决能力，这一点在不同的阶段都可能会遇到，所以没有写到上面。

      如果你已经达到或超过3、4、5，恭喜你，你已经是一个职业的“页面重构工作者”了。为了我们自身的发展，关注新技术、技术创新、提高用户体验、审美观、程序脚本的实现方式等，也是十分必要的。大家一起进步吧。

原文：http://www.cssforest.org/blog/index.php?id=121

作者：Ghost

      在中小型的网站项目上，也许强调分工真得没有必要，看现在的网络科技公司，不都只配置美工和程序员。不过在大型项目上，真得不需要明确分工么？

      期待着Felix的下一篇作品，学习学习。

      JunChen在最近的一篇《为何XHTML原型会失败》中说出了一个实质问题，即在快速变化的互联网公司中，非XHTML原型只是“看上去很美”而已。

      究其原因。除了JunChen提到的“难以维护”以外，对设计和开发人员精力的消耗也是一个重要方面。

      让我们来看一个典型的流程：

1. 用户研究员进行用户研究，根据结果编写了研究报告（比如角色模型和使用场景）；
2. 交互设计师按照用户研究报告，设计了线框图；
3. 视觉设计师拿到线框图，和交互设计师讨论并沟通后，进行视觉设计并输出高保真视觉原型；
4. 前端开发工程师拿到视觉原型，在和交互设计师及视觉设计师沟通后，进行编码工作，输出HTML文件；
5. 用户研究员开始可用性测试，并将问题反馈给交互设计师；
6. 回到第一步，直至用户研究员（或其他的什么人）认为质量合格。

      这一看似合理的流水线作业存在什么问题呢？让我们来仔细分析一下：

1. 困惑的交互设计师

      用户研究是一个渐进式接近真相的过程，其结果不可能一步到位。尤其在研究初期，哪些因素会对产品设计有较大影响，哪些因素实际无足轻重，这是没有办法事先准确预估的。这就造成当交互设计师在依照研究结果设计时，发现研究结果不能给自己的设计以有力的支撑。

      比如，当两种交互方式都可以达到同样目的、而从已有的数据中又无法判断用户会喜欢哪种时，交互设计师就会犹豫不决。从资源的角度来考虑，请研究员再一次制订计划、招募用户并实施研究，是不太可能的；更不用说设计两种原型并分别测试了。因此此时交互设计师只能依据自己的经验，或者进行押宝。

      此外，交互设计师还面临一个颇为尴尬的问题：由于处于流程中的中间环节，缺少坚实的硬性产出，他很难、甚至没办法证明自己的工作价值。一方面，交互设计是一种偏“软”的技能，它目前没有、将来也很难产生一个标准化的量尺来考量其自身的质量。可用性测试可以做到部分量化，比如完成时间、出错次数等，但十几个人（一般甚至更少）的数据在统计学上是没有任何意义的。而且，有多少用户能理解那种低保真的原型呢？另一方面，就算用Axure等软件制作可操作的原型然后拿去做测试，各个业务部门会相信测试结果么？没错，你可以强硬一些，比如采取“如果业务部门不参与观察测试，就算自动放弃决策时的发言权”这样的办法，可这只能说你有工作方法，这实在无益于专业技能的提升。而且有多少设计师可以强势到让所有的业务部门闭嘴的？

      实施社会分工的目的之一，就是实施标准化的作业。而当流水线中某一环节的产出物质量，是随着其作者的经验而变化时，也就是说质量并不能定量控制时，分工的意义就不复存在，这一生产方式也就不可能按简单复制的方式扩张规模。

2. 交互、视觉和前端间的沟通成本，和可能的不愉快

      在交互设计师和视觉设计师交接工作时，沟通不可避免。视觉设计师要充分领会交互设计师的意图，这需要沟通；反过来视觉设计师给交互设计师的线框图提意见，这也需要沟通。尤其在整个部门缺乏UI规范时，沟通成本可能会高得吓人。比如交互设计师认为某处需要用3级标题（比如h3），到了视觉这里直接用了一行红字。所以常常觉得“有那时间费力沟通，还不如直接改了算了”。结果改完了交互设计师心里会想“你怎么也不和我打声招呼就改了”，不愉快就这么来了。

      到了前端开发那里，问题就更复杂了。首先，前端开发需要实现所有细节，而出于资源上的考虑，这些细节未必都会由交互和视觉设计师的产出物覆盖到（比如同一页面上仅有一处文字有微小变化，那么线框图和视觉稿要分别做两份吗？），那么前端开发就需要经常和前面两者沟通；其次，如果前端开发发觉设计稿的实现难度或成本太高，那么情况就更为棘手，最麻烦的莫过于要重新设计交互原型。

      当然，上述问题基本都能靠沟通解决，问题是，你愿意花多少时间去沟通呢？从这个角度来说，敏捷开发的沟通成本是最低的，因为沟通就是产出。而反过来上述流程的沟通成本很高，因为沟通是用来解释产出的，是产出成本之外的“额外成本”。

3. 瀑布模型与生俱来的缺陷

      上述流程是一个典型的瀑布模型，一旦在可用性测试阶段发现问题，就需要重新再走整个流程，其效率之低可想而知。此外，由于涉及到的环节和人员不少，流程走得次数越多，出问题的机会也越多。最常见的是各个环节的产出物版本控制困难，甚至根本没有版本控制，结果往往造成项目组中每个人拿到的产出物（如Demo）都不一样，这是一个非常可怕的风险，会给项目过程和质量带来非常严重的影响。

      我对这个问题采取过“文档管理＋版本控制＋减少分工”的方法，效果很好。这个后文会阐述，这里先不展开。

4. 无技术含量可言的重复劳动

      在一些页面调整不大的日常项目中，交互设计师用2小时做的原型，到了前端那里可能半个小时就把HTML搞定了，如果用CSSEdit那样的工具，实现过程甚至更快、更惬意。那么，为什么要把原本一件很小的工作硬生生地拆成两部分来做呢？

      举一个非常常见的例子：业务部门提需求说要改某某宣传文案，如果按照上述流程，交互先做线框，给到视觉确认，然后到前端修改，往最快了说也得半小时吧。而若交互设计师直接改HTML，十分钟搞定。

      有人说找到相应的模板还要时间呢，这好办，做个可搜索的模板库就好了。我们曾参考DocBlock规范做过VelocityDoc，效果很好。

5. 破坏了网页设计工作本身的美感

      网页设计是技术和艺术的结合，一个优秀的设计师不仅大量吸收传统的设计知识（如平面设计），更懂得如何利用合适的技术去带来艺术上的创新。这个过程是相辅相成的，硬性拆开只会限制设计师的创造力。

      这就好像搞油画的必须要掌握不同染料和画布的性质，搞雕塑的既要有创意又有能动手（你能想象出一个雕塑家只管创意而从不亲自去实现吗）一样，使用技术来展现艺术，借助艺术去探究可能的技术。

      据说Apple的工业设计师都要清楚地理解各种材料的特点的，如果只让他们画图，Unibody这样的杰作又如何诞生？

      说了半天问题，下篇中我们来看怎么解决。

原文：http://heartstringz.net/blog/posts/view/why-no-division-in-web-design-1

转至：心弦