<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY 
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space" 
bgColor=#ffffff>
<DIV><FONT face=Arial size=2>My strong sense is that the canonical UI for 
choosing points in a metric space (time, as typically&nbsp;viewed,&nbsp;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;&nbsp;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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>DD</FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=mjs@apple.com href="mailto:mjs@apple.com">Maciej Stachowiak</A> 
</DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=pkasting@google.com 
  href="mailto:pkasting@google.com">Peter Kasting</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=whatwg@lists.whatwg.org 
  href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</A> ; <A 
  title=bzbarsky@mit.edu href="mailto:bzbarsky@mit.edu">Boris Zbarsky</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, March 31, 2009 3:58 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [whatwg] Input type for 
  phone numbers</DIV>
  <DIV><BR></DIV><BR>
  <DIV>
  <DIV>On Mar 31, 2009, at 10:25 AM, Peter Kasting wrote:</DIV><BR 
  class=Apple-interchange-newline>
  <BLOCKQUOTE type="cite">
    <DIV class=gmail_quote>On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky <SPAN 
    dir=ltr>&lt;<A 
    href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</A>&gt;</SPAN> wrote:<BR>
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
      <DIV class=im>I agree that entering a week is pretty rare, though. 
      &nbsp;;)</DIV></BLOCKQUOTE>
    <DIV><BR></DIV>
    <DIV>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. &nbsp;So while I'm on the "week is not that 
    useful" bandwagon, it'll be simple to support once "date" is 
    supported.</DIV></DIV></BLOCKQUOTE><BR></DIV>
  <DIV>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.</DIV>
  <DIV><BR></DIV>
  <DIV>Regards,</DIV>
  <DIV>Maciej</DIV>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>