我想问你是否有理由在应用程序用户界面中将菜单中的所有项目等都大写,例如
- 文件->页面设置
- 编辑->全选
- 帮助->技术支持
为什么我不应该将这些项目标记为 File->Page setup 等?这种大写对我来说似乎是错误的 - 但我不是以英语为母语的人,所以我可能不会挖掘它。
我想问你是否有理由在应用程序用户界面中将菜单中的所有项目等都大写,例如
为什么我不应该将这些项目标记为 File->Page setup 等?这种大写对我来说似乎是错误的 - 但我不是以英语为母语的人,所以我可能不会挖掘它。
在英语中,除了连词(of、for 等)和介词(如 with)之外,通常标题的所有单词都大写。用户界面元素(按钮、标题、菜单项)的格式类似于标题。
我有一个我现在正在使用的软件,它有一个“任务”菜单和 3 个项目,如下所示:
“新任务”的大小写差异对我来说突出了一英里 - 它看起来并不“正确”。
从可用性的角度来看,标题风格的大写(每个单词的首字母大写)增加了标题中非首字母的显眼性。这可以帮助用户更快地在标题中找到关键词以识别和区分菜单项。例如比较:
相对:
理想情况下,这是不必要的,因为您的菜单标题应该以它们的关键区分词开头,但有时这并不能成为可接受的标题。
在 Apple Human Interface Guidelines中,标题样式是菜单项(和命令/按钮)的标准样式。在 Vista 之前,标题样式也是 MS Windows 的标准,当时 Windows 用户体验指南在许多情况下从推荐标题样式切换到句子样式(仅首字母的首字母大写),包括菜单标题(http:/ /msdn.microsoft.com/en-us/library/aa511502.aspx)。我认为这是为应用程序提供会话网络“<a href="http://msdn.microsoft.com/en-us/library/ms997506.aspx" rel="noreferrer">inductive”风格的努力的一部分,其中选项被表述为命令句(例如,“创建电源计划”、“为所有当前项目执行此操作”)。
就个人而言,我会避免为应用程序使用这种冗长的 UI,尤其是对于那些经常被用户使用的应用程序,因此通过扩展坚持标题样式。更多的单词会增加混乱,更多的阅读会减慢用户的速度。事实上,用户倾向于跳过大段文本,因为阅读需要很长时间,因此添加单词通常会在功能上降低清晰度。
因为菜单的格式通常类似于英文标题。在标题中,第一个单词以及任何名词、形容词、动词、副词和代词总是大写。如果它们不是标题中的第一个单词,则冠词和介词通常不大写。
我目前正在与一位同事就此争论不休。就 UI 标准而言,我可能属于苹果阵营,而他则完全属于微软阵营。微软最近一直在推动Downstyle(我不时看到这个名字,关于这种做法,特别是涉及头条新闻,只大写第一个字母)。我的同事声称它“测试良好”。当每个单词都没有大写字母时,用户(毫不奇怪)可以更快地阅读文本。但是,我认为这不应该成为将它用于用户界面元素的理由。我认为这是有原因的,但测试起来可能很棘手。
当用户测试他们从未见过的软件(或网站)时,他们主要是在阅读所有内容(包括 UI)。他们比“显示所有回复”更快地阅读“显示所有回复”。但是,经过一段时间后,我相信用户会转向不阅读 UI 元素,而是依靠更快的方法来获取他们将要点击的目标,例如位置或形状。在这种情况下,“显示所有回复”更容易被挑选出来,因为它显示的形状比“显示所有回复”更清晰(眯起眼睛可能会显示这一点)。由于用户不是在阅读按钮和菜单,而是将他们想要的东西与那个东西的记忆相匹配,所以它测试得更好是因为用户可以更快地阅读它的论点已经分崩离析。Upstyle比Downstyle,但重复访问更容易,最终超越Downstyle。
如果您想查看在 UI 中使用大量Downstyle的网站,请查看 Outlook.com 或 OneDrive.com,它们都是 Microsoft 产品。似乎很明显,在这些网站上使用Downstyle是令人沮丧的失败,我不是这样说的,因为我“习惯于” UpStyle(毕竟,20 多年的相反情况会在我的感知中产生一些非常强烈的认知“噪音”)。尽管如此,我认为它失败了,因为对所有内容都使用了薄的 Helvetica Extra Light 文本,依靠翻转来指出几乎所有可点击的东西(所有这些都不适用于平板电脑用户)以及一般的平坦度(不是一个单一的阴影,即使它有助于消除伪下拉菜单的歧义)使 UI 比它应该的更难使用。
所以我的建议是,保持标题大小写(Upstyle),除非您希望您的网站看起来像 Microsoft 网站,直到他们看到他们的方式错误并重新设计它以看起来像他们以前的方式(就像其他人一样)。