[whatwg] Datepicker design (semi-off-topic)

[Matthew Thomas]

On 9 Jul, 2004, at 10:17 PM, fantasai wrote:
>
> Matthew Thomas wrote:
> ...
>>     calendar would be. Even for a pointing device, the
>>     most efficient interface (at least for choosing any
>>     date not in the current month) would involve menus
>>     opened from each segment of the datepicker (one-
>>     -dimensional menus for year and month, and a two-
>>     -dimensional menu for day), rather than using a
>>     calendar.
>>     *   "calendar" --> "datepicker"
>
> That's only if you know exactly which date you want to pick. Works 
> well for date-of-birth, but not for appointments. If I'm setting up an 
> appointment or picking a date for flying out of the country, I'd 
> rather see a calendar with the weekdays lined up in a grid.

Yes, that's what I meant by "a two-dimensional menu for day".

So if, for example, your OS was set to DD/MM/YYYY date format, a 
datepicker might appear like this:

                      [11/07/2004]H

This is what a datepicker looks like in all toolkits I know of. ("H" 
represents a pair of increment+decrement buttons.)

By default, the "11" would be selected. So to change the value to July 
24th, for example, you would type "24", replacing the 11.

To enter a completely different date, you could type it, e.g. 
"13/6/1989". Typing each "/" would navigate to (and select) the next 
segment of the field, just like pressing the right arrow key would. So 
even for days, months, and years that were *all* far away from those in 
the current date (so it was not worth using the up and down keys to 
increment/decrement the default value), typing the new date would be 
exactly the same, and exactly as efficient, as if you'd typed it in an 
empty text field.

Single-clicking on a segment of the field would select that segment. 
Double-clicking on it, or clicking-and-holding on it, could open a 
menu:
                              ____
                             | ^  |
                             |1999|
                             |2000|
                             |2001|
                             |2002|
                             |2003|
                       [11/07*2004*H
                             |2005|
                             |2006|
                             |2007|
                             |2008|
                             |2009|
                             | v  |
                              """"

As I said, for year and month this menu would be one-
-dimensional, but for day it would be two-dimensional.
      ____________________
     |Mo Tu We Th Fr Sa Su|
     |          1  2  3  4|
     | 5  6  7  8  9 10*11*07/2004]H
     |12 13 14 15 16 17 18|
     |19 20 21 22 23 24 25|
     |26 27 28 29 30 31   |
      """"""""""""""""""""

Now here's the part that would be more efficient than a full-blown 
calendar. If you wanted to, for example, find "the Tuesday just over 
eight weeks from today", you could just drag the menu rightward to 
Tuesday and downward eight rows, and the menu would contract and expand 
to follow you. (This is similar to the "Insert Table" toolbar 
menubutton in Microsoft Word, which you can drag to specify the number 
of rows * columns in the table.)
            ____________________
           |We Th Fr Sa Su Mo Tu|
           | 7  8  9 10 11 12 13|4]H
           |14 15 16 17 18 19 20|
           |21 22 23 24 25 26 27|
           |28 29 30 31  1  2  3|
           | 4  5  6  7  8  9 10|
           |11 12 13 14 15 16 17|
           |18 19 20 21 22 23 24|
           |25 26 27 28 29 30 31|
           | 1  2  3  4  5  6 *7*
            """"""""""""""""""""
That would be much quicker than flipping back and forth through months 
in a fixed calendar control.

> ...
>>     *   'If an upload control or a form element has an
>>         invalid accept attribute, the value is assumed to
>>         be "*/*". Such an attribute for a file upload
>>         control still overrides any accept attribute for
>>         the relevant form element.'
>>     (Why? Because the faulty value is much more likely to
>>     be the author's attempt at a non-specialization
>>     exception to the form's rule, than an attempt at a
>>     specialization.
>
> I'd rather see the thing ignored, which is the usual way of handling 
> errors like this.
> ...

Yes, it would be nice if that was a reasonable thing to do. But if the 
FORM element has a valid accept attribute, it's unlikely to be a 
superset of the intended type for the individual control; so it's 
highly likely to result in a form unusable for its intended purpose.

-- 
Matthew Thomas
http://mpt.net.nz/