UX 和 HTML5：让我们帮助用户填写您的移动表单（第 1 部分）

表单是用户与您的网站（和移动应用程序）进行的最基本的主要交互之一。 他们将人们联系在一起并让他们交流。 他们让他们评论文章并向作者解释他们如何强烈反对他们所写的内容。 他们让人们直接在约会应用程序上聊天以结识“那个”。 无论是论坛、产品订单、在线社区、账户创建还是在线支付，表单都是用户在线生活的重要组成部分。

现在是 2018 年，在全球范围内，我们的移动用户数量超过了桌面用户。 然而，我们仍然将这些用户视为网络的二等公民。 每个人都在写和谈论用户体验。 那么，为什么，为什么，为什么这么多网站和产品仍然做错了。 为什么他们的移动用户体验会损害半个世界？ 为什么现在仍然很痛苦，为什么现在预订航班和以移动形式注册帐户仍然超级困难？ 用户期待更好！

推荐阅读：万维网，不是富裕的西方网络

这是两篇系列文章的第一部分。 在这篇文章中，我将总结一些基本的最佳实践来改进您的移动表单，包括可扫描性和可读性。 我将指导您完成标签和输入放置、大小和优化。 我们将看到如何选择正确的表单元素来降低交互成本。 最后，您将学习如何预防和处理移动表单上的错误。

在第二部分，我将仔细研究特定的移动功能和 HTML5 表单元素，我们将超越经典的表单元素，制作独特而有趣的 Web 应用程序和网站。

注意：虽然本文中的大部分代码增强都与 Web 相关（因为我不了解 Swift 或 Java），但可用性最佳实践适用于移动应用程序。

表单设计 101：优先考虑可扫描性和可读性

“表单是名称、值、对，在一种结构中，用于在计算机上存储数据，这些数据作为标签和人类的输入字段被吐出。” 这是 Luke Wroblewski 在一次会议上的直接引述。 和他一样，我相信大多数表单可用性问题都来自这种为用户提供数据库结构的倾向。

强大的信息架构

要构建更好的表单，您首先需要远离数据库的结构。 尝试了解用户希望如何填写表格。 这就是对表单进行一些可用性测试和用户研究变得方便的地方。 用户心智模型是一个 UX 概念，可以帮助您。 尼尔森诺曼集团将其描述为“用户对手头系统的看法”。 请您的测试人员大声思考并告诉您他们将如何填写表格。 他们期望哪些步骤？ 什么先来？ 接下来是什么？ 这将使您更好地了解如何以更用户友好的方式构建表单。

视觉上对属于一起的字段进行分组也将帮助用户填写表单。 在代码中，使用fieldset标记以编程方式对它们进行分组。 它还将帮助屏幕阅读器理解层次结构。

如果表单很长，默认情况下不要公开所有内容。 对你展示的东西要聪明。 明智地使用分支来仅显示人们需要的字段。 例如，在结帐表单中，不要显示所有发货选项的所有详细字段。 这将使用户不​​知所措。 显示足够的信息以帮助他们选择正确的运输选项。 然后，仅显示与该选项相关的详细信息和字段。

用户的注意力会随着时间的推移而变短：在表格末尾询问可选的内容。 例如，如果您的表格是客户满意度调查，请在最后询问人口统计信息。 更好的是，如果可能的话，自动填充它们。 仅向用户询问必要的内容。

最后，提前计划本地化：当您的表单被翻译后会发生什么？ 比如说，对于德国人来说会发生什么？ 你的设计还能用吗？

标签放置和输入优化

单列布局效果最好

由于空间不足，您无法在移动屏幕上放置标签和字段：

• 以单列布局呈现字段。 移动设备上没有多列的空间。 无论如何，多列表单在桌面上也不是一个好主意。
• 在纵向模式下，最好将标签放在字段顶部，以便用户在键入时可以看到字段中的内容。

• 在横向模式下，屏幕的高度会降低。 您可能希望将标签放在左侧，将输入放在右侧。 但是测试它以确保它有效。

有关标签放置的更多信息，请参阅 Baymard Institute 的“移动表单可用性：在字段上方放置标签”。

标签应该清晰可见，并且可以在没有上下文的情况下使用

请记住，一旦某个字段获得焦点，键盘就会打开，并且至少会占据屏幕区域的三分之一。 在小型移动屏幕上，用户还必须滚动才能填写表格。 这意味着他们在填写表格时会丢失部分上下文。 相应地计划：

• 您的标签应该是清晰可见的文本，可以在没有上下文的情况下阅读和理解。 用户应该能够将每个标签和字段对作为单独的任务完成，即使他们失去了上下文。

• 尽可能避免使用行话、缩写和行业特定语言。
• 始终如一。 如果您在标签中使用过一次“客户”，请坚持使用该词。 以后避免使用“客户端”，因为它可能会使用户感到困惑。
• 字体大小应该足够大。 尽快在真实设备上测试您的表单，并相应调整大小。
• 对于某些用户来说，全大写文本可能难以阅读。 您可能希望避免在标签上使用全大写文本。
• 标签副本应简短且可扫描。 如果某个领域需要澄清，请不要将其放在标签中。 请改用字段描述。

输入大小最佳实践

如果可能，输入元素的大小应该与预期内容的大小相匹配。 这将帮助用户快速填写表格并了解预期内容。

使用掩码避免在移动设备上拆分输入

不要仅仅为了格式化而拆分输入。 在移动设备上尤其烦人，用户无法使用键盘在字段之间导航。 它需要额外的点击才能转到下一个字段来填写表格。 您可能会想，“但是当我在该字段中获得所需数量的字符时，我会自动将焦点放在下一个字段上”。 那可以工作。 但是您将控制 UI，这对于用户来说变得不可预测。 此外，如果您自动将它们发送到下一个字段并且他们需要更正最后一个字段中的某些内容，那将是一件痛苦的事情。 最后，猜测拆分输入的强制要求更加复杂。 所以，让我们停止玩“但是如果”游戏，不要拆分输入。

我明白了：您仍然希望能够将用户数据格式化成小块，以帮助他们填写您的字段。 你是完全正确的。 为此，您可以使用 mask 。 无需拆分输入，只需在其顶部放置一个遮罩，以直观地帮助用户填充它。 这是一个帮助用户填写信用卡字段的面具的视频示例：

掩码通过引导用户使用正确的格式来帮助防止错误。 避免逐渐暴露它们——直接显示格式。 另外，避免在 mask 中放置假值。 用户可能会认为它已经被填满了。 这就是为什么我在演示中将数字替换为一个小“X”。 找出最适合您的输入类型的方法。

最后，请记住，某些数据可能因国家/地区而异，有时格式也会发生变化（例如电话号码）。 相应地计划。

高效字段说明

显示有效的字段描述可以在无缝和痛苦的表单体验之间产生差异。

描述可以用来做什么？

描述可以通过多种方式帮助用户。 这里有一些例子。

• 你到底要什么？
  

  无论出于何种与数据库相关的原因，一些货运公司都会要求提供“地址 1”和“地址 2”字段。 这对用户来说非常令人困惑，但您可能在这里别无选择。 添加描述字段以帮助用户了解他们需要在每个字段中输入的内容。

  

  首字母缩写词和缩写词也是如此。 我知道我说过你应该避免它们，但有时你不能。 例如，如果您为特定行业处理复杂的表格，它们可能有自己的一组缩写。 任何需要填写表格的新用户可能（还）不熟悉这些缩写。 在某处提供描述将对他们有所帮助。

• 为什么需要这些信息？
  如果用户不了解您为什么需要它以及您将如何使用它，他们可能不愿意向您提供个人信息。 但有时您仍需要出于法律原因要求提供此类信息（例如销售酒类的网站的出生日期）。 在此处使用字段描述将帮助用户理解为什么需要此类信息。
  
  

  在电子商务网站上，您可能需要询问用户的电话号码，以防送货员需要联系他们。 这是一个正当的理由。 因此，再次使用描述向电子商务用户解释为什么您需要他们的电话号码。

  

“我在哪里可以找到信息？”
如果您的用户需要在其他地方找到某些信息才能填写表格，请告诉他们在哪里可以找到它。 我开发了一个移动应用程序，让用户可以跟踪他们的房子。 用户需要使用序列号将应用程序与监控设备配对。 在设备上找到这个序列号并不容易； 它需要一些指导。 我们加了一点？ 序列号字段旁边的按钮。 该按钮打开一个显示图片和一些指示的模式，以帮助用户了解在哪里可以找到监控设备上的序列号。 电子商务网站对促销代码也是如此：它们提供指示符，告诉用户在哪里可以找到代码。



• “我应该如何格式化信息？”
  有些字段需要特定的格式。 在这种情况下，使用描述让用户预先知道格式规则。 这里有一些例子：
  • 电话号码：我需要在字段前面输入国际拨号代码（+xx）吗？
  • 有最大长度吗？ 移动端的 Twitter 在这方面做得很好。
  • 处理货币金额时，格式是逗号（如 10,000）还是空格（如 10,000）？
  • 您期望日期的格式是什么？ 我会让你在维基百科上查一下那是什么噩梦。 DD MM YY 和 MM DD YY 之间的差异可能会给用户在在线预订时带来*很多*的麻烦。
  请注意，许多格式问题可以通过输入掩码解决。 我们将在本文后面讨论（或者如果您不耐烦，可以直接进入）。

  

如何显示说明

在上面的示例中，我们看到了几种显示字段描述的方法。 以下是要执行的操作的摘要：

• 内联描述应直接可见并显示在字段旁边。
• 如果您需要更深入的内容描述，您可以使用tooltips 或 modals 。 工具提示通常在桌面悬停和在移动设备上点击时触发。 模式也是如此：例如，当用户点击帮助图标或“查看更多”链接时打开它。

小心占位符

我明白了：删除移动设备上的字段以获得空间并改用占位符是很诱人的。 我们都走上了这条路。 但请不要。 HML5 规范对此很清楚：“占位符属性表示旨在帮助用户输入数据的简短提示（单词或短语）”。 这就是为什么：

• 当用户开始输入时，占位符消失。 然后，用户必须依靠短期记忆来记住他们应该在字段中输入的内容。 如果他们不能，他们将需要清空该字段才能看到指示。
• 用户在提交之前很难仔细检查字段，因为字段不再有任何标签指示。
• 一旦提交了字段，就很难从错误中恢复，因为同样没有标签可以帮助用户。

即使您使用带有标签的占位符，您仍然可能会遇到一些问题。 很难区分填充字段和带占位符的字段。 我是一名 UX 设计师，撰写有关移动表单设计的文章，甚至上周我也被其中一个人欺骗了。 如果它发生在我身上，它也会发生在你的用户身上——相信我。 最后，大多数占位符都有浅灰色文本，因此您可能也会遇到一些对比度问题。

如果您想更深入地了解这个主题，有一篇很棒的文章，名为“Placeholder Attribute Is Not A Label，还有 Joshua Winn 和 FeedbackGuru 详细介绍了为什么这是一个坏主意。 Nielsen Norman Group 还写了一篇关于该主题的文章，名为“表单字段中的占位符是有害的”。

占位符在 HTML5 中不是强制性的。 从可用性的角度来看，您当然不需要在表单的每个字段中都使用占位符。 但是随着 Bootstrap 和其他框架的大量采用，看起来很多人只是复制和粘贴组件。 这些组件有占位符，所以我想人们觉得有义务在代码中的占位符中添加一些东西？ 如果表单的占位符看起来像“请在此处填写您的标签”，那么您做错了。

尽管如此，字段内的标签对于字段可预测的短格式仍然可以很好地工作。 登录表单是一个很好的选择。 但请不要使用 HTML5 占位符来编码。 在代码中使用真正的标签并使用 CSS 和 JavaScript 移动它。

自从 Android 的 Material Design 成功之后，一种模式开始出现：浮动标签。 当字段未填写时，此标签位于字段内，因此在移动设备上占用的垂直空间要少一些。 当用户开始与字段交互时，标签会移动到字段上方。

这看起来是一种有趣的方式来获得一些空间，而不会遇到上面提到的“占位符代替标签”问题。 然而，它并没有解决用户可能将占位符误认为填充内容的问题。

成功表单的交互成本降低

降低用户完成任务的交互成本（即点击次数、滑动次数等）将帮助您构建无缝的表单体验。 有不同的技术可以实现这一目标。 让我们详细看看其中的几个。

互联网上的一项神奇研究告诉我减少字段的数量

更多字段意味着更少的转化，对吧？ 您可能已经遇到过“我们将订阅表单从 11 个字段减少到 4 个字段，并将转化率提高了 160%”的研究。 这是一个经典。 而且，如果您查看他们的联系表格，那是有道理的。 为什么用户要填写 11 个字段只是为了联系公司？ 你不能要求那些几乎不认识你的人做出这么大的承诺，对吧？

首先只询问有用的信息。 为什么需要一个人的性别才能为他们创建帐户？ 如果您的订阅表格是针对在线服务的，为什么地址有两行？

只询问您需要的信息。 然后在上下文中询问信息。 如果您有一个电子商务网站，与注册时相比，用户可能更倾向于在结帐过程的运输部分向您提供他们的地址。 它将使您的电子商务注册表单在移动设备上更容易填写！

此外，不要盲目相信你在互联网上找到的每一个统计数据和研究。 还记得 11-fields-to-4 研究吗？ 最近的另一项研究表明，通过将字段从 9 个减少到 6 个，转化率下降了 14%。 令人震惊，不是吗？ 为什么？ 好吧，他们删除了最吸引人的领域。 长话短说，他们又回到了 9 个领域，将最重要的放在首位，瞧，转化率增加了 19.21%。

底线是，虽然这些研究很有趣，但这些网站不是您的网站。 不要盲目相信您在互联网上找到的第一项研究。

所以，你可以做什么？ 测试。 测试。 并测试！

• 进行一些用户测试以查看完成移动表单的时间。
• 测量辍学。
• 测量某些领域的问题。
• 衡量与某些领域相关的挫败感。 用户提供这些信息的意愿如何？ 这些信息有多私人？

优化触控交互

使控件易于触摸

如果您的字段太小或难以到达，用户会犯错误并且需要额外的交互来实现他们的目标。 还记得菲特定律吗？ 您也可以将其应用到移动设计中：通过增加触摸目标大小使您的标签、字段和表单控件易于点击。 对于 web 上的标签，多一点填充可以增加可触摸区域。 有时您还需要在元素之间添加一些边距以避免错过点击。

此外，不要忘记通过配对for和 ID 值将标签与其组件链接。 这样，如果用户错过了对标签的点击，相应的字段仍将获得焦点。

Steven Hoober 对触控区域进行了一些用户研究。 您可以在“为触控而设计”中找到摘要。 根据他的发现，他制作了一个小小的塑料尺子工具：移动触控模板。 该工具可以帮助您确保您的触摸区域足够大以适应移动表单，更普遍地适用于移动设计。

要了解有关触控设计的更多信息，您可以阅读以下内容：

• “手指友好型设计：理想的移动触摸屏目标尺寸”
• “拇指区：为移动用户设计”

提供反馈

移动用户没有鼠标（不是开玩笑），所以他们不会得到桌面用户在点击按钮时得到的“点击”反馈。 移动表单用户在与元素交互时需要清晰的反馈：

• 为用户正在与之交互的表单字段提供焦点状态。
• 当用户与按钮交互时提供视觉反馈。

我不是材料设计对按钮的连锁反应的忠实粉丝。 但我必须承认，当用户与按钮交互时，Android 上的动画会提供清晰的反馈。

兑现下一个和上一个按钮顺序

最后，尊重移动键盘上的下一个和上一个按钮。 用户可以使用它们快速导航字段。 tabindex顺序应该与字段和组件的视觉顺序相匹配。

尽可能避免在移动设备上使用下拉菜单

Web 上的下拉菜单（HTML 选择元素）需要大量的选项卡和交互。 因此，正如 Luke Wroblewski 所说，它们应该是最后的 UI。 在许多情况下，许多其他 UI 组件比下拉​​菜单效果更好。

如果您有两到四个选项，则分段控件和单选按钮是下拉菜单的不错选择。 当您可以直接在一个屏幕上显示所有选项时，为什么要隐藏下拉菜单下的选项？ 请注意，与单选按钮一样，分段控件是互斥的。

国家/地区列表是组件的理想候选者。 一百多个国家的下拉列表是移动设备上的交互噩梦。 如果您正在寻找阿富汗（在列表的开头）或津巴布韦（在列表的末尾），那也没关系。 如果您正在寻找 Luxembourg，您最终会陷入一场滚动游戏以到达列表的中间，到字母 M 太远，试图回到 L，等等。

长下拉菜单可以替换为预测文本输入字段。 当用户开始输入 L 时，界面会建议九个国家。 如果他们添加一个 U -瞧！ — 卢森堡。 四个交互而不是两个，与下拉菜单的多达六个或七个滚动交互。

如果您需要用户选择日期，请忘记将其拆分为日、月和年下拉列表，就像人们习惯在纸质表格上所做的那样。 用日期选择器替换多个日期下拉列表。 HTML5 输入type=date在大多数情况下都有效。 但是您可能有一些特殊需求，最终会在 JavaScript 中构建自己的日期选择器，特别是如果您从事预订业务（酒店、汽车、航班）。

在他的文章“Mobile DropDowns Revisited”中，Klaus Schaefers 解释了使用日期选择器来确定到达和离开日期如何使交互速度提高 60%。

让我们坚持预订业务。 假设用户需要将多个旅行者添加到他们的行程中。 您可以**用*步进器**替换下拉列表*来选择乘客人数。 步进器是一种控件，允许用户通过点击+和-按钮来增加和减少值。 当必须添加少于六个人时，这往往会更快。 它也更直观。 下面是在 Android 原生 Airbnb 应用程序中用于选择客人的步进器示例，以及在 Kayak 的移动优化网站上用于添加乘客的步进器示例。

下拉列表的最后一个替代方案是列表视图。 例如，这些选项将列在特定的子视图中，如单选按钮。 这主要是 Android 设置的工作方式。

通过自动完成变得聪明

如果你想降低表单的交互成本，那就聪明点。 不要询问您可以根据用户提供的其他信息自动检测或猜测的信息。 尽可能多地自动完成和预填充。

地点和地址

如果用户搜索地点或需要输入地址，您可以提供自动完成功能来帮助他们。 当他们键入时，API 会为他们填写地址的其余部分。 这也减少了错误。

你可以使用：

• Google 地方信息 API
• 基于 OpenStreetMap 的 Algolia Places

在法国和许多其他国家，您可以根据区号猜测城市。 因此，如果法国用户输入区号，您可以自动完成或至少建议城市。 我的国家卢森堡很小（不要取笑我）。 我的区号与我的街道相关联。 因此，如果我输入我的区号，表格甚至应该能够建议我的街道。

信用卡

另一个容易自动检测的领域是信用卡。 您无需询问用户他们拥有哪种类型的信用卡。 您可以根据他们输入的初始数字自动检测到这一点。 甚至还有一个图书馆可以为您完成这项工作。

使用 HTML5 自动完成（自动填充）

HTML 自动完成属性可以根据用户之前的输入预填充字段。 此属性具有开和关状态。 一些聪明的人已经开始制定一个规范，以使其更强大，并扩展表单字段的自动完成属性。 WHATWG 也有一个有趣的列表。

Chrome 和其他移动浏览器已经支持信用卡和姓名的一些扩展值。 这意味着用户可以使用他们在其他网站上使用的姓名和信用卡数据预先填写表格。

简而言之，当您必须在不同系统之间进行选择时，请计算每个系统需要的交互次数。

错误发生：处理移动表单中的错误

我们迈向更好的移动表单的最后一步是处理错误和错误。 我们可以尽量减少错误以减轻用户的认知负担。 我们还可以帮助他们从错误中恢复，因为无论您的表单设计多么出色，错误都会发生。

填写表格时避免错误

“预防胜于治疗，”我母亲常说。 表单设计也是如此：防止错误将改善您的移动表单的体验。

显式格式限制

“做事要保守。 对你从别人那里接受的东西要自由。” 这种稳健性原则也可以应用于表单字段。 如果可能，让用户以任何格式输入数据。

如果您认为需要限制用户可以在该字段中输入的内容，请先问自己“为什么”。 在用户体验领域，我们有一种叫做“三个为什么”的技术。 如果答案是“因为 blah blah 数据库”，也许是时候改变了。 例如，你为什么拒绝在用户名字段中使用 e、a 和 o 等特殊字符？ 我写了一篇文章，解释当我尝试输入“Stephanie”作为用户名时，表单对我来说是多么粗鲁。 我仍在试图找出一个很好的理由（除了数据库原因）。

如果您有充分的理由要求用户提供特定格式，请提前说明。 您可以使用 HTML5占位符向用户提示数据应该是什么样子，但同样要小心。 您还可以使用本文开头介绍的所有字段描述技术。 最后，输入掩码可以引导用户使用正确的格式。

标记必填字段（和可选字段）

不要等待用户提交完成一半的表单来告诉他们必填字段。 如果一个字段是强制性的，用户应该知道它。 用星号 ( * ) 和图例标记必填字段已成为表单的标准模式。 好的部分是它不占用太多空间。 问题是它没有语义价值，因此如果编码不当并且如果您依赖人们的表单交互习惯，它可能会导致可访问性问题。

您可以改为使用“必填”（或“强制”）和“可选”字样显式标记必填和可选字段。 Baymard Institute 和 Luke Wroblewski 都同意这一点。 这避免了移动设备上长表单的歧义，例如在使用滚动条时，继续进行其他操作，然后返回并且不记得必填字段是否标有星号或其他内容。

最终，如何标记这些字段的决定将取决于字段的设计和长度以及上下文。 再次，了解您是否做出正确决定的最佳方法是测试表格。

合理的默认值

请注意表单中的默认选择选项。 当我申请上一份工作时，有一张信息表。 婚姻状况是可选的。 他们将下拉列表中的第一个元素“离婚”作为默认字段。 所以，我要么不回答（因为它是一个可选字段），让系统相信我离婚了，要么纠正这个并披露我的实际婚姻状况，即使我不想。

另外，要注意性别。 同样，对于不想透露的人有一个选择； 明确你为什么要询问他们的性别； 更好的是，要求代词，或者不要问你是否真的不需要。 如果您对此主题感兴趣，我推荐“为性别多样性和包容性设计表格”。 如果性别是可选的，同样，不要自动检查第一个选项，否则人们将无法取消选中该单选按钮并选择不回答。

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• 登录时
  在登录表单中，屏蔽/取消屏蔽密码选项将极大地改善用户体验。
  亚马逊在其登录表单中迭代密码方面有着有趣的历史。 它曾经有一个您看不到密码的版本。 下一次迭代允许用户展示它。 然后，默认情况下会显示密码，您可以将其隐藏。 这是 2015 年的样子：

  

  亚马逊测试了最后一个版本，60% 的人对此表示怀疑。 因此，他们将未选中的“隐藏密码”复选框替换为“显示密码”复选框。 这将在用户键入时在字段下方以较小的字符显示密码。 这是撰写本文时的样子：

  

  如您所见，总有改进的余地。

内联验证

如果您熟悉可用性原则，您可能知道格式塔邻近法则。 在移动设备上，避免在用户点击提交按钮后页面顶部没有上下文信息的错误摘要。

相反，错误消息应该位于错误本身附近。

实时验证

您也不需要等到用户点击提交按钮。 您可以在用户填写字段时验证字段并显示反馈。

一些提示：

• 如前所述，密码字段将受益于每次击键的实时验证和反馈。
• 您可能还想在创建帐户时实时验证用户名，以确保它们可用。 Twitter 在这方面做得很好。
• 不要验证每一次击键。 等到用户完成输入。 （对 Web 表单使用 JavaScript blur ，或者等待几秒钟来检测不活动。）

注意：*Mihael Konjevic 写了一篇关于“表单中的内联验证：设计体验”的精彩文章。 他解释了“早奖励，晚惩罚”的概念。*

“如果用户正在输入处于有效状态的字段中的数据，请在输入数据后执行验证。”

“如果用户在处于无效状态的字段中输入数据，请在数据输入期间执行验证。”

颜色很重要

我并不是说颜色很重要，只是因为我现在的姜黄色、粉红色和紫色的头发颜色。 颜色在表单设计中真的很重要。

网络上有一些您不想打破的约定。 非色盲用户知道红色表示错误，黄色表示警告，绿色几乎总是表示确认或成功。 最好坚持这三种颜色。 不过，红色会让人们感到焦虑。 用户可能认为他们犯了一个非常严重的错误。 使用橙色或黄色作为错误消息可以减少恐慌。 黄色和橙色的问题在于很难找到适合色盲的色调。

说到色盲：颜色不应该是传达错误信息的唯一方式。 这是一个可访问性标准。

在下面左侧的示例中，有错误的字段为橙色，已更正的字段变为绿色。 我用色盲测试工具截取了中间的截图：你已经无法区分默认的灰色边框和绿色边框了。 在最后一个屏幕截图中添加一些图标可确保将错误消息传达给色盲人士。

从错误中恢复：编写用户友好的错误消息

在这一点上，我们已经尽我们所能来帮助用户填写我们的表格并避免错误。 但有时，尽管我们尽了最大的努力，错误还是会发生。 是时候弄清楚如何帮助用户从这些错误中恢复过来了。

首先，记住：不要劫持系统的控制权。 如果问题不严重，用户应该能够尽可能多地继续与界面的其余部分进行交互。 尽可能避免那些阻止用户的 JavaScript 警报错误消息和模式。 此外，如果您的表单需要一些权限，请在使用流程中请求它。 如果未授予权限，请不要将其视为错误，因为事实并非如此。 请注意您在此处使用的副本。

你不是机器人，你的用户也不是

机器人很酷，我知道。 但你不是机器人，你的用户也不是。 然而，如此多的错误消息仍然写得如此糟糕。 以下是一些关于人性化错误消息的提示：

• 永远不要显示原始错误消息，例如“发生了 2393 类型的错误。 服务器无法完成操作。” 相反，用人类语言解释发生了什么以及为什么会发生。
• 永远不要显示死胡同的错误消息，例如“发生错误”。 而是建议从错误中恢复的方法。 编写可操作的副本。
• 切勿使用“重试”按钮显示模糊的错误消息，例如“找不到具有指定主机名的服务器”。 相反，使错误消息信息丰富且一致。 请不要听起来像机器人。
• 不要假设人们知道消息的上下文。 您的用户不是精通技术的极客。 相反，用通俗易懂的语言向他们解释如何从这个错误中恢复，不要使用技术术语。

注意您在消息中使用的语言

无论你写什么，都要避免让人们对错误感到愚蠢。 如果可能的话，省略否定词； 他们往往会吓到人们，使他们更加焦虑。 改用礼貌、积极、肯定的语气。

不要责怪用户的错误； 而是责怪系统。 系统不会记仇的，我保证。 将用户的注意力转移到系统无法处理该动作的原因上，并向他们解释如何找到解决方案。

一个小技巧是大声读出你自己的信息。 它将帮助您听到它是否有效或过于苛刻或过于随意等。

您还可以通过错误消息获得创意，并结合图像和幽默以减少它们的威胁性。 不过，这实际上取决于您品牌的身份和基调。

为了帮助您编写更好的错误消息，我建议您阅读以下内容：

• “没有 UX 作家的产品团队的 6 点显微检查清单”
• “错误信息的艺术：在出现问题时写出清晰、有用的副本”

提交表格的时间

用户已填写表格，没有更多错误，一切看起来都很好。 最后，是时候提交表单了！

第一条规则是，不要屏蔽提交按钮。 严重地！ 我想知道这个想法是什么扭曲的想法，但我已经以某些形式看到了它。 只有在填写完所有必填字段且没有任何错误时，才会显示提交按钮。 用户想知道是否有问题或表单的按钮未加载或网站已损坏等令人不安。

如果您不希望用户在缺少必填字段或存在验证错误时点击提交按钮，请在submit输入上使用disabled HTML 属性。 一旦表单有效并准备好提交，您将需要使用 JavaScript 重新启用该按钮。

如果您有主要和次要号召性用语，请使用颜色、大小和样式来显示层次结构。

如果想知道确认按钮应该出现在取消按钮之前还是之后，我（和很多其他人）也是如此。 如果您正在构建本机应用程序，请遵守操作系统指南。 自从 Android 在其第四版中更改了按钮位置以来，它变得特别有趣。 在网络上，它更复杂，因为没有真正的指导方针。 无论使用哪种操作系统，以下是针对移动设备优化的提交按钮的一些一般准则：

• 发出号召性用语，描述性的、可操作的动词。
• 当用户点击它时提供视觉反馈。
• 如果您有两个按钮，请突出主要操作。
• 除非您正在处理非常特定的后台企业表单（在这种情况下，您将面临很多针对移动设备进行优化的挑战），否则请避免使用重置按钮。 用户可能会将其与提交按钮混淆，并且会意外丢失所有数据。

结论

在第一部分中，我讨论了许多小技巧，可以将您的表单提升到一个新的水平并帮助用户填写它。其中一些通用指南和移动最佳实践可能无法 100% 奏效——这就是问题所在与最佳实践。 因此，请始终在真实用户和真实设备上测试您的表单，并根据用户的特定需求和体验调整指南。

此外，做一些回归和自动化功能测试——同样，在真实设备上。 Chrome 的移动模拟器不足以测试触摸优化的表单。 我这样说是因为我推出了一个电子商务网站，其中包含一个无法在移动设备上运行的搜索表单。 我们只使用模拟器进行了自动化测试。 这就是发生的事情。 搜索表单隐藏在搜索图标下。 您可以点击该按钮，该按钮会打开一个带有搜索字段的框。 它通过将鼠标悬停模拟为触摸事件来工作。 我们测试了点击按钮，它打开了盒子。 没有人试图发起搜索。 因此，没有人（甚至客户）看到搜索字段在用户尝试与之交互时就消失了。 发生了什么？ 当输入元素获得焦点时，按钮失去了悬停状态，因此它关闭了带有字段的框。 自动化测试无法捕捉到这一点，因为输入没有失去焦点。 因此，我们推出了一个没有移动搜索功能的电子商务网站。 不是超级体验。

在本系列的第二部分，我们将看到更高级的移动专用技术。 我们将看到如何使用很酷的 HTML5 功能来格式化字段，以及如何使用移动功能将移动用户体验提升到一个新的水平。