最近 UCD 翻译小组有一篇文章是：XHTML原型开发－用代码说话。千鸟也一直宣传着蓝图、文档、原型的方法论。

从 03 年开始，我就直接使用 (X)HTML 去做原型，从一个人，到数个人协同工作，都是直接用 (X)HTML 实现。在经历 N 个大大小小的产品/项目后，在06年11月，我写了一篇关于用 XHTML 做原型的文章：进行 Web 界面原型设计的一种方法。单从这个方法本身上看，是很实际、实用的。起码我已经在数个项目（从零开始的项目）中体会到了好处。

这个方法最大的好处是，可以模拟整个产品并且可以立即投入开发、降低沟通成本，成本高么？一点也不，因为前端工作时间是必然要花的。有很多人用 Axure，我讨厌这个工具的原因是，它无端的在草图到原型中间增加了一道工序（如果一开始是 sketch 到 mockup，那么就变成了 sketch 到 prototype 到 mockup，这里就把 prototype 和 mockup 都当成是原型吧）。Axure 虽然能制作带交互的原型，但破烂的 HTML 和 JS，对于要求高敏捷度的 Web 项目来说，重复劳动。Web开发的需求变动是非常快的，很容易出现在制作 mockup 的过程中，发生变动，此时还有精力去修改 prototype 么？一切只是看上去很美！

这个方法最大的缺点是：难以维护。一个产品已经升级到 2.0 版本，可原型还是 1.0（我现在还放着用这个方法在两年前做的Blog后台管理，和去年做的UCD大社区前台原型，可对应产品已经不知道升级到什么版本了）。为什么从 1.0 到 2.0 之间不去维护原型呢？大部分人不是不愿意去维护，而是维护的成本太高，而且重复劳动。就像上面说的 prototype 和 mockup，当需要调节一些 CSS、JS，和小范围的 HTML 时，更多的时候是直接修改已经上线的产品，或者为开发人员提供一个个零散的 HTML 文件（别笑，别告诉我你没做过）。当实际发布的版本，比当初的原型版本要新的时候，就不会有人记得要去升级原型了。要 100% 避免是不可能的，我尝试用制度去控制，无功而返，成本太高了。使用好的 (X)HTML 框架 + JS 框架，能从一定程度上解决上面提到的问题。但仍然是不彻底的。

这里必须提到开发中的模板渲染问题。因为从原型到程序使用的模板，HTML必然会分崩离析，项目中的很多代码，已经不是原型中的代码了（CSS 不是同一个文件，JS 不是同一个文件，在很多项目、框架中如此）。我曾经跟一工程师说，我想要的框架是原型和代码是在一起的，原型就是模板，模板就是原型，可以不依赖于程序而直接预览，改版升级的时候可以直接使用。这样就可以解决原型维护问题，解决后期改善过程中一个个零散的 HTML 文件、让人难以接受的在模板中加代码注释。

后来那位工程师自行开发了一个框架（PHP），基本实现了原型和代码在一起。通过中间脚本去生成模板（或称为视图，View）。我相信在实际运用过程中，已经发挥了很大的作用，现在 UCD大社区的后台管理就是用的此框架。但是这样的框架写中间脚本的成本很高，而且中间脚本最好是在原型之前或者随原型同步进行，另外对付 Blog、简单的CMS之类可以说得心应手，但对于复杂的系统、SNS 等就有些显得力不从心了，权限控制、强交互、繁杂的呈现细节，成本急剧增长。

从事 Web Design 这么长以来，仍然没有很完美的协作方法，最主要的问题还是在原型开发和维护上。在救世主没有出现之前，使用 (X)HTML 还是最灵活的办法，我们还是像游击队一样东奔西窜吧。

未提出什么好的解决办法，权当抛砖引玉。

打印  |  相关话题：原型(Prototype)   |  类别：设计思想  |  源地址