这篇文章的主题是关于为何我们应该停止强制使用特定的日期格式(如MM/DD/YYYY),尤其是在2023年的今天。作者在文章中提到了Mark Wyner,一位非常有才华的用户体验专家。Wyner展示了一个例子,说明了在用户界面中如何更好地展示日期格式要求。在他的例子中,改进后的版本将日期格式要求放在输入框上方,而不是作为占位符,这样用户在输入时要求不会消失。
下面是正文~~~
前段时间,偶然看到了 Mark Wyner 的一篇帖子,他是一位非常有才华的用户体验专家。
他在帖子中写道:
翻译:占位符文本是有其适用场景的。将其用于补充信息是可以的。只是不要用它来承载任何关键信息。相反,应将要求放在输入标签的内部。
为了支持他的观点,他提供了这样一个示意图:
如你在左侧看到的,所需的日期格式作为占位符提供。一旦你开始输入日期,提示就会消失。
在右侧,你可以看到一个改进版本,在输入框上方提供了日期格式要求。
这样它就不会消失。他列举了许多为什么这样更好的理由。
我百分之百同意他的观点。更进一步,我会将其放在输入框下方或在主文本上方的单独一行,因为主文本的长度(和方向)可能会因语言而异。
这只是一个例子,用来展示要求应该始终可见。
另一个很好的例子是密码字段。确保其有效的最糟糕方式是一一指出问题:
- 你缺少一个数字
- 你缺少一个特殊字符
- 密码太短
- 密码太长
- 并且一次只显示一个错误
要做得正确,所有要求不仅在用户不符合时可见。
在用户开始输入密码之前,这些要求应该就已经可见!
通过这两个例子,你可以很容易地理解,在所有表单中,在输入之前,所有要求都应该是清晰的。
它作为一个不同主题的例子,但我将用它来说明另一个。
现在是2023年,我们可以在输入日期方面走得更远。
MM/DD/YYYY 不是一个全球通用的日期格式!看看这张地图:
每种颜色代表不同的日期格式。3.39亿人使用它,但有46亿人不使用,其余的人使用这些和各种其他格式的混合。
以下声明是普遍的,与 Mark 的帖子无关:
我们不再需要强制日期格式了!
强制日期格式始于官方纸质表格,你必须以正确的格式填写日期,以降低公务员处理文件时出错的风险。
随着数字化的发展,这种做法被1:1转移到在线表格,并在我们身边停留了二十多年。
这也是因为旧系统无法处理各种日期系统而变得方便。
但快进到2023年,我们没有理由强制日期格式。
我们可以读取用户正在使用的日期格式。可能不是直接的,但是有效。
无论如何,我们可以回退到默认设置。
我们还可以使用同样的格式来解析和验证日期。然后,我们可以拥有一个统一的日期,并将其与 API 和网页应用逻辑一起使用。
这意味着我们可以接受用户喜欢的日期格式。当然,我仍然会提醒用户他的格式,以防万一,但总的来说,它可以使应用程序体验对于国际和多语言观众更好。
讨论
在这部分,我会指出我对自己提议的一些初步考虑。
获取用户日期格式是可行的,并且有效,因为 JS 能够以用户首选的方式格式化日期,所以我们可以逆向操作。但据我所知,这不是一个直接的解决方案。Intl 似乎没有直接获取日期格式的方法。
首先:应该有。
其次:我理解为什么有些人因为这个原因不使用它。
目前,一个polyfill库和流行的日期处理库中的函数在我看来足以使这种方法足够受到管理,可以使用它。
我看到的另一个问题是设计师、产品负责人等人仍然强制使用一种日期格式。现在或将来,教育他们我们不再需要这样做,降低用户的摩擦,将是一个很好的时机。
我看到的另一个问题是,即使在所有股东和 JavaScript 标准库的支持下(可以这么说),一些编程人员仍然会认为这不是一个直接的解决方案。
允许用户以他们使用的格式输入值?绝对不!
实际上,他们已经在小数上这样做了。他们可以使用点或逗号作为小数分隔符。此外,一些应用程序包括首选日期格式在内的这些设置。
对于这些系统来说,允许在输入字段中使用首选日期格式更容易让股东接受,因为他们有时会对浏览器强加的设置望而却步,而且这也会使实施变得简单直接。
还有一些人可能会争辩说,与实施和维护的成本相比,收益很低。我个人见过有人在总共5MB的页面上打败1kB的多余流量。所以我不太容易接受高成本的想法。我们有选择地关注,总是可以考虑用户为中心的方面。
但我同意这不是一个游戏规则改变者,也不提供很多价值。不是总是严格环境所支持的。
但是,如果你想不出如何改善用户体验的主意,这里有。我们仍然同意一些事情,但其价值已消失,我们可以走得更远。
事实证明,标准的 HTML 输入日期字段已经支持这一功能。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。