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 10:05:28 -0800
Message-ID: <CAAxVY9dQB1fxh93-GUDMnz45jkNvbSG3Li1e+uVPrKE8YnJxMw@mail.gmail.com>
To: Bjartur Thorlacius <svartman95@gmail.com>
Cc: WebIntents <public-web-intents@w3.org>
On Fri, Dec 16, 2011 at 12:00 PM, Bjartur Thorlacius
<svartman95@gmail.com> wrote:
> On Fri, 16 Dec 2011 16:23:05 -0000, Greg Billock <gbillock@google.com>
> wrote:
>> There's a lot to recommend this register-silently-then-select-upon-use
>> model. That's partly why we want to have a declarative registration
>> model, so that user agents can choose to behave this way. There are
>> some
>> complications. For instance, silent registration and then
>> automatically following an intent with no user in the loop would allow
>> for a new cross-site tracking mechanism, which is not acceptable. The
>> user agent needs to be careful about such issues, but I think the
>> problems are soluble.
> User Agents should only follow the intents of users, not sites.
> Users, not sites, choose actions. The current proposal gives the
> responsibility of choosing an action to scripts, but essentially requires
> that users select implementations of the action. The problem with this is
> twofold.
> Firstly users must have the power to pick actions. In practice, scripts
> should defer to users but are left without a standard way to do so. And
> annoyingly, scripts have the power to refuse to ask users. Either way,
> usability is harmed. As for the representative example, I for one tend to
> read letters sites want me to spam representatives with, although this may
> correlate with my not having a representative.

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.

> Secondly, some actions are of such nature that many users have only one
> implementation to choose from. What actions these are varies between users.
> Prompts for choice one of one implementation are equivalent to OK/Cancel
> prompts. I should not have to state how harmful overuse of them is. Sites
> should of course not even be able to request the user run fdisk C: or mkfs
> /dev/sda.

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.

> The solution is obvious: let users choose actions (as sites could only be
> hoped to allow users to do) and optionally implementations.
> Registering an action is akin to bookmarking. Automatic and silent
> registration will be great. User interfaces should display actions and
> implementations actually, and by extension often, used more prominently than
> those never needed and offer blacklisting for users that can be bothered.
> Whitelisting can of course be used in properly managed user agents. I expect
> user agents to be able to resolve this.

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?

>> Bjartur Thorlacius wrote:
>>> Users can initiate actions on resources. Users can make two important
>>> choices: what actions to initiate, and on what resources. Often, but not
>>> always, they also want to choose the implementation of the action. For
>>> some actions however, the user most certainly wants the only available
>>> implementation. On the other hand, initiating an action for which no
>>> implementation is available is an error.
>>> The User Agent manages the list of available implementations and media
>>> types they accept, and thereby the list of valid actions for any type of
>>> representation of a given resource. Given a resource and types only the
>>> User Agent is able to present a list of valid actions to the user.
>>> Sites can offer resources, and they can offer services or implementations
>>> of
>>> actions. User Agents can collect these offers and derive what
>>> implementations can be applied to what resources. Finally, it is the
>>> user's
>>> to tell the User Agent what actions to apply on what resources, and where
>>> necessary, what implementation to use.
> --
> -,Bjartur
Received on Monday, 19 December 2011 18:06:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC