Re: [contacts] HTML Contact Sharing

On Mon, Sep 27, 2010 at 12:14 PM, Nilsson, Claes1 <
Claes1.Nilsson@sonyericsson.com> wrote:

>  Yes, of course, the user consent model is the same for both APIs.
>
>
>
> So, Richard, which are the main differences in capabilities between the JS
> Contacts API and the HTML Contacts API, i.e. what could be done with the JS
> version and that could not be done with the HTML-based version?
>

I believe there are no differences at all. Only the access model to the same
underlying information varies slightly different (in the HTML version there
is one less step - no asynchronous contact notification bar [1] required).
In the JS API I could mimic the HTML version by assigning a click event to a
button that would invoke the JS API. However, this would currently only
result in an asynchronous notification being displayed in a typical UA -
when what I really want is to directly invoke the Contact Picker UI widget
[2].

If it were possible to say that the asynchronous notification can be
overridden _if_ (and only if) a click event is invoked on an HTML element,
then I believe that might lead to an even cleaner solution than the proposed
integration with the <device> element. If the JS API is invoked in any other
way (i.e. without the invocation of a click event) then it should display
the asynchronous notification bar. That would be really interesting and
negate the need for integration with the device element, per se.

So this would show no async notification bar:

<input type="button" value="Get Contacts" onclick="getContacts()"/>
<script type="text/javascript">
function getContacts() {
  navigator.service.contacts.find(/*...*/);
}
</script>

but this would require the display of an async notification bar:

<script type="text/javascript">
function getContacts() {
  navigator.service.contacts.find(/*...*/);
}
getContacts();
</script>

How to specify that in the spec is another matter however. Any thoughts
would be appreciated.

- Richard

[1] http://dev.w3.org/2009/dap/contacts/contacts_notification.png

[2] http://dev.w3.org/2009/dap/contacts/contacts_picker.png


>
>
> *From:* Rich Tibbett [mailto:rich.tibbett@gmail.com]
> *Sent:* den 27 september 2010 11:41
> *To:* Nilsson, Claes1
> *Cc:* public-device-apis@w3.org; Isberg, Anders
> *Subject:* Re: [contacts] HTML Contact Sharing
>
>
>
> On Mon, Sep 27, 2010 at 11:26 AM, Nilsson, Claes1 <
> Claes1.Nilsson@sonyericsson.com> wrote:
>
> Hi Richard,
>
>
>
> Generally I like the idea of creating simple APIs based on HTML elements.
> As far as I understand your intention is to provide a simpler alternative
> for developers than the JS Contacts API. This HTML API will be usable for
> some use cases.
>
>
>
> Comparing with the Firefox demo implementation of the JS API I assume that
> the use case covered by the HTML Contact API is the “Use Contacts to
> Personalize This Page” case.
>
>
>
> Right.
>
>
>
>  The “e-mail autocompletion” use cases wouldn’t be possible to implement
> with the “Device-element” as a “selector”-button is required. Correct?
>
>
>
> Autocompletion is a feature of the implementation. It could be provided by
> a UA on top of a page without the page itself needing to request this
> feature. i.e. it doesn't need to be specified in an API IMO.
>
>
>
>
>
> Furthermore, in your example in Appendix A I miss user consent for
> approving the operation.
>
>
>
> Consent is implicit. By selecting contacts to share consent is given in the
> same way as uploading a file works in the file picker. If I don't want to
> share I don't click to share or click cancel when the contacts UI widget
> appears.
>
>
>
> Thanks,
>
>
>
> Rich
>
>
>
>
>
> *From:* public-device-apis-request@w3.org [mailto:
> public-device-apis-request@w3.org] *On Behalf Of *Rich Tibbett
> *Sent:* den 22 september 2010 02:20
> *To:* public-device-apis@w3.org
> *Subject:* [contacts] HTML Contact Sharing
>
>
>
> I've uploaded a new proposal that defines HTML enhancements to provide
> access to a user's address book data. The first draft can be viewed here:
>
>
>
>   http://dev.w3.org/2009/dap/contacts/HTML.html
>
>
>
> This draft is up for discussion - it does not assume consensus on the
> material at this point.
>
>
>
> The proposal is based on HTML Device [1] and reuses the basic security and
> privacy principles and existing low-level parts of the programmatic Contacts
> API [2] to provide address book data to a web application.
>
>
>
> We chose to build atop of the device element for a number of reasons,
> primarily because:
>
>
>
> - unknown/unimplemented HTML input elements degrade to a text field which
> isn't an intuitive user experience if the feature is not supported in the
> user's current browser.
>
>
>
> - the HTML device element is not a form-based element. That isn't the
> primary intention of it's use to obtain contact information. Having said
> that ...
>
>
>
> - the HTML device element's data attribute can be serialized quite nicely
> (in a JSON.stringify like manner) for transmission via web forms if it
> needed to be and then deserialized (in a JSON.parse like manner) at the
> other end as required. Whether the device element could/should provide
> serialization guidelines is a matter for the WHATWG to decide in [1]. (in
> the HTML Contact Sharing spec a note has been added to this effect). For
> example, the device element's value attribute could be set to the
> stringified value of the data attribute to allow for standard web form
> submission and parsing on the server-side.
>
>
>
> This proposal is an early draft and will be developed going forward.
>
>
>
> The intention is for both the programmatic model in [2] and the HTML-based
> model to co-exist within a conforming user agent, allowing a web developer
> to choose the most suitable mechanism according to their application's needs
> and to allow either model to function with the aid of a common user
> interface/experience, contact storage and format.
>
>
>
> All feedback is welcome and will be taken onboard in order to create the
> most compelling integration model we can. As always,
>
>
>
> - Rich
>
>
>
> [1] http://dev.w3.org/html5/html-device/
>
>
>
> [2] http://dev.w3.org/2009/dap/contacts/Overview.html
>
>
>
>
>
>
>