求是设计会

以下内容来自沈浩翔，由沈浩翔撰写完成，沈浩翔校对。并同步发布于沈浩翔个人博客。

版权声明：文章版权归原作者和求是设计会共同拥有，转载时请以超链接形式标明文章原始出处和作者信息。

开始之前

内容级别：高级

本文主要内容：本文是这次旅途的最后一站。这一篇我们将把思绪收回到控件上来，探讨下Lookless Control在项目开发上的意义，在用户体验上的意义。以及展望一下未来的控件趋势。

本文适用对象：交互设计师、产品设计师、前端开发工程师、架构师、产品经理。

预备知识：

• 必要知识：了解MVC，有与架构师合作经验。了解面向对象编程的思想，听说过面向服务的架构。独立做过探索性项目。
• 提升知识：重构过现有控件更佳，了解某些控件架构更佳，完成过控件级别的通用设计或做过GUI程序员更佳，做过研究性课题的Demo更佳。

关于更多知识：短短一篇文章，肯定无法将我想分享的所有内容传达出来，仅是抛砖引玉。

• 如果对文中提到的很多概念有很多疑问，欢迎大家留言，或Email：qiushid@gmail.com，我们会尽力给出让人满意的答复。
• 如果对本文中提到的很多内容，还不能理解，请积极查阅文末给出的参考资料，或自己主动学习，一定会给你带来巨大的帮助。

内容目录

• 引子-文西，我是阿漆
• Radio Button、List Box & Combo Box（Drop Down）
• 看我72变的进度条
• Lookless Control的意义
• 结语：模式之外
• 参考资料

引子-文西，我是阿漆

听说很多公司的朋友都在看我这个系列的文章，我很受鼓励，希望能和大家一起继续进步吧。这个系列中，我好几篇都提到文章也适用于产品经理。个中原因，以后如果有时间，我会再写一个设计师向产品经理转型的系列文章（有机会的话，也会笼统解析一下The Sixth Sense的实现方式和发展方向）。现在就赶快进入最后一站吧。

此系列的前三篇中，第一篇，强调了布局，主要是将思考限制在现在有限的二维屏幕空间下，讲的实际上是现有情况下，控件创新所受的限制。第二篇提到了控件的抽象类，那些抽象类实质上就是控件的本质，讲的实际上是受现在限制的情况下，一种最大程度上通用灵活的控件分类模型。而第三篇提到的是重新建模思考，是借鉴了现有通用设计中灵活而经得住考验的一些方法，对现有控件分类的进一步改良，并尝试思考，在非限制性情况下，未来控件设计的可能性。而本篇则将从近未来的设计趋势说开去，进一步去尝试思考未来非限制情况下，设计的可能性。

最初学设计的时候，可能大家都会听老师扯淡：“什么是椅子？”然后大家七嘴八舌一阵之后，老师会说：“其实我们可以放开思维，不一定要有四个脚，不一定要有靠背，不一定要有ooxx，椅子是支撑我们坐姿的一种工具。”然后在扯淡一些，然后布置个作业，屁股一拍，就等着下节课来收割我们的作业了。

说的再直白些，有人问你菜单是什么，你怎么回答？是该回答，那一条或者一块导航的区域吗？是该回答传统的菜单那样的，或者带有工具条还带有下拉层级的？或者说是像Office2007的Ribbon那样的？这些是菜单的本质吗？

如果有人问你，什么是单选框，你怎么回答？是反复和对方确认，问对方要的是Radio Button还是List Box嘛？

我觉得，如果在单纯的项目为导向的情况下，以上回答都是无可厚非的。但如果是以研究为导向的项目的话，这样的回答就显得过于呆板了。这种出于熟练工作经验的回答，往往就简单的将自己限制死了，在这样的情况下，你非说用户体验上能得到改良是可能的，但出现创新是不太现实的。菜单是对产品中各个层面的入口的显示表达。单选框是一组多选一的列表。这是它们的本质。它们的外形可以完全从它们的本质上剥离出来，这就是Lookless Control的真正含义。

而国内用户体验行业的大致进展，还处于改良阶段。没有一些系统学习的积累和跨专业知识的融合，这个行业是进入不了创新层面的。所以中国的互联网模式是C2C（Copy to China）模式。你说真的要创新出新的通用性的控件，重新定义一些模式，定义一些概念，在国内现阶段的状况下是痴人说梦。所以我们也不必互相较真谁比谁更创新一些。也就50步和100步之间的互相歧视而已，反而弄得设计这个行业也染满文人相轻之风气。

当你在做一个项目时，你能轻巧的像阿漆从他的手提箱里提出一个大哥大说：“这表面上是一个大哥大，实际上是一个吹风机。”那时，你的设计水平才真和这个大环境拉开差距。然后你拿着这个大哥大，给自己吹吹头发，说：“作为一个设计人员，想法非常重要。”这样才会真有些说服力。我特别喜欢星爷作品中，这些充满智慧的解构。

Radio Button、List Box & Combo Box（Drop Down）

我们先回到一个大家都很爱争论的问题上来。在做某个产品的设计的时候，到底选用Radio Button还是List Box，或者说是Combo Box？其实当我在项目中遇到这种争论时，我喜欢保持沉默。当我做产品经理的时候，我必将这个问题归于优先级非常低的层面，因为他们都可以用于多选一的。如果项目中的架构设计的好的话，先开始用任一设计都没有问题。因为后面遇到特殊需求，可以很容易的更改数据绑定，替换成另一种控件。

其实正是从这个角度，当初很多人会质疑一个问题，交互设计是不是一个夕阳职业？

因为说到底，这三个控件究竟该如何选择，很简单。当选项数量少并空间充裕的时候，可以用Radio Button。当空间不充裕时，选用Combo Box，因为压缩了空间，所以Combo Box多了一次点击。当空间充足，而可能还需要对比，或者可能要融入多选的情况下的话，可以选择List Box。假设当程序员在开发时，也能如此快速准确的做出临阵决定，并且符合用户体验原则，那么交互设计师的存在意义在哪里呢？（你要说分析需求什么的，以后谈产品经理的时候，再谈其中所暗藏的问题。）

有个有趣的故事，Dr WPF的博客上看到的。他说当初微软在设计WPF自带控件的时候，还设计了Radio Button Panel，然后每个选项是一个Radio Button。后来其中有个员工就提出来了，这个Radio Button Panel和List Box一样啊，只不过每个List Box Item的表现形式是一个Radio Button罢了。后来Radio Button Panel这个控件就被从WPF体系里移除了。

之前和在英国的上司提这件事的时候。他还是提出了一个观点，就是这种做法让这个控件标签，不语义化了。写着是一个List Box，却展示的是一个Radio Button的列表。这的确是一个问题，毕竟List Box不是一个抽象的形式，已经代表了一种具体的表现样式了。对此，微软会在未来重新加回一个Radio Button Panel的控件，还是会把抽象扩展的权限放的更宽，我们不得而知。我从分离彻底性和灵活性考虑，后者更有可能。（至于语义化的问题，这里就不拓展开去了，又是一个大话题。）

看我72变的进度条

一说起进度条，我们马上可以想到的是TMD又中病毒了，重装电脑的过程中，我们默默面对的悲剧~哈哈哈哈哈。

不扯皮了，不过进度条真的是一个很有趣的控件。Charles Petzold基于ProgressBar，单纯靠重定义外观，设计了温度计、码表、slider、弹簧等各种东西。按星爷的话就是，我表面上是一个码表，其实我是一个进度条~

关于进度条，让我印象最深刻的，应该就是多媒体播放器的进度条和Chrome的下载进度条了。

多媒体播放器的进度条很有意思，有多种状态，缓冲的时候做伪装进度条，给人回馈，暗示等待。缓冲完毕后，则转换成一个显示真实播放进度的真实进度条；同时很多播放器的进度条在此时还集合了Slide的功能。而就这样一个作用丰富的进度条，仅仅占用了界面上那么小的一段空间。甚至在播放的时候，还和整个控制面板会一同隐藏，实在是用户体验设计上的一个经典。

Google Chrome下载进度条

第二篇最后留了个课后题，关于分析Chrome的下载进度条的，索性就在这里分析掉好了。

首先，那整个控件是一个复杂的Split Button，左右两个部分是两个控件。右边的下拉箭头是一个dropdown，dropdown中的Item是一系列按钮控件。左侧按钮有几组状态，第一组是下载状态：下载完毕，下载中，下载暂停，不同状态下，触发事件不同；第二组是下载源文件大小判断，无法判断下载文件的总大小时，进度条成伪装进度条状态，不断循环，可以判断时，则变成真实进度条。左侧按钮分为四个部分，文件名称、文件图标、文件下载进度文字说明、进度条。为了节约空间，进度条外观又完全的进行重构，包括设计样式，和设计运行动画。

Google的很多控件都有这样独具匠心的设计，足见其架构团队的力量。比如以前懒人有禅提过的Google Wave的滚动条，比如我很久以前提过的Google Reader的无尽滚动条。

当然这说起来也就上面这么几行话，但是因为是非现有模板的控件，所以程序员和设计师之间需要做很充分的沟通和协同工作，彼此保持信任。然后程序员要非常熟悉控件的构造原理，特别是滚动条，还涉及到复杂的布局和定位问题，还涉及到性能优化的问题。一个公司的产品，非常能体现架构团队的能力和产品架构的问题。也很体现一个公司跨团队合作的能力。以前听说过阿里某个UED中所写的启发式搜索框下拉框这些的，无法实现，最后这些设计被咔掉。其实这也很好理解，启发式控件想到是很容易的，但要做到，必须要能很好很优雅的处理数据的结构，不论是依赖人工也好，或者说依赖优秀的协同过滤引擎也好。如果前期这方面没有优化好，后期要么花大资源去改造完善（而且也要有有这样能力的人去完成这个工作），否则这样的设计就会被PM因为资源不足，优先级偏低被咔掉。好的想法，离好的产品还很远很远，需求与实现的转化，路也很长很长。

WPF中把进度条这些没有归入到内容控件中去，所以在第二篇的列表中没有详细的归纳进去。有时希望将一些文字内容和进度条绑定起来，那就通过内容控件和进度条控件，再构造出新控件来。或者也可以分开，仅仅通过控制器，通过触发器同步两者的状态。下面是我通过WPF做的一个demo（用Blend或VS可以打开）。略微复杂，构造了新控件ProgressIndicator，设计了ProgressIndicator的多重状态，设计了不同状态的动画；通过ListBox构造了RadioButtonPanel，将RadioButtonPanel的内容、表现、结构分离了。然后再将RadioButton的选择和ProgressIndicator的状态切换绑定在一起。（尝试了一下Chrome的圆形进度条，需要更多技巧，暂时时间有限，搁置了。）

狂摸我下载源文件。用Blend或VS打开。

Lookless Control的意义

虽然这一切的想法很好，但也隐藏了很多暗礁。再好的兵器，也需要良好的武艺去驾驭。

对项目开发的意义

Lookless Control让团队成员的分工更独立了。低保真模型或线框图完成后，开发可以直接进入页面结构处理阶段。开发只要根据PD(Product Design Document）所述，选择对应的控件，就可以大致打理好页面结构。然后就可以进行背后的功能性的开发和绑定。同时，视觉设计师，可以根据对不同控件的样式设计来完善控件的外观和布局特性。如果视觉设计师仅能完成平面效果图的话，那最多再配一些前端开发将视觉设计转化成前端代码（html+css或flex或XAML或其他）。

项目的不同模块解耦的更彻底，方便分阶段部署项目实施。比如可以先快速分离好层次，前期用最快速的方式构建能用的系统。然后将系统用起来，获得认可，争取资源。当资源到位时，再分部分对产品进行重构升级。

比如我以一个yahoo的photo管理器为例。

如上先画好大致的wireframe。

然后以各种控件名为单位，写出页面结构（其中UI:splitbutton是自定义控件，需要开发人员自己构造）。

视觉设计师同时完善视觉效果。

然后前端开发就把各个控件的样式完成。

对项目管理者来说，这似乎井井有条，项目也更利于管理了。但实际上不是的，这些流程和方法类似一种制度上的保障，配合上一个还可以的团队，只能保障完成60-70分的产品。项目管理的方法和技术对成熟规范的项目有极大的助力。但一旦要在产品中加入创新的方式和方法，要对知识工作者组成的带有创新性的项目进行管理，短板效应就会暴露无遗。一个团队中缺乏掌控全局的人，个人分工更彻底后，每个人的短板都会更明显。而分工越多，不同类型工作间的灰色地带就越多，这会放大沟通成本和边际效应。再算上沟通损失，以及项目组的人员流动，项目中暗礁很多。

这是我讲座中的概念图，大部分的应用开发就在这个圆环的层次。再外围就是我所介绍的控件开发和创新的层次（等我整理完毕，我会放出完整的presentation文件下载）。

平时我们大部分的项目的工作，就是出mockup，然后去实现，很多深层次的体验问题都没有去触及。

另外，其实有一个有趣的现象。因为可以分阶段来部署项目，所以越是项目导向的项目，越不容易出现创新，项目中所用的控件和交互特别容易平庸化，平庸的叠加，就是整个产品的平庸。反而是独立开发将分离的工作自己独立完成，更容易产生创新。

对控件设计的意义

Lookless Control带来了更多的创新。比如时下流行的Light Box或Slide Picture，Endless ScrollBar，Tree Grid，都蕴含着这种理念。当我们想要开发一个应用的时候，要完成一个相同的功能需求，我们可以提供更多的用户体验可能性，而不用触碰系统内部结构。比如MSRA的高霖的个站，就用drag&drop完成了一切功能，包括导航、链接、多选一。这是一个Lookless Control尝试不同体验的绝佳案例。

但越大的灵活性，往往带来越多的滥用。语义化的一个很重要的意义是增强信息回溯能力，增强信息的结构性。但过多的灵活性很容易将其破坏。比如说用ProgressBar的重构来代替Slide；比如说将Grid与其Command Bar直接结合，比如说创建过多的新的独立控件。项目中可能会控件泛滥。

另外是体验的破坏。因为可以做更多的扩展，加入了更多的有趣的交互方式。但一个控件的设计是需要一种平衡的，每种交互方式，要有合理的视觉隐喻或其他隐喻，降低其认知门槛。2000年初flash泛滥，以及后来的Ajax的一些泛滥，都有这个问题。我以前写过，交互有两个方向，一个是方便，一个是体验。在需要追求方便的常用应用中，加入过多的交互，交互就是有害的。（Cooper将应用分为独占、临时等几个状态，就是因为不同情境下，交互设计的目标是不同的。）而且，过度设计还很有可能降低性能，性能直接影响人机交互的反应时间，一旦机器的反应时间超出我们心理预期的反应时间，对用户体验的破坏就是最大的。

一个体验式家具购物网站。

一个非常经典的体验式购物车，摸图进入网站。

对未来的兼容

我认为这是它最大的意义。Lookless Control还承担着对未来自然用户界面（NUI, Natural User Interface）的一种期待，

马云曾豪言想做百年企业。但即便是常青树IBM也不过近百年，计算机行业也不过近70年。只有良好的架构设计，才能适应和兼容未来。

Lookless Control是对架构的一次革新，它让信息的存储管理与信息的表达分离开来。我一直都认为包括鼠标、键盘、触摸屏这些的，都是过渡时期的交互产品。

未来的交互必然是针对三维空间的VR技术。现在就逐渐将视觉和交互层面的内容从信息的存储管理中剥离开来是非常有意义的。未来就只需要对表现层和交互层分别进行替换就可以了。

所有部分都可替换。

我在上一篇就提到，要为未来做设计。Lookless Control中所体现的思想，很符合这个理念。

结语：模式之外

这系列文章中，我介绍了一些模式，比如特别介绍了MVC这种模式，介绍了各种分离和映射。最后还特别讲到了Lookless Control这种近未来会非常主流的控件设计模式。

但世上没有完美的东西。现有的很多设计模式都是经过了时间的考验，留下来的经典。但经典也会随着时间的流逝而被遗忘。对任何模式也要抱着抱残守缺的态度。僵化的模式和僵化的语言一样，会落寞下去。语言的绵延不在于标准化和固化，而在于不断重复后产生的新的变化。优秀的语言和模式，会成为高素质人才有用的工具，但不会成为全部。如果不理解这些模式背后蕴藏的思想，那未来很有可能反而被这些模式桎梏。如果认为创新就是打破规律，那么首先也应该明确哪些才是规律。

不断地重复一些事情，可能会孕育出新的技能和方法。这一如人类社会的进化。人类不会无端的就产生新的发明，只是在重复劳动中，我们才能明白一些规律。我们拷问一些规律的行为背后的本质，我们试图思考这个本质是否可以寻求其他方式去表达。

实际上，整个系列中所有的概念和方法，你现在不一定有机会运用在你的项目中，可能你的项目也无法提供你一些机会去了解和理解。但是无论你是跨过了这个层面，直接去做需求分析师也好，产品经理也好，还是你仍然在做一些重复而委屈的反复的工作也好，仔细去理解这个系列，一定能给你带来帮助。有一天，当你有机会加入一个伟大的团队，你的才华就会复活。

参考资料

• Lookless Control：http://drwpf.com/blog/2009/05/12/itemscontrol-l-is-for-lookless/ By Dr.WPF
• Natural User Interface：http://drwpf.com/blog/2009/08/05/itemscontrol-n-is-for-natural-user-interface/ By Dr.WPF
• 使用模板自定义 WPF 控件: http://msdn.microsoft.com/zh-cn/magazine/cc163497.aspx By Charles Petzold

• ：http://book.douban.com/subject/2020442/ By Alan·Cooper

• 增强现实（AR，Augmented Reality）: http://baike.baidu.com/view/104668.html By 百度百科
• The Sixth Sense: http://www.pranavmistry.com/projects/sixthsense/ By MIT Media Lab