RE: Question from Webkit developer related with the use cases of Contacts API

Le lundi 04 juillet 2011 à 10:30 -0400, Josh Soref a écrit :
> > I came up with the following main use cases (which obviously are a 
> > personal perspective, and very much up for discussion):
> > • auto-filling a form with my personal address and/or phone number 
> > (for getting sent an item I just bought, making an hotel reservation, 
> > using an eGov service)
> 
> I consider this something which a good browser should be able to learn
> on its own, without having access to my address book.

That's probably true; that said, different service providers will demand
different level of details organized in different ways, which a browser
can't detect (but that a developer on the service provider side can).

> [Scenario]
> I just joined RIM and moved to Toronto. My brand new computer had an
> address book program which probably had an API which allowed access to
> its data. But the reality is that my address book didn't have the data
> that was needed.

Note that if the Contacts API was available and sufficiently widely
deployed among service providers, it's pretty likely you would have
entered your address in your addressbook to avoid having to fill it
again and again.


> > • auto-filling a form with one postal address from someone I know (to 
> > send them a gift)
> 
> This seems like a case where supporting some amount of drag and drop
> and the ability to show the user a blob and let the user select a part
> of the blob would be sufficient.

> If I could drag and drop a contact from my address book to an input
> field and have the browser ask me which pieces I wanted to include,
> I'd be rather happy.

That's more or less what the Contacts API is about, except that instead
of asking the user to select which fields to paste, the developer can
also state which data is needed.

It would be awkward at best to have to drag and drop successively
entries from an addressbook to get the street address, then the postal
code, etc.

> This is what I got when I tried to drag my Zakim business card
> (Microsoft Outlook 2007) to Wikipedia's search field (Mozilla Nightly
> 7.0a1 2011-06-28):
> 
>     Zakim Bus: +1 (617) 761-6200
> 
> That was actually sufficiently close to my needs. If I needed to strip
> away the label, I could easily do so.

Well, "easily" depends on the amount of stuff you would have needed to
delete (e.g. probably also need to delete the address if there was one,
etc), and editing text fields isn't exactly the most easy thing on many
non-PC devices.

> I'd imagine that when browsers start supporting <input type="phone"> or whatever,

<input type="tel"> is what HTML5 defines.

>  drag and drop could automatically deal with showing the user a
> logical choice if necessary or automatically selecting the only one if
> there's only one.

That would seem useful indeed; but I doubt there will be an <input
type="address"> or <input type="postalcode"> (or <input
type="birthday">, etc).

> > • getting auto-completion on an email address of someone in my 
> > addressbook (for on-line email, sending invitation to on-line 
> > services, sharing content from a given Web site) [this would obviously 
> > also apply to other fields, e.g. phone number, social network account, 
> > etc]
> 
> Again, I wonder if drag and drop isn't sufficient here. It might be
> the case that you're using a crippled platform which doesn't have drag
> and drop (Maemo?), in which case, perhaps the platform needs a working
> clipboard (I hear Windows Phone 7 will get a clipboard eventually!).

I think drag & drop is useful as a point of reference on how to get two
types of content to interact together, but it doesn't solve a problem
unless the behavior is actually defined.

Arguably, your drag and drop analogy could lead to a markup-based
solution with an <input type="contacts"> (that could thus serve as a
target for the drag & drop); that input field could presumably take
similar parameters as the ones in navigator.contacts.find() to filter
out the kind of data the developers are interested in.

I think we considered at some point using an <input type="contacts">
approach, but decided against it because it would be hard to have a
proper fallback for it (since in the absence of it being supported, you
would need several text input, not a single one).

That said, there was a concrete proposal for this based on the <device>
element (which has since disappeared from the surface of the earth):
http://dev.w3.org/2009/dap/contacts/HTML.html

(Linked to our ISSUE-99 http://www.w3.org/2009/dap/track/issues/99 )

> > • sharing an arbitrary number of email addresses with an on-line 
> > social network to expand my network
> 
> For kicks, I tried selecting 3 contacts in Outlook and dragging them
> to data:text/html,<textarea> in Nightly, and it gave me their cards.
> 
> To get more control of my data, I was able to select view>current
> view>list (in Outlook), and then adjust which columns it showed and
> then drag the rows I wanted to Nightly. The result was total control
> (I'm actually rather happy about this, and it required essentially 0
> lines of code - well 1 for the data url).

That isn't exactly the best user experience, though; imagine giving the
instructions to achieve this to someone who doesn't actually enjoy
tinkering with unrelated tools to their tasks at hand.

> Now, most people aren't likely to spend the time doing this, but maybe
> they'd benefit from browsers providing a way let them filter data
> before it's sent to web pages. Certainly for CSV or Tab Delimited
> data, it wouldn't be too hard.

That seems like a good description of what the Contacts API is about.

> Again, in this case, if someone had <input type="email" multiple>,
> then ideally the browser would automatically either collect all such
> fields, or give me a summary:

Agreed; <input type="tel">, <input type="email"> (and possibly <input
type="uri"> as well) would probably benefit from integration with the
user addressbook as well. But addressbook have more data than this
(incl. addresses, pictures, birthday dates, names, etc).

Dom

Received on Monday, 4 July 2011 14:52:38 UTC