CS巴别塔(1)

所有的触屏滑动手势都做错了

Posted in Uncategorized by Kenny Yuan on 2015/01/23

这次不是标题党,是他们真的都做错了

滑动返回、滑动删除这一类的横向滑动手势比想像中的难用,观察一下大量的非GEEK用户就能发现,这个手势的成功率很低。其实,哪怕GEEK们也不能保证每次滑动操作都成功,不信的话,你不经意地滑几次试试。

所以这里要重新叙述一下我的一个老观点:滑动的方向不应该由最初的几个触摸事件的运动方向来决定,而是应该学习用户的习惯来决定。说到实现的话,可以是观察用户习惯然后硬编码到源代码中,也可以用机器学习的方式。

具体举例来说,如果我想横向滑动,但不小心在最初的2毫米是斜向上45度的——于是,无论我后面的滑动操作横向滑了多远(比如5厘米),手势检测过程也会把这个识别成为竖向的滚动,而不是横向的滑动返回。

虽然这问题主要表现在横向滑动上,但其实不只是横向滑动有问题,是滑动的方向决策有问题。

所以,你是去反复教育用户去接受你的严格假定,还是去接受用户的输入同时改进一下手势识别的算法?

(不要跟我说实现有难度,本人程序员,并非可被随意忽悠的设计师。而且很多年前就已经实现过延迟决定滑动方向的手势检测状态机)

Advertisements
Tagged with: , ,

习惯养成

Posted in Uncategorized by Kenny Yuan on 2014/05/28

过去的网页都设计得挺干净。根据眼球跟踪仪统计显示,用户喜欢先看标题,就跟看报纸头条大标题似的。其实吧,这个习惯,哪怕没有仪器的统计数据,也容易猜得出来……

然后,banner广告把这地方占据了。

再然后,用户们就被训练得不看那个最显眼的、一定是广告的、叫做banner的东西了……

Banner这样的黄金地段失去了价值,逼着网站不得不开发新增长点。仔细想一想,用户喜欢看正文环绕的插图,这也是不用仪器的跟踪数据来证明就能想象得到。于是,插图式的广告就出现了

再于是,用户们就被训练得不看正文环绕的那个特显眼的方块了……哪怕你用#ff0000和#ffff00做背景色来交替闪也不行!

再后来微软的Windows/MSN Messenger开始流行,那个动画的小窗口,从屏幕右下角“长”出来,伴随着一声“咚”的声音,让人很难不注意它,不愧为一种提醒用户的好方式……然后,网站就在右下角弹小窗广告了(夸张一些的,在广告小窗上会给你一个关闭按钮,点了之后,还会先播放一个动画广告然后才缩起来——都不让用户完全关闭)

很快,用户们对这种动画弹小窗也开始麻木了……

形势很严峻,下一步要怎么往用户眼前塞他们不想看的东西?很自然地,有人想到了“新版”IE加了一个黄色的警告条,这个黄色的条还会闪一下蓝色……对!就是它了!又是一个用户会注意的地方……广告!广告!More广告!!!

于是用户们又开始对这个黄色的警告条免疫了……

……

有一天,我突然发现一些下载网站的诱骗链接/按钮都没有了,整个网页上下滚动了三遍,发现只有一个孤零零的、大大的绿色下载按钮,我却不敢点……

P.S. 观察某些移动APP用户,已经学会了新的习惯(“操作性条件反射”)——在移动APP中,所有弹出的非全屏界面,坚决不点那个显眼的彩色大按钮,专点小个的灰色按钮…………什么?你说按钮上面的文字?谁喜欢去仔细读啊……

Tagged with: ,

想象力和UX

Posted in Uncategorized by Kenny Yuan on 2014/05/23

人类的想象力往往没有那么强,了解一些历史的人,应该不会对这个结论感到意外。不多做说明和论证,上一个图。

高大上的智能手表

回到UX上来说,我认为这个结论仍然是成立的。于是就有了一个类似的判断:那些职业做UX咨询/设计的人,往往不能设计出超越技术限制的UX。

(在这里插个段子:有个朋友做UX/UI设计时,总要来咨询我,问“这样的功能做得到么”。有时候我会写一些简要的说明,给出程序实现的思路。为什么非要这样来问我呢?因为他们公司的程序员经常会用“这个在技术上办不到”来拒绝UI上的更改)

想要超越现有模式的UX革新,还是要靠技术帮来做领路人,影响力大的比如Douglas Engelbart,影响力小的比如Fingerworks。

无法超越技术限制的职业UX咨询师,一个很典型的例子就是Jakob Nielsen。

哪怕不是升级换代式的革新,仅仅是利用现有的技术,那些专做UX的职业人士的表现,也相当令人失望,比如在我看来,现有的touch HCI还远远没有开发出它的潜力,这个观点我也在多个不同场合表达过,也有相当多的具体例子可供说明。其实,这个情况是有解的,需要的是真正的合作,需要UX和Coding两方坐在一起,抛下一切固有的思维包袱的重新来过。

(上面段落中的最后一句,我没有强有力的证明。但是我曾经同时以两种身份,做过一些个人项目和研究,对这种模式的潜力有充分的信心)

Tagged with: ,

论动画的设计

Posted in Uncategorized by Kenny Yuan on 2014/01/08

标题仍然是开了一个小玩笑,不过倒也不是瞎说。

这年头大家都在乎动画了,大约能总结以下几点:

1、样式是不是好看;

2、效果是不是让人感觉舒适、愉悦(最好不要带来任何不适感);

3、总量的控制,不要给“正事儿”捣乱;

4、要有一个统一合理的隐喻;

然后下面呢,就是我的私货了,也是我一直想推广的理念(可惜没有人买帐啊)。

A、动画不能是“死”的。不能一播放就变成了“开弓没有回头箭”,比如iPhone屏幕要休眠了,会有一个变黑的动画,大约1秒多吧,如果用户发现了,想打断这个过程,会去屏幕上点点划划想“挽救”,但现在的设计是不管用户输入的,必定要去休眠——“朕意已决,无需多言”。

另一个例子是弹出的对话框,这个动画很慢,在动画还没结束的时候,反应快的用户基本上已经知道要去点哪个按钮了(人类强大的模式识别能力),但是动画中的元素是“死”的,那些按钮是不能点击的,于是用户会感觉明明点击了,但是没有效果(微吃是一个Usability问题)。

再举一个电子书翻页的例子,多数电子书阅读器的翻页动画是必须要看的,不看完动画不能翻下一页(或上一页)……说到这里,你可以感受一下想连续翻10页,或者翻错了一页想快速翻回去时的心情……

B、动画不能是单模式的。单模式动画会让人感觉很过时,很不“怀申”。单模式的例子:整个动画的画面一起滚动/平移,整个动画的画面整体缩放。更好的动画的必要条件是组成元素的运动轨迹并不一致但又有规律可循(分不清必要条件和充分条件的请优雅地transform and roll out)。

C、不能带来illusion。这其实是一个底线,但常常会被打破。有些是设计上的问题,比如我原来提到过的虚拟键盘设计造成了Hermann grid illusion。其实实体键盘也有,比如苹果家的银底黑键帽。或者设计没有严重问题,是动画本身的illusion,比如有一个大面积的网格对象在滚动,如果它的网格元素的个体识别度不高,又赶上了驻波,就会造成反方向倒退的假像(想想电影中的车轮)。

(未完待续)

P.S. 说“未完待续”有点儿显得自己还没想好似的,我还是试着说一句“临时有事,回头再接着整理贴上来”吧,这样显得自己准备充足,嘻嘻……

Tagged with: , ,

说说用户界面那些事——鸣雷篇

Posted in Uncategorized by Kenny Yuan on 2012/01/10

聪明的一休哥片段

一休哥提问:这些界面设计有什么共同之处?

图像

小叶子回答:So called “Hermann Grid Illusion”

参考:

Tagged with: , ,

说说用户界面那些事儿-银杏篇

Posted in Uncategorized by Kenny Yuan on 2010/09/19

汽车驾驶员需要专注,肯定不能边开车边看电影——就连打电话、发短信造成的事故都挺高发的,更别提电影了,这是在NHTSA有数据可查的。所以车载系统的屏幕,为了安全,最好也只显示枯燥的导航地图。但是乘客们不这样想,乘客们会想要利用车载系统来娱乐,比如看看电视、放放电影什么的。无奈安全第一,于是在常见的设计方案中,车载系统会“贴心地”在行驶中关闭娱乐功能,只允许使用地图功能。

但这个方案并不怎么高明:除了专业司机,很少有人会坐在停驶的车上看几小时的电影,而行驶途中的乘客则是最无聊的——跑长途时,行车几个小时太平常不过了,连续几天每天跑十个钟头的也很常见,就说在北京城内,堵俩钟头也算稀松平常的——这就让用户花高价买来的车载娱乐系统成了摆设(什么QNX什么WINCE的高科技RTOS,都是骗银滴)。这时候,可能有些负责任的厂商就会开始教育用户了:“just don’t sit in that spot——我们不是提供了后座上的车载娱乐系统了么?您倒是坐后座上去啊?”于是,当两人旅行的时候,如果乘客们不想在车上无聊,就会发生“妻离子散、劳燕分飞、两地分居、君在奔驰头我坐奥迪尾”的问题。而且因为无人陪同,驾驶员更容易疲倦,也就有可能造成更高的事故率——那可真是“撒手人寰、驾鹤西游、尘归尘土归土、生死相隔解愁肠”了。

在我往下接着侃之前,请读者您花10分钟细细考虑一下这些场景,并试着找一找技术上的解决方案……

梅赛德斯在08年发布了一项名为SplitView的技术(官方中文名称为“分屏视图”,是联合BOSCH做出来的),请看视频:http://www.5min.com/Video/Mercedes-Benz-SplitView-Tech-Review-259734353

大概地解释一下:司机在左边,看到的画面是导航地图;乘客在右边,看到的画面是电影。电影的声音可以外放(比如演唱会之类的还是可以让驾驶员听听的),或者也可以将声音全部输送到乘客的无线耳机上。所有的中控台按纽都是给驾驶员用的,控制的是导航画面等功能。乘客使用一个独立的无线遥控器来控制娱乐功能。嗯……遥控器?

Remote Click

Remote Click

我想,看过了视频之后,关于这个系统的优劣,聪明的读者你一定已经有所体会,我就不多评价了。这个系统的原理也很简单:从像素上来讲,那个显示屏是“双份”的,所以画面都是同时显示的(并非分时)。只不过两份画面被分别限制了可视角度,估计是利用了裸眼3D之类的技术,但是设定了不同的研发目标而已。

本文没有末尾的总结,因为读者们总是最聪明的 🙂

Mercedes Benz Splitview官方图

Mercedes Benz Splitview官方图

Ctrl + X, Ctrl +S; Ctrl +X, Ctrl + C …

Tagged with: , ,

说说用户界面那些事儿(第三部分)

Posted in Uncategorized by Kenny Yuan on 2010/09/12

这真是一个最好的时代,也是一个最坏的时代:优秀的用户界面全都相似,差劲的用户界面却各有千秋——但无论如何,一个优秀的计算设备必须要有一个优秀的用户界面,这是放之四海皆准的事实。好的用户界面是设备的生命之光、欲望之火种源,同时也是设备的罪恶……

——哦,对不起,我不是文学青年,不能引用太多的“名著”开头,这部分文章里,我得继续讲科学定律……截止到目前为止,本系列文章仍然在介绍小学文化程度的基础知识,没有侃大山,也就没有切题(因为题目叫《说说用户界面那些事儿》,典型的侃-able title)。所以我尽量压缩内容,尝试在本篇内结束这些没人爱看的基础知识介绍,从下篇开侃。

嗯,虽然我很想压缩内容,但是有一个新的变化:我终于又回归到了机械键盘一族(Cherry的青轴)。虽然在twitter上我不是像某些同学那样不管什么样的鸡毛蒜皮的小事都要不停地推啊推啊的那种话痨但是有了这块超级好用的每按一次键就发出清脆的响声让人感觉打起字来就像弹钢琴时用上了节拍器一样合谐的Cherry机械键盘之后我发现我打字的欲望开始变得异常地强烈了起来甚至达到了一句话竟然可以写出上百个字都没有标点符号的程度而且整个句子都只是没多少意义的文字而已似乎只是为了打字而打字这一个单纯的目的而已了——嗯,话说小时候写作文的时候也是这样凑字数的。

——常看网络小说的你一定知道的:以上段落作废……(并非只有起点的大大们才能享有这种权利)

Cherry青轴机械键盘

Cherry青轴机械键盘


(2.3) Hick-Hyman Law (希克海曼定律)

常有脑残批评我的思想太阴暗,为什么不忽略那些负面的东西,只看那些伟光正的。从这个角度来说的话,此系列的前两篇文章恐怕也太“负面”了。所以我来写点光明的、令人振奋的东西,同样的,它还是科学定律:

——嗯,以上段落仍旧作废。下面我来介绍一个科学定律:Hick-Hyman Law (希克海曼定律)。

T = b * log2 (N + 1)

其中,N是选项个数,b是可以用经验法测量的常量,T是做出选择所需要的时间。

这个定律说明,当选项的个数以线性增长时,在若干个选项中作出选择所需要的时间是以对数曲线增长的。换句话说,选项的数目在快速增长的时候,做出选择所需要的时间只是在慢慢地增长。假如选项的数目增长了250倍,所需的时间也仅仅是增长了8倍左右。在前面一句多余的解释之外,还有一个多余的图表用来解释:

从图中我们可以看出,如果你弄了许多的菜单项出来,用户肯定会受到困扰,操作时间会变长。但是操作时间的增长数量,和菜单项数目的增长数量相比,基本上可以无视了。

Maya的PieMenu里有很多选项


关于这个定律,其实还有一些可以深入的话题,还可以扯到认知科学和神经网络。但我一来懂得不多,二来不想浪费太多篇幅,所以就到此打住——嗯,有话痨趋势的我在此不得不多说一句,研究HCI一定要懂一些Cognitive Sciences(认知科学),不用精通但是怎么也得懂一些基础。比如:Change Blindness, Inattention Blindness和IOR之类的……


(2.4) Power Law of Practice (实践的幂定律)

古人云,常言道,俗话说,曾子曰,Confucius he say:“包子有肉不在摺儿上”……哦,错了,应该是“一回生、二回熟”(所以,摺上有肉的包子不能只蒸一回,嘻嘻)

——以上段落作废。

我们都有过这样的体会,在最开始做一件事情的时候,往往需要集中全部精力,但往往还做得不够好,比如骑自行车/学开车,或者解数独,或者打地鼠,或者玩Super Mario Bro——还记得你第一次上手红白机的时候么?在控制Mario向前跳跃的时候,你有没有把手柄当成了WII手柄来用?后来当你可以不用Konami Code也能全八面迅速通关的时候,你肯定不会再把游戏机从桌子上扯下来了吧?

Super Mario Bro


上上下下左右左右前前后后


Power Law of Practice (实践的幂定律)

T = a * N ^ (-b)

其中,N是练习的次数,T是第N次的完成时间,a和b是常数。

这个定律的意思是:随着练习次数的增加,完成相同任务所需要的时间是指数下降的,参见下图:


有了这样的一条定律,对我们来说无疑又是一大利好消息——哪怕一个任务设计得很糟糕、很耗时也不用太担心,只要用户多加练习,那么用户完成任务的时间就会大幅下降,而且是迅速地大幅度下降。

如果你想验一下Power Law of Practice,可以先找一个秒表(或用手机功能/手机App),开始计时,然后清空你的浏览器的内容缓存、所有保存的表单内容、所有保存的密码、所有的URL历史、所有的Cookie,然后记录下所用的时间。然后再重新开始并计算时间,如此重复若干次,然后画图。

如果你多注意观察,在以下这些电脑用户的身上也能观察到Power Law of Practice的效果:超市收银员、银行柜员、照相馆里PS一寸免冠照片的操作员、电脑城装机器的技术员……

虽然有Power Law of Practice的保驾护航,但是,我要说“但是”:一般在设计一个普通操作的时候,最好也不要超过3次鼠标点击。这并不是一个科学定律,只是一个经验公式;而且它也不是普适的,只是针对一般性的普通操作。举个例子来说:一个频繁更新的软件,如果在下载完更新包后,一定需要用户的操作才可以实施更新,那么,最好能让用户在三次鼠标点击之内完成这一次更新。(联想一下JRE Update/Adobe Update/iTunes Update/Windows Update,再对比一下Google Chrome这种不需要任何鼠标点击的)

嗯,接下来我的恭喜作为读者的你,看了我这么多枯燥的说教竟然还没有被吓跑,其实我还有心介绍一些更多的理论上的东西,比如GOMS/MTM之类的,但一来那只是一种测量方法,二来做科普时基本上无法夹带我的私货(嗯,开篇说过了,我自己在做的一个基于手势的HCI,暂定名为WheelUI),三来有许多有意思的东西如果不“先下手为强”,估计别人慢慢地就都知道了(那样子就无法完成ZB伟业了)……呵呵,你看我写了这么多理由,就是为了能够到此为止,点到为止,从些不再写知识点,继而进入侃大山的历史新篇章…… History became legend; legend became lenovo… until, when chance came, a new era had begun… And a brand new saga is being written…

谢谢观赏,下次再见!



00:00:25,469 --》 02:45:35,634
<font color="#ffff00"
反义:Sharon桶 盆泥
脚对:大妈 杀啦
世间粥:歪脖子的小马,不拉屎皮特



(以上是字幕组加上的一大堆乱七八糟的文字,我从来没有看懂它们的意义,请不要跨服务器追捕)






Tagged with: ,

说说用户界面那些事儿(第二部分)

Posted in Uncategorized by Kenny Yuan on 2010/06/29

(2.2) Steering law (转向定律)


书接上回……嗯,上回书说到:十位英雄正在青楼之上饮酒吃菜,忽听得“噔噔噔噔”有人上楼,直惊得十位英雄是苶呆呆发楞!要问来者何人?嘿嘿,我就是不说……

可Fork的岔口: http://en.wikipedia.org/wiki/Steering_law

在本章开始处,已经列出了即将要写的一些“定律”。我想好奇心强的人应该已经wiki+google过了。所以,如果在内容上本文无法胜出,那么就算白干了。嗯,多说一句:如果为此就故意在前面隐藏不写,也是没用的,因为wiki+google仍然会把这些“隐藏”的东西带给人们。所以关键还是content, content, content. (语感好的同学会知道这三个词应该怎么读)

Steering Law(转向定律)这个名字来源于汽车转向。根据中国特别色,可能用Handlebar Law(拐把定律)更合适一些——谁让我们是自行车大国呢?为了理解这个定律,设想你要通过一个又长又窄的隧道,对汽车来说这隧道是2米多宽(或者对自行车来说是两尺多宽),你敢用多快的速度通过呢?如果这隧道是20米宽,你敢用多快的速度通过呢?(注:关于速度/速率这样的名词问题,在这里就不细究了;另:一提到Steering就想到“外内外”的同学,请去找Stig切磋)

慢慢拖吧,撞坏了赔不起

慢慢拖吧,撞坏了赔不起


Steering Law在“隧道”为矩形的时候,其数学形式为

Steering定律: T = a + b * ( A / W )


其中的T是到达目标的时间,a和b还是常量,A是走过的路径的长度,W是矩形隧道的宽度。

Steering定律图解

Steering定律图解

(Steering定律还有一个通用的“计算器”形式,路径宽度用函数来描述,本文就不涉及了,还是矩形的好理解)


这个公式表明:路径越短,到达目标的时间就越短;隧道越宽,到达目标的时间就越短。联系前文的例子,这是符合生活经验和直觉的。

Steering定律是根据Fitts定律推导出来的。在应用Fitts定律分析的时候,如果对用户的输入所经过的2维空间上的路径有要求,就需要考虑Steering定律了,比如前面分析过的Pie Menu,就不能忽略Steering定律——Pie Menu项目的宽度 really matters(不过不能用矩形隧道的简化形式,呵呵)。


Steering Law实例分析1:神秘的三角区域

在此文中有一个很好的实例,我就直接给出链接了:http://www.scsblog.cn/articles/fittslaw.html (简体转贴版,底下有原文链接,懂繁体的可以去看原文)


Steering Law实例分析2:杯具的DataTip

Visual Stuio 2005的DataTip功能是一个不错的设计,当鼠标指针指向一个变量后,就会出现一个DataTip来显示它的内容,并且通过点击加号,还可以把变量的成员展开。这是个方便操作的好设计,但在某些情况下,它也会成为杯具,见下图(点击图片可以看100%全图):

谁能点到最左端那个加号

谁能点到最左端那个加号

想要点击加号,鼠标就只能横移,上下都不能出界太多。否则DataTip会被关闭,只能重头再来一次。虽然上图中的数据和变量是专门为了演示而编写的,但是在实际调试中,这样的超长DataTip也很常见。

应用Steering Law来分析,我们会发现这个“隧道”的宽度W太小了,如果增大宽度W,就可以使操作更方便。增加宽度的效果可以用下述实验来体验:在DataTip弹出之后,在DataTip上的任意位置点击鼠标右键弹出菜单,这时DataTip就会被“冻结”在屏幕上,然后我们就可以经过任意路径移动鼠标到加号处,此时的W是一个相当大的值(超过一个屏幕的高度)。

(注:DataTip的加号并不一定非要点击,用鼠标指向这个加号也能展开成员。减少点击次数也是一种提高易用性的方式,后面会有内容专门谈这个问题)


实例分析3:人人都恨滚动条

不管是用手,用笔,还是用鼠标,使用滚动条都是一件很不爽的事情。之所以这么说,是因为以下的这些原因,以垂直滚动条为例:

问题1:滚动条的水平宽度很小,从当前鼠标位置移动到垂直滚动条上,平均移动距离D大约是半个屏幕,而W则是非常小的一个值(20个像素以下)。按照Fitts定律,这样的移动,效率不高(对于最大化的窗口,如果屏幕的最右边也计入滚动条的区域,则会大大改观W值)。
问题2:很多人不知道滚动块是可以拖、滚动条的空白区是可以点的,他们只会点击两端标有箭头的按钮。这两个按钮很小,不好定位。如果当前视图在文档中占的比较很小,可拖动的滚动块也会非常地小(还是Fitts定律)。
问题3:对滚动块进行拖动的时候,如果在水平方向上鼠标位移大于5~6倍的滚动条宽度,滚动块就会跳回原来的位置。应用Steering Law来分析,宽度W虽然有所提高,但仍然不够大。
问题4:滚动条能指示视图在文档中的位置和比例,但无法提供与内容相关的滚动信息(嗯,Chrome的搜索结果指示算是一个特例)。当然这一条不是用Fitts/Steering定律来分析得到的。

(写这段文字的时候,我坐在办公室,听着四面八方传来的“哗哗哗”的滚轮的声音)

作为对比,我们来考查一下iPhone触摸屏上的滚动:不管是单指还是双指滚动,都是对几乎所有可视区域可用的。此时的W=屏幕宽度(或几乎等于屏幕高度——对于水平滚动)。如果你有iPhone,请回想一下这种操作或者直接体验一下,比如故意斜向滑动手指,来滚动重直内容(测试宽度W)。

图:iPhone滚动“条”,WP7的滚动“条”

(另:对于有索引的内容,一个可以操作的指示器会比滚动条更有优势,比如各种通讯录界面中的A-Z指示器)


虚拟的宽度W:辅助和宽容

让我们再回过头来考查Steering定律:汽车通过狭窄的隧道,速度肯定会降下来,可火车却能很快通过。这中间的区别当然不是因为火车司机不怕死,而是在于火车有铁轨,铁轨限制了火车的方向,不会让它“出轨”撞到墙上(再比如拓海的排水沟过弯)。

拓海的排水沟跑法

拓海的排水沟跑法

同样的道理,在绘图程序中,如果想用鼠标绘制一条水平直线(同样,不深究“直线”和“线段”这样的名词区别),相当于让鼠标指针通过一个高度为1像素的横向隧道。这种操作非常困难(用直尺比着鼠标都很难做到,不信你试)。所以在绘图程序中会提供一种“限制”功能,限制鼠标只能水平或者垂直运动(或者加上四个斜45度方向共计8个方向),这就相当于把汽车变成了有铁轨的火车来通过隧道。Photoshop移动物体时的Shift键限制也是同理。在分析Fitts定律时,我们认为屏幕边框代表了一个相当大的宽度W;同理,我们可以认为,在这些例子中Steering定律的隧道宽度W也是一个相当大的数字,所以最终时间T可以很小。


离开鼠标屏和触屏,在有实体的交互中,这种增大W的方式依然存在。汽车的人机交互界面一般称为HMI(人·机器接口)。在汽车的HMI中,也包括一些电子交互系统,比如Audi的MMI和Bimmer的iDrive,通过屏幕和旋钮/按键来进行交互。Lexus的Remote Touch用的则是力回馈控制杆和按钮。假设屏幕上有两个选项,那么你在拨动控制杆的时候,会感觉到控制杆不是可以连续搬动的,而是有两个很明显的“档位”;如果屏幕上有三个选项,那么就会有三个“档位”,以此类推。这种交互设计,通过“档位”的辅助,为运动轨迹增加了辅助(Steering定律的W),同时也增加了目标物体定位的宽容度(Fitts定律的W),最终使得用户能快速操作,并且不用集中全部精力在屏幕上,最终提高了驾驶安全性。

Lexus的Remote Touch

Lexus的Remote Touch

Lexus Remote Touch的Screen

Lexus Remote Touch的Screen


如果你认为这种带回馈的控制杆还不算实体交互,那么可以考虑一下汽车的换档杆:

手动换档杆

手动换档杆


不管是鼠标屏、触屏,还是刚买回家的新电器,对于同样的操作,熟手和新手的完成时间大相径庭(想想你的父母第一次用iPhone的时候误拨了多少次电话出去?或者你多久才教会他们用一件新电器?),各位看官,这——究竟是为何——呢?……嗯,欲知此中的规律,且听下回书——分解——


扩展阅读&扩展练习

上次写的内容,在结尾处扔了一堆扩展阅读和扩展练习,感觉有点像讲课了(要知道我很讨厌老师的——所以我这回装得像说书的)。所以,这次的文章取消这两部分——当然,我并没有拦着你使用大脑和google,对不?


更新关于触屏的触感:2011 CES上露面的TeslaTouch是一个伟大的发明,它的网站是:http://www.teslatouch.com/ 大约来说,它看起来是一个普通的触屏,但是能够在指定的区域提供指定的触感,开发人员可以将屏幕上的内容和屏幕的触感结合起来,有一个演示的例子:屏幕上显示的是结冰花的玻璃,当你的手在上面摸的时候,会有类似冰花的触感;你摸过的区域会显示为透明的玻璃,这时候再去摸这个区域,它就是玻璃的触感了——还记得iPhone上的iSteam程序么?很明显,这个冰花程序要比它cool多了:) 另外,那些靠马达震动的触屏,比起来简直就是XXXXX(省略140字)。最后多说一句,这个TeslaTouch的名字也揭示了它的原理,详见它官网中的PDF 🙂




Tagged with: , ,

说说用户界面那些事儿(第一部分)

Posted in Uncategorized by Kenny Yuan on 2010/06/24

(读者请跳过本段括号内的文字:经常来骂人的那位同学,您请回吧,每回都那么激动,别气坏了身体,要知道,这篇文章的ZB程度可是很严重的……)


第一章:可跳过不看的前言废话


之所以写这个文章,是因为最近在做一个基于手势的人机交互项目(自费的个人项目,暂定名为 #WheelUI)。


见过很多别人写的类似文章,都会讲自己“当年从低级到高级走过来的每一步”(往往还要提到ABC/XYZ等对新人来说很生疏的名词术语,外加感叹当时的条件有多艰苦),可我偏不愿意写那样的八股——我只想写一点可能对别人有用的知识、经验以及感悟,和一条可能的未来之路。


标题中使用UI而没有用GUI,是因为在通常的概念中,GUI一词和WIMP绑定得过于紧密。WIMP是指基于Window Icon Menu Pointer(窗口/图标/菜单/指针)的界面,这些东西是197x年在Xerox PARC搞出来的,在198x年苹果去挖了一批人做出了第一台Mac,之后微软也去挖了人搞出来Windows,后来Windows几乎一统江湖。不过近些年苹果又咸鱼翻身搞起了GUI的革命,主要武器就是Multi-Touch(多点触摸)。Multi-Touch和WIMP一样也不是苹果的原创,这两者的历史都可以追溯到197x年。以下是一些知识链接:


WIMP: http://en.wikipedia.org/wiki/WIMP_(computing) Please Note: P本来是Pointing Device,本文中我用了Pointer。
Multi-Touch in Wiki: http://en.wikipedia.org/wiki/Multi-touch
还有Bill Buxton写的一个综述: http://www.billbuxton.com/multitouchOverview.html
Bill Buxton也是Xerox PARC出身的,是Multi-Touch的先驱人物: http://en.wikipedia.org/wiki/Bill_Buxton
这里是他的专栏: http://www.businessweek.com/bios/Bill_Buxton.htm
从Market Value这个角度来说,Apple的咸鱼翻身相当成功:http://news.bbc.co.uk/2/hi/business/10168684.stm



早年的Apple MAC上的GUI

早年的Apple MAC上的GUI



Xerox Star 8010

比Apple更古老的GUI



多点触摸的用户界面可以直接用手指点被控目标,相比使用鼠标间接输入算是前进了一步,但总会有人不满足:“还有没有别的方式可以人机交互?”说到这里可能有些人已经明白,我要说的其实不是UI而是HCI,只不过是HCI这个词在中文圈子里没人青睐,为了让更多的人听明白只好改说UI。
HCI: http://en.wikipedia.org/wiki/Human-computer_interaction


本文就是想要说说用户界面HCI那些事儿。


注:关于上文中对苹果的创新的“贬低”,我想声明一下:口口相传的段子会把创新的“前传”全部剔除,只剩下一个孤独的英雄人物。想要了解更多?推荐去看一本叫做《创新的神话》的书,或者从google开始。另外还需要声明的是:将某项技术推广到全世界,同样是功劳大大地有,我一点我从不否认。



Xerox PARC外观

Xerox PARC外观

(图片注解:多年以后,当榨布丝和给慈站在行邢队的面前,肯定会想起当年他们参观Xerox PARC的那个下午。当时,PARC是一个……)



第二章:用户界面的科学定律(Laws of HCI)



作为正文的第一部分,一定要有一个好的开始。最近的CVPR2010上,有人用CV机器学习的方式来检阅论文质量,达到的效果是“以拒绝15%的正样本为代价,可以滤除一半的负样本”(http://dahuasky.spaces.live.com/Blog/cns!1AB3BC993DB84FD7!1168.entry)。为了能够看起来像一篇好文章,我打算在这一章要介绍几个科学定律,大致有以下内容:Fitts’s Law, Meyer’s Law, Steering Law, Law of Crossing, Hick’s Law, Power Law of Practice等。


(2.1) Fitts’ Law (费兹定律)


(友情提示:在此处可以fork,但欢迎继续阅读本节中的实例分析和后面的内容 http://en.wikipedia.org/wiki/Fitts’_law


通俗来讲,Fitts定律是用来计算在目标已知的情况下,直线移动鼠标指针到目标所需要的时间的定律,它的数学表示形式如下:

Fitts定律:T = a + b * log2 (D/W + 1)


其中T是完成移动所需要的时间,a和b是常量,D当前指针距离目标的距离,W是目标的宽度。或者更精确地来说:

图解Fitts's Law中的变量

图解Fitts's Law中的变量


T = 平均完成移动的时间
a = 启动设备需要的时间常量
b = 设备固有速率的一个时间常量
D = 当前指针位置到目标的中心位置的距离
W = 在移动方向上目标的长度,或者是判断指针是否已在物体上的宽容度(比如针对1像素的点,设计宽容度为5*5=25个点,这时水平移动的W=5)


Fitts不仅仅是对鼠标移动任务起作用。触摸屏/键盘/其它硬件等,只要涉及到人机界面和人的操控动作,都适用Fitts’ Law。


对于使用者来说,时间T越小表明当前的操作越快捷。时间T和很多因素有关,从数学式中不难看出它们的含义(请注意其中的线性/对数关系)。之所以说Fitts定律是科学定律,因为它提出了预测,并且有实验证伪的可能。在实际的实验中,Fitts定律和实验结果吻合得很好、很精确。


举一个最常见的例子来解析Fitts定律:如果想要关闭窗口,你需要把鼠标指针移动到窗口右上角的close按钮上(很显然这是在说“低级”的Win32 GUI):
a = 你用手去抓住鼠标的时间;或者:已经抓着鼠标的手,从静止状态启动进入到运动状态的时间;
b = 和鼠标速率反相关的时间系数,速率越高,时间系数b越小。
D = 当前的鼠标指针位置到close按钮的直线距离。距离越短移动得就越快(时间T就越小)。
W = 红色close按钮的size,一般是20多个像素见方。很明显它的个头越大越好找到(时间T也就越小)。


从上面这个鼠标指针的例子,我们也能发现Fitts定律的所存在的问题:
Fitts定律问题1:它只适用于单个直线方向上的时间计算;(2D空间上的后文后谈到)
Fitts定律问题2:在鼠标的应用研究中,如果有鼠标加速度,它就不适用了;
Fitts定律问题3:如果用户经过了多次训练,它也变得不适用了(下面有一个小节将要讨论这个问题)


在实际使用中,有许多人用下述方式来关闭已经最大化的窗口——他们用鼠标狠狠地向右上角一甩,之后鼠标指针就一定是位于屏幕的最右上角了,这个位置虽然看上去不在close按钮范围内,但是它仍然被视为在close按钮内部——如果考虑一个虚拟平面的话,其实这时候鼠标指针的位置早就在屏幕之外了,但因为屏幕实际空间有限,所以鼠标指针被限制到了屏幕右上角。此时Fitts定律仍然有效:只要将W视作非常大的一个值即可(甚至可以比屏幕还大),于是套用公式时会发现T值最终很小,这正好与实际情况相符。

虽然看上去鼠标没有在关闭按钮上,但实际上却可以关闭窗口

虽然看上去鼠标没有在关闭按钮上,但实际上却可以关闭窗口


根据Fitts定律,我们不难推出以下结论:


Fitts定律推论1:可操作元素(如图标)需要有合适的大小,太小的话操作会变慢(W变小,T就变大);
Fitts定律推论2:如果可操作元素布局合理,可以更迅速地操作,因为D变小,T就变小;
Fitts定律推论3:Popup菜单比窗口上方的下拉菜单好使,因为D变小,T就变小。(注:D并不仅仅是对指针来说的,如果为了弹出Popup菜单,需要另一手的配合运动,那就是另外一回事了——除非熟练掌握了键盘,否则另一只手的启动时间a往往是一个不小的数值)
Fitts定律推论4:屏幕的四个边缘和四个角落是非常容易找到的位置,比如在Win32下,最大化状态的窗口,其关闭按钮非常容易找到,就是因为它利用了屏幕角落(W变得很大,甚至超过了D,此时T会很小)。Mac的下拉菜单容易找到,也是同理。


应用Fitts定律分析Pie Menu


下面我们利用Fitts定律来考查一种设计:Pie Menu (http://en.wikipedia.org/wiki/Marking_menu)


Pie Menu也叫Radial Menu,它类似于右键弹出菜单,但是它的每个选项是一个扇形,最中间的“Pie Hole”(不是骂人)被用来直接关闭Pie Menu,参见下面的示意图:

Pie Menu示例

Pie Menu示例


或者一个实际的例子:

Pie Menu实例

Pie Menu实例


从Fitts定律的角度,我们很容易发现Pie Menu的优点:
Pie Menu优点1:移动到每个选项的时间都很短,因为D很小且W较大
Pie Menu优点2:经过处理,可以使W变得更大(超过屏幕大小),这样就更方便操作——只需要限制鼠标指针不得离开Pie Menu即可达到此效果(后面有个例子要说到这一点)
Pie Menu优点3:如果Pie Menu是误触发,关闭它的时间是接近零的常量


Pie Menu在实际中


(示意图)罗技的MouseWare驱动中的Pie Menu

(示意图)罗技的MouseWare驱动中的Pie Menu

后来版本的“Web风火轮”

后来版本的“Web风火轮”

第一个版本虽然是方的,不是Pie,但使用起来其实更方便:当鼠标中键(滚轮)按下的时候,会在当前鼠标位置显示3×3网格的的Pie Menu,鼠标位于正中央,点击中间的cell可以关闭Pie Menu。其它8个cells代表了8个功能,这8个方向非常容易区分,很难混淆。并且无论鼠标实际移动了多少距离,它都会被限制在这3×3的网格中,不会离开(这就使得公式中的W变得相当大)。

除了“第一次点击呼出,第二次点击执行”这样的两次点击的方式,这个Pie Menu还有如下的操作方式:如果鼠标中键按下但并未抬起,然后移动鼠标到相应的cell,此时再抬起鼠标,同样可以激活该cell代表的命令。整个过程变为:按下->移动(在某方向上移动任意距离)->抬起,一气呵成。


可以想像,如果右上角的cell的功能是关闭窗口,这个方式会比点击窗口上的关闭按钮要方便许多。后来版本的“Web风火轮”花哨了许多,但也变得不实用了,因为8方向的Pie Menu非常容易找到cell,而更多的方向则不那么好控制,毕竟在这时候的指针移动是2维的,而不仅仅是沿着一条限定好的直线进行(见前面的Fitts定律问题1)。本文后面的章节会谈到Steering Law,这个定律就是Fitts’ Law在二维平面上的形式。



文章内容已经很长了,先写到这里吧,待续 🙂





——————

注1:Fitts’ Law的标准译法不详,见过有一个人翻译成“费兹”,于是就这样写了。其文章的URL是:http://www.scsblog.cn/articles/fittslaw.html (简体转载本)。在这个文章里作者也举了一些例子。不过不如我的例子用得好,嘻嘻……


注2:还有一个Meyer’s Law也试图建立类似的模型:

Meyer定律:T = A + B * Sqrt (D/W)


其中:
T = 移动到目标的时间
D = 当前位置和目标的距离
W = 目标的宽度(或容忍度)
A 约为 -13 msec
B 约为 108 msec



扩展阅读

除去前文中已经给出的链接,下列URL同样推荐观看:

  1. 可视化的 Fitts定律 http://particletree.com/features/visualizing-fittss-law/
  2. Fitts定律的在线Demo http://fww.few.vu.nl/hci/interactive/fitts/
  3. Fitts’ Laws以及其它定律的简介 http://www.sapdesignguild.org/community/design/print_laws.asp
  4. CodingHorror Blog中对Fitts定律的介绍文章(注意其示意图中有标注错误) http://www.codinghorror.com/blog/2006/08/fitts-law-and-infinite-width.html
  5. 2000年MSDN的文章,简单用Fitts Law分析了Web元素 http://msdn.microsoft.com/en-us/library/ms993291.aspx
  6. Pie Menu http://www.piemenus.com/
  7. Pie Menu开源实例 http://sourceforge.net/projects/circledock/
  8. QT的一个Pie Menu粗糙实现 http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpiemenu/
  9. Pie Dock http://www.markusfisch.de/?PieDock
  10. JavaScript Pie Menu online demo http://www.markusfisch.de/downloads/PieDockDemo/ 源码在 http://www.markusfisch.de/downloads/PieDockDemo/PieMenu.js
  11. http://en.wikipedia.org/wiki/Marking_menu#External_links


扩展练习

  1. 分析Chrome浏览器在最大化状态下的标签页布局安排
  2. 寻找上文中没有提到的新视角,来比较Popup Menu和Pie Menu的优劣
  3. 用Fitts’ Law来分析鼠标手势的优劣
  4. 用Fitts’ Law来分析一个你认为设计得很好的网站,再分析一个你认为设计得很差的网站
  5. 这个平板杂志的概念设计中用到了Pie Menu,请分析它的优劣 http://berglondon.com/blog/2009/12/17/magplus/ (首页有视频和图像)
  6. 为这篇文章寻找理论基础 http://www.ifanr.com/3559 (《触不到的按钮》by ifanr 爱范儿 ♂专注于拇指设备的小众讨论)
  7. 用Fitts’ Law来分析Snap to Grid功能(或者allSnap小程序/winamp或gtalk等内建Snap功能的程序/Win7新增的窗口大小管理功能/Mac的窗口最合适尺寸功能/etc.)
  8. 用Fitts’ Law来分析Touch Pad和IBM小红点的优劣
  9. 分析这样的快捷键安排:Ctrl+X, Ctrl+C, Ctrl+V (为什么不用Ctrl+P来执行Paste?)
  10. 试着再举几个Fitts’ Law的应用实例(比如Anykey)
  11. 思考Fitts’ Law还有哪些不足/不适用的情形




Tagged with: , ,