RE: Declarative invocation

Dear James,

The declarative invocation markup would ideally support multiple inputs from a webpage and multiple outputs back to the webpage.  There might be multiple intents supported on a page, and perhaps there might even be overlap between the inputs and outputs.

For example, a file input element could declare the mime type(s) accepted, and this could be used with a pick intent to return a blob (single output).  This blob might be then be usable as a further input to an 'image edit' intent that returns an updated blob (single input, single output).  Finally when the input form is submitted the blob is sent.  This could allow a webpage without JS enabled to upload an edited image captured from a device camera, all from within the web browser.  The user can use trusted web apps for the image capture and for the image editing without exposing the camera API and without sharing UA state via an image editing web app.

For example, a section of an input form with contact inputs (name, address, etc), could be used with an intent that can search a trusted 'contacts' web app using supplied fields to direct the search and returning the requested fields that are used to populate the input form (multiple input, multiple output).  The user might make some changes to the address and invoke another web intent to save the new contact address (multiple input, no output?).

There may be some opportunity to coordinate the required markup with general 'semantic web' markup, such a microdata.  The web browser could then implement the UI and invocation without the webpage needing to add the UI support, and this might be done in a manner that is less vulnerable to spoofing.  I would also be keen to explore how this could help accessibility of webpage input forms.

For example, a photo viewing webpage might markup a slideshow allowing a presentation web app, that is specifically adapted to a limited device, to show the slide show and this could be invoked via a web intent (multiple input, no output).

The direction to take with the webpage UI support for invoking web intents is not clear to me yet.  It would be good to support buttons that can invoke an intent, such as a 'share' intent button, and this would allow a webpage to voluntarily place and style invocation buttons.  Buttons might also by placed around form input elements, such as a text input form element.

Other options being explored are allowing a web app to take over an element or region of a webpage when invoked - for example could a web app invoked via web intents might take over a webpage text input form element within the page to offer a rich HTML editor.   Other options are to overlay a webpage region, or a popup?

Support is also needed for legacy webpages, without semantic markup and web intents invocation buttons etc.  This might not need a standard, and might be a matter for the web browser, but it could use the infrastructure provided for declarative invocation.  For example a web browser might offer a content menu option to invoke a range of web intents for a file input element and remember the choice, or offer a range of intents to edit a text input element, etc.  A database of useful intents for various web pages might be maintained.

The PUA CG is chartered to develop extensions that improve the security of private UA state and could take on the task developing declarative markup for invoking web intents?

cheers
Fred

From: jhawkins@google.com
Date: Wed, 2 Jan 2013 11:09:15 -0800
To: fredandw@live.com
CC: public-web-intents@w3.org
Subject: Re: Declarative invocation

I agree that declarative invocation would be pretty awesome.  I think the list is generally in agreement; however, it hasn't been very high on the list of things to spec out, so it hasn't happened yet.


Do you want to provide some examples of what you think it may look like?


Thanks,James

On Sat, Dec 8, 2012 at 7:45 PM, Fred Andrews <fredandw@live.com> wrote:





Web Intents would appear to be well suited to supporting rich interactive UI via apps in webpages without Javascript enabled. This requires a declarative invocation specification.

For example, editing a textbox, or filling a contact input form, providing an image input blob, social share widgets, etc.



It might be useful to allow input forms to be marked up with Web Intent inputs and result outputs plus the intent action and type.  Web browser might be able to guess or remember appropriate intents to use for input forms even on pages not marked up for this.  For example, a wikimedia textbox for which the user can choose a rich app to edit or generate content.



A new fallback element might also be handy, for example if a browser does not support declarative web intents then this element could include a default html editor for a text/html textbox, or include a group of popular social widgets for sharing.  This might work in a similar way to the <noscript> element, or might be the body of a web intent invocation element for which the body is ignored if web intents are enabled.



Declarative invocation might also be easier for web authors.

There appears to be potential for helping users that choose to only enable javascript on trusted webpages because the user would gain the choice of using a rich app from a trusted website to perform some common tasks.



cheers
Fred