Web注册表单设计样式的研究下.docx
《Web注册表单设计样式的研究下.docx》由会员分享,可在线阅读,更多相关《Web注册表单设计样式的研究下.docx(23页珍藏版)》请在冰豆网上搜索。
Web注册表单设计样式的研究下
Web注册表单设计样式的研究-下部(折折熊译)
2008-07-2416:
57:
48in产品product
上周我们已经给大家介绍了我们对于web表单调查研究结果的第一部分。
调研的主要目的是提供给凭直接来判断有效性的设计师和开发人员一些理论依据。
我们也介绍了一些如何让web表单成为完美的友好用户界面的指导方针。
我们把更多关键表单单独开来(例如校验表单)从而关注注册表单。
然后我们分别完成每个被选择网站的注册表单并且分析这些表单的设计方法。
以下我们介绍这个研究的第二部分——关于100个流行网站web表单的调研结果。
请注意这个文章不是关于校验表单——那是另外一个讨论的话题,我们把它独立开来看待成一个即将要讨论的文章。
我们要感谢Wufoo为我们提供构架来引导我们的调查。
3、表单的功能性
在研究的第一部分里,我们已经仔细考虑过注册链接和注册表单的布局和视觉表现形式。
但是如果表单不能正常工作的话设计的多漂亮都没有用,表单完成率依然很低。
让我们现在来考虑一下注册表单功能性的典型问题以及设计时的方式方法。
3.1.Hover,active,focus–使用中的效果?
显然地,为了提高表单的完成率,设计师试图避免各种各样的分散因素,并且提供一个清晰明确并且简单的web表单。
这就是为什么任何视觉效果需要非常适当地使用的本质原因。
∙84%的web表单没有任何种类的hover、active或者focus的效果。
∙16%使用非常细微的鼠标上移的效果。
3.2.帮助,支持,工具技巧:
静态还是动态的?
有时候,输入区域的标签不够明确,但是用户却需要足够理解才能提供这些信息。
用户名适用哪些字符格式?
密码的字符数限制是多少?
提供的Email地址会不会自动变成登录名使用?
用户通过建议和技巧的帮助最小化地减少输入框重新考虑的次数。
而且,没有比虽然输入的内容看上去完全正确,但是输入框却不接受的情况更恼怒的了。
为了避免这个问题,设计师(通常)使用不引人注目但清晰的建议提示。
调查报告中57%的web表单只有“静态”的帮助提示,这些帮助提示只是之前假定好的一些和用户有关的提示信息;这些提示被明显地放在输入框的旁边。
10%的操作提示通常是在一些帮助图标被点击之后或者用户输入信息时才会出现的。
3.3.帮助,支持,操作提示:
应该放在什么位置?
当在为用户提供帮助时,一定要确定帮助是简单地提示,并且可以方便地被找到和理解。
这是确保用户通过帮助提示不犯错误地完成表单的决定性因素。
为了达到这个目标,你需要知道用户希望这些帮助在什么地方出现。
所以,这些帮助和提示通常被放在表单的什么位置呢?
如果帮助提示出现的话,它们会出现在…
∙在输入区域下面(57%)
∙在输入区域的右侧(26%)
∙在输入区域的上方(13%)
∙在输入区域的左侧(4%)
我们注意到提示信息直接放在输入框下方是一个强烈的趋势。
通常这类帮助提示会有稍微不同的色彩,大部分情况比主要内容要浅一些。
3.4.输入确认:
静态的还是Ajax动态?
去年一整年,很多网站为了和用户进行互动,看上去似乎确实充满了Ajax的应用,但Ajax在流行网站服务中仍然还没有设法达到临界点。
令人惊讶的是,我们不能认清Ajax的趋势。
用户在输入完所有信息点击提交按钮的“经典”确认技术依然比Javascript的实时确认要来的流行。
根据我们的研究:
∙30%的表单只在表单顶部显示一条错误信息。
(没有提示哪个输入框有问题)
∙29%的表单会在输入框旁边提示相应的操作帮助(顶部没有提供错误信息)
∙25%的表单同时使用错误信息和输入框提示。
∙22%的表单利用Ajax的实时确认来进行提示。
∙14%利用Javascript的错误提醒。
∙1%的表单是用系统信息提醒,并且给出“后退”链接。
3.5.错误信息的设计
正如你所看到的,我们已经识别出6种不同类型的错误提示。
显而易见,14%的表单仍旧使用Javascript错误窗口来传达问题(例如,YouSendIt,Mail.ru,Newsvine,Clipmarks,Yandex,看下面的截图),然而只有22%使用Ajax确认(通常用来确认用户名的有效性)。
当然也显然的是没有一个网站是没有任何确认的。
Newsvine使用Javascript错误窗口来传达问题。
通常设计师试图报告错误的使用方法。
a、在点击提交按钮之后显示错误信息;b、在视觉上高光“不正确”的输入框。
第一种错误情况通常会作为一条信息在页面的顶部(表单之前)显示出来。
第二种情况通常是把错误的输入框的边框色彩和输入的标签进行高光(大部分情况是红色的字体以及红色的背景色)。
有时候设计师合并两种技术并且利用输入区域高光错误信息的方法。
例如,看一下Ning结合两种技术的注册表单(请看下面的截图)
通常,红色被用于标示错误;但是在这种情况下就没有必要了。
当表单完成时,Tickspot,M和Furl使用黄色来表示遇到的问题。
不过,如果有任意一种色彩来表示注册成功的话,它应该就是绿色,97%的网站表示成功的视觉就是用绿色的。
3.6有必要确认Email吗?
只有18%的网站需要确认Email(例如,Odeo,Ning)。
老实说,我们实在没有任何理由让用户重复输入email地址,毕竟用户能够看到他们输的是什么,因为email地址的区域不像是密码区域那样是以星状显示的,对吧?
3.7有必要去确认密码吗?
当用户看不到自己所输的内容(他们看到的是以星号代替的)时让他们确认输入感觉上是有理由的。
但是很多网站为了缩短完成注册表单的时间而去掉二次确认的步骤。
72%的情况是有必要确认密码的,但是许多例如Facebook,Friendster,LinkedIn,Stumbleupon,Pownce和Twitter的网站都不要求确认密码。
3.8.需要使用校验码吗?
如果校验码去掉的话用户肯定很开心,但是实际上校验码却是必要的,因为网站需要防止垃圾注册软件创建很多垃圾帐户,不然他们需要不停地在数据库中过滤掉这些账户。
根据我们的调查,
∙52%的网站没有使用校验码。
∙有39%的网站是不能在不刷新页面的情况下实时刷新校验码的,这个实在是在可用性上非常的糟糕的一件事。
但是我们还是不能看清注册表单是否需要校验码的趋势。
任何情况下,如果你使用校验码,请确定它是易可读的,或者在不可读的情况用户可以实时刷新校验码的。
一些网站没有提供实时刷新校验码的功能,除了Digg,AOL,Slashdot,Google等。
Fm倒是能够让校验码变成可以听的,当它很难被识别的时候。
3.9.需要使用取消按钮吗?
当我们在思考设计表单时一些认为会碰到的问题时,我们期望注册表单没有取消按钮,因为毕竟所有选项都已经填写好了,对于用户来讲就没有太大的意义去退出这个表单。
然而我们在一定程度上错了。
只有8%的情况使用了取消按钮,这些情况中的一些取消按钮正好出现在“条款和协议”的下面(例如,ZohoWriter)。
所以如果用户不同意服务条款,他们会退出这个流程。
另一方面,一些服务在注册之前给出了一个支付方案(例如,Crazyegg)。
在这种情况下用户选择错了支付方案时他们需要利用取消按钮返回并重新选择另外更好的支付方案。
除此以外:
我们还是不明白为什么Dzone要把取消按钮放在注册表单的左侧。
如果使用取消按钮的话,有4%的情况是放在提交按钮的右侧。
在这些网站中观察发现,取消和提交按钮没有非常强烈的视觉区别,而且还被挨在一起。
从可用性观点上去看,把主要动作和次要动作用视觉区分开来并且用明确的空隙去区别它们是更有意义的。
3.10.提交按钮的对齐方式
考虑到表单的样式,把提交按钮左对齐、右对齐或者放在中间是有实际意义的。
有56%的设计师把提交按钮左对齐,第二位是26%的把按钮居中对齐。
右对齐的提交按钮依然比较流行(17%),但是一般都是起到需要进行下一步操作时的指示作用。
在这些情况中提交按钮经常是以“继续”或者“下一步”为标题的。
理由是:
通常桌面软件中的“下一步”按钮就是放在右侧的。
3.11.感谢信息
几年前,大多数服务在成功注册之后会提供一个简单,基础的感谢信息(通常还带有一个登录的链接),现在大多数站点都试图去激发用户立刻探索一下他们的服务。
∙45%的网站要求用户在完成注册之后提供更多的信息,在他们的网站上找到自己的朋友,或者邀请用户的朋友来使用他们的网站。
∙33%的表单会用友好并具有吸引力的语气指出“接下来要去地方”(网站功能的探索)。
∙4%的网站提供了一个基础的“谢谢你”的消息。
∙2%是直接跳转到首页。
更多的发现
∙99%的案例中都是用到标签索引(除了Habrahabr)
∙24%的表单使用谈话式的语气,试图通过标示的对话达到用户所需。
在这种环境中通常使用类似“你叫什么?
”,“你的Email请告诉我一下?
”或者“我想要……”等非正式的语句。
∙38%的网站宁可毅然选择正式商务的语气,友好地让用户填写所需的信息。
(例如,“您的用户名”,“确认密码”等等)
∙38%的网站使用系统语言,用户被要求“登录”,“用户密码”,“地址”等等。
概要
让我们对以上调研进行简单的回顾和总结。
请记住我们只考虑注册表单。
∙注册表单没有任何hover,active或者focus的特效(84%)。
∙提示和帮助不管是静态(57%)或者动态(33%)都是出现在输入框下方(57%)或者右侧(26%)。
∙状态确认和动态确认一样流行。
当然Ajax不是趋势
∙82%不需要email确认
∙72%需要密码确认
∙校验码可用(48%)可不用(52%)
∙92%不用取消按钮
∙提交按钮是左对齐(56%)或者居中对齐(26%)
∙感谢信息激发用户继续探索网站的服务(45%)
WebFormDesignPatterns:
Sign-UpForms,Part2
∙ByVitalyFriedman
∙July8th,2008
∙Design
∙92Comments
∙PublishingPolicy
Advertisement
Lastweekwehavepresentedfirstfindingsofourwebformssurvey.Themainobjectiveofthesurveywastoprovidedesignersanddeveloperswithsomeintuitionofhoweffectivewebformsaredesigned;wealsopresentedsomeguidelinesofhowaneffectiveanduser-friendlywebformcanbeachieved.
Wehavefocusedonsign-upformsaswewantedtoconsiderfurthercrucialforms(e.g.checkoutforms)separately.Afterwardswe’vegonethrougheachandeveryonesign-upformoftheselectedsitesandanalyzedthedesignapproachesimplementedintheseforms.Belowwepresentthesecondpartofourfindings—theresultsofoursurveyamongweb-formsof100popularweb-siteswhereweb-forms(should)matter.
Pleasenoticethatthispostisnotaboutcheckoutforms—that’satopicforanotherdiscussion,wemayconsiderthemseparatelyinoneoftheupcomingposts.WewouldliketothankWufooforprovidinguswithaframeworktoconductoursurvey.
3.Functionalityoftheforms
Inthefirstpartofourresearchwehaveconsideredtheplacementofthesign-uplinksandsign-upformsaswellasonthevisualappearanceofforms.However,nomatterhowniceadesignlookslike,iftheformdoesn’tworkproperly,thecompletionrateswillremainlow.Letusnowconsiderthefunctionalityofthesign-upformsaswellastypicalproblems,patternsandsolutionsusedwhenitcomestothedesignoftheseforms.
3.1.Hover,active,focus–effectsinuse?
Apparently,toimproveformcompletionratesdesignerstrytoavoidallkindofdistractionsandofferaclear,unambiguousandsimplewebform.Thisisessentiallythereasonwhyanyvisualeffectsareusedverymoderately—ifusedatall.
∙84%ofthewebformswhichwe’verevieweddidn’thaveanykindofhover,activeorfocus-effects,
∙16%usedverysubtlehover-effects.
3.2.Help,support,tooltips:
staticordynamic?
Sometimesthelabeloftheinputfieldsisn’tconcreteenough;however,usersneedtohaveasufficientunderstandingoftheinformationtheyneedtoprovide.Whichcharactersareallowedintheusername?
Howmanycharactersshouldapasswordhave?
Doesaprovidede-mailautomaticallybecomelogintousetheservice?
Hintsandtooltipsprovideassistancehelpinguserstominimizethenumberoftimesaninputshouldbereconsidered.Besides,thereisnothingmoreannoyingthatsomeinputfieldwhichdoesn’tacceptuser’sinputalthoughitseemstobeperfectlycorrect.Toavoidit,designersmakeuseof(usually)unobtrusiveandclearhints.
57%ofthereviewedwebformsprovided“static”help—tipswhicharesupposedtoexplainwhatisexpectedfromtheuser’sinput;thesetipsareobviouslyplacednexttotheinputfield.10%ofthetooltipsappearondemand–usuallyaftersomehelp-iconisclickedorwhentheuseristypingtheinformationintheinputfield.
3.3.Help,support,tooltips:
wherearetheyplaced?
Whenprovidinguserswithassistanceitisnecessarytomakesurenotthatthehelpissimplyprovided,butthatitcanbeeasilyfoundandunderstoodbyusers.Itiscrucialtomakesurethatusersdon’tmakemistakesassociatingahinttoaninputfield.Toachieveityouneedtoknowwhereusersexpecthintstoappear.Sowherearehintsandhelpusuallyplacedwithintheform?
Ifhintsandhelpappear,theyappear…
∙belowthefield(57%)
∙ontherightsideofthefield(26%)
∙abovethefield(13%)
∙ontheleftsideofthefield(4%)
Wehaveobservedastrongtrendtowardhintsplaceddirectlybelowtheinputfield.Usuallysuchhintshaveaslightlydifferentcolor,inmostcaseslighterthanthemaincontent.
3.4.Inputvalidation:
staticorAjax?
AlthoughAjaxseemstohaveliterallyfloodedwebsiteswitharichuserinteractionoverthelastyears,itstillhasn’tmanagedtoreachacriticalmassamongpopularweb-services.Surprisingly,weweren’tabletoidentifyatrendtowardAjax.The“classic”validationtechniqueswhichvalidateinputaftertheuserhasclickedonthesubmit-buttonaremorepopularthanreal-time-validationwithJavaScript.
Accordingtoourresearch,
∙30%oftheformsdisplayedonlyanerror-messageatthetopoftheform(noinputfieldswerehighlighted),
∙29%hadhighlightedinputfieldswithcorrespondingmessagesnexttotheinputfield(noerror-messageswereprovidedatthetopofthepage),
∙25%usedbotherror-messagesandinputfields,
∙22%usedreal-timevalidationwithAjax,
∙14%usedJavaScript-errorwarnings,
∙1%usedasystem-messagewitha“goback”-link.
3.5.Designoferrormessages
Asyoucansee,wehaveidentifiedsixdifferenttypesoferrorvalidation.Itisremarkablethat14%oftheformsstilluseJavascript-error-windowstocommunicateproblems(e.g.YouSendIt,Mail.ru,Newsvine,Clipmarks,Yandex,seescreenshotbelow)whileonly22%hadatleastpartialAjax-validation(usuallyforcheckingavailableusernames).Itisalsoremarkablethatnotasinglesitehadnovalidationwhatsoever.
NewsvineusesJavaScript-errorwarningstocommunicateproblems.
Usuallydesignerstendtoreportmistakesusinga)errormessagesappearingafterthesubmit-buttonisclickedand/orb)highlighting“incorrect”inputfieldsvisually.Inthefirstcaseerrorsareusuallybulletedandpresentedasalistatthetopofthepage,beforetheform.Inthesecondcaseusuallythecoloroftheborderofthe“wrong”inputfieldishighlightedtogether