DPL是Design Pattern Library的简称。曾因为pattern这个词的中文翻译和Alite有过争论，尽管国内一般译作”模式“，但由于模式这个词的被滥用，我认为这个词不足以明晰的表达pattern的含义，而常常和软件工程中的设计模式产生混淆，就具体的语境而言理解为”案例“或”范式“似乎更为恰当，解释为案例还是范式则取决于DPL内pattern的深入程度，如UI-pattern做的基本上是案例收集的工作，而yahoo的DPL则以guideline为主，理解为”范式”似乎更为恰当。
Design pattern的概念也源于软件工程，在软件工程领域，design pattern被定义为面向对象编程中常见问题的通用解决方案。这种解释尽管未必完全适用web开发，但从这个定义中我们至少可以获得两个关键认识：pattern是问题的解决方案，并且解决的是常见的、会重复出现的问题。
这样理解仍然比较抽象，或许我们需要回到pattern的概念。举例而言，假设我们有一家新的公司没有制定过任何的员工制度，那么当某一天有一个员工请假的时候，老板可能不会理会，因为这是一种意外情况，因为正常情况下大家都很少缺勤，但当过了两天，过了一个星期，到后来平均每个人每个月至少请假一次的时候，那么请假就不再是一个特例而变成了一种常见问题，那么这个关于员工经常请假的现象就是一个pattern。而与此相应的，老板和财务、行政一合计，这样不行，太乱了！ok，我们制定一个考勤制度，规定好请假的流程，比如一般情况下请假要提前多久，要找谁签字批准，要如何补假或销假，这样的一套解决方案也就是我们所谓的design pattern。
在上面这个例子中我们可以得到以下几个结论：
- Pattern是基于实际问题的抽象描述或总结
- Pattern是视具体情境而变的（不同的公司有不同的制度）
- Design pattern是针对常见问题的解决方案，可以包括应用实例，但并不是必需
- Design pattern是一种通用的解决方案，并不能完全解决实际场景的应用
UED的DPL
就UED层面而言，design pattern一般包括两种类型，一是常用功能组件的可视化控制器（usercontrol），如tab解决单位空间的容积率问题、翻页控制器解决列表信 息的继续浏览问题，二是数据或信息的处理逻辑，如用积分或虚拟货币来提高用户的参与度，用注册后的任务引导来提高用户信息的完成度等等。而DPL则一般是由网站中一系列常见的、重要的问题的解决方案（包括可视化组件控制器和不可视的处理逻辑）构成的文档说明。
DPL首先是符合视觉规范和交互设计原则的，也就是说DPL首先是能保证其本身在多数情境下的合理性，其次应该是通过实际开发和设计经验所归纳整理出来的，不存在凭空制造出来的DPL，而应该是交互设计们共同认可和确定的design pattern。他是一个相对动态调整和完善，但又需要保证一定的稳定性的文档结构，能够update以保证其符合新的开发环境和用户需求，而保证一定的稳定性则是为了避免频繁变动使得其失去存在的意义。
在DPL中pattern文档最重要的部分是问题（或应用情境）和解决方案。Jared Spool曾总结DPL中应有的内容包括：
- 模式名称（Pattern Name）
- 描述（Description）
- 应用场景（Context of Use）
- 在何处使用（Where to Use it）
- 原理（How it Works）
- 规范详情（Specifications）
- 相关模式（Related Patterns）
- 其他实现模式（Competitive Approaches）
- 源代码（Source Code）
- 可用性研究结果（Usability Research）
- 讨论（Discussion）
DPL能解决什么问题？
对于团队而言，DPL最大的作用在于提高工作效率，增加一致性，而对于交互设计师个人而言最重要的则是有助于减少无用或者滥用的创新。尤其是对于大型网站而言，多样化的产品线的分工，对于相似问题的解决方案也往往差异很大，DPL的引入则在很大程度上保证了不同设计师在处理相似问题上能使用相同的解决方案，这既是一致性原则的需要，也是降低产品开发风险的有效手段。
但DPL并不是仅仅为交互设计师提供参考的作用，DPL的内容深度决定了DPL的应用层次：如果DPL中的规范详情中覆盖视觉指南和相关gallery，那么DPL同时也可作为视觉设计师的界面规范；而如果DPL中的可视化组件控制器能够提供代码解决方案，包括HTML、JS和CSS，那么前端JS框架的UI库也能够成为DPL的补充。在应用层面上其起到的作用与对交互设计师是一样的。
DPL可能带来的风险
DPL的一个最大风险是对于创新的排斥。因此DPL不能作为实际问题的解决方案，而只是常见问题的通用解决方案，这两者有什么区别？仍然举例来说，比如在我们的design pattern中我们对类窗体对话框进行了如下规范描述：
“应该为标题栏添加关闭按钮，以保证与windows视图中的对话框具有一致的使用体验”
那么在大多数情况下，我们都应该为对话框添加关闭按钮，但这并不代表着能以这种方式应用所有可能场景。Design pattern的应用不可能是不加思考的采用，仍然需要设计师根据具体的情境考虑应用的可能问题。比如在一个具体的场景中，用户在对话框中要进行需要耗时较长的任务，那么在任务进行过程中关于对话框所代表的含义就变得比较复杂，如果采用标准的规范描述，那么在这里就可能出现问题。
这就需要交互设计师考虑关闭操作的实际意义，是终止任务，还是仅仅关闭任务的进度指示，如果是终止任务，那么终止未完成的任务会否对用户的数据造成影响，如果只是关闭进度指示，那么用户如何在稍后获知任务的完成情况？
DPL的定位决定了它不可能做大而全、并且细化到具体情境和任务中的实际可能性，DPL只能是作为业务的一套可参考的解决方案集。在设计具体任务时必须考虑该问题在DPL是否已有相应的解决方案，在可选的方案中哪种更适合当前情境，在实际应用上design pattern的规范能否满足需求。
Robert.think
