Web Intents - a short introduction

Web Intents is designed to address the problem of a Site wanting to do
a certain Action with a Partner known to the User but not the Site.
The User doesn't really want the Site to know which Partner the User
has selected, nor does the User really want the Partner to know which
Site caused the User to contact the Partner.

Real world example: there's a Bill being proposed to a local
legislature. A number of Interest Groups want to lobby in
favor/against. To do this, they offer people sample letters to send to
their representatives. An individual has a representative, but
shouldn't need to tell the Interest Group who it is, that's private
and unnecessary. The individual might customize the letter before
sending it to the representative. The individual doesn't want the
representative to know which interest group they support, that's
private. In the real world, the Individual takes the sample letter
from the Interest Group, adjusts it, selects their Representative and
sends it.

An Intent could be "contact-representative", and an Interest Group
(Site) could use that. The Individual uses a User Agent which let's
the user select a Provider (Partner) for the intent
"contact-representative" and passes along the letter (the content) on
behalf of the User.

How does the user find an Intent Provider for this Intent? There are
lots of ways. They could receive Mail from their Representative with
the info, they could visit their Representative's (Partner) office
(Web Site) and receive the info as a business card (IntentProvider
Offer) and stick it into their Address Book (their Browser could
automatically store these). What happens if they move or their
representative changes? They'll receive a bad reply if they try to
contact the old representative and make a note not to contact it again
(this isn't a deletion, it's an annotation, you can keep seeing the
business card but remember you don't use it). They could visit the
House of Representatives and browse for their representative
(directory lookup/search), or they could visit the right office and
just get a new card (direct Site visit).

Now, contact-representative is a bit too specific for a general
Action, but it's descriptive of how things could work.

More likely intents are "Save", "Send", "Print", "Share", "Call", "Chat".

Let's look at how a User Agent might handle one of these:
Print. Your typical application on your average desktop computer has
an Action for printing. When you select print, you get a dialog (from
the System, your User Agent) listing possible Providers/Partners who
can handle the Action of Printing. Sometimes this list is empty.
There's often an option to Search/Browse from a list of local/network
printers. You can even add a number of these from this dialog. The
application (client/web site) isn't told about printers you add, it
doesn't care. When you finally select a printer for printing, your
application sends the System (User Agent) the data (print job) and the
System sends it to the Printer (Partner/Provider) you selected. The
System (User Agent) may have a Queue where it shows progress for all
your print jobs (not just from this one application), and your Printer
(Provider) may have its own Status showing its Queue of jobs. The
original application doesn't need to care about any of this.

What if you want to do something different than use a local printer?
There are Web Sites which provide Fax services (they tend to take
PDFs/PostScript, just like real printers), and there are some services
which let you access documents from anywhere (RIM offers a service
called Print To Go which let's you print to your PlayBook). With the
Web Intents model, instead of you installing Native Code for a Printer
Driver on your system for this web fax or web print, your could direct
your browser (or another User Agent) to that site and it will discover
(learn+remember) the provider. When you later chose encounter a need
to Print, your User Agent can list this service and let you select it.
If the service requires additional info (fax services tend to require
a phone number, and both could require credentials), the User Agent
could present a distinct page where you fill in the necessary info. If
your UA can't provide the extra UI (possible), then the Provider could
instead queue the request until you contact it by another means.

An intent could also be something like "get-temperature" or
"get-orientation" or "monitor-temperature" or "monitor-orientation",
these would allow the user to hook up sensors (local, network, stubs,
or otherwise) to an Application. This is similar to how a user can
choose to plug in a Joystick, Gamepad, or specialized Keyboard to a
game system.

-- 
Sent from my mobile device

Received on Friday, 18 November 2011 21:26:15 UTC