接受长帐号的最佳可用性实践答案

【问题标题】：Best usability practice for accepting long-ish account numbers接受长帐号的最佳可用性实践
【发布时间】：2010-08-23 21:17:41
【问题描述】：

一位用户最近询问（好的，抱怨）为什么我们网站上的一个 19 位帐号被分成 4 个长度为 [5,5,5,4] 的单独文本框。作为最初的设计师，我无法回答这个问题，但我一直认为这样做是为了保持数据质量并可能提供更好的用户体验。

其他更通用的示例包括带区号的电话（10 位连续数字与 [3,3,4]），当然还有 SSN（9 位与 [3,2,4]）

这让我想知道是否有关于该主题的任何已知标准？你什么时候分开你的ID#？特别是在用户体验和最大限度地减少数据输入错误方面。

【问题讨论】：

我不确定可用性，但这是帮助客户记住帐号的好方法。在法国，电话号码也是 10 位数字，我们将它们两两分开，因为记住 00 到 99 之间的 5 个数字比记住 0100000000 到 0599999999 之间的数字更容易。这只是助记符。
用户每次登录时都必须记住并输入那个 19 位数字吗？如果是这样，哎哟！我见过的最好的伪标准包括让用户使用他的电子邮件地址、OpenID 或他们自己设计的字母数字用户名。
@BobK，同意所有这些方法。但我正在寻找关于长身份证号码问题的见解。假设它是 ISBN 号或航空公司预订号或诸如此类，如果您不想容忍长帐号的想法:-)

标签： usability data-quality

【解决方案1】：

我知道对此进行了一些研究，目前我能找到的最多的是Short-term memory 上的维基百科文章，特别是chunking。还有The Magical Number Seven, Plus or Minus Two。

当我向最终用户提供 ID 时，我个人喜欢将其分成 5 个块，这似乎与系统的原始设计者使用的约定相同。除了“感觉正确”之外，我没有任何合乎逻辑的理由可以让你选择这个号码。如果不能花很多钱进行研究，“直觉”和跟随其他系统的争论可能是要走的路。

也就是说，如果您可以通过以下方式使 UI 对用户更有用：

完成后自动从一个字段的末尾移动到另一个字段的开头
当用户在非第一个空字段中按下删除键时，自动从一个字段的开头移动到前一个字段并删除最后一个字符

或

用一个长字段替换它，上面有某种形式的“输入掩码”（不确定这在纯 HTML 中是否可行，但使用其中一个 UI 框架可能是可行的）所以它看起来像 "_____ - _____ - _____ - ____"最后看起来像"1235 - 54321 - 12345 - 1234"

这几乎肯定会让他们更快乐！

【讨论】：

【解决方案2】：

不了解标准，但从个人角度来看：

如果有多个字段，请确保一旦字段已满，光标就会移动到下一个字段。
如果只有一个字段，请允许在该字段中使用空格/破折号/任何内容，因为您可以将它们过滤掉。例如，当站点/程序强制您以“dd/mm/yyyy”格式输入日期时，这真的很烦人，这意味着必须用零填充日/月。 “23/8/2010”应该是可以接受的。

【讨论】：

完全不同意第一点。 AT&T 在输入电话号码时已经习惯了这一点。这样做的问题是，如果您输入错误的数字之一，它会自动将您跳到嵌套框。然后当你回去纠正你的错误时，你会跳回到下一个盒子（因为第一个盒子已经满了）。没有什么比这更烦人了。按 Tab 键是完全可以接受的，而且 IMO 通常比自动推进光标更标准。
在这种情况下，当您返回完整的错误时，它不应该自动返回到空框。正是因为这个原因，所以应该在按键之后跳转到下一个框，而不是在整个框有焦点的时候。
至于 tab 是标准的，我总是惊讶于有多少人不知道按 tab 会前进到下一个框，然后抓住鼠标移动到下一个。对我来说，这使得自动跳跃成为更好的选择。

【解决方案3】：

您需要考虑特定应用程序的更广泛背景。任何设计决策都有利弊，但其影响会因情况而异，因此您每次都必须考虑。

将长数字分成几个字段可以更容易阅读，尤其是如果您选择以与大多数用户相同的方式划分数字。您通常还可以在用户转到下一个字段时立即验证输入，以便更早地指出错误。

另一方面，现在用户很少键入像这样的长数字：大多数时候他们只是从他们选择的任何记事解决方案中复制粘贴它们，以他们拥有的任何格式那里。这意味着单个字段，对长度或允许的字符没有任何限制，突然变得很有意义——你可以过滤掉字符（只要确保在某个时候向用户显示数字的最终形式）。在字段之间移动焦点也存在问题，浏览器会记住以前的值（您只需要选择一个数字，而不是相同数字的 4 个部分）等等。

一般来说，我会说随着浏览器慢慢变得越来越可用，您应该通过使用库存解决方案来利用它们提供的机制，而不是自己发明复杂的解决方案。您今天可能比他们先一步，但两年后浏览器会赶上来，您的网站会很烂。

【讨论】：