HYXT Blog

we produce valuable software for K12.
clock November 27, 2008 14:19 by author Sky Jia (贾超)

By robert at 2008-11-11

原文地址: http://www.tianya8.net/zblog/post/90.html

  

1、关注用户任务

1.1、告诉我填写这个表单是做什么的?

如果这是一个注册表单,你需要告诉我注册能带给我什么;如果这是一个联系网站管理员的表单,你需要告诉我管理员将如何处理我的信息。

1.2、表单提交后,不要把我晾在一边

是的,还有很多用户在提交表单后不知所措,没有告诉我提交是否成功,或者提示我提交成功,然后就把我晾在某个地方。

虽然很喜欢mister-wong的界面风格,但是当我注册完了之后,我还是不知道该干什么。Errr...那么我现在要做的就是去收邮件吗?

1.3、如果表单较长,创建表单导航

在线购物是一个很好的例子,几乎所有的购物网站都建立了"挑选商品——查看详细信息——添加购物篮——支付——订单完成"或与之类似的全局导航。这样当用户在购物流程中并不会觉得自己是在一个很长的表单中,而只是为了一个特点的目标而进行的必要的点击。

即使是在一个表单里,如果表单包含多个任务,也应该将其分步骤进行。参考blogger.com的注册表单:

为每个任务添加说明。也许你需要了解一下fieldsetlegend属性。

2、必要、简单

2.1、自以为是技术约束

我实在不能理解要求用户"必须使用字母是数字组合作为密码"有何意义,尤其是在银行网站上,尽管我能理解这些网站对于安全性的考虑,但我仍然因此必须对于自己的常用密码进行适当的修改以适应要求,这由此产生另外一个问题——我经常忘记我的密码,比如adsense

2.2、站在你的用户角度想问题

我同意不能理解当我填写一个在线表单投诉问题,却要我留下电话号码和地址?OMG,你们的营销人员是第一天上班吗?如果我愿意电话联系,我难道看不到你们网站底部的800电话号码吗?

2.3"我不是很聪明,但也不会太笨"

对不起,我不需要你告诉我邮编是5位数字。

web2.0风潮吹遍神州大地的时候,我们的网站设计刮起了一股清新之分,与之相应的,表单设计却变成了冗余与累赘的试验田。看看163或者zhuaxia的注册表单,你就会明白什么叫过尤不及

2.4、如果使用email作为用户名,密码重复是否必要?

对于传统的注册表单而言,密码重复验证非常必要,理由很简单,对于非可见的输入,在没有其他取回密码的机制下,保证用户不会输入错误只能采用这种简单的验证机制。

但是现在很多新的互联网服务都开始采用email作为登录名,这就给表单设计提供了一个新的思考方式:当密码可以方便的重新取回,那么让人厌倦的密码重复验证是否还是必不可少?不少网站已经开始将repeat password从页面上去除了,下面是twitter的注册页面,何其清爽:

3、减少信息迷惑

3.1、用星号区别必填和选填项

尽管这已经是几乎所有guidelines的标准,仍然有很多网站并没有在意这一点。看看pownce的注册表单:

为什么不直接告诉我这些是必填的,一定要我点击提交后再告诉我这些非填不可

3.2、表单指引务必明确而直接,不要故弄玄虚,不是所有用户都有兴趣和你玩。

在我随机挑选测试的注册表单中,xing无疑是做的最糟糕的。糟糕的并非界面设计或代码结构,而是失败的本地化。

作为一个读过十几年语文并且一直在互联网里生活的网民,我对于这个表单的疑问实在太多了。

我可以理解xing原本是国外网站,但是你要在中文圈里混,至少也要适应一下姓在前名在后的中国传统吧。好吧,姑且认为要你为中文用户修改页面比较麻烦,那么能不能请你告诉我,what's the meaning of"城市(商务)" and "身份"

4、防止用户错误

4.1、与其在提交后检测,不如在提交前检测

可以参考3.1里的pownce的案例。事实上,现在推出的大多数web服务已经越来越多的使用javascript来进行表单验证,jqueryprototype等也都有很多好用的表单验证插件。

记得,用户最厌倦的情况之一就是:当提交表单后刷新页面,然后告诉他有信息填写不完整和错误,然后密码部分被清空要用户重新填写。

4.2、如果提供验证码,不要太过分

之前看"史上最强验证码 "时,其实颇觉理所当然,那些网站本身就是服务某些专业人士,因此问你Na2S4O6的中文名称是什么也无可厚非,那大门本来就是对俺们关闭的。但是你要做普罗大众如我辈的web服务,也忒考验俺辈的耐心了吧。

4.3、千万,千万,千万不要使用reset按钮

有什么理由要用户将刚刚填写的所有信息全部清空?

5、提供反馈

5.1、对于已完成的任务进行提示和鼓励

在适当的时候给用户一点掌声和鼓励会起到很大的效果,就行《使命召唤2》开始的那个苏联教官在我的射击课上跟我说的,"很好,就差一点了,继续训练吧"

对于网站而言,一个典雅而有效的例子就是用百分比来描述表单的完成率,你会发现用户有一种使用时的"洁癖",拒绝任何的不完美,因此当看到这个70%时,他会迫切的要将其变为100%,是的,你的目的达到了。

5.2、不要恐吓用户

对不起,用语夸张了点,但是大多用户都遇到过"可怕的"alert窗口的情况。当你提交一个表单,滴的一声弹出一个灰色窗口,"weqwew32673712323错误,请重新输入"

于是你心惊肉跳,哪里错了,哪里错了?友好一些的就告诉你Email地址填写不合法,不友好的就干脆就是一个只给程序员哥哥看的错误代码。俺的小命啊,只是填写一个表单吗,用得着这样吓俺幼小的心灵吗?


clock November 27, 2008 14:17 by author Sky Jia (贾超)

Article copyright by Jakob Nielsen

Jakob Nielsen版权所有

作者:Jakob Nielsen

译者:UCD翻译小组Link
原文地址:
http://www.useit.com/alertbox/20000416.html 

大在大部分网页表单中,移除重置按钮会有效提升可用性,同样的,取消按钮对网页的意义也不太大。

启发式的交互设计中最基本的一点是在任何情况下为用户提供"紧急出口",离开当前环境。撤销功能是最好的解决方法之一,基本原则只是告诉我们要提供撤销功能但并没有告诉我们怎么做。往往,不同的原则适用于不同的用户界面:

  • 在基于窗口环境的用户界面中,取消按钮可以让用户通过对对话框的操作,实现探索性的学习。相比较而言,你在老些的系统中下达了错误的命令往往意味着你将陷入绝境。
  • 在编辑系统中通常会有撤销命令来使文档回复到用户编辑之前的状态。有时,多级撤销和重复命令是很有用但又令人困扰的功能。

网页试图通过重置和取消按钮来复制以上特性,但用户往往更愿意通过浏览器的后退按钮来离开误入的页面。

不要使用重置按钮!

如果去掉所有重置按钮,网页将变为一片净土。这些按钮非但不能帮助用户,还可能伤害到他们。

重置功能会把用户输入到表单中的所有信息清除掉,但为什么用户要使用这样的功能呢?用户浏览网页的时候会在页面之间频繁转换,他们很少重复访问相同的表
单,因此,表单在呈现给用户的时候就是干干净净的。而当用户使用相同的进程重新访问一个表单时,编辑原有的数据往往比重新填写更便捷。

重置按钮会在以下三个方面伤害用户:

  • 最糟糕的问题是用户想点击提交却误点了重置,他们填写的信息将一下子付之东流。
  • 在表单底部提供两个按钮将混淆交互界面并让用户难以搞清下一步要做什么。用户会把一小部分时间浪费在浏览无用的按钮和决定哪一个才是该点的上面。
  • 当用户希望在表单中修改已经填写的信息时,面对额外的按钮会做出以下两个选择:
    • 在输入框中修改不正确的内容
    • 点击重置,在清空的输入框中重新填写内容

额外的选择会迫使用户进行额外的思考,而使用最佳的交互方式所节省的时间往往小于用户考虑决定使用最常用的方式所花费的时间。这将浪费用户一到两秒的时间来从中取舍,这也是尽量不要让用户选择的原因。(一秒钟听起来没什么了不起,但它意味着每年一亿美元左右的生产力浪费。)

让所有输入可撤销

去掉了重置按钮,我们有必要为用户提供其他的修改错误输入的方式。对于文本框和选择框来说,用户可以随时输入或恢复到最初的状态。

不幸的是,有些使用了非标准风格的单选框(radio button)和下拉菜单的表单并没有提供回到初始状态的选项,而这是网页设计的典型错误之一。往往,一旦用户选择了一个选项,就没有办法作出"什么都不
"的选择。永远别忘了在单选按钮和下拉菜单中加入明确的默认选项,否则你用户的麻烦就大了。(请参考
复选框和单选按钮设计的13条军规

例外:重复输入表单的重置按钮

当同时满足以下两个条件时,重置按钮将发挥它的作用:

  • 表单总是由一个用户反复填写
  • 填写的内容每次都有较大差异

即使某个用户经常使用一个表单,当填入的数据每次都很相似时重置按钮也不是十分必要的。在这种情况下编写原有的数据要比重新来过简单得多。

保守地使用取消按钮

网页并不像软件一样拥有对话框,而是一个用户游走于各个页面之间的导航环境。自从超文本导航成为用户的使用习惯,人们开始依赖后退按钮来逃离窘境。每当用户误入了不想进入的页面,他们就会自然而然地把鼠标放到后退按钮上。

因为后退是网页浏览中很常规的行为,单独的取消功能也就不是那么重要了。如果用户不喜欢当前的页面,可以肯定,后退按钮就要出场了。

当用户害怕自己提交了不想提交的信息时,可以为他们提供取消按钮,这样能够提供给他们比直接退出更安全的的感觉。

在需要多步填写的表单中用户会在超过一个页面上进行输入,这时取消按钮是个不错的选择,因为后退按钮不会撤销之前的输入。

当然,不能指望用户每次都点取消,应该有一个后端/后台逻辑来处理点击后退来中断多步输入的行为。额外的复杂性是我不推荐在网页中加入复杂应用的原因之一,更好的办法是使用另一种形式来实现。

购物车中的移除按钮

很有必要在购物车中添加特殊的按钮来帮助用户移除商品,我们无法知道用户是不是了解他们能够通过购买"0"件商品来取消购物。(但是反正这个小技巧也不影响其它用户,所以还是应该实现出来给懂的人用)

(作者:请参考拙作购物车的可用性,来了解更多表单设计中的规则)

到底什么时候使用用取消按钮就

Lisa Padol 问道:

"当你讨论取消和重置按钮时并没有提及停止(即在载入时停止页面)和刷新按钮,不是吗?

  

我觉得这不仅是可以接受的,也很必要为比如下载文件的过程加入取消按钮。"

她的假定完全正确,浏览器的"停止"按钮很好地加强了用户的控制权。而对于文件传输和其它一些得花好几秒钟的操作也应该这样做。设计师必须给Applet(网页上的Java应用)和

其它耗时的设计元素都加上停止功能。


clock November 27, 2008 14:16 by author Sky Jia (贾超)

Article copyright by Gabriel Svennerberg
Gabriel Svennerberg
版权所有
原作者:Gabriel Svennerberg;译者:
UCD翻译小组mysmth2003

原文网址:http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web-forms/ 

动作按钮存在于每个web表单的底端。它们太平常了,以至于我们甚至不能仔细思考实际怎么去设计它们。从一堆伟大的易用性思想和我自己的经验中可收集到的信息中,我想提出一套做法来让这种设计更高效些。

Position 位置

根据Jakob Nielsen(雅各布·尼尔森)的观点,按钮的规则并没有那么麻烦。每个位置都有它的优点和缺点。而重要的一点是一致,如有可能遵照GUI标准平台的规范。

在网络世界以外,也有GUI标准,问题是他们在不同的平台上是不同的。在Windows平台上,GUI规范表明"确认"应该在左侧,而"退出"在右侧。而在苹果平台下,恰恰相反。






web中,并没有固定的标准要求怎么去做,所以我们必须聪明地找出什么位置是最合适的。
Luke Wroblewski
(卢克·罗博乌斯奇)在《网络应用表单设计》一文中专注于这个话题的探索。他建议把首要动作"确定"放置在表单的左侧,次要动作"退出"放置在表单右侧。
他进一步在《网络表单设计》一书中,阐述了从易用性对比测试中的发现:测试表明主要动作在左侧而次级动作在右侧具有更快的绩效。



Robert Hoekman, jr.
(罗布特·霍克曼)也思考了不少关于这方面的内容,并且在《设计片段》(Designing the Moment)提出他的想法。
他同意Luke Wrobleski的关于首要动作在表单左侧的观点,这样做的原因在于可以形成一条很好的线,视线可以跟随,推下表格,从而轻松扫描。另一个原因在于如果用户用tab键(键盘左上方的制表符)操控表单,首要动作可以先于次要动作在表格命令下进行。

Labeling the actions 标记动作


Robert Hoekman, jr.
也有一些关于按钮标记的想法,比恰当标记"确定""退出"按钮
更好的办法是直接标记实际的动作。如果执行一个"存储一个笔记"save a note)动作,为什么不让"存储笔记(save a note"按钮替代"确定"按钮呢?
Jakob Nielsen也建议按钮上的文字要说明这个按钮究竟要干嘛,不要只用类似于"确定"这种空泛的文字。 这么做用户会更有自信地使用,因为他知道当他按动按钮的时候将会发生什么。

Visual distinction 视觉的差别
另一件事是Robert Hoekman,jr.讨论视觉上区分动作,使得用户能够很轻松地做出正确的选择。

Luke Wroblewski也推断出,做首要的动作要比次要的动作更突出。在易用性测试的调查中,他发现如果首要比次要动作有一点不同的设计的时候,用户会花多一些时间去完成表单。而另一方面,用户会更有信心,较少做出错误的选择。他建议使用不同颜色制作按钮或者让次要动作变成一个普通的链接。

一个简单的方法从视觉上区分两点:我经常去做,则使用粗体(bold font weight),放在首要动作上,而一个正常的字体放在次要动作上。

Robert Hoekman, jr.推荐"对次要动作使用一个普通的链接",他的理由是说这可以更清楚的判断谁是首要的。但是它也适用于费茨法则,即距离和目标尺寸设多大可被触及并且点击——目标越大会越快些(被触及、点击)。首要动作因此应该比次要动作大一些。

The Reset button 重置按钮
重置按钮被用来重新设置一个完整的表单。这种早期相当常见的应用,到如今却很少被看到。不过我想我也说一些关于这个按钮的话,当它经常被当作成对的按钮出现在表单中的时候。在多数情况下,这个按钮最好是完全不用。所有经常错误点击重置按钮的用户因此会删掉他们输入的一切内容。(我在
Confusing Northface contact form中写过),并且认真地说,你需要多频繁重设整个表单,并且如果你这么做,会产生怎样的问题。这个按钮所具有的风险简单要同可能的收益做一个大的对比,加之在很多情况下,会对表单增加更大的混乱。
正如Jakob Nielsen放到他的警示框专栏《复原和退出按钮》中的话:

    
网络将会变成更开心的地方,如果所有的重置按钮被虚拟的移走之后。这种按钮几乎不能帮助用户,反而会伤害他们。可能唯一的时间是当重置按钮被请求的时候,是当一个表单被同一个用户重复使用的时候,并且每次输入的信息是不同的。

关于重置按钮Luke Wroblewski有一个想法,他认为如果你提供一个也应该提供一个撤回(undo)选项。用户点击重置按钮重新恢复表单,可以起到撤回的作用。此举意味着你不得不暂时的存储表单数据,但为用户的方便提供了很小的价值。

Best practices 最佳方法

基于以上所有的观点,加上我使用并设计web表单的经验,我提出一些好办法。

  • Position the Primary action to the left 首要动作放在左边 
    把按钮放在表单的左边,可以使得眼睛跟随一条清晰的路线。通过首要动作放在次要动作的左边,也便于tab次序。
  • Label the actions in a natural language 标签动作用自然的语言 
    通过描述实际动作发生,用户更舒适的感受他期待使用的内容。
  • Make the Primary action stand out 使首要动作凸显 
    这样可以让用户更轻松选择他们想要的选项,而不会从一堆选项中艰难的发现。
  • (Almost) Never use a iReset button (几乎)不要使用重置按钮  
    重置按钮经常会伤害用户,而不会太多帮助他们。唯一的可能是他们在表单中需要它们,是同一个用户反复再三做不同输入的时候,即一旦你使用了"重置",也就意味着为用户提供了一个撤回功能。

你同意我的结论或者对此有不同观点,请分享吧!

关于作者
Gabriel Svennerberg
是一位网络开发人员和互动设计师,35岁,自从1996年就从事web的工作。起先自我雇佣,后来在VäxjöVarberg Stockholm等不同的代理商工作,如今为
Saab Security构建网络应用以及强化用户体验工作。
http://www.svennerberg.com/about/


clock November 26, 2008 13:08 by author Sky Jia (贾超)

Jakob Nielsen, usability guru and author of Usability Engineering, raises the concern that Agile methods are a threat to traditional approaches to designing usability. He says that Agile’s greatest threat to usability is that “it's a method proposed by programmers and mainly addresses the implementation side of system development”. Alistair Cockburn counters that this claim just isn’t true:

  1. It doesn’t matter who proposed a good idea, only whether the idea is good.
  2. This sets up an “us versus them” split in the community instead of an “us plus them” coming together.
  3. Unlike the other threats Nielsen names, he doesn’t offer a solution, so he leaves us with his “us versus them” unsolvable problem, which is unacceptable.

Proposed solution: Just use good ideas – don’t worry about where they come from. As Kurt Morris posted on the agile usability list, “It’s amazing what can get accomplished once you get past the artificial “us v them” mentality.”

Nielsen goes on to raise the issue that the Agile habit of breaking the stories down into smaller tasks threatens to obscure the total user experience, allowing features to be developed in an inconsistent manner. At its worst, he says: “the user interface can end up resembling a patchwork.”. Nielsen’s solution:

  • Perform Usability testing quickly and repeatedly. He says “Weekly tests are completely feasible and give you a surefire way to integrate several user feedback rounds within even the shortest sprint.”
  • Parallel Tracks allow the usability work to be done just one step ahead of the development work.
  • Use low fidelity prototypes (such as paper) that don’t require coding minimizing the time spent upfront.

Jeff Patton has distilled 12 usability best practices (echoing several of Nielsen’s):

  1. Drive: UX practitioners are part of the customer or product owner team
  2. Research, model, and design up front - but only just enough
  3. Chunk your design work
  4. Use parallel track development to work ahead, and follow behind
  5. Buy design time with complex engineering stories
  6. Cultivate a user validation group for use for continuous user validation
  7. Schedule continuous user research in a separate track from development
  8. Leverage user time for multiple activities
  9. Use RITE to iterate UI before development
  10. Prototype in low fidelity
  11. Treat prototype as specification
  12. Become a design facilitator

The RITE (pdf) method that Jeff describes comes from Microsoft’s Games Studio: “RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes.”. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.

In addition, Jeff finds his role has changed: “As I've begun to work within Agile teams, my approach has changed to favor collaborative design. More and more I find myself acting as facilitator to harvest and model information from large groups of people. I find myself working with groups of users and developers to write user scenarios, and sketch user interface design.”

Finally, Alistair says (in reference to the developer/usability divide): “Just remember, ‘There’s only us."


Search

Calendar

<<  September 2010  >>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

Categories

Tags