E2.13.1distant-date calendar cost设计研究
远期日期用日历选择成本高
别名: 日历选远期 · date picker paging · 翻月选生日
概念解释
弹出的月历一次只给一个月（或一周）的格子。目标日期离「今天」越远，人就要翻过越多页：生日、证件有效期、十年后的合同，翻月成本随距离线性涨。远期日历成本（distant-date calendar cost）说的是用格子去够一个已知、远离当前月的日期，是在用浏览工具做回忆任务。它管的是距离带来的翻页负担，不是能不能键入，也不是起止两个日期能不能并排看见。
机制
月历擅长回答「这几天里哪一天」：格子都在眼前，比较的是相邻日。远期日期在工作记忆里通常已经是年月日结构（1998 年 7 月），任务是外化这份结构，不是在时间轴上散步。每翻一页只移动一个月，十年就是一百二十次，中途还要确认有没有翻过。部分控件提供年下拉，把线性翻页改成两次选择，成本下降，但许多人找不到年控件，仍去点箭头。成本曲线对「明天、下周五」几乎为零，对「出生日期」陡升，同一控件不能假装两种任务一样贵。
怎么研究
让人用同一月历选择「明天」「下个月某日」「二十年前的生日」，记录翻页次数、时间、是否中途改用键入。自变量：是否有年选择、默认落在哪一月、一周从周几起。因变量：到达时间、翻过头再翻回来的次数。不要只用近日期当测试集，那会把月历判成「很快」。眼动可看人是在找年下拉还是在连点箭头。
边界
预约近几天的场景里，远期成本不存在，月历反而是对的：格子展示空闲，键入还要另查。农历、财政年度、学期这类非公历结构，翻公历月帮不上忙。只读展示一段历史（时间线）不是选择器，翻页负担的主体不同。键盘用户若能直接改年数字，翻页成本可以被键入通道消掉——那已不是纯日历路径。
怎么落地
- 把月历留给近日期和「看看哪天有空」；出生日期、证件日期不要作为主路径。
- 若必须用月历覆盖远期，提供可发现的年（及月）直达，不要只留一对箭头。
- 打开时把视图落在合理默认（今天或已填值），不要从公元元年附近起翻。
- 验证：选「明天」和选自己的生日。后者若要连点几十次箭头，远期成本就还压在用户身上。