这篇日记类的随笔来自几天前在北京公司遇到的一群人和想到的一些思路，但由于当时工作很紧，没时间记录，今日补上。

我原以为本公司没有UI部门。因为我刚到公司时接手的就是一个UI项目，而且这个项目居然是由某个部门经理发起的，平台组是完成这个项目的主要成员，所以我认为公司可能没有UI部门，或者平台组就是高管层眼中的UI部门。

直到到了北京的某一天，项目主管突然告诉我下午要见见UI部门的人，向他们演示一下我做的demo，并讲解一下我们新的UI组件的优势和特点，这时我感觉 UI部门可能是担当着类似公司“产品管理部”一样的角色，他们检查各个产品组的产品有没有UI问题，合不合规范等等。虽然此时的我有点摸不着头脑，但倘若 公司真的有一些管理分离的制度我也不觉得奇怪，毕竟是个大企业嘛。

可是直到我见到了这个传说中的UI组的全部成员时——仅三个人——我才意识到自己的想象力有多么狭隘，公司在我心目中头一次恢复了大企业的形象，自从我来 到北京以后。这个小组是由几个做网页很强的人组成的，或至少她们做网页很强，她们懂技术不多，也不需要太多，她们的责任是制作公司每个产品线的UI规范， 这种规范包括用户最终见到的字体、图片、颜色、各种部件的间距等等。遗憾的是她们刚刚成立，人数太少，缺乏强制执行力，又不太容易和技术力量衔接，所以很 多工作还不能有效开展。

这件事使我有了这样的想法，我们每个人每天都在接触UI系统，可是我们对UI的理解却大相径庭，简单列举一下，至少有下面三种。

1。产品的最终用户界面。
既通常人们所说的“软件设计”，最近有一本不错的书叫<<Bringing design to software>>，讲的就是这种意义上的UI。它包括用户的最终体验，是技术、艺术与人体工程学、用户心理学等等领域的结合。

2。支持最终用户界面显示元素的平台。
比如AWT、Swing、SWT、Windows Forms等等，规模庞大的还有HTML+Browser、Flash、Eclipse UI、GEF等等。这些都是技术上的解决方案，与实际显示效果无关。但是由于绝大多数的平台使用者都原意重用平台提供的UI组件，所以平台对组件的缺省实 现对开发者意义重大，比如用VB开发的应用程序都希望能有Windows XP的界面风格。这时就派生出了另一种技术模式——skinnable。

3。最终用户界面的显示元素的抽象标准。
往往是艺术工作者和技术工作者共同的工作，就像我前面提出的字体、图片、颜色、各种部件的间距等等，这些一般都是以规范的方式提供的，很少涉及实现方法。

这三种对UI这个缩写的解释分别意味着UI系统的需求、实现和标准。这使得我们（正在做UI系统的所有人）有必要坐下来好好考虑考虑什么是一个完整的UI系统。

做UI的泡泡