大写用户界面中的文本

Question

我想问你是否有理由将应用程序用户界面中的菜单等中的所有项目都大写，例如

• 文件->页面设置
• 编辑->全选
• 帮助->技术支持

为什么我不应该将这些项目标记为文件->页面设置等？ 这种大写对我来说似乎是错误的 - 但我不是以英语为母语的人，所以我可能不会挖掘它。

Answer 1

在英语中，除了连词（of、for 等）和介词（如 with）之外，通常标题的所有单词都大写。用户界面元素（按钮、标题、菜单项）的格式与标题类似。

我现在正在使用一个软件，它有一个“任务”菜单和以下 3 个项目：

• 新任务
• 删除任务
• 任务属性

“新任务”的大小写差异对我来说很明显 - 它看起来并不“正确”。

Answer 2

从可用性的角度来看，标题风格的大写（每个单词的首字母大写）会增加标题中非首字母的显眼度。这可以帮助用户更快地在标题中找到关键词以识别和区分菜单项。例如比较：

• 页面设置
• 页面浏览

对比：

• 页面设置
• 页面浏览量

理想情况下，这是不必要的，因为您的菜单标题应该开始以它们的关键区分词，但有时这并不能成为可接受的标题。

在 Apple Human Interface Guidelines 中，标题样式是菜单项（和命令/按钮）的标准样式。标题样式也是 MS Windows 的标准，直到 Vista，当 Windows 用户体验指南在许多情况下从推荐标题样式切换到句子样式（仅首字母的首字母大写）时，包括菜单标题 (http://msdn.microsoft.com/en-us/library/aa511502.aspx)。我认为这是为应用程序提供会话网络“inductive”风格的努力的一部分，其中选项被表述为命令句（例如，“创建电源计划”、“为所有当前项目执行此操作”）。

就我个人而言，我会避免为应用程序使用这种冗长的 UI，特别是对于那些经常被用户使用的应用程序，因此通过扩展坚持标题样式。更多的单词会增加混乱，更多的阅读会减慢用户的速度。事实上，用户倾向于跳过大段文字，因为阅读需要很长时间，因此添加单词通常会在功能上降低清晰度。

Answer 3

因为菜单的格式通常类似于英文中的titles。在标题中，第一个单词以及任何名词、形容词、动词、副词和代词总是大写。如果它们不是标题中的第一个单词，则冠词和介词一般不大写。

Answer 4

我目前正在与一位同事就此争论不休。就 UI 标准而言，我可能属于苹果阵营，而他则完全属于微软阵营。微软最近一直在推动Downstyle（我不时看到这个名字，关于这种做法，特别是涉及头条新闻，只大写第一个字母）。我的同事声称它“测试良好”。当每个单词都没有大写字母时，用户（毫不奇怪）可以更快地阅读文本。但是，我认为这不应该成为将它用于用户界面元素的理由。我认为这是有原因的，但测试起来可能会很棘手。

当用户测试他们以前从未见过的软件（或网站）时，他们主要是在阅读所有内容（包括 UI）。他们比“显示所有回复”更快地阅读“显示所有回复”。但是，经过一段时间后，我相信用户会转向不阅读 UI 元素，而是依靠更快的方法来获取他们将要点击的目标，例如位置或形状。在这种情况下，“显示所有回复”更容易被挑选出来，因为它显示的形状比“显示所有回复”更清晰（眯起眼睛可能会显示这一点）。因为用户不是在阅读按钮和菜单，而是将他们想要的东西与那个东西的记忆相匹配，所以它测试得更好的论点是因为用户可以更快地阅读它。测试这一点的正确方法可能是查看用户在 Upstyle 中开始时是否比在 Downstyle 中慢，但在重复访问时更容易，最终超过 低调.

如果您想查看在 UI 中使用大量 Downstyle 的网站，请查看 Outlook.com 或 OneDrive.com，它们都是 Microsoft 产品。似乎很明显，在这些网站上使用 Downstyle 是令人沮丧的失败，我不是这样说的，因为我“习惯于”UpStyle （毕竟，20 多年看到相反的情况会在我的感知中产生一些非常强烈的认知“噪音”）。尽管如此，我认为它失败了，因为对所有内容都使用了薄的 Helvetica Extra Light 文本，依靠翻转来指出几乎所有可点击的东西（所有这些都不适用于平板电脑用户）以及一般的平坦度（不是一个单一的阴影，即使它有助于消除伪下拉菜单的歧义）使 UI 比应有的更难使用。

所以我的建议是，保留标题大小写 (Upstyle)，除非您希望您的网站看起来像 Microsoft 网站，直到他们发现他们的方式错误并重新设计它以看起来他们过去的方式（就像其他人一样）。