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

Re: Bjartur's Actual Criticism (finally)

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Mon, 19 Dec 2011 22:48:10 -0000
To: "Paul Kinlan" <paulkinlan@google.com>
Cc: WebIntents <public-web-intents@w3.org>, gbillock@google.com
Message-ID: <op.v6rdmks7ewg2x1@bxr>
On Mon, 19 Dec 2011 21:43:59 -0000, Paul Kinlan <paulkinlan@google.com>  
wrote:
> The publisher needs to be in control of where the actions are placed  
> inside
> their experience.
As a user I have to disagree with you. I seem to wrongly believe that we,  
not publisher, are to experience. But I guess we have to agree to  
disagree. Authority is yours.

> The actual picker will be managed by the user agent.
>
The latter picker, yes.

> For sites that don't support the actions the UA could have them embedded  
> in
> their chrome as generic actions to take place on the users command in
> consistent places in the browser (such as the URL bar or menus). But that
> is up to the UA.
UI duplication is harmful. If most pages I use bundle an UI I have to  
choose between having duplicate UI most of the time (both consistent  
chrome UI and inconsistent in-page UI), or inconsistent UI most of the  
time and no UI some of the time. Also the set of supported actions varies  
between UAs as the set is populated as service offers are picked up. Thus  
as new actions are invented and discovered by my UA I will have a  
situation where the consistent chrome UI has new actions the inconsistent  
in-page UI may or may not have. If pages implement UI for actions my UA  
has not discovered yet they *have* to bundle service offers.

The choice of whether to display buttons, and if so whether to display  
buttons for actions or for every available implementation, depends on  
factors such as number of discovered actions and implementations and even  
the personality of the user. Neither should be communicated to sites, and  
thus the decision must be taken by either the user agent or the user  
himself.

Abstracting the choice of services a la mailcap is an improvement, but why  
stop halfway?
Received on Monday, 19 December 2011 23:49:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 19 December 2011 23:49:40 GMT