Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
Hi all, sorry for not jumping into this thread earlier. I'll try to summarise my opinions succinctly in order to avoid extra noise. On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Unfortunately there is no formal use cases document, rather they were discussed as the API was developed (it has changed a lot since the first input was made available). In general this API shines compared to the available input types when you need either multiple people at once and/or multiple fields from given contacts. If you want to email 50 people, you're better off selecting them in a contacts picker than typing them in, even assuming friendly completion from input type=email (note that since the contacts picker that the API expects can be platform-provided, existing structure you may have in your contacts DB such as groups can be used directly). Likewise if you need to enter email and snail addresses for someone, you're better off picking that person once rather than having to select them multiple times with a completion helper (or typing everything in, of course). Based on this we can see use cases such as: • Send printed invites to a whole bunch of people to a party/wedding/whatever, needing full name and address. • Set up a Web VoIP conference and invite people over email. • Load a bunch of friends and get a map of which locations in town are closest to all (as in http://old.isokron.com/ but with more than two people). That's just what's at the top of my head tonight, but I think it gives an idea. As for input type=contacts, it's something that was considered but it's less straightforward than one would hope as there are several aspects to consider. The first is that it would need to expose an input type=contacts.contacts API in the same way as input type=file.files does. That's pretty simple — in fact that API is 90% of what's in the Contacts API. But then it needs to contribute to form submission. They idea of just attaching a vCard as a file for each contact was floated but it feels like a cop out. It also requires browsers to correctly generate vCard content (since even if they had access to the raw vCard they'd need to keep only the relevant fields). It's not the end of the world but, as usual, there are kinks. Another option is to use one of the conventions for multi-model forms so that if you have input type=contacts name=mycontacts you generate mycontacts[email], mycontacts[name], etc. or possibly (in the multiple case) mycontacts[0][email], mycontacts[0][name], etc. There's no single convention for that though, so it doesn't feel overly satisfying. Then there's fallback. New input types work best when it makes sense for them to fallback to input type=text (the default): email, url, tel, search, dates all work that way. For contacts, it really doesn't work all that well and you'd' have to hide it (or provide some heavy lifting). There's also the issue of what you show since it's a visible control. You need a button to trigger the contacts dialog of course, but you also need something to provide the user with visual feedback that they've selected a set of contacts. This can be anything from a You have selected 47 contacts string to actually displaying each contact and its relevant fields. Wherever you fall in that spectrum, you then have the issue of how to style it. Speaking personally, I'd very much rather not spend the next five years finding yet more CSS workarounds to get a new form control to work in a dazzling system*browser matrix. None of this is insurmountable but it's extra work for benefits that aren't immediately obvious (to me). What's more, it's work that seems to involve a solid potential for interop snafus. The Contacts API is actually designed to operate in the same way as input type=file.click() does, but sans the form-related issues. It only triggers on valid auto-invocation events and asynchronously provides a list of objects (the fields of which are tailored to match the request). The idea behind the approach is that if ever there is a will to make this into a form input type, then the code path to support the API on top of it should be as short as calling input type=contacts accept-fields='name email url'.click(). So, put another way, what the spec doesn't tell you is that it *is* input type=contacts, with the same security model and the same platform integration, but trimmed down to include what you need for the use cases and to exclude what you don't for the headaches. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai o...@chromium.org wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. This has lots of follow-on advantages too: - Browser-provided UI is consistent for the user WRT the OS (see file pickers). Your app would need to guess to match the visual and interaction style. - Browsers can handle all of this with much less code on your part. The latency involved in building and sending the custom UI makes for a bad experience, and is it work you really want to be biting off for your app? - A11y, focus management, and all the rest with Just Work (TM). On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.comwrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome , and send me your complaints! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. I think a token field based UI for this (like the address field in Mail on Mac OS X, or the attendees field in iCal) might make for good UI for this sort of thing. But this design assumes that the email address is desired, or at least relevant to display. Are there use cases where a contact is desired for a purpose completely unrelated to email addresses? Perhaps if you are making a dialer or an SMS app, but I'm not sure that is a case we want to support. Regards, Maciej Ojan On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.com wrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome, and send me your complaints! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Tue, Jun 28, 2011 at 10:10 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. I think a token field based UI for this (like the address field in Mail on Mac OS X, or the attendees field in iCal) might make for good UI for this sort of thing. But this design assumes that the email address is desired, or at least relevant to display. Are there use cases where a contact is desired for a purpose completely unrelated to email addresses? Perhaps if you are making a dialer or an SMS app, but I'm not sure that is a case we want to support. I think we probably do want to support those use-cases. You could still make this work with an input element. Security-wise, I think it would be OK to expose the entirety of the contact info once the user selects a contact. So the app would then be able to show whatever they want in the UI. I didn't want to delve too much into API details before getting a list of use-cases, but with the use-cases I have in mind, I think we'd also want a way of filtering items the user can pick from, similar to the accept attribute on input type=file. For example, for an SMS app we'd only want to show contacts that have a mobile phone number. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Seconded. On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. Ojan On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.com wrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome , and send me your complaints! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_CONTACTS to WebCore
Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
