精读《 Designing The Perfect Date And Time Picker》 about weekly

[zhaoyangsoft]

以人为本的设计流程， 激发设计的创意

构思激发创意

当设计师确定了设计需求， 下一步就是去考虑可能的解决方案。 这个过程被称作  idear generation(激发创意)   或者 ideation (构思); 对于不同的业务诉求的日期， 设计师会带着这些设计需求和用户群体； 去构思其决解决方案; 

对于需要视觉上区分周末的的需求 可以这样：

对于需要记录日期对应行程或者todos 的需求 可以这样:

设计的过程 是要以人为本的构思， 要考虑用户的整体体验. 让用户 易学易用 用着爽,感觉到愉悦和快乐; 这些都可以通过给出 示能和意符 来指引反馈， 如：

激发足够数量的创意。

    在设计流程的开始的时候，不要拘泥于一两个思考点 ；纵观全篇示例设计，会有非常多的创意点；在每个业务场景中都会有几个比较实用和突出； 也举个定时调度器的日期组件设计:  这个时候就不需要或者不允许用户直接进行编辑input 只能选择， 防止用户的输入日期格式，对于scheduler 来说不支持 如下图：

可以质疑 每一件事情

     “愚蠢” 的问题可能会触及事情的本质;  创意，不用受限制， 避免过早的抛弃任何点子 ; 有可能它会包含着潜在的创意， 能够在日后被提取，被应用到设计之中， 如滑动 拖拽选择日期; 

应对差错的设计

 良好的设计还不够, 设计师需要考虑设计出 当人们确实错了的时候的状况.  在全文示例中，也有很多容错的处理；How do we avoid displaying unavailable dates or zero-results dead ends

小结

本文很多demo 示例可以抽象总结一下： 设计师需要让日期组件符合业务的场景和用户的需求、从易学易用性出发 尽量让用户轻松愉悦快捷方便的使用 即：考虑用户的整体体验；

[spllot]

日期选择器的设计更多的需要与业务或者实际使用场景相结合，才能给用户带来良好的交互体验。在数据场景下有两个例子是印象比较深刻的。

1 数据场景下看数的诉求，我们经常会有听到，用户想看最近1天|最近7天|最近30天|...的GMV|订单|...，而有时候数据并非实时的，可能是T-1|T-2，那么最近1天而非我们平时所说的最近1天，因此我们在设计日期选择器的时候，一方面会将不可选的日期灰掉（告诉用户这些日期下没数据，同时也间接告诉用户数据是非实时的，是T-n的），另一方面，会与下拉框做结合，给出最近1天|最近7天|最近30天这些选项的快速选择，直达用户诉求，同时加上自定义选项，让用户能够自行定义看数的周期。

2 日期周期选择是用一个range-date-picker，还是两个date-picker？可能大多数同学会选择使用一个range-date-picker，因为比较简单，从交互上只需要从一个日期面板上选择日期范围即可。然而，并非如此，range-date-picker选择日期范围时，交互上一般都是先选startDate再选endDate，当要变化看数周期时，还需要再重选startDate和endDate，如果用户的看数的场景是固定startDate而变化endDate的话,选择range-date-picker的交互是startDate->endDate1->startDate->endDate2->startDate->endDate3....，而选择两个date-picker的话，交互就会相对简单了 startDate->endDate1->endDate2->endDate3....。因此，该场景下两个date-picker会是相对好的一种选择方案。

[linhuiw]

同样觉得日期的选择需要结合业务去考虑.
之前接触过财年的区间, 以及具体特殊周的区间选择(周三到周三, 周一到周一).
数据产品中, 日期区间还要考虑到, 数据未产出的日期, 以及特殊情况的日期, 比如春节,大促这种特殊日期.
这些在具体业务中, 做日期组件的时候, 都需要去承载.

[chenkehxx]

不同业务场景下所需要的日期组件是不一样的。你很难实现一个通用的日期组件是去满足所有的业务需求。只能说在开发日期组件时满足最基本的需求，同时留下一定扩展接口去让用户实现自定义的需求。从最本质上来讲，DatePicker本质是一个Input的输入框，只是为了更好的用户交互和防止用户输入非法值所进行的一个约束。

如果真的要开发一个日期组件，我觉得如果能实现作者提到的那几个点就可以覆盖80%的场景，剩下的场景应该由用户自定义开发。

• DatePicker是否支持DateRangePicker.
• 是否允许用户直接在输入框输入日期和相关的验证规则
• 是否用户点击icon或input时进行弹框(个人意见：这点无所谓)
• 是否支持一下特殊日期选择，比如前一天，后一天，前一个月
• 支持在日期显示其他信息，比如航班价格
• 弹框消失方式，自动消失或用户手动消失
• 如何展示不可用日期

[ascoders]

日期选择器是个业务组件，从文章总结来看，原因如下：

1. 由于日期交互的复杂性，导致基本上需要弹框操作，进而让操作步骤增加，一个优秀的设计师会尽量减少用户操作步长，因此与日期相关的业务部分就会放入弹层中。
2. 许多与日期强关联的业务，比如机票定价、日程安排，结合到日期选择器中更直观，提高用户对信息的检索效率。
3. 日期选择功能本身与业务场景是强耦合的，业务场景决定了日期选择器的形态，比如只需要“年月日分秒”中任意一种组合的场景，或者是固定步长、强调某个时间段的场景。我们的数据场景就要求“周”选择状态下，点击任何一天都能选中一整周，这个场景文章中也没有提到，因为与业务关联太强了。

[arcthur]

通观全文，我觉得抓住两个重点就可以作选择

1. 合适的粒度。对于 date picker 来说，文章总结三种形式其实是各不相同的，对于产品来说一定是具体到这个场景下需要用到什么粒度的 date picker 来定。
2. 特殊日子与快速选择。特殊日子首先是代表与业务相关的含义，第二是普遍意义上的特殊日子，如周末与假期。业务中，文章中有举到 google fights 的例子，会直接在日历上展示的是往返的机票的价格，在国内的网站包括携程我们发现也是用类似的方式，这样就方便在第一步选择一个合适的时间。另外，还有像用明天，这周末，这种带有提示性词来代表具体的日子，选择起来更具人性化。

[huxiaoyun]

设计完美的日期选择器

摘要

日期选择器作为基础组件重要不可或缺的一员，大家已经快习惯它一成不变的样子，输入框+日期选择弹出层。但到业务中，这种墨守成规的样子真的能百分百契合业务需求吗。这篇文章从多个网站的日期选择场景出发，企图归纳出日期选择器的最佳实践。这篇文章对移动端的日期选择暂无涉猎，都是PC端，列举出通用场景，每个类型日期选择器需要考虑的设计。
文章链接：https://www.smashingmagazine.com/2017/07/designing-perfect-date-time-picker/

设计原则

通用设计

1）明确需求，是实现日期选择、日期区间选择、时间选择
2）用户选中日期后是否需要自动触发下一步？尤其是在某些固定业务流程中
3）日期选择器是否是最佳的日期选择方法？如果提供预定义的日期选择按钮是不是更快呢？
4）如何避免展示不可用日期？
5）是否需要根据上下文自动定位？ 适用于生日选择场景。

输入框设计

1）用户是否可以自定义输入日期，还是只能通过点击选择程序给出的日期？
2）用户自定义输入如何保证日期格式正确性？有时候直接输入的效率明显高于点击选择，在很多银行流水查询的场景中就提供自定义输入
3）是否需要提供预设场景输入？ 比如昨天，三天前，七天前，30天前？
4）是否需要包含默认值？如果有默认，应该是什么？像google flight 根据用户历史数据提供默认值，临近节假日默认填充节假日。
5）当用户激活输入框时，是否保留默认值？
6）是否提供重置按钮？
7）是否提供『前一项』『现在』『后一项』导航？

日期弹出层设计

1）理想状态下，任何日期选择都应该在三步之内完成
2）日期选择弹出层的触发方式？ 是点输入框就还是点日期小图标？
3）默认情况下，展示多少周、月、天？
4）周的定义是周一到周日 还是 周日到周六？
5）如何提示当前时间和当前时间？
6）是否需要提供『前一项』『现在』『后一项』导航？如果提供，选择天、月、年的场景下如何展示？
7）提示用户最关心的信息，比如 价格、公共假期，可采用背景色、点标记
8）是否用户点击非弹出层自动关闭弹出层？是否需要提供关闭按钮？
9）是否可以不和输入框联动？
10）用户可以重置选中的日期吗？

日期区间设计

1）理想状态下，任何日期区间选择需要在六步之内完成
2）用户选中后是否立刻做背景色提示？
3）当用户选择时，区间是否需要随着用户动作改变？比如用户hover时，动态改变选中区间。
4）是否提供快捷键切换 日、月、年选择？

时间选择设计

1）最简单的方法是竖直的日期，水平的时间选择
2）更有用的是先提供日期还是时间选择？ 时间选择可以作为一个过滤项，移除某些不可用的日期，这个也很有用。
3）提供最常使用的时间片段，并提供快捷键选择。

文章中亮点设计

google flight

这个案例在最小的范围内提供用户找出最优选择。

春夏秋冬

这个案例另辟蹊径增加了季节的概念，在某些旅游、机票类业务场景季节是非常必要的概念，提供超出月更粗粒度的日期范围选择。

枚举选择时间

使用一系列的按钮代替时间选择器，比如像我们的作息时间表，大部分是把时间划分成有规律的时间段供用户选择，固化用户选择。

对话式交互

采用与用户交互的方式选择日期，如果今后应用上AI，单纯的日期选择器是不是会消失不见呢？..

总结

总得来说，日期选择器在每个不通的业务场景和需求下的展现形式、交互都会有所有不同。首先一定一定要明确确定需要日期选择器的场景，许多与日期强关联的业务，比如机票定价、日程安排，结合到日期选择器中更直观，提高用户对信息的检索效率。满足用户需求场景的同时，尽量减少用户操作链路。