W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: Bjartur's Actual Criticism (finally)

From: Greg Billock <gbillock@google.com>
Date: Mon, 19 Dec 2011 13:06:12 -0800
Message-ID: <CAAxVY9dGhsA7mJLD0EL8H5FGgftMj31=ar3uGvVAZ7neMCdxXQ@mail.gmail.com>
To: WebIntents <public-web-intents@w3.org>
On Mon, Dec 19, 2011 at 10:40 AM, Bjartur Thorlacius
<svartman95@gmail.com> wrote:
> On Mon, 19 Dec 2011 18:05:28 -0000, Greg Billock <gbillock@google.com>
> wrote:
>>
>> There is nothing in the spec forbidding user agents from hooking content
>> and
>> providing ways to trigger intents without the direct involvement of
>> the client site.
>> In fact, I expect this to happen. Extensions should be able to add such
>> hooks
>> as well.
>>
> I am arguing that as user agents are in a better position to hook content
> and thus the spec should be greatly simplified by removing the client
> interface. Not only should user agents be able to hook content, sites should
> not be encouraged to hide the content and override user agent hooking. The
> specification should at least not imply that it is the responsibility of
> client sites to implement UI for Intents.

The way I'm reading this is that you understand the spec to say that the client
site is responsible for showing the picker interface (that is, where the UA
presents to the user a selection process for choosing a service to handle an
intent). That's certainly not the intention, and perhaps the wording should be
chosen more carefully. If you visit http://webintents.org and try some of the
examples, you'll perhaps have a better sense of the goal workflow we have
in mind right now.

The reason client sites need an API to trigger intents is so they can make use
modalities obvious and accessible to users. Think of "print" buttons, "share"
buttons, etc. I think it would be sacrificing an important discoverability tool
not to allow sites to signal these kind of integration points.

>> That may be true, and we hope that user agents implement the picker
>> function
>> (where the user is asked to select a service) in a non-annoying way. The
>> spec
>> is unlikely to mandate anything along these lines directly, though; it
>> is a judgment
>> call for user agents to make as to how to best perform that function. As
>> we've discussed elsewhere, there will probably be a "SHOULD" type
>> suggestion
>> here, since to make the ecosystem work, web developers want to have a good
>> sense of what happens to users when interacting with these types of
>> controls.
>>
> My point was not that pickers could be implemented poorly. My point was that
> users need to be in the loop (i.e. consent), and doing so by selecting an
> action is "better" than by selecting an implementation as users may or may
> not care about the choice of the latter and thus we have to assume UAs may
> guess the choice of service or otherwise automate and streamline the
> process.
>
>
>> Yes. It sounds like what you have in mind is a wishlist for user agent
>> implementation, and that the proposed spec will not forbid any of that
>> behavior,
>> and while not mandating it, will probably end up suggesting at least some
>> of it.
>> Is that correct?
>>
> I wish for UI to be implemented in UAs. I want the spec to specify only the
> interface between UAs and services and leave out all user interface
> implementation details.
>
> What is the use case for the client site interface? Note that while
> technically, as you pointed out, the spec won't forbid sites from not using
> the client site interface, I fear they might. And the only thing I can think
> of using it for is overriding user agents' UIs with whatever UI the author
> has grown accustomed to.
Received on Monday, 19 December 2011 21:06:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 19 December 2011 21:06:50 GMT