- 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
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 UTC