深入控件创新[3] – 探究控件设计思想

沈浩翔
沈浩翔(翔仔)
08届浙大工业设计毕业生
08年毕业至今,工作于道富信息科技(浙江)有限公司,信息架构工程师。本系列源于2010年7月1日在公司做的内部讲座,于7月3日重新整理。

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

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

开始之前

内容级别:高级

本文主要内容:本文是这次旅途的第三站。从上一篇延伸开来,介绍一些思想的发源,从架构的角度来谈设计思想,发散到控件设计之外的故事,在第四站,我们再把思绪收回到控件上来。

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

预备知识

  • 必要知识:了解信息架构(熟悉更好),喜欢归纳、分类和思考。了解MVC,有与架构师合作经验。了解面向对象编程的思想,听说过面向服务的架构。
  • 提升知识:听说过关系型数据库更佳,听说过ORM更佳,接触过UML更佳,了解mashup更佳,做过研究性课题的Demo更佳。

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

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

内容目录

  • 引子-克服我们的心理障碍
  • MVC的前世今生
  • 如何设计建模
  • 结语:你心中的未来是什么样子的?
  • 参考资料

引子-克服我们的心理障碍

我们都说设计师是一个创造未来,改变人们生活方式的职业。我们是要给未来做设计吗?如果这是我们对自己设计生涯的期许,那么我们就该学习任何有助于创造未来的东西。

刚去世的上海大学校长钱伟长先生常以他自己举例:“我36岁学力学,44岁学俄语,58岁学电池知识。不要以为年纪大了就不能学东西,我学计算机是在64岁以后,我现在也搞计算机了,当然不像年轻人那么好,不过也吓不倒我。真理只有一条,国家需要你干,你就学。”

钱伟长

我想套用他的那句话:真理只有一条,想要设计未来,未来需要你做到的,你就学

我想再套用我非常欣赏的上交建筑系的刘老师(城市笔记人)的一句话:要克服设计的美学化,克服设计师身体与建筑(软件、网上应用)之间和使用者之间的隔离,设计师最好向工匠和使用者延伸一步。向工匠延伸则了解构造之理,向使用者延伸则深入业务需求。国内的探讨主要热衷于向业务需求的延伸,我这儿就剑走偏锋的探讨一些向构造之理延伸的知识。

每个人都对自己的未来有所期许,也有所暗示,而有时这样的暗示又恰恰就阻止了我们。对技术的害怕似乎是很多设计师挥之不去的心理障碍。我听过太多技术束缚思想论,最后还是小马过河自己淌了过去。理性和感性的边界根本不是那样的,最后他们都融汇在一起。

在这个教育体制不完善,专业设置不合理,完全没有课程教育体系的国家里,所谓的专业,才是我们最大的束缚。忘记你的专业背景,一切都变得更轻松。唯一阻碍我们进步的,可能只是我们的知识结构。我也会试着介绍一个对我们未来成长更有助益的知识结构。

风光的大师们不会讲解基础层面的事情,总是在谈概念,谈想法,谈创意,谈哲学。对于他们那个档次的人而言,这些可能都太简单了,可是绝大部分人一辈子都没有学会这些非常简单的事情。所以我就从这些简单的讲起,愿有灵性的读者中,未来能出现中国自己的设计大师。

本篇就着力于这些一直在设计未来的思想的传承发展,基于我个人的知识结构,将这些专业间的灰色地带明晰起来。越是高级的东西,就越是基础,本篇定义内容级别为高级,但理解起来一定比前两篇更容易,几乎不需要出现任何与代码相关的字眼。不但适用于控件设计,更适用于其他设计。

MVC的前世今生

MVC的概念

MVC就是Model-View-Control的简写,是一种复合设计模式。简单而不精确的解释就是,Model用于结构化数据,View用于表现界面,Control作为控制机,在交互或事件触发下,在Model和View间进行数据交换。

MVC

设计模式有很多,我特别在这里提MVC是因为它与时下流行的AJAX联系非常紧密,而且在微软WPF的控件设计思路中,运用了一种叫MVVM(Model-View-ViewModel)的模式,本质上就是一种轻量级的MVC模式。在未来相当长的一段时间内,这种模式都会是控件设计的主流。

MVC的历史

我在上一篇的文末参考资料中给出了一篇1996年的专栏文章:《Working with objects in the user interfaces》。

这篇文章介绍了MVC产生的历史,和当时的设计思考。

20世纪70年代施乐公司的帕洛阿尔托研究中心(Xerox PARC)的Smalltalk团队,想到对象可以变得可视化的在屏幕上显示,用户可以直观的操作。代替命令行界面的第一代GUI就是在那样的环境下诞生的。同时,那个时候研究人员就已经开始关注对象,面向对象编程的思想就是在那个环境诞生的。

Smalltalk

有了第一代GUI,我们所知道的最早的控件也就诞生了。(这些故事都可以在第一篇中介绍的《Designing Interactions》中看到)

但当时的可视化信息都是被绑定在对象上的,比如一个按钮就是一个对象,一组按钮就是一组对象,那就需要一组可视化信息。在80年代到90年代中旬,这种情况都没改变。那是彻底的服务器端控件的时代。

客户端-服务端技术在1996年已经非常流行了,当时将界面放在客户端(瘦客户端),将业务和应用逻辑放在服务器端。后来又衍生成四层架构过。再后来又简化为两层。(后话,现在流行的AJAX,有三层架构,客户端端显示View层,Control在客户端控制web服务器和客户端之间的信息交换,Model存在web服务器,而再之后,还有一层数据库服务器。Web服务器与数据库服务器之间还需要进行一次ORM,这里就不扯了)

这里我们还是来介绍一下前无古人的第一代GUI设计的思想和原则吧:

原则 用户需求 实现方式
系统要直观 希望系统能将信息按照用户所想的显示出来(用户心智模型在系统的信息模型上正确的显示出来) 对系统进行建模,建设出符合用户认知的对象模型(合理稳定的系统架构)
系统要易用 希望界面上的信息和操作的控件都是用户正好需要的(将表现和操作从用户和择优选出,裁剪出来) 在用户在界面上可以看到和操作对象(优秀的交互设计和对数据进行可视化)
系统要分布式架构(即系统要设计的有弹性) 可以向个人的工作环境中不断的添加新的任务,基于新的目的做扩展(将面向任务的信息工具整合进个人的工作环境,所有业务逻辑,信息处理由系统服务器处理完成) 建设完善的对象操作模式(将不同类型的对象分类进行管理;基于合理的对象模型,给对象添加方法、接口、实现类)

文中括号里的内容是原文的直译,我将这些带有些技术术语的话翻译的更白话一些就是括号外的话。

够不够简单?越是天才的想法越是简单,简单就是简化简化再简化!这些原则放在现在任何一个应用中都是无比的犀利和精准。不过多说就是废话。

按上文表格中所示,我觉得太多设计师把设计就定义在易用层面了。其中直观层面的设计基本是由真正的信息架构师和系统架构师完成的。弹性部分的设计,大部分还是由系统架构师完成的。说的伤自尊一些的话就是,仅定义在易用层面的设计还是浮于表面的,把这部分的作用吹得天花乱坠没意思,自欺欺人!

有的朋友在做产品经理,无法将需求翻译成一个完整的设计计划那算不得真正合格的产品经理。需求只是葡萄,把葡萄酿成酒才是用户体验的关键。(我比较无法理解没有架构意识的设计师如何转行称作产品经理。这个可以参看我以前翻译的Alan Cooper的《质量革命》,我就不拓展开去了,以后有机会再写设计师转型向产品经理所要具备的方方面面。)

观察需求

第一代GUI最大的意义,就是让一切变得直观了。为何思考到要直观?这里除了过人的观察力,依旧还是要依靠前人的知识。主要依赖的还是心理学和社会学的知识。

比如《Mind Matter》里提到的一个简单的现象:我们电脑死机时,我们就会拍桌子或者拍电脑,觉得这样就会让电脑更快恢复过来,回应我们的操作。这是一个现象,但背后隐藏的是我们的心智模型,我们从何处产生了这种认知?将现象和心智模型关联起来,找出激发需求的深层次原因!

这个现象同时表明,电脑的信息展示模型,仍旧没有对应到我们的心智模型。所以后来电脑还在处理内容的时候都会有或真或假的进度提示,如鼠标变为沙漏,比如进度条。

每个设计必有一个可以言明的原因,而不只是设计师的感觉。

建模!建模!建模!!!

建立系统模型的过程。又称模型化。建模是研究系统的重要手段和前提。凡是用模型描述系统的因果关系或相互关系的过程都属于建模。所建模型只是实际系统原型的简化,因此既不可能也没必要把实际系统的所有细节都列举出来。实际建模时,必须在模型的简化与分析结果的准确性之间作出适当的折中,这是建模遵循的一条原则。

将业务提取出来,将通用的部分提取出来,进行简化(也就是抽象),这就建模。

第一代GUI是严重基于对象的技术。那时人们建立的模型可以称为类模型,类模型关注与独立的对象。而在建立MVC模型的时候,人们更关注与对象之间的相互作用,我们可以将其看做是一种角色模型。

基于这种角色模型认知的稳定性和通用性,人们把人机交互分为了四部分角色,用户作为人机交互中人这个对象的一个角色,主要负责表现用户的心智模型(作为系统设计者要关注用户这个角色的地方);Model作为人际交互中机这个对象的一个角色,主要处理数据内部不可见的各种机制和复杂关系;View作为机这个对象的一个角色,主要负责表达系统信息展示出来的样子;而人们把人机交互过程中人和机都要做的一些事,统一到Controller这个角色中去。

这就是MVC这个模型的建模思想。但我们也可以清楚的看到,心智模型这种概括是非常笼统的,可以更多的细化和完善,提高系统的丰富性、弹性和稳定性,这可能是未来的一个重点,也是设计师们普遍关心的。同时我们也可以看到单纯的将鼠标、键盘、电脑屏幕这些作为Controller的媒介,也显得单薄和死板,这也必然是未来突破的一个方向。甚至Model和View也可能在未来完全超出我们的想象。我认为,从建模思想着手,我们的确是完全有机会去设计未来的。

(本朝为何毫无创新能力?因为本朝根本没有基于完整建模的新产品出现。我朝只有把外国的东西C2C,然后进行修改和裁剪,或者说本土化。这的确是优化用户体验,但是也局限了我朝产品的突破性。从设计模式设计思想到各类协议,全部都是国外的,特别是老美的。我朝科研工作人员,只喜欢拿来,进行我朝特色的修正,出本土协议,所以才会有TD啊,龙芯啊,GFW啊,血狮啊这类东西。取财自于民,废材至全民。不光是这些成型的协议和产品,更可怕的是对知识体系的裁剪和破坏。

再看很多国内的书,还将这种断章取义的行为,称之为不对称创新。这种创新是对这个国家的智力和未来的破坏性开采。虽然是离钱最近的模式,但也是离未来最远的模式。机巧智术,知之为高,知之而不用者尤高。这种行为,带来的是对知识传承的破坏,也是对信仰的破灭。愿我们的知识工作者,在有一天,能尽一些保护知识的责任。)

如何设计建模

为何要学习设计建模

我只是觉得我大学里做设计都很累,还都觉得在瞎折腾。每年做十到三十个项目,瞎忙。毕业以来,我在公司只做了一个跨度三年的项目,和一个自己控制的项目。课余也基本不触碰项目,所有外快项目全部推掉,连个站也懒得建。这些时间大部分都用于阅读,和实践阅读所学。

我知道很多设计师都有水来土掩兵来将挡的霸气,习惯靠经验,见招拆招。我觉得这在设计初期培养设计感觉是很好的方式。但这终究不是长久之计,难道大家就不怕被世界瞬息万变的需求折磨死么?难道说设计师就是为了疲于应付那些需求而存在的?

给大家看张图:

pace layer

最上层就是艺术和时尚,接下去就是商业。这两层的变化节奏是很快的,只追着这两层设计,那就像一直被绑住萝卜悬在眼前的骡子,不停的在推磨,却永远离那萝卜一步之遥。追逐者是无法完成超越的,永远都无法为未来做设计。我朝和西方极乐世界在科技文明上、创新能力上的差距,就是一堆追逐者和一组创造者之间的差距。这根本就不是用年份所能衡量的差距。家庭条件允许,有机会还是该去西天取趟经。

我一直就是这么想的。寻找一些一劳永逸的方式,是我一直以来的天性。当我深刻感受到大学所接受的教育之不成体系,我就明白我一定需要非常多的时间,专心去把这个体系的样子自己构架出来。于是,我必须去寻找这个世界上伟大的前辈们,站在他们的肩膀上,我才能知道有多少优秀的方法来节约我的生命

有做得到的事也有做不到的事

比如早睡早起就是做不到的~

有太多设计师认为自己天才的想法无法实施而纠结万分,带着情绪工作,不利身心健康啊。了解前人总结的模式,和他们提出模式的思想,可以用前人的智慧帮我们做判断。什么事情是可以放在短期计划里实现的,什么设计是伤筋动骨的大工程。什么设计方案是必然被对时间代价斤斤计较的项目经理腰斩的~

基于经验也好,基于知识也好,做出判断后,该做啥做啥,给多少资源办多少事。发现一些又要马儿跑得快又要马儿不吃草的需求,那还不如洗洗睡,多看些书。(这大概是架构师的基本素质,哈哈。所以你说什么有点儿想法,就想忽悠优质程序员来做牛做马创业的,都快洗洗睡,赶紧的~)

我非常感激自己刚出道就有自己控制一个项目的机会。这个机会给了我之后知行合一的去思考架构问题带来了很多帮助。

是个类ERP项目,当时仅有一个特别重要的需求:员工可以在不同的组调动,可能临时性的在多个项目中帮忙,员工可能在不同的工作上花不同的时间,然后需要将员工在各方面花费的工作时间自动化的记录下来,以便不同的组长方便的做时间统计,然后做项目计划。并且项目组也是经常会解散和移动的。

就这仅仅一个需求,我就基本上被秒杀了,相信这个需求秒杀99%的设计师和产品经理完全没问题。每当想添加新模块时,必是无穷尽的重构。说是内部系统,要完成完美的弹性设计,其模型复杂度还是比较夸张的。(基本上就一个信息回溯能力和易用性门槛之间的矛盾权衡问题,大部分ERP本质上通过复杂性来增强回溯能力。而看一下现代Web2.0的系统则加强易用性,流动性,完全弱化其信息回溯能力。我在这个问题上深入研究后,就觉得Google在未来还必然就是接着牛逼。除了搜索引擎,它在很多应用的信息回溯能力上的铺垫做的很好,然后再去强化不同产品的易用性。甩开其他公司一条街。你的公司里若没有那么好的精巧设计的基础库,那么很多设计方案就洗洗睡。有做得到的事儿,也有做不到的事~)

项目的后话,暂且不提。认识到这些问题,到逐渐在架构层面设计摸到一些门道,差不多花了我整整2年时间。国内你见不到有学校教这些东西,到任何公司,也不可能有mentor来将你带向这个方向。(没钱去西天取经,就只好自强不息啦,盗版给了我们知识,网络给了我们力量~)

认识到要用架构、建模来解决我碰到的设计问题,是一个很简单的事情,但实施起来很困难。没有特定的知识结构是无法快速学习的。在设计模式的学习上,会有一定的门槛。可能一下子就想去啃设计模式那块砖,只能是撞得灰头土脸,然后得出这个东西是过于理性,设计师无法学习的,这类谬误的结论。

从信息架构开始建模

一切建模,必从分类和归纳开始。我上一篇中提过,信息架构是一门前瞻性的学科,因为其基础在于分类学。前文中那张图,左侧是自然和社会中的不同层次,右侧就是信息架构中的不同层次。 最右下角的分面层级系统,是至今前辈们总结出来的最普适最稳定的一种分类法。

北极熊那本书的作用就至此,给设计师们打一个知识基础。因为非常理论化,实践操作起来还是很难的,国内公司也不会拨钱给你专门来搞这些。我曾尝试用信息架构的方式从头开始建模我的项目,花了一周时间,仅出了一个非常粗略的框架,由于自己要负责项目的很多部分,只好放弃这个幻想。虽不能放入实战,但对我们未来的成长,却是影响深远。因为读完这本之后,我基本知道要去看什么方向的内容,去追寻那些前人总结出来的好用的设计模式,去代替我自己没必要的摸索。

(前文中那张图实际来自于《Web信息架构》作者Peter的另一本书《随意搜寻》,眼尖的同学可能会在看Sixth Sense的视频的时候,发现MIT的小伙也把那本书放在案头,并且在视频中出镜率不低。每个天才的构思,必有其设计的根源。找出来,学会它,成为自己的智慧。)

映射!映射!映射!!!

信息架构和设计模式间,其实有很多相同之处。

在啃完信息架构之后很久,由于项目原因,我接触了MVC框架,同时开始啃《AJAX实战》。书中提及的数据服务器到Web服务器所需的ORM,实际上和MVC的设计思想是很像的。把关系映射到模型。基本上,想让项目的弹性和灵活性更好,就需要在已知的两者之间增加一个映射层(上一篇中曾一笔带过,mapping这种结构可以无比复杂)。一个映射层就完成一次多对多的关系。控制这个映射层的细分粒度,做出权衡,可以达到模型设计灵活性和简洁性之间的平衡。

一提到多对多的关系,很多人可能就能回想起信息架构中的Tagging。是的,从某种意义上说Tagging,就是在人的心智模型和系统信息模型之间,尝试着加一个映射层(在本文介绍的MVC前世今生最后,我提过从心智模型着力,去设计未来,这就是国外的IT产业设计未来的思路。Tagging兴起之后的热点就是研究tagging的稳定性,那就是06年开始的热点。一个有延续性的产业生态环境就是这样的,如此才可能出现创新)。

如果有人曾对传统分类和大众分类之间的利弊探讨总结过的话,也许还会联想到面向对象编程中的继承与传统分类是多么类似,大中分类的Tagging又与面向对象编程的多态是多么类似(的确面向对象的那套理论,比现有的传统分类+大众分类更稳定和合理,但信息架构层面的理论,可能会走出另一些创造性的方式)。

其实,很多时候,不同领域的人用不同的名词做出总结而已,本质上,设计师和程序员们,都在追求一些类似的设计思想


how to play baseball

(摸图片,看完整PDF)

文末的参考资料中,我会给出一个AIGA的一个开放性课程,是一个关于棒球游戏的信息架构的建模课题。非常有趣,如果有机会的话,我觉得研究生阶段应该多尝试些这样的课题,并且进行跨专业交流。这样的项目很容易培养出一个可能可以进行商业化的创新性项目,而且论文也可能随之而出。(这类事情正是国外的学校和大公司正在做的。创新能力的传承就是这么来的。给未来传递火炬,而不是灰烬。)

什么是分面(Facet)?

Facet

分面的意义在于认识事物的维度(我以前在博客中提过分面不止是搜索,这背后的原因皆在这里,但也不会像现在一样花十几天时间来写这么一个系列来说明这些问题)。

任何事物都是多维的,稳定如林奈生物分类系统,你从另一个维度去审视,也是可以打破重构的。更换角度,寻求突破,这是创新的基础。那一个面向任意维度的设计,是不是就是西方追求普适和稳定模型的科学狂人们追逐的目标呢?那是必然的!所以西方会有黎曼将笛卡尔的三维世界推向任意维度,所以《Big Bang Theory》里的Sheldon才如此牛逼轰轰藐视Leonard们。

所以即便有了面向对象的编程(OOP),神棍们还会提出面向切面的编程(AOP),所以面向服务的架构(SOA)才显得有可能。(所以跨国巨鳄们,才愿意砸钱研究这些东西。有了这更灵活有弹性的系统,那些公司未来的自动化程度就更高,必然更甩掉我朝公司几条街。咱们就接着山寨,接着加班追吧。想到这事儿,我就窝火,这加班加的多不值当。)

那一个控件究竟需要展示的一组或多组数据怎样的维度呢?或者说,同一维度是否也可以有多种表达方式?这是否就意味着Lookless Control呢?(下篇再来回答这些问题)

所以再回过头来想想,Donald Norman也在不断寻求更稳定的设计维度,才会如此犀利的提出UCD(以用户为中心的设计)是否已经过时,未来是否应该是ACD (以活动为中心的设计)。

建一个稳定的模型

how to play baseball

(摸图片,看完整PDF)

前文中我提到了AIGA的那个开放性课程。可以看到很多学生对哪个棒球游戏的建模。脱离业务需求,去谈这些模型到底哪个最优秀是没有意义的。每种建模都代表了作者对这类问题分类的一种看法。我们可以看到有的建的很复杂。它们在信息的结构性上可能也会产生很多符合心智模型,但不符合信息模型的回路。但这至少告诉我们一个问题。单纯的思维导图,根本不能完成复杂模型的建模,对思维整理的帮助也很有限。思维导图很大程度上,是一种营销工具。或者可以用来记录头脑风暴。但头脑风暴之后,还有非常重要的分类和归类的很多问题没有解决。那些问题需要用亲和图,或者说卡片分类啊,德尔菲法啊这类方法去解决。

card sorting

然后在这些复杂模型之上,我们还需要进行简化,将很多复杂的信息关系先隐藏起来,以免干扰我们在大方向上的思路问题。当整个简化后的模型提炼完成,一个相对抽象、相对稳定的模型就建立了。

我在上一篇中提过,我自己简化学科分类,认为世上只剩哲学、语言和分类学三门学科。这样一种归纳,就是我对个人知识体系进行的一种建模。在此基础上,我可以更好的管理自己的知识。

  • 分类学是一种思维工具。设计模式,就是分类学中的一些最佳实践的结晶。所以设计模式是非常优秀的代替折腾的工具。
  • 要打破已有分类学中稳定而顽固的成见,那是哲学层面的事,追求分面或者更通用的东西,都来自哲思。
  • 将这些东西沉淀,流传下来,用互相之间可以理解的媒介,进行沟通,那就是语言。

我会学习工具类的东西,方便自己偷懒,快速完成工作(为啥一个优秀的知识工作者顶十个凡人?效率问题,解决问题优雅度问题~)。我会用这带来的时间,尝试哲思,去突破现有工具设计中的弊端。然后我会用我熟悉的语言总结记录下来。我觉得这算是走出推磨的驴子怪圈的一种方式。

这就是快速学习的根基。这样才算进入知识积累的高速跑道(这就是读研究生阶段应该掌握的一些东西。然后博士阶段就该靠这些东西去研究创新区域。对比下我朝教育,不如趁早洗洗睡)。如此归纳之后,我完全看不出设计和技术之间会有什么水火不容的瓶颈,必须让我舍弃其一的去成长。小马淌水过河后,长出一口气,可以接着一路狂奔了。

结语-你心中的未来是什么样子的?

我说不准未来是什么样子。但未来会有很多样子,各种各样的机会。我们甚至还有创造新模式的各种机会。不过眼下,我们至少可以通过前文的分析知道,未来会分离更彻底。有的层面会被剥离开来,用一套工具进行Mapping,完成以前绑定在一起的工作。

设计模式中,有种策略模式,就是将变化频繁的部分剥离出来,封装起来,让这变化部分可以被很容易的替换。而就像前文中所说的,时尚、艺术和商业是变化最快的层面。那么这些在未来都会被率先剥离出来吗?

而微软,在控件设计的时候,用MVVM模式把视觉表现层彻底剥离开来了。这意味着什么?这意味着,我表面上是一把刮胡刀,实际上是一个吹风机;我表面上是一只皮鞋,我实际上也是一个吹风机。这意味着Lookless Control!

作为一个设计人员,形象非常重要。我们整装待发,敬请期待本系列最后一站——《深入控件创新[4]-Lookless Control》。

参考资料

无觅相关文章插件

Category: 教程, 设计报告

Tagged: , , , , ,

4 回复

  1. Meng 说:

    期待你的第4章

发表评论

使用腾讯微博登陆

使用新浪微博登陆

直接发表评论