What we choose is never what we really need.
9/27/2008
恋声
比如KOKIA,温柔而透明。
比如南拳妈妈,安静的温暖。
比如plastic tree,没有杂质的柔声细语。
比如石田彰,比如关俊彦,比如大谷育江,比如藤田惠美。
以前并未觉得Maximilian Hecker的声音特别。今晚重听lady sleep,突然找回了丢失很久的平静。人总是不自觉的陷入假象,逼迫自己紧张而不自知。突然被触发,像昏暗且满是灰尘屋子,被突然拉开了帘子,看到飞扬的尘屑,看到斑驳的光,看到慢慢散去的阴霾。
9/24/2008
反省……
更加让我惭愧的是据说上线时英文版庆出现了不少问题……比如不地道的英文等等,心虚到国庆都不敢提前走了……
9/11/2008
网站地图可用性
翻译:october
校对:toMMy
概述
网站地图最新的用户测试表明,网站地图作为次级导航助手依然非常有效。在我们长达7年的研究中,网站地图比过去更加容易使用。
通过信息空间的视觉表现帮助用户理解可以去哪,是最老的超文本链接可用性原则之一。网站地图的可视化效果能对网站或者企业内部网的主要导航特征提供有效补充。
网站地图最主要的好处在于让用户一眼就能了解网站概况。它使用一个单独的完整页面来表达网站信息构架(IA)。如果设计良好,该概况会包括层级信息,但信息量又不会多到让用户无所适从。
我们将网站地图定义为充当网站指南的页面。我们研究的网站地图有很多表单形式,包括字母索引,动态图表,二维列表。网站地图包括一系列特征、外观、名称,包括“指南”、“概述”、“索引”、“目录”。
两项研究
为了发现用户如何使用网站地图,我们进行了两轮可用性研究,测试了一系列的网站地图设计,观察用户如何执行代表性任务。
共有30位用户参与了网站地图测试。两组,每组15位。
我们测试了以下20个网站,包括电子商务、营销导向、高科技公司、B2B、内容、非盈利组织和政府机构网站。
Sites Tested In Study 1 | Sites Tested In Study 2 |
---|---|
CDNOW (e-commerce) Documentum (high-tech product) Interwoven (high-tech product) Mercedes Benz USA (marketing site for cars) Museum of Modern Art (non-profit) New Jersey Transit (local transportation) Novell (B2B) Salon (online magazine) Siemens Medical Solutions (B2B) United States Treasury Department | Administration on Aging (government) BMW USA (marketing site for cars) Citysearch Boston (visitor info) Harvard Pilgrim (health insurance) The Knot (wedding information/e-commerce) Marriott (hotels, with online booking) Scholastic (children's books) Texas Roadhouse (restaurant chain) TiVo (high-tech product) |
在两组测试中,我们首先引导用户进入首页,指定任务而不特地提及网站地图。该项测试评估有多少用户会自发使用网站地图。在后续的每组测试中,如果用户没有主动使用网站地图,我们会特地要求用户使用。
测试1七年前就曾经进行过。对比测试1和测试2,我们能够评估网站地图可用性的长期趋势。
几乎没人使用网站地图
几乎没人使用网站地图。测试2中,我们要求用户了解网站结构,仅有7%的用户使用了网站地图。这个数字比测试1低27%。
好消息是用户在少部分需要的情况下能够找到网站地图。测试2中,我们要求用户“找到列出网站每部分的网页”时,67%的用户成功发现了网站地图。
保持简单
网站地图有两条主要可用性指南:
* 以“网站地图”为名,在网站中始终将其作为标签链接至网站地图页面。
* 使用静态设计。不要提供交互网站地图工具。网站地图应当直截了当的呈现(如果需要的话可以使用滚动条)。
这些原则从第一版报告开始就没有变更过。动态或者交互的网站地图在7年前曾导致可怕的失败,在测试2中依然带来了麻烦。网站地图的目标是让用户了解信息概况。如果用户要费力才能查看地图的不同部分,网站地图就失去了优势。
网站地图毕竟只是地图,它不应当成为另一个导航。
我们一再发现,用户讨厌非标准的用户界面。这些非标准的用户界面迫使用户为了某一个网站学习特定的网络使用方式。网站地图应当简洁,链接布局紧凑,用户一眼就能看到所有东西。
我们所要求的唯一有些难度的事就是使用多栏布局。测试2中,使用多栏布局的网站地图中,61%的用户轻松完成任务,在单栏布局的网站地图中,此数据为47%。
多栏网站地图效果更好,因为用户较少使用滚动条就可了解网站结构。在网站地图中使用长滚动条,用户容易迷路。他们的典型行为是会多次上下拖动滚动条,经常有意无意的错过内容。事实上,用户经常在开始时迅速浏览高层目录,然后回到页面上方进行更加细致的搜索,有时多次重复这一过程,目的一次比一次更加明确。相反,多栏布局网站地图便于用户快速浏览所有目录和子目录,便于在深入前把握全局。
网站地图为何而存在?
7年前,我们调查的50个网站中48%使用网站地图。今天,我们调查的150个网站中71%使用网站地图,我们Intranet Information Architecture报告中分析的56个企业内部网59%使用拥有网站地图。同时,两项调研进展过程中,大多数网站地图在一定程度上变得更加有用。
现在虽然流行出色的网站地图,但用户并没有经常使用。那么网站为什么要制作网站地图?因为它们能够帮助用户了解你的网站和你的服务。
我依然推荐使用网站地图,因为它们是唯一能为用户提供网站全局纵览的页面。也许有人主张网站导航提供了同样的功能。比如,一些导航提供下拉菜单,用户能看见网站每个部分的导航选项。但即使有这些菜单,用户也只能一次浏览一项内容选项。
网站地图允许用户在一个页面上看到所有可用内容,并能够将用户直接送至其希望的页面。网站地图同时也能够提供简洁的用户界面和有价值的内容,帮助用户在内容杂乱的网站上找到信息。然而网站地图并非万金油。网站地图无法解决网站结构的固有问题,比如混乱的导航结构,糟糕的版块命名,毫不协调的子站点。
如果网站地图需要大量设计投入,它们不会带来有足够的投资回报率。但由于我们的指南都要求网站地图保持简洁,制作一个网站地图不需要很多工作量,它会给一些用户带来帮助。更重要的是,它会在关键时刻帮助用户:用户在网站迷路,没有找到网站地图时也许会离开你的网站。
网站地图是次级导航栏,与面包屑导航一样。的确,支持网站地图的主张也类似于支持面包屑导航:
* 它们不会对不使用者造成影响
* 它们的确对一部分人有帮助
* 它们不需要花费过多成本
9/10/2008
9/09/2008
Last Friends

Last Friends
近期在看的一部日剧。剧里面都是寂寞的等爱的人。每个人心里都有残缺,无法显示真实的自己,却温暖了身边的人。
片头+音乐:
片头制作得非常出色,眼神交错,命运相织,世界和内心原本就是纯白。原本早就听过宇多田光的prisoner of love,但每当片头和剧情中想起她明亮的声音,心依然不由得为之一震。音乐与剧情结合至产生共鸣。
印象很深的话:
Ruka:“不要在想了,不要再想你的事了,不会在这么担心你了,因为什么都做不了,你都说了从来没被爱过。 ”
Michiru:“Ruka,救救我。”
编剧:
浅野妙子 Taeko Asano
演员:
长泽正美 Masami Nagasawa——蓝田美知留
上野树里 Juri Ueno——岸本琉可
瑛太 Eita ——水岛武
水川麻美 Asami Mizukawa——泷川绘里
锦户亮 Ryo Nishikido——及川宗佑
……
要用尽全部的爱。因为时光回不来。因为感情不由人控制。她暧昧的飘过,突然的死亡。
Caroline's Corner: 表单中的按钮——如何放置及命名
Source: Caroline Jarrett, 3 September 2008 Submitted by Caroline Jarrett
翻译:october
校对:toMMy
原文:Caroline's Corner: Buttons on Forms - where to put them, and what to call them
经常有人问我:“OK按钮放在Cancel按钮的左边还是右边?”
还有另一种常见问法,要不要把“Cancel”换成“Back”、“Previous’”,或者“Next’”。
问题简单,答案复杂
我很乐意告诉你:OK按钮放在左边。或者放在右边。或者其他容易描述和记忆的方式。正如表单中的多种情况,最简单的答案不一定真正合适。有谁希望答案总是视情况而定?可用性中视情况而定的问题太多了。然而真正的答案依然是“视情况而定”。但我们可以从“视情况而定”中转移视线,我来告诉你一些规则。
规则1:参考其他表单
首先应当找出用户使用的其他表单,看看那些表单中如何放置按钮。比如,Jakob Nielsen几年前指出大多数用户在其他网站花费的时间远多于在你的网站花费的时间。或者如果你在创建一个与Microsoft Office软件共同使用的项目,那么你的用户倾向于期望你的项目沿用Microsoft Office软件惯例。如果你的用户同时使用PC和Mac,情况会有些棘手,因为这两种操作系统有些冲突的操作习惯。做些市场调研,看看哪种操作系统对用户更重要,你需要仔细考虑表单应遵循哪种操作系统。
规则2:把按钮列放在对话结束的地方
用户点击按钮表示结束本次对话后,表单继续询问用户问题,这是最大的问题。用户提交后接下来就是系统的任务了。此处需要按钮,它通常被称为“OK”、“Send”、“Submit”或者“Next”。要点是点击后任务结束。我见过的一个常见错误是:把重要指示甚至所有问题放在最终按钮的后面。对用户来说那是隐藏区域。不要这么做。
规则3:决定是否需要按钮
不久之前,我写过一个专题“The Piece of HTML created just for me: Reset”。主题是“Reset”按钮对表单设计人员来说很方便,填写表单后点击“Reset”按钮清除输入内容。不幸的是,大多数“Reset”按钮都无用,对其他用户来说很招人厌。真的需要其他按钮吗?用户希望放弃辛苦填写的数据吗?如果不是真的需要,就不要用。
规则4:决定按钮是不是看起来可点击
有时表单末尾明确需要两个或更多可能的动作:也许是 “Send” 和 “Throw away my work’”或者 “OK” 和 “Cancel”。Luke Wroblewski将最重要的动作称为“主动作”,其他称为“次动作”。他和Etre公司就表单中如何放置“Submit”和“Cancel”按钮以及是否将“Cancel”做成链接或者降低其视觉比重做了一些测试。
令人惊讶的是,他们发现将两个按钮放在一起的方案效果都差不多。仅有一例失败,就是将“Cancel”放在表单下方,将“Submit”放在远离右边的地方。(题外话:我曾期望将“Submit”放在表单下方,“Cancel”远离右边放置的效果等同于将按钮放在一起的方案,但出于一些原因没有测试该方案。)
就完成表单的时间而言,按钮看起来相似的方案效果最佳。降低Cancel按钮的视觉比重或者做成链接的方案会花费用户稍长时间。然而,重要的是用户倾向于以下方案:“用户在Cancel视觉比重较少的方案中表现得最佳,即使这些方案会降低他们的速度。这表明用户更关心避免数据丢失,而不是快速提交表单。”我认为几乎在所有案例中,精确度和用户舒适度比表单填写时间稍胜一筹。因此我会减少此动作的视觉比重——但也许会带来灾难行为,比如说“Throw away all my data(清除数据)”。
该规则有个补充:确保按钮看起来可点击。我经常使用网络银行,按钮仅是一个加了文字的普通橙色长方形,每次我都感觉困惑,没有阴影效果突出按钮,让其看上去可点击。如果你觉得缺乏创意,尝试搜索“web button(网站按钮)”图片,从特别难看到非常酷,应有尽有。或者更实际的办法是看看你最喜欢的网站是怎么做按钮的。
规则5:用标签说明按钮的功能最后一步是决定按钮应当配以什么样的标签。我经常看见以“OK”和“Cancel”标识的按钮,并没有清楚表达出按钮的含义。设想经常出现的Cancel对话框:你请求系统结束任务,系统跳出标识为“OK”和“Cancel”的对话框。“Cancel”的意思是结束任务,还是取消刚才的请求?请注意,没有规则表明“只能以一个词标识按钮”,很明显,也没有规则表示“必须要用‘OK’和‘Cancel’按钮”。
9/08/2008
表单设计应当避免的常见错误
翻译:october
校对:toMMy
原文:Pitfalls to Avoid When Designing Forms
1. 危险的重置按钮。大多数情况下,没有必要出现重置按钮。如果用户碰巧点击了,它们几乎总是产生麻烦——因为这会清空表单,而没有任何确认框提示(至少在主流浏览器和主流表单执行动作中)。下图的德语表单虽然精心规划,但设计不佳。这张表单用来计算地铁路线中两地之间的距离:

请注意,这张表单已经是修正版,第一次设计得更糟。你知道右下方按钮写着什么吗(该位置按钮的通常是“OK”或“Submit”按钮)?这里的按钮是“Neue Faht”(新路线)……,点击该按钮会清空已经输入的全部内容。
快速补救:不使用重设按钮。(如果仔细权衡后决定需要重设按钮,一定谨慎使用。)
2. 能够选择很好,是吗?并非如此。至少对网站表单而言并不一定好。仅在用户要完成任务的场景中提供必要选项——其他都会让屏幕看起来杂乱、产生困惑,而且实际上用户无法花时间思考哪些选项是需要的,哪些选项是重要的。讽刺的是,大多数网站表单的功能比Google搜索简单得多,Google要搜索几十亿个网页,但这些表单依然比Google表单复杂上亿倍。
如果真的需要许多选项,考虑使用可展开的高级对话框将极少使用的选项隐藏起来。想想Wikipedia如何更改句法快速集成对话框(编辑页面时,可以点击编辑框下方的链接将其插入页面),避免全部或者过多显示,而是部分显示,并通过主题选项框进行分类。

3. 表格依然是网页和网站的一部分。由此,它们应当遵循网站可用性基本规则,比如字体应足够大以便于阅读,链接和非链接应明确区分。通常使用下划线或者蓝色标识表示链接可点击。但是,请看下图Hotmail登录表单——是不是仅仅查看就能辨别出其中的链接?

事实上,顶端的蓝色文字(“Have an MSN Hotmail…”)看起来可点击,但它仅仅是文字,不能引导到其他地方。另一方面,底部(“Use enhanced security”)是链接,即使没有任何视觉线索能表明这点。
提示表单成功和失败的信息没有使用明确的的配色方案,这是另一个常见问题。无论什么信息,都不要用红色标识成功信息,比如,“恭喜,表单提交成功!”——使用红色会引起一瞬间的疑惑。类似的,纯信息传递中,应当避免使用警告含义的标识。
4. 你在做算数,而不是用户。如果脚本能自动计算,就不要让用户来算。下图是时区转换表单,有个越洋朋友来看你,你可以用它来安排日程。

这张表单提供两个基本选项:转换当前日期,或者转换自定义日期。但是,使用列表中部的输入框自定义日期和时间,点击提交时该项值会被忽略……除非同时选择了“Use the following Date/ Time”(使用以下日期/时间)选项。只要输入自定义日期,系统就应当自动选择“Use the following Date/ Time”(使用以下日期/时间)选项(如果表单不能处理自定义日期,用户为什么还要输入?)。
5.不要让用户一定要点击单选框。而应该是点击单选框旁的文字也可以。这是Windows系统界面惯例,却被许多网络表单忽视……即使HTML提供了非常简便的方法(甚至不必使用JavaScript)。下图表单来自Google站点,点击“Put page under…”时,单选框并未被选中:

6. 不要迫使用户使用自定义日期控件或者其他小工具。日历工具表单中的日期控件的确不错,但有时候用户仅仅希望用纯文本形式输入日期(比如,输入:“2008-12-24”)。如果真的决定需要一个日历控件,那么不要迫使逼用户使用:比如光标移动到输入框中时,弹出日历控件。德国官方铁路路线计算表就是这么个例子——当选择输入框时,弹出日历控件,但即使手动输入后点击表单中的其他输入框,日历控件也不会自动关闭(因此总是需要点击关闭按钮)。

举个更有用的例子,我们来看一看Google Calendar的编辑器。编辑事件的日期或者时间时,会弹出控件。通常如果你不希望使用它时,它也不会产生阻碍,而是允许你自由输入文本。
7. Ajax变化过于细微。是的,Ajax是自从tag以来最伟大的网络产物,但这并不意味着它不会被滥用……因为它会以很多方式被滥用。一种滥用是提供表单反馈——比如,“您已登录”或者“表单输入有误”——用户很容易错过页面上细微的Ajax更新。这种情况下,重复点击Submit(提交)按钮也不会有帮助,反而会导致困惑。过于细微的版面布局对于重要信息来说很糟,但至少如果有页面转换和相应的可视化载入时间,用户也许能留心到该信息。
如果对表单出错或者成功增加Ajax反馈,确保易被查看。用户认为也许会花费一些时间才能提交成功,所以会在点击提交按钮后甚至会切换到其他浏览器窗口;返回原窗口时,用户是否能得到反馈信息或者用户是否会认为表单提交出了问题?
8. 输入框中的3D效果看起来过时,而且有时很难看,但不要移走它们或所有的3D色彩暗示,除非你发现它会增加困惑。若你正使用默认输入框,它会在当前窗口显示一些3D效果的内边缘线。如果在白色背景中使用白框,不要完全去掉3D效果,否则输入区域会不太像输入框。按钮上的3D效果外边缘线也存在同样问题,去掉它们,按钮会不太像可点击项。如果你使用明确的颜色暗示,表单又足够短的话,相信你能够去掉那么多3D效果——比如背景色较暗、白色输入框的搜索表单。虽然对此我有些拿不定注意,但你可以自己判断:

9. 如果数据没问题,就让其通过,而不要要求再次确认,也不要让用户提供的数据和数据库所需要的数据形式完全一致。一些网站表单会进行数据转换,比如将用户自由输入的地址格式转换为“正确的”数据库格式,然后将其用组合框形式呈现并要求用户再次确认。但是如果明确知道组合框选区的确是用户需要的,不需要再次确认来查看结果——相反,结果页面之前或之后应当少一些强加选项,允许用户选择其他,也许效果更好。
甚至有些表单会迫使用户使用精确的数据库格式。比如输入信用卡号码时表单不接受空格,去除即可,不要让用户自己动手去掉空格。
10. 是的,出售详细用户数据能迅速致富(至少我有所耳闻)。但这并不意味着网络服务收集大量信息是正确的事。例如你专门提供邮件服务,那么用户性别、家庭电话号码等等信息真的那么重要吗?最好的网络表单仅要求用户提供该项网络服务绝对需要的信息(此外,如有需要,会有法律、安全等输入框,比如可怕的验证码是现在表单可用性的重大问题)。还有其他有用的可用性指南。比如保持文本简短,对界面来说有利无弊。同样,要求用户做选择时使用正面文字;用“do this”或者“show this”比“don’t do this” or “hide this”更容易迅速理解(更不要提“don’t hide”等其情况了)。表格一旦提交,将用户送至对现有任务(如果任务尚未完结的话)最合适的页面非常重要,而不是一个通用的感谢页面。无论做什么,需要知道用户在其他网站表单中花费了大量时间,因此有时候优化方案也许是只要重复用户习惯并且已经理解的表单就够了——同时也要考虑用户也许打开了多个窗口,你的网站表单仅是其中一个,用户会将表单当成次要任务,倘若发现表单无法实现他们的期望,可能就会放弃填写。
最后,大多数设计优秀表单的要点都是常识,因此只是需要时间反省并以局外人的视角审视表单。尝试想像一个不了解(或者不关心)数据结构、众多考量或者产品历史的人会如何看待表单。对用户而言,表单本身可能并不是任务,而是达成任务的必要障碍。最好能像设计交通标志(时速100 km/h时能一眼看到)一样设计表单,而不能像设计书那样(躺在椅子里有很长时间阅读一本书)。
网站搜索框设计诀窍
校对:toMMy
原文:Tips on site search box design
虽然很多在线购物者更愿意用导航链接浏览网站,但我们不应当忽视搜索框的重要作用。
如果来访的购物者清楚的知道想要什么,他们会很明确的使用搜索框。这种情况下购物者显示出了明确的购物意图,因此搜索框能够把该意图转变为真实的购买行为。
根据Fast Search提供的数据 (pdf),30%的购物者进入电子商务网站后会立刻使用搜索框,超过30%的人通过导航没有找到需要的物品后转而使用搜索框。
那么,如何让这一切变得更加容易一些?以下是些小诀窍:
搜索框大小
允许用户输入较长的搜索请求,比如两个或者两个以上的词,这是现在的流行做法。那些查找具体电视机型号或者笔记本电脑型号的用户会倾向于使用较长的搜索请求。这意味着我们需要较长的搜索框。
理想的文本框应当能够容纳约30个字符,即5个单词左右。如果用户输入了更长的搜索请求,就无法看到全部文本。这不算糟糕,但如果搜索框能长一些,用户会更容易修改搜索内容中的拼写错误。
以Kelkoo为例,该网站为搜索框提供了足够的输入空间:

显化搜索框
搜索框应出现在页面的显著位置。许多网站倾向于将其放置在页面右上角,但将其安排在中间,购物者会更容易发现。Comet网站最近发布了新版首页,更加突出了搜索框(同时加大了搜索框)。Comet网站发现搜索框是有效的转化工具,所以做出了此变更。
旧版搜索框被放在了页面右边,如下图:

新版中,搜索框被明显突出:

提供搜索预测
搜索框中输入关键词时,用户必须用几个词来描述产品,并猜测电子商务网站会如何呈现该产品。
让搜索变得更加容易的绝佳方式,是在用户输入搜索项时给与搜索建议,正如Google Suggest。用户能用最小的投入获取想要的东西。
Borders.co.uk网站最近升级增加了这一功能:

允许用户缩小搜索范围
如果用户搜索的产品数量非常巨大,用户更愿意通过缩小目标限定搜索范围。
Amazon网站就是如此。你可以通过其18个目录缩小搜索范围,以呈现更加相关的搜索结果:

用标签明确标识搜索框
大多数的购物者很容易找到搜索框,但我们不应当让那些对网络不是特别熟悉的人为此花不必要的精力。
Waterstones网站虽然将搜索框放在页面左侧,但它清晰明确的标记出其搜索工具:

页面载入后,光标默认定位在搜索框内
这是个小细节,但能够让顾客更加容易开始搜索。Google及其他主要搜索引擎都是如此,这能帮助用户更加迅速的达成目标。
但并非所有电子商务网站都是如此。Kelkoo和Amazon网站载入页面后,都将光标默认定位在搜索框内,但在M&S和Next等网站中,用户必须移动鼠标进行定位,才能输入搜索项。
移除搜索框中现有文字
许多网站和下例中的Marks & Spencer网站一样,在搜索框中写入文字解释功能。点击搜索框时,文字自动消失,你可以自由输入搜索项。

如果搜索框中的解释文字无法消失,用户会感觉沮丧,他们必须删除文本再输入搜索项。值得庆幸的是,很少有网站犯这个错误,而迪斯尼英国网店恰恰犯了这个错误。
网络排版十大错误
翻译:october
校对:toMMy
原文: Top Ten Web Typography Sins。
虽然许多设计师能很快接受网络标准,但让人惊讶的是他们常常忽视了基本的排版标准。以下是必须避免的十个致命问题:
问题1:使用连字符,而非长破折号。
问题2:使用句号而非省略号。
问题3:使用直引号(Dumb Quotes)。
问题4:句子之间使用两个空格。
问题6:使用过多强调方式。
问题7:下划线穿越下行字母。
问题8:用Photoshop制作字体。
问题10:应用大写效果时不使用CSS。
网站表单的国际地址
翻译:october
校验:toMMy
原文:International Address Fields in Web Forms
网站表单作为企业与客户之间进行在线沟通的实现者,往往承担着收集关键信息的任务。例如收集电子邮箱地址便于进一步沟通,收集邮寄地址用于投递产品,收集账单信息用于处理付款等等。因此被问到网站表单设计最常见的问题——“如何设计国际地址”时,我并没有感到很惊讶 。
分析地址变化的细微区别之前,值得指出的是人们对地址结构拥有共识。经过多年通信经验及邮政系统的积累,人们对构成地址栏的要素形成了非常具体的概念。这种共识非常绝对。眼动数据表明,一旦人们开始在地址栏的输入框中填写信息,人们往往不再看该输入框的标签信息。人们对地址栏的基本结构很熟悉,并不需要标签提示。
考虑组成地址的输入框是很重要的一点。图1显示了美国地址中通常包括的条目的排列方式。图2是另一种方案,每个条目都分行显示,这种方法缺乏关联理解输入框的优点。因此,人们更倾向于相对独立的对待每个输入条目,而非将地址看作一个整体。
图1:网站表单中的美国常用地址结构

图2:分割的美国地址结构

幸运的是,世界上组成地址的要素有着相当多的共性。大多数国家,地址栏中的目的地、收件人都是采用从具体到模糊的渐进结构,而俄罗斯、伊朗明显是例外。因此要给一家公司中的某人寄东西,地址栏中第一栏为收件人姓名,然后是公司名称,之后是街道、城市,最后一栏是国家。如图3。这种结构能用于所有国际地址。
图3:国际地址结构

国际变化
地址栏的国际变化从最具体的条目开始——拥有地址的人。世界上的人名可能是一个、两个、三个或更多个字。Formulate Information Design的文章“The Name Riddle”描述了姓名中的可能变化,从印尼首任总统Sukarno到沙特第五任国王:Fahad bin Abdul Aziz bin Abdul Rahman Al-Sa’ud。
即使在一个国家内,街道地址也会有很大差异。美国邮政邮政地址标准描述了美国街道地址的差异——从1401 Main St to RR 9 Box 23A 到RR 9 Box 23A to 475 Lanfant PLz SW, Rm 10022。
姓名和街道地址差异很大,但是每个单一输入框只要够长即可。门牌号码在街道名之前?没问题。门牌号码在街道名后面?也不是问题。但是对于地址栏中的城市问题,就没那么简单了。
除了城市名称、邮编外,城市一栏同样可包括州、地区、省、或者国家。国家不同,每一项可能有不同的叫法、简称,在地址栏中的位置也不一样。不同国家的邮编形式也不同,包括空格、数字、字母以及长度。这些要素的顺序差异巨大。图4显示的是地址栏中城市项可能发生的变化。
图4:城市项变化样例

为解决这些国际变化,网站表单设计师采用了很多方法:特定表单、可变表单以及通用表单。
特定表单
若知道或可以确切推断客户的国家,采用特定表格的办法最为有效。用这种方法,可以为每个特定国家定制地址栏结构。图5显示的是法国、意大利的地址栏。请注意位置和标签的变化。
图5:法国和意大利的地址栏

如果能非常肯定客户的国家,特定表单能提供可快速理解的熟悉的地址结构,从而加速表格填写的完成时间。Frank da Cruz的Compulsive Guide to Postal Addresses是一个了解世界各地独特地址结构的奇妙网站,据此你可以制定针对特定国家的地址栏布局。
可变表单
和特定表单方式一样,这种设计利用可变化的格式,设计特定国家的地址栏。但是,这种格式是基于用户选择而非已知或者推断的位置。如图6所示,eBay的注册表单就使用了可变表单。如果有人更改了默认国家选项——该默认选项基于eBay对用户的访问位置判断——表单会显示被选择国家的地址框,以替代默认地址框。
图6:eBay 允许用户可更改注册表单中地址。

这种情况下,若在地址栏下拉菜单中选择加拿大而非澳大利亚,“State/Territory”变为“Province”,“Postcode ”变为“Postal Code”。尤其值得关注的是,更改国家时,用户在通用地址结构的表单中输入的任何信息,比如名字或者街道地址,应当被保留。消除用户已经提供的信息极可能会惹恼用户。
通用表格
通用国际地址表单格式是另外一种保持多种地址栏变化以支持特定国家的解决方案。通用格式为组成地址栏要素的栏目提供单独的输入区域,让你能应付姓名以及街道地址的变化。为了适应地址栏布局以及城市项的变化,你可以使用一套通用的输入栏。Amazon.com的表格正是如此,如图7。
图7:Amazon.com的地址栏通过采用通用表单的形式支持不同国家的地址输入。

不同于根据国家显示不同的下拉菜单,单独输入栏被加上各种标签,比如州、省、地区,用户可以据此填写信息。类似的,“Zip/Postal Code” 标签同样包括了在输入框中针对邮编不同形式的邮编。该输入框可以填写字符、空格,长度不定。在多行项目中填写地址栏各项元素时,你可以应付邮编、地区、城镇,而无需暗示特定的地址结构。
这种通用表单能够为国际地址提供灵活的输入栏,但是错误检查会变得比较困难,因为一些字段会有多种表现形式。而且,由于其灵活性,通用表单没有对国家或文化进行真正优化,它通常有用,但非理想形式。
本文考虑了几种国际地址栏设计方案,但还存在其他类型或者问题。若有其他见解,欢迎发表评论。