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

Dom wrote:
> 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).

My concern is that I don't want a web page/service provider filtering out sensitive information. It should never *see* that information.

> 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.

Perhaps, but unlikely.

The Banks and other groups insist on protecting my "privacy" by actively turning off all the useful parts of my browser. I fully expect them to demand that I provide genuine blood for signatures at some point.

> 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.

From my memory of the spec, it definitely doesn't express the right understanding....

Spec text from 3.1:
>> A user agent must not provide contact information to Web sites
>> without the express permission of the user. A user agent must
>> acquire permission through a user interface, unless they have
>> prearranged trust relationships with users, as described below.

>> The user interface must include the document base URL.

>> Those permissions that are acquired through the user interface
>> and that are preserved beyond the current browsing session (i.e.
>> beyond the time when the browsing context is navigated to another
>> URL) must be revocable and a user agent must respect revoked
>> permissions.

Here, what I need as a user is not to be told the URL that's asking for access to data. I need to see (and control) which data will be given to the page, with a line item veto so that I can remove data and a way to add extra bits.

For example, my n900 has a number of business cards which have both public and private information. A card might be "Josh Soref" and have my Business Phone, my Business Cell Phone, my Business Address, my Home Phone, my Personal Cell Phone, my Home Address, and some note fields. On my n900, I can choose to send a subset of those fields when I send a business card (the UI isn't great, ideally I'd be able to say "just include name fields + business fields" instead of manually selecting each field I wanted).

When reviewing information about a business card, you can recognize "oh, I really didn't want to send my luggage code [1234] to that web page".

> 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 probably an argument for web sites to offer to accept vCards instead of making me manually enter things into individual fields which sometimes do and sometimes do not have automatic advance behaviors. It's currently awkward to enter that data using a keyboard just as much as it is to do DnD (and as my hands were hurting, the typing was actually rather painful).

> 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.

As I noted earlier, my n900 makes it *easy* to select which field(s) I want to send -- other implementations should do the same. Practically speaking, it's the smallest UI we need to consider (roughly row of checkboxes and labels). The intelligence required to omit a label when only a single field is provided is trivial.

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

Right, thanks for looking it up for me :).

> >  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">

Indeed, but this brings up an interesting point (actually, I was going to originally address it at the end, but I'm moving it forward to here).

The fact is that IMEs are stupid.

For mobile devices, being able to enter a name or address from my addressbook into an arbitrary <input> is probably the right thing. This isn't an API that web pages need, it's a knock at the fact that current IMEs are really barely glorified typewriters instead of being aware of their available data.

If I try using a Text Editor on a touch screen based device, I will generally get an IME which is basically an on screen keyboard. The IME does not let me pull in information from my Address Book, and if I had a Rich Text Editor, it wouldn't let me insert a picture. Instead I have to either open my Address Book and copy things and then use the IME to paste them, or in the case of a Picture, I need to rely on the Rich Text Editor to have a specific feature to let me select a picture.

When Microsoft was designing Windows Phone 7, they explained that the average reason people wanted Copy and Paste wasn't because they needed Copy and Paste, but because they, like me, needed a way to enter things such as information from a Contact.

On this point, I agree with Microsoft, if my IME could let me enter information from my Address Book, then I would have done that much more often than I would otherwise have needed an to perform a generic cut/copy/paste. This isn't to say that Cut/Copy/Paste isn't useful or necessary, just that we often really need import/export more often than we need that feature (e.g. my Address Book could import a Contact from a web page or text file -- not one that was annotated, or my Phone could import a Phone number from a web page/text file -- not one that was annotated).

> or <input type="postalcode">

Postal code is indeed more interesting. In the USA and Finland, a postal code is \d{5} (well, in the US it's really \d{5}(\d{4}|); in Canada and England, it's ([a-z]\d){3} (but the official formatting includes hyphens).

Html5 offers: <input pattern="\d{5}">. Given the way pattern works, a UA should be able to apply the pattern to its available fields and determine which ones are working matches and offer those as suggestions. Unfortunately, the UA will need to preprocess the regexp and the data, namely dropping punctuation from both (my zip code could be written as 555554444 even though the pattern might want 55555-4444, or vice versa -- this nonsense is more apparent when dealing with phone number fields).

> (or <input type="birthday">, etc).

<input type="date"> would be fine, a user agent could filter to things which satisfy that criteria. My average card only has one Date field (which happens to be a birthday). If I try to drag an Event (which has 2 date fields: Beginning and End), then a browser could easily (really should) let me choose one of them.

> 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).

<input accept="text/x-vcard"> would be nice. I really hate having to tab through fields and would much rather just paste my entire address into a single field anyway.

> 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.

It isn't the ideal experience no, but it's hopefully a useful reference for how things could/should work.

When I choose to upload 3 contacts, I probably do want to only select certain fields (and generally I only want to send fields for which there is data...), and being given a list of fields with previews of their values would be incredibly useful.

----
Allow me to offer another use case. Before I left Finland a friend needed help performing a "mail-merge". Basically he had a database with say 1100 contacts and he needed to print envelope labels for 1000 of those contacts (i.e. most but not all of them). This would be a great thing for a web application.

What anyone will have to do is to select which contacts they want, and which fields they want, and then provide that to an application (in my case Word, but ideally let's say http://printer.example.com/label-maker/ ), which would then generate a page with the content for printing/previewing/spot checking, whatever.

Note that the contacts in the database I was working from had *way* more information than just the mailing address, and a lot of it was strictly confidential. That information absolutely should not be exposed to printer.example.com at any time. It isn't sufficient to let the site select only the data it needs, it's necessary that the site never see the data it shouldn't be allowed to see.

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

It doesn't seem to match what an implementer is likely to do (which of course worries me).

> 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. ... pictures

<input type="file" accept="image/*"> will cover pictures.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 4 July 2011 16:58:07 UTC