-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
精读《 Designing The Perfect Date And Time Picker》 #25
Comments
日期选择器是个业务组件,从文章总结来看,原因如下:
|
通观全文,我觉得抓住两个重点就可以作选择
|
设计完美的日期选择器摘要日期选择器作为基础组件重要不可或缺的一员,大家已经快习惯它一成不变的样子,输入框+日期选择弹出层。但到业务中,这种墨守成规的样子真的能百分百契合业务需求吗。这篇文章从多个网站的日期选择场景出发,企图归纳出日期选择器的最佳实践。这篇文章对移动端的日期选择暂无涉猎,都是PC端,列举出通用场景,每个类型日期选择器需要考虑的设计。 设计原则通用设计1)明确需求,是实现日期选择、日期区间选择、时间选择 输入框设计1)用户是否可以自定义输入日期,还是只能通过点击选择程序给出的日期? 日期弹出层设计1)理想状态下,任何日期选择都应该在三步之内完成 日期区间设计1)理想状态下,任何日期区间选择需要在六步之内完成 时间选择设计1)最简单的方法是竖直的日期,水平的时间选择 文章中亮点设计google flight这个案例在最小的范围内提供用户找出最优选择。春夏秋冬这个案例另辟蹊径增加了季节的概念,在某些旅游、机票类业务场景季节是非常必要的概念,提供超出月更粗粒度的日期范围选择。枚举选择时间
对话式交互
总结总得来说,日期选择器在每个不通的业务场景和需求下的展现形式、交互都会有所有不同。首先一定一定要明确确定需要日期选择器的场景,许多与日期强关联的业务,比如机票定价、日程安排,结合到日期选择器中更直观,提高用户对信息的检索效率。满足用户需求场景的同时,尽量减少用户操作链路。 |
日期选择器的设计更多的需要与业务或者实际使用场景相结合,才能给用户带来良好的交互体验。在数据场景下有两个例子是印象比较深刻的。 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会是相对好的一种选择方案。 |
同样觉得日期的选择需要结合业务去考虑. |
不同业务场景下所需要的日期组件是不一样的。你很难实现一个通用的日期组件是去满足所有的业务需求。只能说在开发日期组件时满足最基本的需求,同时留下一定扩展接口去让用户实现自定义的需求。从最本质上来讲,DatePicker本质是一个Input的输入框,只是为了更好的用户交互和防止用户输入非法值所进行的一个约束。 如果真的要开发一个日期组件,我觉得如果能实现作者提到的那几个点就可以覆盖80%的场景,剩下的场景应该由用户自定义开发。
|
文章地址: https://www.smashingmagazine.com/2017/07/designing-perfect-date-time-picker/
time picker 作为基础UI组件的重要一员,可能面对什么样的场景?这些场景分别适合怎样的展现形式?
这篇文章中可以了解到国外各大网站time picker 的设计,不一定是通用型,但都是指定场景下的优秀设计。从这些设计中我们可以提取出哪些优秀的思考优化我们的组件呢~~
大家集思广益,说说你遇到过的最好的time picker (设计和组件都行)? 在实际业务中针对哪些场景做过优化?
谢谢~
The text was updated successfully, but these errors were encountered: