为何XHTML原型会失败？
写于 2008年12月10日 22:10 评论(11)
最近 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 还是最灵活的办法，我们还是像游击队一样东奔西窜吧。
未提出什么好的解决办法，权当抛砖引玉。
J.
原文地址：http://www.junchenwu.com/2008/12/why_xhtml_fails.html
评论(11)
偶觉得framework最重要的意义不是快速，而是“标准化”——如果能在此基础上，将内容、表现及行为也标准化了呢？
不管Axure还是Visio做的高保原型都有那些个毛病，可以形象的称之为顾问专用。我个人的经验：
一旦进入xHtml原型流程，就必须以xHtml原型为中心进行调整，否则xHtml原型的优势在哪里？不能直接改测试机上的代码，不能图一时之快而种下后患，因为小问题积累多了也会产生质变，设计师首先自己就乱了。
有时为了跟进节奏，也许原型会改十遍、几十遍，都是必要的过程和积累。通过维护原型提炼产品规范，通过规范来“促进”工程师开发效率。php有相当成熟的模板技术对口设计原型，因为有高保原型做参照，工程师对模板维护的难度不是特别高。
在（互联网）产品开发中，谁脑子最清醒，以谁（与角色没关系）为中心。
研究过几天的Axure，总觉得搞出来的东西适合演示并不适合后续的开发，所以后来直接还是用HTML直接写原型。
之前听你说了一些关于你们用的那个框架，View之类的不是很明白，有时间还要仔细讨教讨教。
用Visio做过一段时间，后来因为方案跟设计上一直变着，实在受不了那种老是重复的工作！
不知道JunChen说的框架是不是zhanghua的那套？就目前的使用来看，中间层会随着prototype的修改而变化，这是比较头疼的。如果中间层只需要处理元数据的话，而prototype中的元数据和表现能很好的分离，那么这个框架的意义会更大。
@愆伏 是的，呵呵
确实，axure对于版本的迭代造成了许多重复的劳动。
生成的js与html，也烂得要死。我甚至把它看成powerpoint一样，如千鸟说的演示的工具。但也只是在初期才使用它。
期间我也用 xhtml做原型，html里的线框、背景，与CSS的定位，JS的行为。
但是发现，应对较大的版本改动，无论什么原型也好，都难以维护。
还是坚持保持记录，文档/纸质辅助吧。
我跟JunChen一样赞同并一直使用XHTML做原型。对于精通XHTML+CSS来说，这是最省时省力的方式，而且这种原型肩负两种责任，前期面向产品，后期面向开发，最后有一举两得的收获（^_^）。原型一旦成长为可发布的产品以后，它的生命就终结了，我们不会再维护它，而直接转去项目环境内维护，小修小改，直接改页面结构文件。功能大幅升级，以此为项目，继续xhtml+css造原型，依此循环。
如果遭遇复杂交互，面向产品时，辅助图形、JS和flash。面向开发时，再分解静态结构供交互调用。
Axure等，挺适合产品和需求人员，他们创造的作品被我称为“原型的原型”，当然，这种合作方式还挺有效的。
@王宏 如果原型的生命周期就是如此的话，那我也不用写那么多了..就是感觉终结了有些可惜。因为在下次做原型、改版时，确实还是有些价值的。
@JunChen，有时候我们太追求完美了，以前我也把原型都集中保护起来，可是后来发现没有时间、没有人去看，所以就不再更新增加成本。包括漂亮的需求文档，需求管理系统，知识管理系统等等，都美其名曰为以方便后来人备查，其实都是少人问津。当然，很多东西都有存在的必要，但只能适当取舍。
看了“进行 Web 界面原型设计的一种方法”，才知道junchen在说什么了。
我更习惯叫ta为模板库:)