接受长帐号的最佳可用性实践
最近，一位用户询问（好吧，抱怨）为什么我们网站上的 19 位帐号被分成 4 个长度为 [5,5,5,4] 的单独文本框。作为原始设计师，我无法回答这个问题，但我总是假设这样做是为了保持数据质量，并可能提供更好的用户体验。
其他更通用的示例包括带区号的电话（10 个连续数字与 [3,3,4]），当然还有 SSN（9 位数字与 [3,2,4]），
这让我想知道是否有任何已知的标准关于主题？你什么时候分开你的ID#？特别是在用户体验和最大限度地减少数据输入错误方面。
A user recently inquired (OK, complained) as to why a 19-digit account number on our web site was broken up into 4 individual text boxes of length [5,5,5,4]. Not being the original designer, I couldn't answer the question, but I'd always it assumed that it was done in order to preserve data quality and possibly to provide a better user experience also.
Other more generic examples include Phone with Area Code (10 consecutive digits versus [3,3,4]) and of course SSN (9 digits versus [3,2,4])
It got me wondering whether there are any known standards out there on the topic? When do you split up your ID#? Specifically with regards to user experience and minimizing data entry errors.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我知道对此有一些研究，目前我能找到的最多的是关于 的维基百科文章短期记忆，特别是分块。还有神奇的数字七，加或减二。
当我向最终用户提供 ID 时，我个人喜欢将其分成 5 个块，这似乎与系统原始设计者使用的约定相同。除了“感觉不错”之外，我没有任何合理的理由可以告诉你选择这个数字。由于无法花费大量资金进行研究，“直觉”和遵循其他系统的争论可能是正确的选择。
也就是说，如果您可以通过以下方式使 UI 对用户更可用：
，或者
"_____ - _____ - _____ - ____"，最终看起来像"1235 - 54321 - 12345 - 1234"它几乎肯定让他们更快乐！
I know there was some research into this, the most I can find at the moment is the Wikipedia article on Short-term memory, specifically chunking. There's also The Magical Number Seven, Plus or Minus Two.
When I'm providing ID's to end users I, personally like to break it up into blocks of 5 which appears to be the same convention the original designer of your system used. I've got no logical reason that I can give you for having picked this number other than it "feels right". Short of being able to spend a lot of money on carrying out a study, "gut instinct" and following contentions from other systems is probably the way to go.
That said, if you can make the UI more usable to the user by:
OR
"_____ - _____ - _____ - ____"and ends up looking like"1235 - 54321 - 12345 - 1234"It would almost certainly make them happier!
不知道标准，但从个人角度来看：
Don't know about standards, but from a personal point of view:
您需要考虑特定应用程序的更广泛背景。任何设计决策总是有利有弊，但它们的影响会根据情况而变化，所以你每次都必须思考。
将长数字拆分为多个字段可以使其更易于阅读，尤其是当您选择与大多数用户相同的方式划分数字时。您通常还可以在用户转到下一个字段时立即验证输入，以便更早地指出错误。
另一方面，用户现在很少键入像这样的长数字：大多数时候，他们只是从他们选择的任何笔记保存解决方案中以任何格式复制粘贴它们。这意味着没有任何长度或允许字符限制的单个字段突然变得很有意义——您无论如何都可以过滤掉字符（只需确保在某个时刻向用户显示数字的最终形式）。在字段之间移动焦点也存在问题，浏览器会记住以前的值（您只需选择一个数字，而不是同一数字的 4 个部分）等。
总的来说，我想说，随着浏览器慢慢变得越来越多，为了更有用，您应该通过使用库存解决方案来利用它们提供的机制，而不是自己发明复杂的解决方案。今天你可能比他们领先一步，但两年后浏览器就会迎头赶上，你的网站就会很糟糕。
You need to consider the wider context of your particular application. There are always pros and cons of any design decision, but their impact changes depending on the situation, so you have to think every time.
Splitting the long number into several fields makes it easier to read, especially if you choose to divide the number the same way as most of your users. You can also often validate the input as soon as the user goes to the next field, so you indicate errors earlier.
On the other hand, users rarely type long numbers like that nowadays: most of the time they just copy-paste them from whatever note-keeping solution they have chosen, in whatever format they have it there. That means that a single field, without any limit on lenght or allowed characters suddenly makes a lot of sense -- you can filter the characters out anyways (just make sure you display the final form of the number to the user at some point). There are also issues with moving the focus between fields, with browsers remembering previous values (you just have to select one number, not 4 parts of the same number then), etc.
In general, I would say that as browsers slowly become more and more usable, you should take advantage of the mechanisms they provide by using the stock solutions, and not inventing complex solutions on your own. You may be a step before them today, but in two years the browsers will catch up and your site will suck.