Updated: Date Picker Widget

Updated:
- added commentary about alignment with mainstream objects
- added section of additional keys we might want to consider
- added continuity of grid focus when changing months and years



Here is how I imagine an ideal Date Picker widget would behave.

Purpose:
Choose a date as input in an easy to navigate manner.

Behavior:
Like other widgets the calendar widget receives focus to become active 
by tabbing into it. Once focused is received focus is repositioned on 
todays date in a grid of days and weeks. I suggest a grid as a 
reasonable representation because I am an advocate of using the same 
representational metaphors for both visual and aural navigation when it 
would not be overly cumbersome. This gives extra lift to the solution by 
aligning it with mainstream objects.

The spoken text is from specific to general such as

[Selected] 4 Tuesday March 2008 [Not Selected]

As the user navigates they can quickly hear the number and if they allow 
speech to go on long enough they can get the day or more detail. If the 
date is already selected that is stated. If not then "Not Selected" is 
stated at the end. The assumption is that being selected is important to 
the user so they would want to know that right away. The majority of 
dates are not selected so hearing that over and over would be tedious, 
but still important at points of interest. So the first focus on today's 
date would read all the details out in full unless the users starts 
interacting.

Arrowing up and down goes to the same day of the week in the previous or 
next week respectively. If the user advances past the end of the month 
they continue into the next or previous month as appropriate. Visually 
the grid might flip from month to month but audibly arrowing is a 
continuum of dates.

Going left and right advances one day to the next, also in a continuum.  
Visually focus is moved from day to day and wraps from row to row in a 
grid of days and weeks.

Pressing the enter key selects a date. There is no particular reason a 
user can't pick more than one date but actual implementation should 
include the option to allow only one choice which deselects the previous 
choice. In this scenario there should be an alert that says

Selecting this date will unselect 4 Tuesday March 2008
Ok Cancel

For faster navigation there are also shortcuts to advance month to 
month. I suggest control+alt+M. All the desktop/OS examples I checked 
required the user to activate a modality such as weekly or monthly view 
such that arrows would advance in steps of the mode's current time unit. 
I think that is overly complex. control+alt+M to advance a month and 
control+alt+shift+M to retreat a month. In general the control+alt realm 
of keys is becoming more common in web apps because of collisions with 
existing OS/Browser keyboard shortcuts.

Likewise years can be advanced or retreated via control+alt+Y or 
control+alt+shift+Y respectively.

When changing months or years there is a question of where focus should 
be in the grid after the change. I suggest that it should stick to the 
week and day as the user cycles through months or years. For example, if 
they are currently focused on 4 Tuesday March 2008 and I advance a 
month, I should sill be on the first Tuesday but in April, which is 
April 1. This new date should be announced to the user.

I was thinking we did not need another shortcut for changing weeks 
because it is already just hitting the up and down arrow.

I'm assuming there would be a header to the widget containing equivalent 
links to advance and retreat years and months along with the title 
showing which month and year the last focused date is contained in. To 
reach the header the user would shift+tab. Shift+tab takes you out of 
the calendar date picker section and moves you through the month and 
year increment/decrement controls. If the last control is reached and 
shift-tab is pressed again the widget is exited "out the top". If the 
user tabs forward through the widget and back to the date picker 
section, one more tab exits the widget "out the bottom".

{alternate}
Some calendar widgets represented the current Month and Year as 
pull-down menus in the header with the current month/year selected. You 
then use standard navigation to change the selected month or year from 
these menus.

{alternate}
Some calendar widgets have the year as an editable text field so the 
user can just type in 2018 to jump to that date rather than incrementing 
or messing with a menu.

I'm not clear as to whether either of these alternates is better then my 
original suggestion which was just plain header text with controls to 
increment or decrement. Might swing to far on the capability/complexity 
trade off.

{additional keys}
There are many other keys defined in some desktop applications but I 
didn't know if they are of great utility or not. More keystrokes is more 
cognitive load and more client-side code. That said, here is a list of 
additional keystrokes beyond the baseline previously discussed

control+alt+home - first day of the current week
control+alt+end - last day of the current week
control+alt+pageUp - first day of the current month
control+alt+pageDown - last day of the current month
control+alt+t - Jump focus to today

I purposely did not cover selecting time ranges. Most implementations 
I've seen on the web have this as a separate UI element such as 
pull-down menus for start stop points or generalizations such as 
"morning" or "afternoon." This may be because many time selectors are 
implemented as draggable regions which has been difficult to duplicate 
in a web-based UI. It also implies some measure of data entry and 
storage to label what this particular time range is for, which gets 
pretty far into implementation details.

Looking forward to your analysis of the proposal.

CB