Jun 20, 2008

QOC(Questions, Options, Criteria),设计管理的方法

    在设计的时候,常常会有这样的情况:自己和小组成员,以及与其他小组成员之间,包括销售人员、开发人员、用户等,进行讨论的时候,这些来自各方的观点在讨论中自由地流动。大家会在白板上画满彩色的草图;会在白纸上迅速地写写画画,而后随机撕掉;各种各样的即时贴贴的到处都是;各种草图、示意图到处都是。

    在这种情况下,很容易忽略一个好的建议或是一时设计的历史记录,包括那些进行的步骤和得到设计的一些推理。当设计不断取得进展的时候,怎样帮助设计人员捕捉下设计记录及背后的设计思考。方法很多,QOC是其中一个。

    QOC是一种对设计决策过程及各种方案的评估进行完整记录的设计方法(MacLean等,1989)。

    包含三个要素:

  • Q(Questions)问题:设计点
  • O(Options)选择:问题可能的答案或解决方案
  • C(Criteria)标准:评估备选方案的方法

    QOC用图表的方式来呈现,用线条将选择和标准连接起来。实线表示一个肯定的评估,即选择符合标准;虚线表示否定的评估,即选择不符合标准。

    在考虑选择的时候,要同时向用户提供他们可能感兴趣的地点和时间信息。过于详细的补充内容不要放在主屏幕上,但要能通过主屏幕访问到它们。

    在实际项目中,我还没有用到过这个方法,这个方法提及了设计管理方面的问题,如何让设计更有效率和实效,在设计的过程中不断向前稳步推进,这是值得思考和关注的问题。

参考:

《移动设备交互设计》104页

《Experience of UserCentred Design in Nomadic Media》Juhani Heinilä(2005).

Read more...

Jun 17, 2008

移动设备交互设计初步体会

    最近在研究移动设备的交互设计。一开始没有资料,对于移动设备的设计设想了很多,设想的依据是 iPhone、Nokia、HTC等先进的交互设计以及概念产品,心里也没底。在看了《移动设备交互设计》这本书的三章后,想法开始收敛。结合前段时间做用户调查和角色设计的试验,小结几个观点。

    1、不要狭隘的设想未来的移动设备是随身携带的功能超强的手机。移动设备具有专用性,并不是所有功能就集成在一起就是好东西。要确定一套为数不多的、一致的并且用户确实需要的功能,然后以简单直接的方式表达出来。

    2、新技术对移动设备的设计和使用会有很大的影响,要关注新技术的发展,考虑现有的设计在新技术的加入下会有怎样的变化。但同时要防止滥用所有新技术。

    3、移动设备的设计和传统的桌面应用、web应用设计有很大的区别,不仅仅是以效用和任务为中心。在将传统应用迁移到移动设备上时,要考虑人们对这种应用和服务的需求有多少是依赖于其非移动的应用背景的。

    一个重要方法:自由讨论

    让想象力自由发挥,促进不同组织和文化的互相理解,从社会学角度洞察人们的生活,寻找是什么驱动着他们,他们珍视些什么。当每个新的创意产生之后,指定正反方。正方应当对该建议大肆宣扬,从风设想怎样将其扩展;反方应当关注该建议的缺陷,指出其不切实际的地方,以及一些过于乐观的小团体思想。

    虽然这里说的是移动设备交互设计,但和通常的交互设计道理是一致且相同的。

Read more...

Apr 25, 2008

关于交互设计与技术,以及小公司的一些思考

    最近在写UI部分的API文档。在写的过程中,发现产品在技术实现上的许多不足和缺陷,重新思考了一些功能的实现技术以及可行性,并和底层的工程师做了探讨。有一些方法和技术,不但可以提高产品的质量,提高开发效率,更可能极大的改善产品的体验。虽然想法是好的,也确实可以尝试或者应该那样去实现,但受限于技术水平,公司目前没有这样的技术能力去实现。其实,我主要想到的是PHP和Flash技术。这是两样再常见不过的技术了,但公司目前没有人掌握。我想,这基本上会成为我后面这段时间要去学习的东西。

    抛开公司的一些具体情况不谈,做交互设计,在技术领域应该掌握哪些东西,掌握到什么程度,我有一些思考。

    交互设计,我的一个初略的理解,就是把实现模型转变为心智模型。既然交互设计是实现模型和心智模型的纽带和桥梁,那技术能力应该成为交互设计师的一个必备能力和基本素质。

    Cooper在给同行的话中也说到:“交互设计师通常不是来自各级程序员,尽管如此,他们也是精通技术的人。非技术人员无法想象计算机能为我们做的美好新事物。非技术人员无法理解CPU的时间与用户下次击键之前计算机迅速地完成千万次指令的精细平衡。”

    看一看微软亚洲研究院交互设计中心对原型工程师的招聘要求,有这么一条:“Proven record of developing SW applications for Windows. Must master C++ (or Java), Python, and web development languages. Will be great to have strong programming experiences on Macromedia Flash and Director.”

    Cooper也说到:“(交互)设计师很少编程,除非你可以完全控制你的项目,否则你同时设计和开发将对不起你的用户,这存在利益冲突。”

    我理解这个利益冲突,因为这两年我就一直处在这样的冲突中。我想有好的设计,我同时想有好的技术实现。我曾经为走设计的路还是走程序的路而思考辗转过很长时间。当时一个让我不能放弃程序的理由就是,担心两年的程序经验浪费了。当时不理解设计,不理解交互设计,所以当时有那么一条理由。现在看来,没有浪费,很有用,而且还不够用。

    那么对技术的精通哪里来?我认为还是从实际开发中来。在设计的时候,你不需要考虑某个功能的代码具体怎么写,但你知道应该怎么去实现,我想,掌握到这个程度应该就够了。所以不经历实际的开发过程,不经过亲手敲出自己思考的代码的过程,怎么实现那个功能就不会思考那么清楚,精通就远谈不上。

    那是不是交互设计师都是从事过开发工作的人?这个我不清楚。我认为对技术的掌握,是做交互设计的必要条件。如果有一个设计团队,那团队里需要精通技术的人。如果没有团队,只有你一个人,那你就必须掌握技术。

    很多小公司都有这样的人,要做设计要做开发,一定都有和我一样的困惑。公司不懂设计,公司需要你这样一个多面手。在设计和开发之间,这个平衡很难把握,把握住的结果那也是你的设计一般般,你的程序也一般般,做的糟糕的话还很有挫败感。毕竟做全才很难。怎么办?振之曾经跟我建议过,这时候的重心不是在设计,程序实现最重要,更重要的是,让全体开发人员都有为用户着想的意识,把这个意识带到通常那种边设计边开发的过程中去。交互设计和用户体验不是一个人来抗,一个人也抗不好。看过白鸦一篇文章,是对公司是否应该成立设计团队的讨论,结论是对于一些小公司,不如没有设计团队。这里面有一些道理是相同的。

    我有一些完美主义情结,所以我以前的做法是,把设计和开发分开,其实就是把我自己分开,做设计的时候就只管设计,做开发的时候就只管开发,以为这样就遵循了所谓正确的产品开发流程。但实际的结果和理想相差甚远,最后的结果就是产品很糟糕,设计糟糕,程序也糟糕。现在,我改变了一些做法。像振之建议的那样,要让开发人员具有为用户思考的意识。我会经常发一些博文给他们看,发一些成功的产品例子给他们看,然后在休息的时候引发大家来讨论,有时候甚至是争论和辩论。我也给头头讲一些我对产品开发和项目管理的分析,说出一些不合理和可以改进的地方,也给他看成功产品的设计,让他明白设计的重要性和设计的力量,然后头头就会在开会的时候又引发大家来讨论。这些小动作带来的影响是潜移默化的,也是有效的。整个开发团队,包括你自己,都会受益。而对于自己,要不断的学习和提高,不仅在设计上,也在技术上,因为你是连接用户和工程师的桥梁。

    Cooper 说,“ 设计师不仅要成为用户服务的倡导者,还要成为组织内部革新的倡导者”。所以,有与我一样困惑的同志们,抛开那些困惑,思考一下怎样能把产品做好,怎样能做出一个成功的产品,让你的思考影响你周围的人,然后做你所能做的。这样,用来思考困惑的精力就转移到做产品上来,转移到自我学习和提升上来,这比困惑的心情要好的多,也许会找到久违的成就感。

    PS:我不是什么专家型人物,上面的看法和建议是最近的个人感受。

Read more...

Apr 18, 2008

2008-04 UCDChina 南京书友会:排序

    排序,是大家常见的功能,无论在文件系统中、在网络商城中、在数据表格中,按照类型排序,按照时间排序,按照价格排序,还有自由排序,等等。

    排序,就是把一个集合中的对象,按照属性来进行划分,然后按照一定的顺序进行排列。表格,是大家最常见的加以排序功能的载体。如淘宝的商品列表,按照价格高低、卖家所在地、信用等级排序。Excel、财务管理等数据处理软件,按照数据大小排序。详细信息视图下的文件系统,按照文件大小、文件类型、修改时间排序。如果不是详细信息视图,而是平铺、缩略等视图,那也是以大小、时间、类型属性为标准来进行排序,只是这些属性在视图上是隐藏的。

    那为什么要排序呢?大体来看有两个目的。第一点,很显然,排序就是比较,比较就是为了选出目标对象。第二点,就是把集合中的对象按照一定的有序方式输出,得要一个有序的结果。那要这个有序的结果干什么呢?也是给别人看的,也是为了让别人能方便快捷的寻找到有用的目标对象。这样看来,第二点和第一点的最终目标是一致的:用户的直接目标是寻找和选择自己想要的对象。排序是辅助用户达到这个目标的有效手段。很显然,电脑要比人工强大的多,所以集合中的对象越多,排序的作用就越大和越明显。

    那怎么排序?或者说排序的标准是什么?当然,这里不会讨论程序和数据结构。前面说了,排序就是按照对象的属性来进行划分,那么属性就是排序的标准。一个集合中的对象,都有共同的属性。理论上来说,有多少属性,就有多少种排序方式。以文件系统为例,文件的属性有大小、类型、修改时间、创建时间等。再看mp3歌曲的属性,有艺术家、唱片标题、发行年、曲目号码、流派、歌词、来源、音频持续时间、位速、频道、音频采样级别等等。每一种属性都可以用来排序,那是不是太多了?是的,如果所有的属性都按照列表的方式排列开来,那太夸张了。所以,大部分属性是隐藏的,也不提供对这些属性的排序功能。一般只提供基本属性的排序,就如详细视图下的文件列表。

    哪些是基本属性呢?这个就要看目标用户了,对目标用户有用的属性就是基本属性。以mp3来说,我们将用户划分为三类。第一类,只管听,不管这歌是谁唱的,什么时候出的专辑,不管是港台的、大陆的还是英伦的,好听就行。第二类,除了听,还有高一层次需求的,要听××歌手的,要听××年代的,要听××风格的。第三类,更有追求了,是玩音乐的,除了上面两类的要求,还要知道音频采样、频道、位速等等专业的东西。按照cooper对用户的划分,可以分为初、中、高级用户。中间用户永远是占大多数的,所以中间用户的需求,放到排序这里,他们所需求的属性,就是软件、网站、信息系统所提供的排序方式。看看文件系统,确实是那么几项。初级用户虽然暂时用不到按这些属性来排序,但初级用户会成长为中间用户,到时候会用到。而高级用户,那些玩音乐的,真实太少了。那也只有他们在玩音乐的时候才用到那些属性来排序,而当他们听音乐的时候,也就和中间用户,甚至初级用户一样。所以,按照目标用户,以中间用户的需求选择属性,来做为基本的排序方式,对于初级用户,提供基本视图,隐藏或简化排序功能,对于高级用户,提供高级视图,提供更全面的排序方式。

    下面扩展一下对象的属性。除了那些固有属性,还有没有其他动态的属性、变化的属性?有,比如说频率。按照某个对象的使用频率、点击频率来作为排序的对象。在网上商城的一个典型例子就是按照关注程度来排序,按照商品的好评程度来排序,还有大家常见的Tag,也是按频率来排序的。这个机制和搜索引擎有些类似的地方,在网上商城很常见,那在文件系统中是否也引进一下呢?再扩展一下,不但属性是动态的,对象也是动态的。就比如歌曲排行,新歌在不断的加入,而歌曲的点击率也在不断变化,排行榜要实时显示。这个应该是技术上的问题了。

    再扩展一下,属性的格式化和标准化。常见的排序属性,基本都是以关键字排序,也就是把属性字符化,然后对符号进行排序。是否可以避开这个过程,直接对属性进行比较呢?举个例子,本命年,要买红色的东西。我想看看有哪些红色的东西。怎样按颜色来排序?按颜色排序,那就要按颜色的标准码来。但标准码怎么来呢?卖家贴出商品的时候填上颜色码?不好弄。系统自动识别?有难度。所以,按颜色来排序,就不大好实现。如果所有的属性都以二进制流的方式来识别,那将来可排序的属性可能会更多。再来看标准化,比如按照尺寸排序,卖家张三填的是长×宽×高,而卖家李四填的是长×高×宽,那排序后用户做出的选择必然会有差错。属性没有标准,那错误就必然发生。所以对象属性的格式化和标准化是排序的重要方面。

    在有了标准和格式的情况下,那排序的方式有哪些呢?手动?自动?自动排序,我们可以理解为默认排序,也就是以一个基本属性为标准,上面说的按照频率等来自动化的排序也是这样。这个很容易理解。手动,那就是用户自己选择一个属性作为标准。也很容易理解。扩展一下,用户不想以那些属性来排序,用户就要自己来排。这种排序比较常见的就是文件系统,用户可以把文件图标随意排放。还有就是blog里大家对友情链接的排序,对文章分类的排序。Wordpress里有专门的插件,可以通过拖拽来排序。Blogbus里用的是让用户输入数字来排序。这些都代表了自由排序。

    再扩展一下,现在常见的排序都是一维的,也就是按照一个属性来排序,能否按照两个、三个甚至更多属性来同时排序呢?那就需要二维、三维和多维空间。举个二维的例子,按照物品的生产时间和重量这两个属性来排序,那就要画出一个二维坐标,X轴,Y轴,物品在这个二维的坐标中以点的方式来呈现。三维的也可以这样。当然维数越多,技术上越困难,并且也不利于用户做出选择了。

    下面来看一看一些常见的产品,看看它们和排序的关系。

    先来看手机通讯录。我的手机是S40系统。S40系统的通讯录排序,是按照姓名,按照数字和字母顺序来的。我常常遇到这样的情况,我要发同一条信息给几个人。第一个人,我可以通过查找调出他的名字。而第二个、第三个人,我查找不起来了,只能按顺序在通讯录里去一个一个往下按。而S60做的比较好,可以查找后选中checkbox,然后继续查找,再选中。那能否按照联系频率来给通讯录排序呢?S40中有一个“最近常用联系人”,但也只有15个,而且是常通话的联系人,不是常短信的联系人。对于按字母排序,能否按字母块再多一级上级排序呢?比如我要找G开头的一个人的名字,能否让我直接跳到G开头呢?而不是仍然要从A到G按顺序这么一个一个按下去。

    再来看手机九宫格菜单。S40和S60都无法排序。每次进入S40的九宫格,都是默认选中的多媒体文件夹,如果我要发信息,那要按一下左,再按一下上,这就多了两次按键操作。按照我的想法,九宫格菜单应该和桌面电脑的图标一样,可以自由排序,或者按照使用频率排序,而不是固定格式。iPhone我没用过,我想应该可以。

    来看看IM。QQ、MSN、GTalk、百度Hi,都是只有默认按照名字来排序,好像没有其他排序方式。QQ有个最近联系人,但不清楚它的排序方式是什么。如果你的IM里联系人很多,而你要找一个人,给他发个消息,而你又记不得他的IM号码,也记不得他的昵称,那就老老实实的去按顺序找吧。如果给IM软件加上自由排序,或者加上按照联系频率等排序方式,是否更好用呢?

    看看网络相册,Flick和又拍,就有比较好的自由排序机制。而windows live spaces的相册,只能按照创建和上传的默认时间排列。

    还有输入法。智能ABC,估计大家都不用了吧,其实一点都不智能。字是固定的排列,每次都要翻着找。Google输入法就智能了,按照使用频率自动往前排。

    大家可以看看Silverlight的宣传片,从里面可以看出一些排序的应用。

    总结一下,排序,三个要素:集合、对象、属性。然后在这三个属性中变幻吧。当然,前提是,要对用户有用。

Read more...

Apr 17, 2008

[转]RIA技术概览

《程序员》杂志05年第二期原文,个人网站转载请注明作者(王林/Azure)和出处(中国RIA开发者www.riacn.com)并且保留这段版权说明,商业网站转载需要得到CSDN的许可。


RIA技术概览

    互联网已经日益成为应用程序开发的默认平台,传统的Web应用程序(Web Application)是基于HTML页面、服务器端数据传递的模式。而HTML是适合于文本的,随着Web应用程序复杂性越来越高,传统的Web应用程序已经渐渐不能满足Web浏览者更高的、全方位的体验要求了,这就是被Macromedia公司称之为的"体验问题"("Experience Matters")。此时一种被称为Rich Internet Application(简称RIA,中文翻译作"丰富互联网应用程序")的具高度互动性和丰富用户体验的网络应用程序出现了。Macromedia公司也借此机会开发了相关的技术和开发工具,促进RIA的开发和普及。

    1. RIA的产生背景

    企业级应用程序经历了几次系统架构方面的重要转变,在此过程中,客户端的表现能力有起有落。图1显示了Rich Internet Application的发展过程:


图1.Rich Internet Application的发展(摘自Macromedia Flex:创建企业Rich Internet
Application 的表示层解决方案)
    • 基于主机的应用程序:应用程序提供基于文本的非图形化用户界面,只有内部人员才能进行访问。
    • 客户机/服务器(Client/Server,简称C/S)应用程序:二十世纪九十年代随着Windows的出现和客户端处理能力的增强,出现了客户机/服务器应用程序,它们采用图形用户界面,客户端的数据处理能力比较强。但由于客户端应用程序需要进行不断的更新,因此部署成本比较高,只能为少数人所使用。
    • 浏览器/服务器(Browser/Server,简称B/S)应用程序:九十年代中期,互联网飞速发展,出现了浏览器/服务器应用程序,Web的广泛使用解决了C/S应用程序部署、和更新的困难。但由于采用了HTML页面形式的用户界面,客户端的数据处理能力较C/S应用程序有所回落。
        C/S架构的缺点主要是部署、更新的问题。B/S架构的缺点主要是受制于HTML的限制,无法像C/S那样使用丰富的效果来展示数据,用户体验比较糟糕。另外,稳定的客户端/服务器连接,也是必要条件,网络中断将使B/S程序无法运行。从C/S到B/S,这两者受限于技术本身分别发展成了重客户端和重服务器端的模式,而RIA的出现给我们带来重新在客户端和服务器端进行更好的平衡的机会。

        2. 什么是RIA

        RIA 是集桌面应用程序的最佳用户界面功能与Web应用程序的普遍采用和快速、低成本布署以及互动多媒体通信的实时快捷于一体的新一代网络应用程序。RIA中的 Rich Client(丰富客户端)提供可承载已编译客户端应用程序(以文件形式,用HTTP传递)的运行环境,客户端应用程序使用异步客户/服务器架构连接现有的后端应用服务器,这是一种安全、可升级、具有良好适应性的新的面向服务模型,这种模型由采用的Web服务所驱动。结合了声音、视频和实时对话的综合通信技术使RIA具有前所未有的网上用户体验。

        下图就是RIA的应用程序模型:


    图2.RIA的应用程序模型

        3. RIA的优势

        RIA 具有的桌面应用程序的特点包括:在消息确认和格式编排方面提供互动用户界面;在无刷新页面之下提供快捷的界面响应时间;提供通用的用户界面特性如拖放式(drag and drop)以及在线和离线操作能力。RIA具有的Web应用程序的特点包括如:立即布署、跨平台、采用逐步下载来检索内容和数据以及可以充分利用被广泛采纳的互联网标准。RIA具有通信的特点则包括实时互动的声音和图像。

        客户机在RIA中的作用不仅是展示页面,它可以在幕后与用户请求异步地进行计算、传送和检索数据、显示集成的用户界面和综合使用声音和图像,这一切都可以在不依靠客户机连接的服务器或后端的情况下进行。

        对于企业来说,部署RIA的好处在于:

        1)RIA可以继续使用现有的应用程序模型(包括J2EE和.NET),因而无需大规模替换现有的Web应用程序。通过Rich Client技术,可以轻松构建更为直观、易于使用、反应更迅速并且可以脱机使用的应用程序。

        2)RIA可以帮助企业提供多元化的重要业务效益,包括产提高销量、提高品牌忠诚度、延长网站逗留时间、较频繁的重复访问、减少带宽成本、减少支持求助以及增强客户关系等。

        4. RIA目前的发展态势

        在过去的两到三年中,Web开发人员一直是想构建一种比传统HTML更丰富的客户端:这是一个用户接口,它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA技术的出现允许我们在因特网上以一种像使用Web一样简单的方式来部署富客户端程序。无论将来RIA是否能够如人们所猜测的那样完全代替HTML应用系统,对于那些采用C/S架构的胖客户端技术运行复杂应用系统的机构和采用基于B/S架构的瘦客户端技术部署Web应用系统地机构来说,RIA确实提供了一种廉价的选择。下面介绍一下目前出现的几种比较有实力或者有特点的RIA客户端开发技术:

        1) Macromedia Flash/Flex
        Flash 从6.0开始Flash就逐步具备建立窗体风格的应用程序的功能。据Macromedia称已经有98%以上的桌面系统的浏览器都安装了 Macromedia Flash Player。这使得以Macromedia Flash Player为客户端的RIA可以支持种类广泛的平台和设备。
    Flex是为满足希望开发 RIA的企业级程序员的需求而推出的表示服务器和应用程序框架,它可以运行于J2EE和.NET平台。Flex表示服务器提供基于标准的、声明性的编程方法和流程,并提供运行时服务,用于开发和部署丰富客户端应用程序的表示层。Flex开发者使用直观的基于XML的MXML来定义丰富的用户界面。该语言由 Flex服务器翻译成SWF格式的客户端应用程序,在Flash Player中运行。

        2) Laszlo
        Laszlo 是一个开源的RIA开发环境。使用Laszlo平台时,开发者只需编写名为LZX的描述语言(其中整合了XML和Javascript),运行在J2EE 应用服务器上的Laszlo平台会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说,Laszlo的本质和Flex是一样的。Flash是任何浏览器都支持的展示形式,从而一举解决了浏览器之间的移植问题。而且,在未来的计划中,Laszlo还可以将LZX编译成Java或.NET本地代码,从而大大提高运行效率。

        3) Avalon
        Microsoft的Avalon是下一版本的 Windows(代号"Longhorn")的一部分,是一个图形和展示引擎,主要由新加到.NET框架中的一组类集合而成。Avalon定义了一个在 Longhorn中使用的新标记语言,其代号为"XAML"(可扩展应用程序标记语言)。可以使用XAML来定义文本、图像和控件的布局,程序代码可以直接嵌入到XAML中,也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是:基于 Avalon的应用程序必须运行在Longhorn环境中,而Flex和Laszlo是不依赖于平台的,仅仅需要装有Flash播放器的浏览器即可。

        4) Java SWT
        Java 已经出现几年了,并且完全支持创建基于窗体的用户界面。除了Java基础类(JFC/Swing)中的用户界面组件之外,开发人员还可以使用来自于 Eclipse Project的SWT工具箱和许多第三方工具箱进行开发。对于图形来说,可以采用Java 2D API:一个非常完整且非常复杂的图形API。你可以通过一个Web浏览器使用Java插件软件,或使用Java运行时环境中较新的Java Web Start技术来部署应用程序。使用Java建立Rich Client的主要缺陷是它的复杂性(即使对简单的窗体和图形也要求编写非常烦琐的代码)和Java浏览器插件的低市场占有率。

        5) XUL
        XUL (念作"zool")是一种基于XML的用户界面语言,它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序,这些应用程序不但可以在 Mozilla浏览器上运行,而且也可以运行在其他描述引擎上,如Zulu(一个Flash MX组件)和Thinleys(一个Java实现)。XUL描述引擎都非常小(100K以下),它可以使用XML数据也可以生成XML数据。XUL的一个主要缺点在于它目前还没有获得一个主要商业实体的支持。XUL最大的优点在于它与Gecko引擎的集成(打开了通向大量Web标准的大门),以及与大多数其它XML用户界面描述语言相比它是一种非常具有表达力和简洁的语言。

        6) Bindows
        Bindow 是用Javascript和DHTML开发的Web窗体框架。Javascript用于客户端界面的显示和处理,XMLHTTP用于客户端与服务器的信息传输。Javascript在客户端的表现力不容置疑,利用Javascript几乎可以实现Windows应用程序所能干的大部分事情,XMLHTTP 一直以来常被用于实现"无刷新"的Web页面,它和 Javascript配合,可以完成数据从服务器和客户端的传输。Bindows的一个主要的缺点是它采用一次全部载入的方式来实现脚本库,在窗口的加载期,需要一个漫长的等待过程,甚至浏览器的进程会产生无响应的情况。这点Bindows根本没有遵循"用多少去多少"的准则。另外,内部大量利用了IE6 的技术,没有考虑到非IE的浏览器,限制了Bindows的流行。

        5. RIA未来的发展预测

        就目前RIA的使用情况来说,离"RIA时代"还有很远的一段距离。今后几年时间内传统的Web应用程序和RIA将会共存。笔者认为真正具有实力担当起普及丰富客户端应用重任的只有基于Flash Player的Flash/Flex应用程序和Microsoft的基于Avalon的应用程序。短期时间内(估计2-3年时间)可能是 Flash/Flex应用程序在新兴的网络应用程序市场上占有主导地位。随着时间的推移,Flash/Flex应用程序的市场占有率可能会慢慢被基于 Avalon的应用程序所蚕食。当然,Flash Player和Flex以后也会不断推出新版本,相对于升级操作系统或安装Avalon运行环境,人们肯定更愿意升级Flash Player。Flash/Flex应用程序也有其本身固有的软肋,Flash Player的执行效率和对本地资源的操作限制是无法和Avalon相比的,相对于浏览器中的插件而言,Avalon的应用程序拥有更加广阔的可操作空间和更高的执行效率。

        目前Microsoft还在推广一种叫做Smart Client(智能客户端)的客户端程序技术,Microsoft称Smart Client是比Rich Client更优秀的客户端,因而采用Smart Client的应用程序算不算RIA目前我个人还无法作答。这里我们之所以提及Smart Client,是因为Smart Client的特性跟我们谈的Rich Client有太多的相似之处。Smart Client拥有自动更新、离线状态下的数据处理和可以使用本地资源等特征,其中的可使用本地资源这一项无疑是一大卖点,因为浏览器中的 Flash/Flex应用程序目前还无法操作本地的一些资源,比如Flash/Flex应用程序无法将网上的文件保存到本地或者修改本地文件。虽然 Macromedia的Central1.5已经可以对本地文件进行简单的操作,并且flex1.5开发的RIA也能够运行于Central上,但是如何使Central能够得到大范围推广还是个问题。相对于轻量级的Rich Client,Smart Client更接近C/S架构中的客户端程序。Rich Client和Smart Client的定位还是有所区别的:Rich Client更适合作为轻量级的基于浏览器的网络应用程序客户端;Smart Client更适合作为Windows桌面应用程序的智能客户端。

        不管我们今天称之为的RIA今后会不会成为主流应用程序,人们对开发具有高度互动性、丰富用户体验以及功能强大的客户端的追求是不变的。有理由相信,拥有成熟技术和极高市场占有率的Flash客户端将会在RIA道路上越走越远。Microsoft未来的重量级武器:Avalon和Smart Client能否后来者居上让我们拭目以待。

    Read more...

    Mar 17, 2008

    2008-03 UCDChina 南京书友会:帮助

        这次参加的朋友又多了好多,我也“忽悠”了一个做设计的中学好友一起参加。这次讨论的话题是:怎样设计“帮助”更有效?

        由于晚到,没有听到振之关于主动帮助和被动帮助的观点,轮到我发言时,我又罗嗦了一通,实际就是表达的这个意思。这是我对于“帮助”的基本认识。在听完大家一圈的发言之后,我又有了新的观点。

        话题,怎样设计“帮助”更有效,所以就不说好的设计不需要帮助之类的话了。

        听大家的发言,发现大家把“帮助”的含义扩展开来,认为整个网站的设计其实就是“帮助”,教会用户如何使用网站也是“帮助”,还有一些导航和提示也划为“ 帮助”的范畴。其实,我不赞成这样的广义的“帮助”,这些广义的帮助有的应该属于网络营销、网站推广的范畴,这样很容易又和广义的“设计”放在一起讨论,反而不够清晰。

        我的理解是,“帮助”就是针对“困难”来的,就是用户在完成一个目标任务的过程中遇到困难时,有问题时,需要知道如何解决问题所需要的那部分知识。这种知识的表现形式,就是我们所要设计的。

        有哪些表现形式呢?JunChen在文章中提到了常见的“帮助”形式:文档型帮助、情景式帮助、演示型帮助等等,以及这些形式的优缺点。

        我觉得要设计帮助的形式,首先要看是什么样的产品。这里我大概分“普通”和“高级”两类产品。

        “ 普通”的,就是用户不以学习如何使用为目标,而是以直接完成任务为目的,这类产品常见的有网站、IM软件等,用户的目标很直接,也许就是想注册一个帐户,也许就是想加一个好友。用户在执行这些任务的过程中,遇到困难,那需要得到即时的直接的帮助。这时应该以主动帮助为主。对用户操作过程和行为的监控,对相关数据信息的分析,系统能够对当前用户遇到的困难做出“尽可能准”的判断,告诉用户“出了什么问题”,然后以直接的方式,告诉用户,“你应该怎么办 ”。以此来缩短执行目标任务的时间。用户无需知道“为什么”,只需要知道“怎么样”,从而继续任务的执行。通常这样的任务或产品在逻辑和结构上是简单的,情景式帮助和演示型帮助是比较好的形式。

        “高级”的,那就是用户以学习如何使用为目标,这样的用户属于专家用户。常见的产品有图像处理、动画制作、文档处理等等软件。专家用户不会只满足“怎么样 ”,需要知道“为什么”。这样的帮助需要全面和深入。常见的就是帮助文档,而实际中,帮助文档是不够的,用户往往会看专业书籍,那书也成了帮助系统。通常这样的任务或产品在逻辑和结构上是很复杂和庞大的,目前看来,也只有详细而全面的文档才能有效的辅助用户。这样的帮助更多的是被动帮助。

        以上就是听了大家的发言后产生的一些观点。

        在发言中,发现大家普遍的在表达不够流畅,不能完全清晰的表达出自己的观点,有些朋友还不知道该说什么,我也是这样,发言的时候浑身很不自然,说话罗罗嗦嗦。我想有几个原因吧。设计师的性格原因,做设计的人,多是内向和敏感性的人,想法很多,但不一定善于综合总结和表达。这样的性格在众多生面孔面前,更加突出。对于第一次参加的朋友尤为这样。还有就是话题的发散性,发散性会引出很多想法,但想法多了,就难于归纳和总结,所以表达的时候也就缺乏条理。也许问题在具体一些,再详细一些,大家会表达的更到位。

        我觉得语言表达能力对于一个设计师很重要,光有想法不行,表达不出来,坏的脑子里,不能有效的表达出来,别人弄不明白,那同样没用。现在的设计强调的是团队协作,设计师要与用户、与管理人员、与工程人员交流,表达不清楚,误解的几率增多,工作的效率可就下降了。

        貌似我上面的话也没表达清楚,哈哈。慢慢来吧,写博客就是一个不错的训练方法,多交流更重要。

    Read more...

    Feb 24, 2008

    [转]以用户为中心设计思维考问中国IT企业

    一直在想,一些企业是怎么开展UCD的,他们到底是怎么做的。看到大连海事大学中国欧盟可用性研究中心的一份调查,对国内企业的UCD状况有了一些了解。



    转自:http://news.ccw.com.cn/digital/htm2008/20080129_375543.shtml
    【计世网 独家】(作者 大连海事大学中国欧盟可用性研究中心 刘正捷 郭志伟 钱凯 魏慧玲)
        近年来,随着中国经济的发展和市场全球化,用户体验正为越来越多的人所认识,市场竞争的重点正在从技术转向用户体验,消费者对用户体验的要求越来越高,厂商对可用性的关注也与日俱增。为了更进一 步认识中国可用性行业和从业人员的现状及面临的问题,以利于行业今后的顺利发展,大连海事大学中国欧盟可用性研究中心开展了关于中国IT企业以用户为中心 设计(UCD)实践状况的调查研究。其结果值得中国IT企业深思。

        作为可用性工程的核心方法论,以用户为中心的设计方法(UCD)自20世纪80年代末在北美、欧洲发达国家的IT业界开始实际应用,并在实践中不断 完善和成熟,在提高产品可用性质量和用户体验方面取得了明显成效。国内企业起步较晚,但近年来发展迅速,国内各大知名企业纷纷成立用户体验/可用性 /UCD部门,一些规模较小的创新型企业也在这方面有所动作。可用性与用户体验研究正在国内迅速崛起,并逐渐形成一个新兴行业。
        大连海事大学中国欧盟可用性研究中心选择了在可用性和UCD方面已经有一定积累或比较领先的13家中国企业,开展 了关于中国IT企业UCD实践状况的调查研究。调查对象主要为大型企业,也包括少数创新型中小企业,地理和行业分布如图1和图2所示。在每个企业中选取1 名可用性从业人员作为受访者,均有一年以上的可用性从业经验,总体平均从业时间为两年半,其中33%的受访者为普通可用性从业人员,67%为UCD部门主 管。
      
        为了全面系统地了解企业在UCD方面工作开展的状况,调查参照了可用性成熟度模型(UMM)(INUSE, 1998)(Bevan & Earthy, 2001)的以人为中心程度衡量尺度——UMM∶HCS(如表1所示)。

        该尺度用来衡量组织的可用性成熟度,即保证产品可用性质量的能力水平,它所涉及的领域包括:关于使用质量的培训、 用户信息收集、与现有流程的融合及使用质量在企业制度上的保障等方面。根据这个模型,调查工作的侧重点包括可用性的员工培训及认识水平、用户参与程度、 UCD的不断完善、UCD与原有流程的融合和UCD方法应用状况这五个领域。
        国内UCD部门现状
        目前,大多数企业的UCD部门都隶属于产品线下的研发部,少数直接隶属于企业级领导,或位于研究、支撑平台或市场部门下。绝大多数部门都是从美工或者界面设计部门演变过来,少数是由企业高层直接组建。部门成员背景以设计、计算机居多,搭配少数的心理学与社会学。其中大型企业的UCD部门员工背景有比较明显的多学科交叉特点。
        大多数被调查企业的可用性相关工作较多集中在设计阶段,工作主要是用户研究和产品设计。这些企业中的UCD部门已 经受到公司领导的重视,并且越来越得到其他部门的认可,部门人员有扩充的趋势,专业化水准有所提升,分工也越来越细,用户研究工作也逐渐渗透到产品生命周 期中除设计之外的其他阶段。
        员工培训及认识水平
        大多数被调查企业都还没有针对用户体验的培训内容,主要限于UCD部门内部交流。个别企业已经在整个企业范围内针对用户体验进行比较系统的培训,接受培训的人员主要是部门级的管理人员及部分对可用性感兴趣的员工。
        从培训效果来看,只有和UCD部门合作过的员工才能在方法层面上有一些认识。大部分被调查企业的普通员工对于UCD的整体理解仅仅停留在用户界面层面,少 数企业的员工会认识到UCD与整个产品的架构和功能设计有关。在这方面,互联网行业对UCD与整个系统有关的意识较高。
        在多数被调查企业中,普通开发人员在进行某个设计方案选择时,首先会考虑到自己的工作量和工作绩效,其次才会考虑 用户体验。而互联网企业对用户关注的意识较高,因为员工通过对用户行为数据的监控分析,会直观感受到自己的每个决策在用户体验上的最终效果,比较容易在自 己的工作与用户体验之间建立联系。
        用户参与程度
        在对用户参与产品设计开发的认识方面,大部分被调查企业的管理层都已经意识到需要关注和改进产品可用性,有的企业甚至已经通过制度化来保障用户信息的收集,并把产品可用性作为一项系统质量因素来评估产品。
        但受访企业中仅有一家企业对部分产品进行了可用性定量测试并据此建立产品可用性基准。没有采用可用性基准的企业主 要有两种情况:一种是以硬件提供商为代表的企业,虽然有意开展基准测试,但由于方法掌握程度和技术手段的限制,没法得到准确和有意义的定量数据;一种情况 是互联网企业,更倾向于采用点击率等数据去衡量产品的成败,通常不使用可用性定量基准。
        在产品设计开发过程中进行持续可用性评估方面,只有少数企业能够在早期开展持续的迭代设计和评估,过程中则较少采 用基于原型的用户测试,而是更多地依靠行业/领域专家的评估。被调查的互联网企业基本上都不采用持续的测试评估,都是在产品上线后再做评估和改进;传统软 件企业当中,个别企业受瀑布开发模型与CMM体系的影响,不太愿意接受产品的持续变更与改进。正是由于没有反复迭代的设计过程,所以大部分企业内部也没有 相应的设计方案变更管理。
        UCD的不断完善
        超过三分之一的被访企业拥有自己的可用性实验室,有的企业甚至购置了眼动跟踪仪和专业分析软件来提升研究能力,也 有企业通过在不同地点建立多个可用性实验室来加强对公司产品线的支持。有超过三分之一的企业建立了UCD活动的文档模板,这些基础设施的建设表明企业对于 UCD工作积累的重视。
        在UCD部门的自我提高与完善方面,多数企业普遍采用的办法是部门内部在项目之后的经验总结和分享。在部门今后发 展规划与员工技能发展方面,多数企业的UCD部门主管都对UCD部门员工的技能发展进行规划,其主要实施形式有三种:1.部门内部交流学习制度化; 2.外聘专家培训; 3.组织员工参加业界交流活动。
        在有关UCD的对外合作方面,目前国内企业采用外包或外聘专家的并不太普遍,但大多数对外包持接受态度。主要原因 是企业UCD开展程度还不够深,对于UCD的理解和掌控能力不足。在受访企业中主要有三种情况:1.完全不接受外包策略,这主要是受到中国企业普遍的“自 己做(DIY)”文化的影响,喜欢什么事情都自己来做;2.能够接受外包策略,但由于自身可用性成熟度不高,对UCD整体流程的理解不足,不知道流程当中 的哪些环节可以外包,或不知道外包之后如何去进行过程和质量监控以及结果的验收和利用;3.出于企业商业与技术保密考虑,害怕外包会泄漏机密。
        UCD与原有流程的融合
        受访企业普遍认为可用性是重要的产品质量因素,但多数企业并没有将可用性融入到自身的质量管理体系中去,而更多的是由UCD部门自己来控制; 个别实施较好的企业采取在质量管理部门下面建立用户体验分部的做法,做法超前的企业已经将可用性作为重要考查指标纳入质量体系。
        目前受访企业中UCD部门与其他部门,尤其是开发部门的沟通已基本没有太大的问题,但在制度和授权上,还不能保证UCD部门在用户体验方面的主导性和权威性,这在很大程度上还要依赖于具体可用性人员的专业水平和沟通能力。
        总的来说,目前企业开发流程上对UCD提供的空间不够,企业还没有找到把UCD有效和高效地结合到开发流程中的办法。
        UCD方法运用状况
        对企业在产品设计中常用的UCD方法进行调查,结果如表2所示。我们可以看出,被调查企业使用的UCD方法比较广 泛。使用比较多的UCD方法有竞争产品研究、原型法(高保真)、用户满意度调查、文案分析法、用户访谈、可用性测试(发现问题为主)、专家评估、焦点小 组。比较少用的方法包括可达性评估、远程可用性研究、眼动跟踪方法、日志法、认知走查法。


        在被调查的企业中,UCD方面均开展了大量的尝试和实践,积累了一定的经验,对有些方法的运用已经相当纯熟,甚至 开始结合自己的需要探索一些方法的创新。但这些企业的可用性成熟度总体上还没有达到较高水平。他们对比较经济有效的可用性方法使用较多,而对其他方法则使 用较少,从业人员对UCD方法的把握能力还有待提高。
        受调查企业在选择和运用可用性方法的能力上差别较大。一部分企业在对一些常规可用性方法的认识和掌握方面尚有所欠缺。在方法的选择上,主要是受到项目资源和员工认识水平的限制;在方法的具体运用上,更多的限制则是源于员工技能和经验的不足。
        成熟度评估
        为了对国内企业的可用性成熟度发展水平有一个总体上的了解,我们还根据可用性成熟度模型的以人为中心程度衡量尺度——UMM∶HCS(如表1所示),对受调查企业进行了非正式的可用性成熟度评估。通过对调查数据的整理和分析,各受调查企业关于UMM∶HCS各个属性和实践的状况如表3所示。这里采用的评分尺度为:N——没有达到,P——部分达到,L——大部分达到,F——完全达到。


        从结果中可以看出,现阶段国内硬件提供商在可用性成熟度方面相对较好,处于UMM五个成熟度级别的第三级或第四 级,即已实施级或已融合级,这也许是由于消费电子产品领域竞争激烈,企业比较容易直接感受到可用性对最终用户的影响,使得他们迫切体会到可用性的重要性, 从而在这方面大力投入的结果; 软件提供商和用户定制的解决方案提供商在UMM五个成熟度级别中多处于第二级,即已考虑级,这可能是由于软件行业较多受到传统软件工程思想的制约,影响到 他们对UCD的接受和实践;服务提供商则多处于UMM五个成熟度级别的第一级,即已意识级,由于服务提供商行业市场变化迅速的特点,企业需要及时迅速地做 出反应,所以很多互联网服务提供商只能根据自身特点,在开发流程中适当融入了一些可用性活动。
        从业人员的看法
        从调查中可以看到,在UCD方面领先的中国企业已经有两到三年的UCD实践历史,UCD部门也达到了一定的规模,而且正在发展多学科交叉的特点;一些企业 开展的UCD工作取得了很好的效果,得到了管理层和其他部门的认可;从业人员对前景比较乐观,对现状普遍感到满意。这反映出中国企业在面对市场竞争压力时 积极进取的态度,对先进技术和开发方法的敏感和接受能力,也展现出企业应对这些挑战的勇气和能力。
        关于可用性行业未来发展面临的问题和挑战,受访者提到以下几点:企业管理层对UCD的重视程度以及普通员工的认识 水平还有待于进一步提高;从业人员的素质和数量以及专业人才的培养能力与实际需求之间还有较大差距;行业发展不够规范,缺乏对应有的专业和技能水准的衡量 和认定,这不利于行业今后的健康发展; 缺乏与可用性领域国际发展前沿和学术界的交流渠道,企业汲取和更新UCD知识和技能的能力不足,还需进一步提高整个社会对用户体验的认识和诉求。
    链 接
        如何改善UCD部门现状:
        根据对可用性专业的理解和对国内工业界实际情况的认识,我们认为可以从以下几个方面努力:
    1. 加强整个企业范围的UCD普及培训,特别是提高管理层对UCD的认识,这是保证UCD理念在企业文化中扎根的关键;
    2.加强业界同行的相互交流、加强与专业机构和学术界的交流与合作,进行系统规范的UCD培训,使得从业人员可以系统规范地掌握UCD的知识和技能;
    3. 将UCD与现有流程的融合制度化,保证用户在开发过程各个阶段的参与,以及用户研究结果在开发过程中的应用;
    4. 尽可能让开发人员有机会亲自参与到用户研究活动中,从而保证UCD部门与开发部门沟通的顺畅和以用户为中心开发理念的建立;
    5. 建立产品可用性质量基准,明确可用性设计目标,衡量UCD工作效果,并提高UCD价值的可见性;
    6. 改造现有开发流程,使其更好地接纳UCD的反复设计和评估活动;
    7. 在产品设计开发早期引入UCD活动,以支持未来产品创新;
    8. 建立可用性活动文档模版,在有条件的情况下建立可用性实验室,提高UCD活动的效率和规范性;
    9. 围绕人才培养开展校企合作,保证培养的专业人才更适合工业界的需要;
    10. 在高校IT类专业普遍开设人机交互有关课程,为UCD的进一步推广提供土壤。

    Read more...