设计完美的日期和时间选择器(2017)

2020-05-19 22:56:03

每隔一个星期二,我们都会发送一份时事通讯,介绍有关前端和用户体验的有用技术。在您的收件箱中订阅并获取智能界面设计核对表PDF。

在过去的几年里,我花了很多时间与不同的公司合作,尝试各种方法,并在可用性测试中对它们进行研究。本系列文章总结了在此期间所做的观察和实验。在接下来的几个月里,我们将探索从旋转木马到汽车配置器的一切。在两周前研究了手风琴的设计之后,今天让我们看看日期和时间选择器的设计-在视觉外观和交互设计的各个方面和风格。

不过,首先要做的是:日期选择器通常被认为是日期选择的万无一失的组件-可预测的、一致的、通用的-所以我们经常使用它们,只是因为它们似乎是一种普遍接受的日期输入模式。但是,就像任何其他表单元素一样,有时它们应该是最后的方法,如果不能以更好的方式推断用户的输入,它们可以帮助用户输入。现在,有些情况下日期选择器非常有用,有些情况下它们只会减慢用户的速度。那么,我们的工作就是仔细研究我们自己的场景,并找出一种最佳的方式来确定时间和日期问题,以帮助用户快速、轻松地提供输入。

当然,最好的输入是符合用户意图的输入,而不必要求用户精确。但是,如果我们将日期输入的预算设置为最多两次敲击,会怎么样呢?一个日期范围要三个水龙头吗?如果我们在游戏中也加进一个时间段,可以打五下吗?你可能会想这是否真的是件大事;毕竟,这只是一个小小的日期选择器!如果日期选择在您的界面中处于最前面和中心位置,那么您应该期待用户经常使用它,并且极端地优化日期输入并不是一个真正的优化问题,而是您网站体验的核心要素。

事实上,在很多情况下,日期选择器都很重要:无论是预约医疗、水疗、租船、电视指南、网上银行、机票还是避暑别墅租赁-几乎任何需要输入日期的东西都可能有某种日期和时间选择器。而且,通常情况下,所有这样的网站都倾向于使用相同的(JQuery)实现,这些实现在不久前插入了UI,此后就被愉快地遗忘了。但是,对于您的特定情况,这可能不是最佳选择。

如果我们仔细研究一下日期选择器的性质,就会发现有大量的设计问题需要解决--其中许多问题根本不简单:

用户应该能够在输入字段中键入日期,还是只能使用日期选取器选择预定义的值?

当用户单击输入或单击日历图标(或两者)时,是否应显示日期选择器覆盖?

日期选取器是否应该包含默认的预填充值?如果是,默认值应该是什么?

我们是否应该包括某种“上一次、当前一次、下一次”的导航?如果是这样的话,我们如何设计它的天数、月数和年数呢?

对于窄屏幕上的日期范围选择器,是在选择两个日期后覆盖自动消失,还是仅在用户单击“继续”按钮继续操作时才自动消失?

日期选择器首先是用于日期选择的正确模式吗?

事实上,我们有很多决定要考虑,而且大多数都不是那么简单。但让我们一次解决一个问题。我们首先应该问自己的主要问题是,我们到底在解决什么问题,在什么情况下解决,日期选择器如何在这方面提供帮助,或者更具体地说,什么样的日期选择器可以帮助用户无缝地完成他们的任务。

在选择应用于您的问题的界面模式之前,重要的是要了解您实际需要哪种类型的日期输入。只知道一天就足够了吗,或者你需要一个日期范围吗?不过,后者并不意味着您必须使用两个日期选择器,但它会影响组件的交互和设计。

您可能还想用时间输入来扩展日期选取器,但这并不意味着体验必须按步骤进行-首先是日期选取器,其次是时间选取器。还可以将日期和时间选择集成到单个组件中。我们将在本文后面探讨其中的一些内容。

除此之外,最好查看访问者最有可能键入的期望值范围。也许您需要使用一组预定义的选项来扩展日期输入,或者限制接受值的范围,或者使用数字输入来补充,以便客户可以手动输入值。事实上,后一种选择可能更有用-问题是它很难正确。

有一件事是肯定的:如果你一直在考虑日期选择器,你知道,你很有可能需要某种日期输入(DUH!)。当然,您可以使用三个单独的数字输入,用分隔符分隔-也许可以使用<;select>;下拉菜单表示日、月和年-但使用这种设计,用户将通过点击和滚动开始一段旅程,这不一定是最无缝或最快的体验。我们希望尽可能快地选择日期,并且能够通过两次点击(点击打开日历,点击选择日期)设置日期比处理三个单独的输入域要容易得多。

那好吧。如果我们只保留一个输入而不是三个单独的输入-例如,使用格式助手DD/MM/YYYY会怎么样呢?当用户开始打字时,日、月、年之间的转换应该是无缝的、自动的,这样用户除了继续在数字键盘上打字外,不需要做任何事情。理想情况下,他们最多击键八次即可完成输入。很明显,我们不能假设用户是否知道确切的日期,但是使精确输入成为可能是有用的,这是对常规日期选择器的补充。特别是在日期输入可能变化很大的界面中(例如护照到期日期),键入值而不是没完没了地敲击年份和月份听起来更合理,对吧?

嗯,数字输入必须足够可靠,才能管理所有类型的边缘情况-而且数量很多。当然,我们将使用某种类型的标签或占位符来指示日、月、年输入的顺序和输入格式的示例,但是内联验证应该能够快速提取格式错误的输入,并建议更正以推动用户在输入流中前进。当心新一周开始的那一天。如果您的公司是国际公司,并且大多数客户来自美国,那么您可能需要根据用户的位置或偏好更改UI,以避免误预订。

可靠也意味着宽容。如果用户想用数字输入MM/DD/YYYY选择2019年3月1日,他们需要键入01/03/19。作为设计师,这正是我们所期望的输入。

现在,当用户遇到该数字输入时,会如何键入数据呢?如果你观察到用户在输入中键入日期,你会看到他们暂停了一秒钟,键入1,然后手动切换到月份输入,键入3,然后手动切换到年份输入,并键入年份-19或2019年。

其他用户将安全起见,并显式键入03和01。还有一些人会尝试在这些输入中的任何一个中包含分隔符。因为在某些实现中,一旦输入被激活,占位符就会消失,所以有些用户会使用与您考虑的分隔符不同的分隔符-通常是连字符(-)或斜杠(/)。一些用户会尝试通过使用输入字段中的向上和向下箭头来递增该值。一些用户在键入日期时会选择在字段中使用Tab键。哦,对于内联验证来说,这真是一场噩梦!

用户为什么要这样做?主要是因为它们过去曾被烧毁过-被数据输入设计得很差的笨重界面烧毁,导致来回奔波的令人沮丧的体验-例如,看到一个解释错误的输入,然后点击一个很小的日期或月份选择输入进行更正,但最终却重置了另一个输入。在所有这些情况下,很容易感到沮丧。在所有这些场景中,设计者的实现应该能够正确解释输入并支持用户,而不是抛出左右的错误(带有自动完成或智能建议)。

当用户激活输入字段时,保留日期格式建议(在占位符中)。在用户手动输入日期时保持分隔符和占位符的显示。如果由于某些原因不能这样做,可以使用浮动标签继续显示格式(这确实存在一些可访问性问题,但也有一些解决方案)。

在输入范围变化很大的情况下,数字输入很重要-可能跨越几年,如签证有效期,或考虑可预测的输入,如生日日期。这就是值得投资于适当的数字输入的地方。您甚至可以将其提升到下一个级别,支持实际的上下文敏感输入。也许您可以不要求特定的输入格式,而是支持诸如“昨天”、“现在”、“今天”、“下周五”、“一年前”、“两周前”甚至“进入七月的5天”这样的查询。

根据应用程序的性质,允许灵活的日期可能会很有用,并且在输入字段中键入查询也很容易。如果这是不可能的,那么在日期选择器旁边添加“今天”、“明天”、“7天后”等易于点击的预定义选项可能是个不错的主意。在搜索机票的最佳票价时,它可能会很有用。事实上,这正是克里姆林.ru使用的技术。当然,您还需要传达您也非常支持这种“智能”模糊输入。

虽然数字输入很有用,并且可以作为后备选项使用,但在某些情况下,日期选择器的用处要大得多-例如,当客户预订短期假期时。如果用户想要在接下来的六周内进行一次快速的周末旅行,但脑海中没有确切的日期-相反,他们正在探索价格和可用性,这意味着他们将在几天到几周之间跳跃,甚至可能在几个月之间跳跃很多。在这种情况下,数字输入会太慢太累,而日历视图会更相关,因为它只需轻轻一点,就会在网格中显示周末选项。

如果我们仔细检查一下与日期选择器输入字段的交互,我们会偶然发现一些围绕其交互设计的微观决策。输入字段应该有默认值,还是应该保留为空,可能填充日期占位符,以显示正确输入的示例?如果我们使用默认值,我们应该选择哪些值?一旦用户选择了日期但刷新了页面,输入应该在字段中保持不变还是自动重置?

坦率地说,我们没有测试上面的任何选项,也没有发现任何偏好,但似乎为客户设置随机值并不是真正的最佳选项,因为这会迫使客户将看似随机的值“修复”为他们实际正在寻找的值。然而,如果你的客户可能会在你的网站上购买最后一分钟的交易(无论是演出、公共交通还是酒店),那么当前日期(“今天”)甚至当前时间(“现在”)可能是一个很好的选择-尤其是在时间敏感的情况下,比如电视指南。最终决定将来自您从您的常客那里收集到的一般行为。

一旦用户选择了日期或时间段,但(意外或故意)刷新了页面,我们可以选择取消选择或保持原样。如果用户不小心刷新,他们不会因为输入丢失而不得不重新键入而高兴。这太让人沮丧了。如果用户故意刷新,他们将看到预定义的日期,并且必须“固定”日期。这也可能非常令人沮丧,除非您在日期输入旁边提供了一个明显的“重置”或“新搜索”链接。客户只需轻触一下即可清除选择,而不是手动删除所有以前的输入。这也是迷你步进器可能会有帮助的地方,因为日期可能不会有太大变化。例如,在后一种情况下,使用两个本地滚轮调整日期太麻烦了。

简而言之,只有当您确定用户可能会选择这些日期时,预填充日期才是一个好主意;此外,在页面刷新后保留数据(除非输入是时间敏感的),并添加“重置”链接以使用户能够轻松取消输入。顺便说一句,重置链接可能也会在日历覆盖中可用。

有人可能会认为,你需要真正有创意,才能为日历覆盖设计出一个独特的设计。毕竟,它们在大多数情况下都是通用的!通常,覆盖显示在日期输入字段的下方,并且大多在窄屏幕上显示为全屏覆盖,在桌面上显示为较小的面板。这些天排成行,按周分组,并有下拉菜单来浏览年份和月份。然而,事实证明,日历覆盖可能包含不同级别的详细信息和导航。

最简单的问题是,本周的排行榜应该从周一开始还是从周日开始?嗯,这取决于你提供的服务和你的目标受众。日期选取器是否应该始终包含年份输入?可能不会出现在公共交通网站、电视指南或送餐服务上。是否应始终显示所有日期选项和月份选项?如果你正在设计一个租车网站,可能就不会了--你可能不需要提前几个月预订一辆车。如果你在可以选择下一年的月份使用这些服务-比如在12月中旬-你可能不会显示年份,因为1月份显然是即将到来的一年的1月份。

不过,它还有另一个层次的复杂性。在某些情况下,显示一周中的实际日期(星期一、星期二等)。很重要(例如,对于预约)。在其他情况下,这是无关紧要的(比如生日)。有时我们确实想要显示可用性或定价(例如预订航班)。有时我们想知道日期范围(租避暑别墅)或确切的时间段(餐厅预订),而不仅仅是日期。在这种情况下,我们需要用时隙选择来补充日期选择,或者以某种方式指示开始日期和结束日期之间的联系。

有必要考虑在日期选择器早期提供的详细程度,以帮助用户更快地做出明智的选择。如果可用性很重要,请考虑明确区分可用选项和不可用选项。此外,如果有不同的选项或价格标签与不同的日期相关联,那么用颜色编码来表示更好的票价或更好的可用性可能会很有用。如果许多客户在周末预订您的服务,请明确指出周末,可能还包括公共节假日。

您会选择在您的界面中突出显示选定日期的哪些内容?也许那天有空吗?也许不同的开业时间或关门时间?在那一天上演的是什么样的节目?限制或禁用某些选择也是一个安全的选择,或者至少在选定的日期范围不能达到预期结果时立即在日历中提供提示。

找出对您的客户很重要的关键细节,并将其突出显示出来-例如,用灰点(表示不可用)和绿点(表示可用)。后者可以显示为不同的大小,用于不同的可用性等级。不过,它不一定非要是全细节视图--潜在地,即使是颜色渐变叠加也可以做到这一点,一旦选择了日期,列表细节视图就可以逐步显示出来。

很容易迷失在所有这些优秀的功能和指标中,但首先做好基础工作也很关键。不要忘了指出当前日期,这样客户就可以很容易地看到远程日期和当前日期之间的关系。

显然,您大部分时间都需要日期,可能还需要月份,但您可能不需要一直显示年份。或者至少,如果不经常使用年份,它就不必像其他输入那样突出,也许只在需要的时候才出现,并以某种渐进的方式披露。在所有这些情况下,您还需要包括天、月和年之间的某种导航。不过,它不一定只是一个选择下拉列表。

对于不太固定的日期选择,比如婚礼日期或开始工作,你可能想要考虑一个更动态的输入,以补充一个好的日期选择器-例如,迷你步进器。

如果许多客户可能会探索相当短的日期选项范围,您可以在输入字段中的日期输入旁边添加快速的“上一个”和“下一个”导航。例如,当预订周末旅行时,用户可能希望在周四晚些时候或周五早些时候离开,但周六晚些时候绝对是不可能的,所以不需要重新键入输入或在日历覆盖中选择日期,只需点击一下就可以产生预期的结果。

事实上,这正是谷歌航班在其日期范围选择器中添加的功能。为了能够在几个月和几年之间快速跳转,您还可以为它们添加一个迷你步进器(同样,想一想护照过期输入的日期更改会有多快)。

一般来说,迷你步进器对每个日期选择器都是一个很好的增强。然而,它可能不应该被认为是日历覆盖的替代品。当然,敲击很容易,但也可能很快变得非常乏味。在可用性会话中,您可以看到在第10次点击之后,每点击一次,烦恼程度(和血压)是如何增加的。最终,一些用户完全改用数字输入(当然,如果可能的话)。

那么,该选择什么呢?首先研究日历的用途和日期输入范围的范围。如果日期可能是相当远的过去或未来(例如,用于预订假期),则使用日期选择器进行数字输入可能是个不错的选择。如果日期输入范围通常很短(少于六周,比如预约医疗预约时),一定要考虑增加一个迷你步进器,以实现更快的跳跃。

理想情况下,只要数字输入足够可靠,提供所有三个选项-数字输入、日历覆盖和迷你步进器-似乎都是安全的选择。如果一次只显示几个选项,那么您的界面可能根本不需要日期选择器。考虑将预定义选项显示为链接、按钮甚至滑块,而不是提示日历覆盖。

日期输入不一定需要日期选择器,但通常日期选择器是一个很好的解决方案。然而,并不是所有的日期选择器都是平等的,交互设计将根据上下文的不同而有很大的不同。不过,有一件事是肯定的:除非日期选择器的显示方式清晰易见,否则必须通过单击或轻触输入字段或日期图片进行提示。

..