Re: Web Intents - Fourth Parties (part 5)

On Tue, Nov 22, 2011 at 3:22 PM, timeless <timeless@gmail.com> wrote:
> Web Intents - Fourth Parties (part 5)
>
> There are three main parties involved in the Actions I've described:
> 1. The User Agent / User
> 2. The Client / Page requesting an Action
> 3. The Partner / Provider that will respond to the Action
>
> I'd like to suggest possible Fourth parties for a moment:
> §11 Filter/Transform Actions
> §12 Reputation Providers
>
> §11 Filter/Transform Actions
>
> I think we're going to want to encourage vendors to produce and offer
> Filter/Transform Actions.
>
> To use my Printing examples, anything that offers Print to File is a
> Transform from <Print> to <Save>*. These can be used to address
> certain problems. Note that while some of these appear to just be
> Previewing tools (ala §7), most actually allow Editing (highlighting,
> rotation, re-sequencing, cutting, saving, etc.).

This is something we've given a little thought to, but without much
definite to say about it. I want to make sure we don't end up
specifying a generic graph construction language which implementors
will find daunting to use. The sweet spot is for compositing
functionality (which may be quite complex!) into web apps, and I want
to make sure that simple case is kept simple. As to whether intents
can be chained, or understood as filter or transform operations, my
current thinking is that this kind of behavior is best left to either
the client page, where particular workflows can be facilitated. (One
demo Paul Kinlan has made uses this kind of thing in the imagemator
[1].) Or to the service, which may want to allow editing of an image
during pick, for instance, or to side-save an image being edited.

In other words, the web apps themselves may be able to use intents in
more complex ways, but the users of those apps wouldn't be responsible
for hooking them up in this way. (Of course, it is possible to imagine
a complex extension providing scripted intent-driven composition to
handle different workflows. That'd be awesome, and would be aimed at
the people using tools like Pipes [2] or IFTTT [3].)

> §12 Reputation Providers
>
> Clients/Providers will often be dealing with confidential + valuable
> data.As such, users could probably benefit from unaffiliated
> reputation providers who can review both Client Pages and Provider
> Partners.

This, in my opinion, isn't really part of the intents API or spec
itself, but is instead part of the more generic problem of assigning
rankings to web apps, which includes security analysis, usability,
fitness to purpose, features comparison, etc. I don't think the spec
should be directly addressing things like this.


[1] http://www.imagemator.com/
[2] http://pipes.yahoo.com/pipes/
[3] http://ifttt.com/

Received on Thursday, 1 December 2011 21:47:22 UTC