五、后RAD时代：领域的成熟
从界面可视，到界面可描述的变化，使UI设计渐已成为一个相对独立领域。UI团队与UED团队之间并没有严格的、学术性区别，在不同的公司中它们的定义并不一样。一般而言，我们称前者为参与UI的全体，而UED则更关注于用户体验的这一部分。有些时候，我们也习惯性地称之为前端开发，或UI开发团队。
在这个领域中有一些明显的特点，例如界面开发过程中采用一种领域设计、开发语言（当然，XML力图成为“通用的描述语言”，于是便有人力主用XHTML来推翻HTML——这个世界上，有领域就有跨领域的“通用”）。我们关注一下HTML+CSS带来的描述能力，首先HTML负责了内容的布局和内容的语义（例如TABLE或IMG），相辅相成的是，CSS则带来了对“上述内容（元素）”的效果修饰。不太为人知的事实是：CSS早期其实是参考传统排版印刷规范而定义的一个子集。
所以，事实上HTML+CSS构成了视觉的“版式”与“修饰”。从这个角度上来看，它们是更接近设计领域的领域语言。而Javascript适时地出现，给HTML+CSS带来了活力，这一切更深层面地源于DHTML/DOM的出现。这从文档结构的抽象上来看，HTML可以描述为“内联+块”元素的集合，前者是块的一个特例。而块的文档结构形式只会有“并列和内嵌”两种，这就是DOM模型中的Sibling与Parent语义的由来(*注1)。所以，DOM可以用非常简单的概念来描述整个HTML。同样的，CSS天生具有“属性继承/覆盖”的特性（层叠样式表的本义），它描述的语义与UI设计中的“效果叠加”是完全对等的。因此，HTML+CSS天生地更为亲切设计人员，并带来了以“效果展现”为主体的WEB设计的繁荣。
这个领域进一步地扩大，我们看到了更多的东西，开发人员也通过DOM/DHTML走向了前端的领域。在过去的十年中，JavaScript大多数时候被作为“一门简单的语言”用在一些入门编程人员出现的地方：例如网页制作，便被人看作是设计师而非专业程序设计人员的工作。本质上说，这是“富服务器端”思想的必然产物。在这种思想下，浏览器端是不必有多少编程的——网页制作人员只需要知道一个按钮上面有一个onclick事件，并可以指向一段（甚至是由其它专业的开发人员提供的）代码即可。
然而当浏览器演变为“富客户端”时，开发人员侵占了网页制作者们的领地。因为用户不再仅仅满足于功能，而开始要求更为友好的体验。我们在前面讨论过：效果是美术设计来保证的，而体验则由前端开发来保证。所以，网页制作者大多数退到网页设计师的战线后面，另一部分则变节了，也成为了“专业程序设计人员”——感谢上帝赋予了他们既艺术又理性的头脑。
这就是这个领域的起源与结构。
同样的，B/S开始取代C/S。当浏览器成为普通用户使用计算设备（包括移动的、桌面的、嵌入的等）的首选时，它便隔离了操作系统与Web 环境下的UI。我们没有在任何地方看到一项要求说：一个Page 必须要有一个跟浏览器Toolbar 风格相同的工具条，或跟窗体风格相同的菜单。从本质上来说，是浏览器的便捷与普众，催生了B/S 结构下的应用和服务开发。而这样一来，桌面原生的客户端就不复存在了，C/S 结构的应用渐渐地开始消失，除非在客户端存在较大的运算、逻辑或对计算环境的控制。
重量级的客户端软件越来越少，因为从根底上说，人们不喜欢用复杂的软件。领域的边界，从浏览器编程界面退缩到网络界面。也就是说，浏览器端（Web 客户端、B 端）的开发人员不再要求“能够调用Win32 API”，而是要求“能够进行网络交互”。
而当这一阵线真正推进到面向socket 的二进制编程时，操作系统就被从这个体系中切割了出去。
Flash Socket 以及HTML5 中的HTML Socket 带来了这种趋势，这种趋势让微软措不及防。一方面Sliverlight 还在为Flash 仓促应战，另一方面IE+JScript 的结构尚未完成六年来最大、最根本的变革（IE8、IE9 或IE10）。然而即使如此，一个如同操作系统一般庞大的Web 领域，已然形成。在这个领域中，微软仍在第一战线，且树敌良多。
当我们把Web 看成一个像操作系统一样的产品平台时，“程序员”便成为产品生成链条中的一环，程序员文化是被重点考虑的对象，但不是全部。包括平面开发人员、设计师、架构师、部署专家、行业分析人员等在内的团队模型必然会建立。小型的XP 团队仍将存在，但这取决于应付的系统规模，以及在纵向切分上同质性的多少。
横向切分将出现在浏览器端开发的整个过程中，这不但是指整个UI，还会有UI过程中的各个细节，例如框架、数据交互、网络界面等。在这一过程中，纵向切分依然会成为补充。例如将网络界面与数据交互并成一个独立的部分，交由Flash Socket来实现，或交由独立的comet 兼容层来实现。但更确切地说，横向分层仍会带来更细分领域的繁荣，例如JSON 或其他微数据格式，以及其他基于Socket 或http/https 进行交互的二进制数据格式将成为专门的研究领域。
这其中的原因是，在B端带来的领域必然扩大到一个无法通过纵向切分来一次性交付的地步，因而必然在这一端出现更细化的横向分层。从经验来看，当一个领域足够成熟时，就意味着它可以接受横向分层了，正如现在的桌面作为一个领域，可以接受UC、UCC以及NDA(*注2)等更为细化的分层一样。
横向切分是领域合作的模式，这也导致横向切分与金字塔式的管理模型结合时，会存在多领域专家汇聚在金字塔顶端的情况。当这种情况出现时，就需要更高的决策层来应对，这也意味着决策层需要更多的经验和能力。当然，我们仍然会失败，因为即使我们把系统先纵后横地切成网状，我们仍然面临总体规模上的复杂性。同时，管理规模的扩张，也导致我们的成本增加，周期拉长。
所以如果你不是做3~5 年的规划或者常常被人垢病的“太空项目”，那么你不需要考虑一个问题的全集。你需要关注的是，在某个具体项目中，是否更合适于某些层面的横向分层，并且有意识地培养该层上的开发人员与相关角色。
我认为可以有颠覆性的思想，但从来不指望颠覆性的变革。所以能同时兼容横向分层的后RAD 时代是漫长的，不过即使是三两年，我想，在IT 业来说，也算得上是漫长的了。
- 注1：parentNode， nextSibling，previousSibling等属性
- 注2：UC：UI/Client；UCC：UI/Control/Client；NDA：Network/Data/Application
