UED/HCI/UI

User Experience Design, Human Computer Interaction, User Interface

强悍的jQuery选择器

| 2 条评论 2007-12-02 11:02:00

周四在公司加班到近凌晨1点,期间在和开发部门的同事焦头烂额的编写js代码时,深深被jQuery强大的选择器所折服。

1、选择不存在的HTML对象时,jQuery不会报错

这点我早就深有体会。在此前使用的Prototype中,选择HTML对象前必须要保证这个对象的合法性,如果这个对象不存在,Prototype就会报错。这听起来很正常,但在jQuery中这种检查完全没必要,因为当一个对象不存在时,它会自动跳过那段代码!这样用起来非常方便。

2、parents()、children()和find()

利用parents()和children()可以很快捷地找到一个对象的父对象和子对象,但在实际使用时,常常遇到使用这两个函数编写好的js代码无法重用的问题,这是因为js代码是按照现有HTML的层级关系编写的,一旦HTML中的层级关系发生变化,js就失效了。幸好有find()这个函数,它可以让你完全不顾上下文的关系,而选择你想要选择的对象。

比如我想在用户点链接的时候,把如下代码中span的内容打印出来:

<div id="wrapper">
<p><a id="testLink">This is a test link.</a></p>
<div>
<p><span>Some text</span></p>
</div>
</div>

如果用parents()和children():

$('#testLink').click(function() { alert($(this).parents().parents().children().children().children('span').html()); return false; });

如果用find():

$('#testLink').click(function() { alert($(this).parents().parents().find('span').html()); return false; });

这看起来好像没什么区别?别急,find()还可以这样用:

$('#testLink').click(function() { alert($('').find('span').html()); return false; });

这一点当时就把我们给震了!虽然实际编写的代码比这个要复杂的多,但我们怎么也没想到前面为空时find()依然有效!我估计此时find('span')就相当于$('span')。

最后就是,有谁知道到底用什么工具可以给jQuery代码生成注释文档?之前提的JSDoc不行。

开关和状态设计

| 1 条评论 2007-11-27 22:13:02

今天发现了一个名为Sapiens的小软件,可以用鼠标快速启动应用程序(可以看成是Quicksilver的鼠标版)。不过它最吸引我的倒不是它的功能,而是参数设置界面中的设计(如下图)。

这个软件内建了一个学习功能,会根据使用者的习惯来进行自我调整,那么如何让使用者知道它的学习状态呢?从上图我们可以看到,“猴子-人-外星人”的比喻恰当有趣,让人忍俊不禁、印象深刻。

看完这个设计,我顺手搜集了一些开关和状态的设计,其中Time Machine(下数第三张图)是我最为欣赏的,它抛弃了传统的单选按钮(radio button)的设计,而是回归了最简单的方式(想想墙壁上的开关)。

网站前台开发,你用什么工具生成文档?

| 4 条评论 2007-11-22 17:01:05

随着在日常工作中接触CSS/Javascript编写的机会越来越多,才发现和后台程序比起来,这方面的开发还处于一个较初级的阶段,比如,找不到一个十分好用的文档注释生成工具。以下两个是目前我在使用的:

CSSDOC

我不知道是否还有其它更好的方案了,抑或CSS不需要注释和文档?反正这是我唯一找到的一个CSS注释文档生成工具,而且它才刚刚起步而已!目前CSSDOC的开发者提供了第一个草案,内容很少,但大致对CSS注释的规范作了一些设定。所幸这个工具遵循DocBlock规范,更新速度也不错,并且计划支持Aptana,从这几方面来看还是颇值得期待的。

JSDoc

JSDoc要稍微完善一些。同样基于DocBlock规范,提供了使用Perl编写的文档分析和生成工具,我简单试用了一下,不管怎么说它能用(要求相当的低,哈哈)。但对我来说最为可惜的是,这东西尚不支持jQuery。

最好的原型和流程图绘制工具:OmniGraffle

| 14 条评论 2007-11-19 17:45:07

“使用哪种原型设计工具”大概是设计师闲聊时出现频率最高的话题之一。据我了解一般以Visio和Photoshop为主,也有人用Flash和PPT,据一个新来的同事说,他们公司还用Excel。我实在想不出用Excel怎么画图,哈哈。我个人最喜欢的工具是OmniGraffle(如下图),自从我用了它以后,就再也不想用其它原型设计软件了。

首先我必须隆重介绍一下Omni Group这家只有26个人的小公司,他们人数虽少,但却产出了像OmniWebOmniGraffleOmniPlanOmniOutliner等等一系列深受用户欢迎的精品软件,实力绝对不容小觑。

你可以用OmniGraffle(以下简称OG)来做很多事情,我一般用它来绘制流程图和界面原型。相比较于Visio等工具,它的以下特点和功能让人爱不释手:

漂亮的界面

OG的界面太漂亮了,至少比灰突突的Visio好看多了。“美的就是好的”(《最佳设计100细则》),用OG绘图的时候脑中常常充满灵感,而对着Visio则只想尽快把工作做完。

能轻而易举的绘制出漂亮的图形

OG的可用性做得很好,可以让一名新手很快地绘制出“想让人舔一口”(Jobs当年评价OS X界面时的原话)的流程图和原型图。我使用它没多久就定义了一套自己的样式(如下图),并在项目中重用。

丰富、精致的模板(Stencil/Template)

除了官方的模板外,Graffletopia网站提供了众多设计精美的模板。不仅有常见的网络、软件流程、电路等类目,甚至还有UCD相关的模板(如下图),不仅显著提升工作效率,而且也使得你的产出物与众不同!


Information Architecture


User-Centered Design Activities

辅助对齐和尺寸调整功能

在用Visio的时候,你有多少次想把多个元素的大小调成一样的?反正我每次用它绘制流程图的时候都想这么做,可每次都需要一个个的调整,让人无可奈何。在OG里面,这是一件小菜一碟的事儿。当你调整任何一个元素的大小时,OG都会自动捕捉并显示页面内所有元素的大小,并辅助鼠标的运动(通过磁性感),以便让这一元素的大小和其它任何一个你想要的元素保持一致(如下图)。对于没用过OG的人来说,这听起来可谓“震撼”,我第一次发现这功能时激动不已!此外,保持两个或多个元素在水平和垂直方向上对齐也是轻而易举的事:辅助线总在你需要的时候出现(如下图)。


辅助尺寸调整


辅助对齐

OG还有数不清的好用的小功能,让人感觉无时无刻不处在这个软件的关怀之中!总之,对于设计类软件来说,OG绝对是用户体验的典范之作。

最后,很不幸的是,这个软件只有Mac版。不过如果你只有PC的话,不妨看看这里 :)

卡片分类测试实施攻略

| 2 条评论 2007-11-16 15:17:08

最近连续做了几次卡片分类,这里把经验总结一下,内容包括:

  1. 测试前的准备
  2. 测试时的流程
  3. 测试后的数据分析

测试前的准备

需要准备的物品包括:卡片、卡片分类测试记录用表、用户保密协议、用户基本信息表、便签纸(一般来说每个用户至少要为其准备20张,当然这要根据你的研究主题来定)、笔、纪念品(可选)、照相机(可选,如需合影)、现金(可选,如需报销用户的交通费用)和摄像机(可选)。

卡片除了包括信息的名称和描述外,最好再加注一个唯一的编号,这样记录数据时只要记录编号即可。

测试时的流程

  1. 主持人自我介绍

    主持人应对本次活动的目的、内容及时间安排做个简要的介绍。值得注意的是,由于大多数用户都没有接触过卡片分类测试,再加上对于陌生环境的不适,难免会产生焦躁感,因此对于卡片分类的形式和流程可以说明一下,帮助用户放松情绪。

  2. 请用户签署保密协议及基本信息表

    一般来说用户不会对保密协议产生异议的,但如果有的话,要当场对异议及处理方式达成共识,并将结果明确记录在协议中。比如,我曾遇到过一个用户,他不喜欢被拍照或摄像,那么这样的意见要补充在协议中。总之,必须让用户明白:签署了协议,就等于同意我们对其个人资料和测试过程中产生的任何内容有使用权。

  3. 用户自我介绍,包括姓名,网上购物经验和问题等

    这是了解用户、缓和现场紧张气氛的好办法,在说说笑笑间,用户和主持人、用户和用户之间的距离就拉近了。这个阶段主要注意对聊天内容的引导(以获得用户资料),以及对时间的控制。

  4. 主持人发放卡片,要用户先看看卡片上的定义,确保每个人对定义没有误解或歧义

    一定要尽量保证用户对卡片的内容有一致且准确的理解,否则数据的有效性就会大打折扣。我在一次测试时发现,对于同一个专业术语(“支付宝卡通”),7个人中居然有4种理解!

  5. 主持人讲解规则,要求用户进行第一次分类

    理论上讲,分类时所遵循的顺序既可以是自顶向下,即先请用户分出尽可能少的类,然后再在每一个类别内细分;也可以自下向上,即分出很多类然后归纳。但从实际情况来看,这两种顺序会对结果产生一定的影响:用户多半不喜欢自顶向下的方法,表现为不愿意进行细分。因此在后面几场测试中,我采用了自下向上的方法,效果要好一些。

    当然这种现象所反映出来的观点可能是不准的,毕竟我测试的样本数量有限。对于这点欢迎各位斧正 :)

    用户在摆放卡片时,不要对其进行任何干扰,也不要让用户间交流。完成后,将事先准备好便签纸和笔发放给每个人,请他们各自为每一个分类命名并记录。

  6. 用户交流、分享

    所有人都完成后便请用户一一进行的交流和分享,要求用户清楚地说明:1)类别数量及名称;2)每类所包含的卡片;3)分类的标准。

    期间主持人要尽量挖掘用户内在的想法,鼓励用户间的讨论;记录员则要快速记录分类结果和用户讨论的内容。

  7. 主持人讲解规则,要求用户进行第二次分类

  8. 用户交流、分享

    进行到这里时用户会产生疲劳感,有条件的话可以提供一些水果和零食,否则就要看主持人的现场控制能力了,呵呵。

  9. 总结及感谢,发放纪念品

  10. 送客!

测试后的数据分析

很遗憾,由于时间的关系,数据分析这块是同事帮我做的,所以还是等她做完了以后再分享吧。 不过我倒是有个小工具要提一下,这就是“卡片分类测试助手”。

这是我编写的一个用于记录和管理卡片分类测试数据的小工具,目前的版本是alpha2。为了能在卡片分类测试结束后,更方便的统计和管理得到的数据,我花了一点时间制作了这个小小的系统。它可以帮助记录所有在卡片分类测试中得到的数据,无论是卡片分类的研究主题、进行场次、用户资料还是分类结果,都可以被分门别类地清晰记录。此外,它还包含了一个简单的报表功能,用以直观地查看分类测试结果。

四谈Mac OS X Dock

| 2 条评论 2007-11-15 17:38:16

我曾写过3篇关于dock的文章,它们是:

  1. OSX在UI上的问题-Dock和Expose

  2. Ars Technica对OSX中Dock可用性的评论

  3. 三谈Mac OS X中Dock的设计

看到AppleInsider上的文章后,我忍不住写下了这第四篇,主要在于驳斥原作者的部分观点。

原作提到:

"将开始菜单分隔成一个个长方形区域,并在这些区域里显示打开的窗口。这一做法明显的缺点就是空间有限。如果同时打开了很多程序的话,狭窄的任务栏并不能标明哪些正在运行。这种横向的长条很难反映打开了多个窗口的同一个程序。也没有办法缩放任务栏中图标的大小。"

我实在搞不懂写这段话时作者是怎么想的!因为

1、对于任务栏或者dock来说,空间占用是一个共同的弊病。比起Windows上的任务栏,OS X上的dock在空间占用上有过之而无不及(减小dock尺寸?你觉得点击上面的图标方便吗?);

2、对于对当前所运行程序的标记,Windows的设计要远好于OS X。这是因为Windows的任务栏仅用于显示和操作已打开的程序/窗口,你可以在这些程序间迅速的切换。如果想启动新的程序,开始菜单、快速启动和桌面快捷方式都是很好的途径,精心的设计一下布局(如下图中我的方案),你可以获得很高的操作效率;但是在OS X上,dock在标明当前运行的程序、以及帮助你在其中切换时会让人发疯。dock上包含了所有的图标,无论是否正在运行,从那些让人眼花缭乱的图标中找到你想要的并不是件轻松的事儿,标识当前运行程序的黑色三角一点都不明显(最新的Leopard修改成了更不明显的),图标的位置也是随着dock上程序/窗口的打开情况而变化,万一点错了你就惨了:慢慢地等着新程序启动完再把它关了吧。现在你知道dock的设计有多糟了;

对于表现一个程序的多个窗口,Windows的任务栏和OS X的dock都没有好的设计。但原作者的批评是莫名其妙的,因为dock图标一样没办法反映同一个程序的多个窗口;

对于任务栏上图标的缩放。我不知道为什么要缩放。当然dock可以缩放,可你不能说飞机会飞我就偏要轮船也会飞。

原作提到:

"启动一个程序后,快速启动没有任何变化;它既没有标明此程序处于运行状态,和这个程序的窗口也没有任何关系。"

快速启动不是dock!原作者的逻辑思维有问题,难道在OS X的桌面上通过快捷方式(OS X上叫“替身”)启动程序后,还要求这个快捷方式像dock一样响应?!

原作提到:

"快速启动的主要问题是,它和任务栏抢占共同的空间。快速启动中显示越多图标,就意味着任务栏上显示当前窗口的空间越小。只有同时开3个窗口的用户才不会遇到这个问题,这也是XP Home默认开启快速启动的原因。"

我同意抢占空间的说法,不过dock同样存在空间占用和应用性冲突的两难问题。

原作提到:

"(在Vista中)任务栏上的任务可以弹出一个预览窗口,但这需要把鼠标放在每个任务栏上面。设想过这些预览直接就在那里,一眼就能看见而不需要鼠标操作?那就是5年前Mac OS X的dock。"

如果能在某些功能上把dock的可用性做得像任务栏一样,此观点还有可取之处;否则首先回答我一个问题:任务栏的发展目标是dock吗?

总的来说,这篇文章的原作者完全是站在dock的角度来评价任务栏,欠缺公允。

------------------------

一些评论者的发言:

mrjoec123:

"I never use the Dock for minimizing windows. Talk about clutter. Plus, it makes all your app icons moving targets. This is also why I keep just about all the apps I commonly use on the Dock itself, instead of hidden in an Applications folder that I have to pop up. Every time I launch an app, the Dock goes nowhere. Much better for muscle memory."

TiAdiMundo:

"I think most of the people here don't see the concept and power of the Taskbar. It is the whole OS! You can reach everything from it and see always (!) every running task. This isn't the case with the Dock. So with the Taskbar it's easy to operate in full screen mode while you can switch to or start every other task. No need for an Exposé-like feature or additional menus.

And because the Taskbar is at the display's border (like the Dock), it doesn't matter how tall the buttons are (Fitt's law!). Scaling only the button's width is very smart to use the space in an optimal way.

With Vista there is now a very good hierarchical structure to display information:

1: the icon shows what program is running

2: the title shows which document a button represent (if there are multiple windows open from the same program. Titles are in the format: "document name - app name")

3: the thumbnails show a small version of the window (by hover over the button)

And one very useful thing about the Taskbar is, that you can minimize a window by just click the equivalent button a second time.

For me, the Dock (and the window management on OS X in general) is the most important reason, why I will not switch over to Mac. My hope was, that Apple would improve the behaviour of the Dock with Leopard but instead they just put more features on top of it (like Exposé before).

The Dock's behaviour is too realistic (> docking) compared with the (IMO) powerful concept of window entities in the Taskbar.

Think of what would happen, if Apple would replace the Tabs in Safari with a Dock-like bar?! The Taskbar in Windows is like a Tabbar for the OS."

jQuery的Ajax在特定版本的IE下执行失败

| 3 条评论 2007-08-27 15:49:01

最近一直在用CakePHPjQuery做东西,不亦乐乎。昨天突然发现在版本号为6.0.2900.2180.xpsp_sp2_gdr.070227-2254的IE上,jQuery内建的Ajax功能无法使用,用ajaxError这个callback可以捕捉到相关的错误,IE给出的提示是”对象不支持此属性或方法”。 Google了一阵子发现我所遇到的情况并非个案,以下是一些相关的讨论: 其中第四条来自于jQuery的Trac,原作者直接提到了这一问题,可惜处理结果居然是”won’t fix”(不会修正)。 诸位有什么好办法?

关于表单可用性的一些资料和想法二:别具一格的布局和愉悦的交互

| 1 条评论 2007-07-02 14:41:01

最近又发现了两个优秀的表单设计,虽然其中的理念都算不上新鲜,但仍然值得拿出来探讨一下,因为类似的设计确实不太常见。

第一个是我在一个名为“Sandvox”的软件中见到的(如下图)。这是一个购买软件授权的表单,表单项包括“版本”、“用户数量”、“优惠券代码”和“购买”的一些选项。现有大部分的表单设计都是表单项纵向排列,表单项中的元素横向排列;但这个表单却反其道而行之,并且在表单项之间以线条来分隔,不仅非常的清晰,而且节省了大量空间,给人以耳目一些的感觉。此外,这个表单在操作上从左向右的顺序也和上面注册的操作相符,逻技关系非常清楚和统一。

第二个则来源于Zoomr这个类似Flickr的照片分享网站。在Flickr莫名其妙地被GFW封锁以后,我就不得不忍痛放弃上面的照片,开始寻找替代品。注册Zoomr的过程是非常愉悦的,这在很大程度上要归功于其优秀的注册表单设计(如下图)。

首先,页面非常干净清爽,内容少,看起来不累,也就是所谓的认知负担低;

其次,表单项的标签和输入框的位置恰到好处,视线遵循由上及下的顺序;

再次,也是这个设计的最大亮点,就是输入框右面的提示信息-它们是让我心情愉悦的根源!想想看,填表本来就是很枯燥无味的过程,但如果你每完成一项,都有人在旁边鼓励你、表扬你,你会有怎样的感受?更别说那个绿色的对号图标让人感觉十分顺畅(绿色常常代表通过,就像交通灯一样,不是吗)!

最后,没有恼人的校验码输入过程。校验码是我填表时最头疼的部分之一,如果单单是数字还好,最怕就是那种包括了大小写字母和数字的长长的看不清楚的一串,还不知道到底是不是大小写敏感的设计(比如无比弱智的北京奥运会门票预定网站提供的注册表单)。当然有些网站在这个部分上处理的不错,给我印象比较深的是Digg,它会对要求输入校验码表示歉意(如下图),至少态度上很诚恳,能够让不耐烦的用户产生一丝怜悯和同情。

以前的文章:《关于表单可用性的一些资料和想法一:标签和输入框的位置

表现事物间层级关系的几种形式

| 0 条评论 2007-06-25 15:29:41

在UI设计中,经常要表现事物之间的层级关系,如"国家-省份-城市-乡镇"这样的关系,我大概总结了一下目前已有的表现方式。

一、连动菜单

连动菜单大体有两种实现方式。一是在页面载入时一次性把所有相关的数据读取出来,然后通过Javascript在客户端连动;二是借助Ajax技术,当上级菜单的项目被选择好后,再在后台读取下级菜单项的内容。

连动菜单的优点在于占用的空间较少,技术实现相对简单,使用上比较广泛,因此从操作习惯上讲,用户更容易接受一些。其缺点也十分明显:

  1. 由以前的论述可知,下拉菜单是非常吸引眼球的表单元素。为了表现多层关系,在表单中过多的使用下拉菜单会在一定程度上削弱其它界面元素的重要性;

  2. 连动菜单仅能表现层级关系本身,而很难表现每一层的属性和内容。比如我想对每一层进行某种操作,或者显示某层下面大量的内容,连动菜单就很难做到;

  3. 无论是使用纯粹的JS,还是借助Ajax技术,都在可用性上存在潜在的问题。在层次较多的情况下,前者的实现效率很难保证;后者则常常出现响应延迟的问题。

二、浏览视图

浏览视图是Mac OS X中组织和管理项目的一大特色,其优点是用户对操作流程中做出的选择较为清楚,并且较好的表现了上下级的逻辑关系,淘宝网采用了类似的设计(如下图)。但 当下级层次的数量无法事先确定时,采用这种设计会迫使用户界面横向拉伸(就像OS X中的一样),这不仅会使得用户界面的尺寸变得很宽-甚至超出了屏幕的范围,还造成了用户视觉焦点的跳跃性运动,很容易造成视觉疲劳,而且这种动态的横向 伸展还使得用户很难定位之前选择的目标。

简言之,个人认为使用浏览视图时一定要谨慎考虑,避免出现上文中提到的问题。

三、标签页

标签页大概是最常见的一种表现层级关系的形式了。在一个层级关系无比复杂的系统中,设计合理的标签页可以在很大程度上解决恼人的用户"迷路"问题。可惜我经常在网上看到理解不了的、貌似是标签的东西……

四、列表视图

这一设计也是OS X中的一大特色(当然你也可以理解为这是"树状结构"的另一种表现形式),目前在网页上还不多见,印象中只有Yahoo!在其UI Library有所引入

理解和分析虚拟社区中的行为

| 0 条评论 2007-06-04 19:10:15

这篇blog是去年写的,一直在草稿箱里面躺着,估计我也不会继续把它写完了,索性贴出来吧。 读书笔记的第二篇:Understanding and analysing activity and learning in virtual communities(F. Henri & B. Pudelko,2003)。 研究目的:提出虚拟社区(以下简称VC)的四种类型,观察、分析和评估在VC中的行为和学习过程。 理论基础:社会学习理论(social learning theory,Wenger,1998) 其它记录:   1、传统理论认为社区的概念必须与以下两方面相联系:(a)a common physical space;(b)a history sharing。在这两个因素之上建立着复杂的社会关系(Breton,1995;Weinreich,1997);   2、VC在存在性和扮演一个社会化的角色方面可以达到真实社区同样的程度(Rheingold,1993);   3、对participation的定义:“the social experience of living in the world in terms of membership in social communities and active involvement in social enterprises”

关于

丁宇(Felix Ding),电脑Geek,狂热的爱书和爱乐分子。现在在Idean做用户体验设计咨询方面的工作。咨询Email: 。注:1)请先自我介绍;2)请确保你先看过“提问的艺术”。

订阅到RSS