My strong sense is that the canonical UI for choosing points in a metric space (time, as typically viewed, being a one dimensional Euclidean metric space) has not yet been built. Using a pointer like a mouse together with timing delays between mouseup and mousedown together with 3D accelerometer data probably would give us the ability to choose any date or real number (bounded above and below by some number), any of a finite number of words from a vocabulary, any coordinate from a 2D, 3D or 4D space, or any node (like a URL) from within the topology of a finite directed graph more quickly than equivalent data could be entered from a keyboard. This includes pretty much all input widgets. What all these spaces share in common vis a vis the human is the conceptual pegs that people assign as landmarks in those navigational realms. In the case of time we have seconds, minutes, days, months, millenia as pegs; in the real numbers, we have powers of ten; in color space we have trichromatic and opponent processes overlaid with cultural nomenclature; in the daily drive to work each day, we have traffic signals, cows etc.; on the globe we have latitude and longitude as well as the more salient pegs of nations, provinces, cities. There is a lot of data that can be leveraged from the speed, acceleration, and position of a mousedrag, even without accelerometers around. The way to choose the feedback relevant to optimizing a user's input may ultimately have a universal solution that works across input domains, but which researchers just haven't started yet to look for. Standardization may be premature.
DD ----- Original Message ----- From: Maciej Stachowiak To: Peter Kasting Cc: [email protected] ; Boris Zbarsky Sent: Tuesday, March 31, 2009 3:58 PM Subject: Re: [whatwg] Input type for phone numbers On Mar 31, 2009, at 10:25 AM, Peter Kasting wrote: On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky <[email protected]> wrote: I agree that entering a week is pretty rare, though. ;) As someone working on supporting new input types in WebKit: Supporting any one form of "date" is nontrivial, but supporting the rest after you support the first _is_ trivial. So while I'm on the "week is not that useful" bandwagon, it'll be simple to support once "date" is supported. It depends on the quality of implementation you want to deliver. With a nice visual date picker, the UI for picking a month or a week is probably quite different from the UI for picking a day, which in turn would be different from the UI for picking a time, or a date and time together. For instance, a day picker would probably only show you month or possibly a 2 or 3 months at a time, whereas that would not make sense for a month picker. Just having a type-in box with no visual picker would result in a control that would likely not be usable for the kinds of sites where you enter dates. Regards, Maciej
