Re: Informal proposal for integration of Contacts API with HTML forms

The general use case I had in mind was only for read only and I think 
that keeping it read-only is fine - It would be rather strange to grant 
scripts write access when user just selected a contact to put into form. 
If there are strong use cases for write access in here it can be done as 
it is done for file writer - as an additional input type ie. something 
like <input type='saveascontact'>. I can't find a good use case for that 
right now though.

Additionally I think it touches an important issue for ContactsWriter 
spec. If an implementation supports both read and write access to 
contacts, then should the contacts returned by contacts.find be 
writable? I don't think this should be the default. Maybe the access 
mode should be specified as a parameter to find? The user agent then 
could display different contact picker, with different message etc.

W dniu 2010-08-11 20:15, Frederick.Hirsch@nokia.com pisze:
> To be clear on the following:
>
> "On setting, if the new value is the empty string, it must empty the list of selected contacts; otherwise, it must throw an INVALID_STATE_ERR exception."
>
> It seems that the approach you suggest is markup to allow read access of specific fields from specific contacts, allowing those values then to be posted with form data.
>
> Is the intent to also allow writing of contacts information to the device, for example either erasing an entire contact (empty string), or updating specified fields?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Aug 10, 2010, at 8:40 AM, ext Wojciech Masłowski wrote:
>
>    
>> For many use cases of Contacts API the desired functionality is reading
>> and processing the data of a specific contact(or set of contacts)
>> selected by the user. Example of such a use case would be a news site
>> with a "send this article to a friend" functionality. This functionality
>> can be achieved using only javascript APIs, but as use cases appear to
>> be potentially very strong, it might be reasonable to provide standard
>> markup element to handle it.
>> The use case described above can be met by extending HTML input element
>> by a new type. The idea is to reuse forms functionality especially
>> <input type="file">  and apply it to contacts.  The advantages of such
>> approach
>> * Having standard UI element vs custom solution for each site.
>> * Integration with forms
>> * Possible to use even with javascript disabled
>> Cons
>> * Duplicates functionality of javascript API
>> * Problematic forms upload format
>>
>> Example markup which could be used in example above:
>>
>> <input type="contact" name="friend" fields="emails, ims" multiple />
>>
>> Supported Attributes:
>>   * required - The required attribute is a boolean attribute. When
>> specified, the element is required. ->  standard html5 meaning
>>   * multiple - The multiple attribute is a boolean attribute that
>> indicates whether the user is to be allowed to specify more than one
>> value. ->  standard html5 meaning
>>   * fields - - The fields attribute is a string attribute which
>> indicates which contact fields are passed to the form. The user agent
>> MUST present clear visual information about which field access is
>> requested by the form. The user agent MAY provide a way for user to
>> further limit the fields which are made available by the user. ->  A new
>> field. It's meaning is the same as search qualifier parameter to
>> contacts.find method of Contact API - it narrows down the scope of data
>> which is passed from the user.
>>
>> DOM interface:
>>
>> interface HTMLContactInputElement : HTMLInputElement {
>>      attribute Contact[] contacts;
>> };
>>
>> Contact input element would expose one new IDL attribute - contacts.
>>
>> * contacts - Returns a FileList object listing the selected files of the
>> form control.  This attribute is set to a list of contact objects
>> representing contacts selected by the user. The field set of the
>> contacts MUST be narrowed down to the field set specified in 'fields'
>> attribute or if the user agent allows user to specify the field set to
>> the user specified fields. ->  analogous to files attribute  on file
>> upload input field.
>>
>> * value: On getting, it must return id of the first selected contact, if
>> any, or the empty string if no contact is selected. On setting, if the
>> new value is the empty string, it must empty the list of selected
>> contacts; otherwise, it must throw an INVALID_STATE_ERR exception. ->
>> The behaviour is analogous to the behaviour of value field on file
>> upload input field.
>>
>> Apart from that, the change events (change and formchange) MUST be
>> triggered whenever user modifies the selected contacts(as described in
>> HTML5 spec).
>>
>> Security&  privacy considerations
>>
>> The privacy considerations are mostly the same as for javascript
>> contacts API. The only difference is that form based approach has user
>> explicit consent baked in - user has to explicitly interact with page to
>> select contacts he wants to share. The biggest problem is for ui to
>> successfully communicate to user what he is sharing. It is easy to
>> imagine situation in which site adds an email field in the form which
>> requests all fields of the contact, the user clicks it selects a contact
>> and thinks he only shared his email address, but actually he shared full
>> contact info. To counter that the user agent MUST clearly express to the
>> user to which fields the access was requested. The same considerations
>> apply of course to contact picker triggered by contacts.find method.
>>
>> UI:
>>
>> The visual representation of a contact input element is implementation
>> specific, but in general it should be similar to File Upload - a button
>> to trigger contact picker and a field to present chosen contact(s). The
>> Clicking the button should trigger contact picker ui. Such an ui MUST
>> clearly present to the user which fields of the contact are exposed to
>> the site. It MAY allow user to further reduce the set of contact fields
>> that are exposed. For example it may present a list of checkboxes for
>> fields. Additionally click() method called on such an alement should not
>> trigger contact picker ui.
>>   ->  The key point is that UI must give a clear message to the user that
>> what he is sharing are contact containing a set of attributes and not
>> just their name or email(which is what he will probably see in contact
>> chooser), the same as when he is using file upload he is sharing content
>> of the file and not just it's name.
>>
>> The other viable way of implementing it is a edit box which would give
>> you list of hints for contacts after typing in few letters - similar to
>> browsers addressbar. If such an approach is used it is important that
>> * the user MUST be informed which fields are being requested
>> * only change events are triggered and not input events and the value
>> attribute should always return only the list of selected contacts and
>> not the letters typed in by the user.
>>
>> Format of data sent on form submit:
>>
>> The problem with contacts is that as opposed to other form inputs it is
>> a set of fields rather than one value. The encodings for sending the
>> data to the server assume that an input fields contain only on value.
>> This problem can be solved in 2 ways:
>>
>> A) Serialize the contact in some way(for example in JSON) and send it as
>> a single value. The server then has to deserialize it.
>>
>> Example:
>> For :
>> <input type="contact" name="friend" fields="name.givenName">
>> with selected contact object with id = "some_id" and
>> name.givenName="Bob" url encoded request looks like this:
>> http://cool.contacts.site.com/process_contact?friend={%20%22id%22%20:%20%22some_id%22,%20%22name%22%20:{%20%22givenName%22%20:%20%22Bob%22%20}
>>
>> B) treat as if contact fields were separate inputs and send them
>> separately. For data from previous example this will be encoded like this:
>>
>> http://cool.contacts.site.com/process_contact?friend.id=some_id&friend.name.givenName=Bob
>>
>> The second approach has a disadvantage because it behaves a bit
>> differently to other form input fields which may be somewhat confusing,
>> but it has the advantage that you can easily maintain a version of the
>> the page for old browsers using simple form approach by sending normal
>> form based version - for example
>>
>> @code for new browsers -
>> <input type="contact" name="friend" fields="name.givenName,
>> name.familyName" />
>> @code for old browsers -
>> <input type="text" name="friend[0][name][givenName]" />
>> <input type="text" name="friend[0][name][familyName]" />
>>
>> the solution for old browsers will require user to manually type all
>> contact data and thus will have poorer user experience, but it will have
>> the same funcrtionality and can be handled by the same server code.
>>
>>
>> -- 
>> Wojciech Masłowski
>> Engeneering CORE Wrocław
>> Opera Software ASA
>> http://www.opera.com
>>
>>
>>      
>    


-- 
Wojciech Masłowski
Engeneering CORE Wrocław
Opera Software ASA
http://www.opera.com

Received on Friday, 13 August 2010 11:05:46 UTC