Re: PFWG review of Contacts API

Hi Michael,

thanks a lot for your review. This is not the official response from the group but rather some personal notes.

On Aug 23, 2011, at 15:36 , Michael Cooper wrote:
> (1) Re: 'photos' attribute, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#attributes-1
> 
> The spec does not allow to provide an alternate text or a description to any of the photos. However, since the photos are meant to be used as profile photos (explicit note provided), in general the name of the contact person should be sufficient to be used as alternate text.
> 
> (a) The following accessibility-related problem could still occur: A contact item has a photo, but no name and no displayName is provided (all attributes except 'id' are optional).
> 
> * This would be a clear disadvantage to the visually impaired users.
> 
> * Proposed change: Add the following note: "If one or multiple photo fields are provided, either the 'displayName' or the 'name' attribute should have reasonable content, thus serving as alternate text for the
> photos." 

That is, unfortunately, not something that we have control over. The purpose of the Contacts API is to expose data that already exists in the user's contacts database. If the user has chosen to create a contact with a picture but no name (which is probably impossible in many contacts managers) then there is nothing we can do but expose that data as it is. I would expect however this problem to be self-solving in the typical case: since this is the user's own data, presumably visually impaired users will not be creating contacts with just a picture and no name. It would be possible for the Contacts API to expose other data sources that the user has access to (e.g. an organisation's LDAP service); in that case there is nothing we can do to fix the data — we're just making it available.

> (b) It is not clear what information the 'type' attribute should carry for a photo item. Is this intentionally left unspecified? The spec would benefit from clarifying what information should go into the 'type' attribute for photos, even if only by examples.

I don't really know, I agree that it could be useful to clarify the purpose of the type field for all sources that use the ContactField interface. In the PoCo specification, there is one example given in which type is set to "thumbnail". I'm not sure what other values would be.

> Regarding 'type' information on photos, we wonder if this information would be useful for semantic purposes, in order to be able to differentiate between multiple photos and their appropriate use. For example, by marking the photos as "work", "leisure", etc., an application could automatically suggest an appropriate photo for a particular situation (e.g. job application, social networking site, etc.). This would also be helpful for people with visual impairment, as part of an automatically generated alternate text for the photos.

That could indeed be a useful usage of this field; that being said as discussed above we have no control over what goes into that information and can only expose it. We are tributary to the underlying contacts database as well as to whatever format it follows (vCard, PoCo, CAB).

> (2) Re: 7. API Invocation via COM Events, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#api-invocation-via-dom-events 
> 
> * The event types mentioned include mainly mouse-specific events (dblclick, mouseup). However, in the spirit of device-independence a user should also be able to activate the Contact Picker via keyboard.
> 
> * Proposed change: Add "keypress" and "keyup" to the list of allowed even types..

That is certainly a valid concern. My initial understanding was that this definition had been imported from DOM 3 Events but I can't find a trace of it (it is meant to be the same that allows popups to open for instance, or that protects <input type=file> for programmatic invocation).

We need to investigate a proper definition for this; it might be best for us to coordinate with www-dom on this one.

> (3) Re: A.1 Accessing Contact Information ­ Example #1, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹1 
> <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--1>
> 
> * In the example shown, it is not clear what the "Select" operation applies to. Can the user select the information fields only (as shown on the left), or can they also select and exclude individual contacts?
> 
> * Proposed change: Use checkboxes on the right side to select specific contacts (the same as on the left side for selecting the information fields).

The idea is that they should be able to select specific individual contacts as well. I see that it is unclear and can use some clarification indeed.

> (4) Re: A.2 Accessing Contact Information ­ Example #2, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹2 
> <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--2>
> 
> * Why is there no mention of the non-blocking contact search notification, as in example #1?
> 
> * Proposed change: Clarify.

That's just an oversight, thanks for spotting it.

> (5) Re: Formatting issue with table header cells in the spec
> 
> Header cells in tables (like the table in 4.9.2 <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#event-handler-attributes>) are displayed as inverted (white on blue). When rolling over its text, the text color remains white and the background color is set to a light yellow. This is not readable anymore.

That's a bug, there needn't be a link there. Fixed, thanks.

> (6) Typos
> 
> * "acheive" in Section B. Adding and Updating Contacts, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#adding-and-updating-contacts 

Well spotted, it's been fixed.

Thanks a lot!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

-- 
Robin Berjon
  Robineko (http://robineko.com/)
  Twitter: @robinberjon

Received on Wednesday, 31 August 2011 11:22:20 UTC