A few WI spec questions
Will Meyer
Great to see the recent developments on WI! Awesome stuff, from a
practitioner's point of view.
I spent a bit of time trying to make a WI proxy for any service that
accepts shares via OExchange (meaning they have a compliant endpoint
URL and an XRD on their host that points to this endpoint [1]), and
have a few questions on the WI spec. Any thoughts appreciated! (BTW
the hosted version of the lib that's handed out in the docs is
http://webintents.org/webtintents.min.js, which 404s — examples. host
is fine).
* Is the model essentially that all interactions are within a popup,
and if so what is the size? Curious for both the within-iframe as
well as new-window cases. There is a mention of disposition inline
but I've not seen other dispositions, nor a ton of docs on the
providers/intent-handlers/services side of the api other than whats in
the JS. Is the UX offered by the example JS the latest prescription
for the UX from the UA's point of view?
* I'd like to register a prompt/verb along with my intent; can I do
that somehow? IOW, if I'm twitter I want my "share" verb to be
"tweet", if I'm StumbleUpon I want it to be "Stumble this", etc. I
want that branding to show up in the UA's picker menus. I'm not clear
how to do this with the intent tag — are other attributes planned?
(similar Q for additional logos/icons, locale options).
* Can I have multiple intent providers for the same type on the same
domain but named differently? It appears keyed off of host from what
I can tell.
* The reference JS doesn't have any UI for accepting/declining intent
providers when they are encountered for the first time — is that the
intent in terms of UA behavior or just a state of the current JS?
* What is the relationship thought to be between the WI verbs[8] and
Activity Streams[7]? e.g. will a "like" be a WI "share"? The AS verb
set has some gaps to be sure, but is the intent that the WI verbs will
be in parallel with or a super(or sub)set of AS?
* On intent registration, type is listed as optional. What is the
default — is it defined indirectly by the action/intent in use?
* <Bikeshedding> the intent/action/verb/service language is a bit
confusing on first glance — registering yourself as being able to
satisfy a user's intent to perform an action by yourself declaring an
"intent", for example.
* Is there any plan to have a set of events along with the
* Is there a set of events defined as part of the spec, informally or
formally at this point?
There are about 350 services [9] that I can bootstrap into WI interop
if I can figure a few of these things out.
Also, more generally, can you point me to anything that summarizes the
general status of the various works? I'm not compeltely clear where
introducer/websend work stands, whether the app-manifest ideas mozilla
has talked about and implemented in its demo extensions [2, 3, 4] are
being considered as an alternative to using the intent tag for
discovery, as well as whether the very latest version of the spec is
whats up publicly up [5, 6].
Gracias,
W
1: http://www.oexchange.org/guide/
2: https://developer.mozilla.org/en/OpenWebApps/The_Manifest
3: http://www.open-mike.org/entry/using-web-applications-for-service-discovery
4: https://github.com/mozilla/openwebapps/blob/master/docs/MANIFEST.md
5: https://github.com/PaulKinlan/webintents
6: http://webintents.org/
7: http://activitystrea.ms/head/activity-schema.html#verbs
8: http://webintents.org/#defaultintents
9: http://www.addthis.com/services
Paul Kinlan
Hi all,
Great to see the recent developments on WI! Awesome stuff, from a
practitioner's point of view.
I spent a bit of time trying to make a WI proxy for any service that
accepts shares via OExchange (meaning they have a compliant endpoint
URL and an XRD on their host that points to this endpoint [1]), and
have a few questions on the WI spec. Any thoughts appreciated! (BTW
the hosted version of the lib that's handed out in the docs is
http://webintents.org/webtintents.min.js, which 404s — examples. host
is fine).
* Is the model essentially that all interactions are within a popup,
and if so what is the size? Curious for both the within-iframe as
well as new-window cases. There is a mention of disposition inline
but I've not seen other dispositions, nor a ton of docs on the
providers/intent-handlers/services side of the api other than whats in
the JS. Is the UX offered by the example JS the latest prescription
for the UX from the UA's point of view?
* I'd like to register a prompt/verb along with my intent; can I do
that somehow? IOW, if I'm twitter I want my "share" verb to be
"tweet", if I'm StumbleUpon I want it to be "Stumble this", etc. I
want that branding to show up in the UA's picker menus. I'm not clear
how to do this with the intent tag — are other attributes planned?
(similar Q for additional logos/icons, locale options).
* Can I have multiple intent providers for the same type on the same
domain but named differently? It appears keyed off of host from what
I can tell.
* The reference JS doesn't have any UI for accepting/declining intent
providers when they are encountered for the first time — is that the
intent in terms of UA behavior or just a state of the current JS?
* What is the relationship thought to be between the WI verbs[8] and
Activity Streams[7]? e.g. will a "like" be a WI "share"? The AS verb
set has some gaps to be sure, but is the intent that the WI verbs will
be in parallel with or a super(or sub)set of AS?
* On intent registration, type is listed as optional. What is the
default — is it defined indirectly by the action/intent in use?
* <Bikeshedding> the intent/action/verb/service language is a bit
confusing on first glance — registering yourself as being able to
satisfy a user's intent to perform an action by yourself declaring an
"intent", for example.
* Is there any plan to have a set of events along with the
* Is there a set of events defined as part of the spec, informally or
formally at this point?
There are about 350 services [9] that I can bootstrap into WI interop
if I can figure a few of these things out.
Also, more generally, can you point me to anything that summarizes the
general status of the various works? I'm not compeltely clear where
introducer/websend work stands, whether the app-manifest ideas mozilla
has talked about and implemented in its demo extensions [2, 3, 4] are
being considered as an alternative to using the intent tag for
discovery, as well as whether the very latest version of the spec is
whats up publicly up [5, 6].
Gracias,
W
1: http://www.oexchange.org/guide/
2: https://developer.mozilla.org/en/OpenWebApps/The_Manifest
3: http://www.open-mike.org/entry/using-web-applications-for-service-discovery
4: https://github.com/mozilla/openwebapps/blob/master/docs/MANIFEST.md
5: https://github.com/PaulKinlan/webintents
6: http://webintents.org/
7: http://activitystrea.ms/head/activity-schema.html#verbs
8: http://webintents.org/#defaultintents
9: http://www.addthis.com/services
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan
Will Meyer
>> * Is the model essentially that all interactions are within a popup,
>> and if so what is the size? Curious for both the within-iframe as
>> well as new-window cases. There is a mention of disposition inline
>> but I've not seen other dispositions, nor a ton of docs on the
>> providers/intent-handlers/services side of the api other than whats in
>> the JS. Is the UX offered by the example JS the latest prescription
>> for the UX from the UA's point of view?
>
> It is not the intention that all interactions are within a popup. The
> service application can define the disposition we are still working on
> defining the correct syntax but a value of "inline" will indicate that the
> application should be hosted inside the intent picker. By default
> applications will open in a new window - the naming of such might be
> "window".
> The current JS shim is very much an experimentation ground, you will notice
> for instance that the "Share URL" example opens up links inline, but the
> "Share Image" example opens up the application in a new window.
> Dispostition is still very early on in the design cycle and as such I
> haven't pushed documentation other than what is described in the issue on
> github.
>>
Gotcha. Assume this list is the place to keep up to date/participate
in the discussions on that design? I'll change my proxy BTW to use
the mechanism of the image example.
>> * I'd like to register a prompt/verb along with my intent; can I do
>> that somehow? IOW, if I'm twitter I want my "share" verb to be
>> "tweet", if I'm StumbleUpon I want it to be "Stumble this", etc. I
>> want that branding to show up in the UA's picker menus. I'm not clear
>> how to do this with the intent tag — are other attributes planned?
>> (similar Q for additional logos/icons, locale options).
>
> The current design is for the "title" in the intent tag to be what is
> displayed in the Picker. If no title is specified we are currently
> defaulting to the document.title. Likewise for Logo's, applications can
> provide their own logo or the UA will choose the favicon.
> Locale options is a good point and is currently not addressed in the UA.
> The initial assumption would be that the application would present the
> title it wanted to display to the user based on how it detected the users
> language and regional settings, for example Twitter might detect the user is
> currently in Spanish and thus register the intent with a Spanish title.
>
In my view there's a difference between the name of the service as
would be seen in something like a management interface, preferences
picker, etc, and the call to action that makes sens at time of intent.
I'd suggest the design support both notions. (For all of this,
including the localization behavior you suggest, I assume the model is
that the intent handler registration overrides previous instances and
thus can be updated on every view of a page that includes it
(conceptually, certainly there could be implementation techniques to
do it more efficiently)).
>>
>> * Can I have multiple intent providers for the same type on the same
>> domain but named differently? It appears keyed off of host from what
>> I can tell.
>
> Yes you can. The current shim is actually keyed off intent so
> webintents.org/share then it is keyed of "href" of the app that will be
> launched and then it is further keyed of data type, so you can't have one
> page handle "share" twice for the same data type, but you can have one page
> handle "share" and "edit" or you could have two pages in the same domain
> both handle "share", or you could have a single page handle "share" for
> image data and "share" for urls.
> I hope I explained that properly. But in effect the shim will add a new
> intent to the system if the following criteria is not met: "if(intent.action
> == action.action && intent.url == action.url && intent.type == action.type)"
> - otherwise it will overwrite the existing data.
Got it.
>> * What is the relationship thought to be between the WI verbs[8] and
>> Activity Streams[7]? e.g. will a "like" be a WI "share"? The AS verb
>> set has some gaps to be sure, but is the intent that the WI verbs will
>> be in parallel with or a super(or sub)set of AS?
>
> The reason we are using URI's is so that we can handle things such
> as Activity Stream verbs, as long as the URI to identify the verb is a valid
> URI - my initial thoughts around this earlier in the year were based on my
> understanding of the XML version of the activity stream spec which defined
> the verb as
> http://activitystrea.ms/schema/1.0/verb (http://activitystrea.ms/schema/1.0/post
> for example).
> Likewise, the data that you pass through to the applications that handle the
> users intent can specify the format as an activity stream encoded piece of
> data as long as the filter is provided as a MIME type - so
> activitystream/photo when used in the "startActivity" would only list
> services that supported the same data payload.
> We are trying not to step on the toes of the already pre-defined verbs on
> activity streams, but at the same time we are not mapping likes to shares,
> it is soley handled by matching the URI of "intent" provided by the service
> against that of what the calling application wishes to initiate.
>>
I'm mostly following -- I think for this to be most useful as a
general concept there has to be fairly strong definition around the
intents and what they mean conceptually, so that there's a greater
chance services will implement things that both make sense for the
use-cases the publisher has in mind (that they implement support for
without knowing which providers the user will be presented with), but
also don't become so specialized as to reduce the options a user gets
in practical use. We took a different approach with OExchange, which
was to require a URI of content in ALL cases, and not define mandatory
type handling (optional is fine). For example, a key use case is the
photo site use case, where as the page developer I just want the user
to be able to share my photo, regardless of whether the service the
user wants to use to share it accepts rich photo data or just urls to
pages, without knowing its a photo page. For "sharing" specifically,
the power of a spec like WI will be realized not when twitter FB and a
few other services can be shared to, but when a huge number of
reasonable options can be auto-selected down to a set that is
preferred by an individual user. All of that is to say that I would
advocate for strong definition around the most basic and probably most
widely-used -- "sharing" -- such that as a page developer it is
possible to accomplish that most basic action without having to
provide many different activities to handle all of the different ways
a service could "accept" a photo.
>> * On intent registration, type is listed as optional. What is the
>> default — is it defined indirectly by the action/intent in use?
>
> The service defines the data types it can handle in the intent registration,
> "*" for any, or image/* for example handle any image, or it can be very
> specific image/png.
> The type filtering on invocation by the client are string matched mime
> types. The client will say, I am sending an image/png or of they don't know
> it might be image/* or even worse *. The User agent will then resolve a
> list of all the services the can handle that data type. If the client
> passes *, then a list of all services that can handle the users intent are
> listed.
Sorry, so I can start an intent with a type of *? What do I pass as
the data, and how does the service know what it is?
>> * Is there any plan to have a set of events along with the
>
> What is after "the"...? Are you thinking about events on the intent tag?
> Success or failure of registration etc?
>
>>
>> * Is there a set of events defined as part of the spec, informally or
>> formally at this point?
>
> No. Data is returned from the calling application and it invokes a
> developer defined callback. The application that is opened by the user, the
> handler of the intent, just inspects window.intent to get the data, there
> are no "onintent" events that you as a service application need to handle,
> you just read the data at "onload" or where ever you need it.
> Likewise the client application will be notified via a callback when a
> response has been posted by the service.
> Do you have any examples of events that you believe we must have?
>
The use-case I've in mind is on the client side...that I want to track
what users do with my content. So I want to know that the user saw my
image and used service X to edit it. The data passed to onActivity is
the data from the service as far as I understand, which doesn't
include for example the actual service identifying uri. Can I
implement the equivalent of FB.Event.subscribe('edge.create',
function(href, widget) {})?
>>
>> There are about 350 services [9] that I can bootstrap into WI interop
>> if I can figure a few of these things out.
>
> I actually wanted to come and speak to you! I will email you off the list.
>
Hit me.
Also, I'd love to chat with you re the UA implementation thoughts.
The concept of using a user's activity to try to dynamically whittle
down the list of compatible providers to show them is something we've
been doing in AddThis for a while (we have the notion of "preferred"
services, which is based on a combination of a lot of things,
including user activity), so anxious to hear more about the thinking
on how Chrome would/will do it. Also, FWIW, I had seen mention
somewhere of the idea of hijacking in an extension existing buttons to
replace them with intents -- def have some thoughts on that as it
relates to site-owner perception/desires.
Thanks again for the thorough replies, exciting stuff.
W
Paul Kinlan
>>Got it.
>> * Can I have multiple intent providers for the same type on the same
>> domain but named differently? It appears keyed off of host from what
>> I can tell.
>
> Yes you can. The current shim is actually keyed off intent so
> webintents.org/share then it is keyed of "href" of the app that will be
> launched and then it is further keyed of data type, so you can't have one
> page handle "share" twice for the same data type, but you can have one page
> handle "share" and "edit" or you could have two pages in the same domain
> both handle "share", or you could have a single page handle "share" for
> image data and "share" for urls.
> I hope I explained that properly. But in effect the shim will add a new
> intent to the system if the following criteria is not met: "if(intent.action
> == action.action && intent.url == action.url && intent.type == action.type)"
> - otherwise it will overwrite the existing data.
Sorry, so I can start an intent with a type of *? What do I pass as
>> * On intent registration, type is listed as optional. What is the
>> default — is it defined indirectly by the action/intent in use?
>
> The service defines the data types it can handle in the intent registration,
> "*" for any, or image/* for example handle any image, or it can be very
> specific image/png.
> The type filtering on invocation by the client are string matched mime
> types. The client will say, I am sending an image/png or of they don't know
> it might be image/* or even worse *. The User agent will then resolve a
> list of all the services the can handle that data type. If the client
> passes *, then a list of all services that can handle the users intent are
> listed.
the data, and how does the service know what it is?
The use-case I've in mind is on the client side...that I want to track
>> * Is there any plan to have a set of events along with the
>
> What is after "the"...? Are you thinking about events on the intent tag?
> Success or failure of registration etc?
>
>>
>> * Is there a set of events defined as part of the spec, informally or
>> formally at this point?
>
> No. Data is returned from the calling application and it invokes a
> developer defined callback. The application that is opened by the user, the
> handler of the intent, just inspects window.intent to get the data, there
> are no "onintent" events that you as a service application need to handle,
> you just read the data at "onload" or where ever you need it.
> Likewise the client application will be notified via a callback when a
> response has been posted by the service.
> Do you have any examples of events that you believe we must have?
>
what users do with my content. So I want to know that the user saw my
image and used service X to edit it. The data passed to onActivity is
the data from the service as far as I understand, which doesn't
include for example the actual service identifying uri. Can I
implement the equivalent of FB.Event.subscribe('edge.create',
function(href, widget) {})?
Hit me.
>>
>> There are about 350 services [9] that I can bootstrap into WI interop
>> if I can figure a few of these things out.
>
> I actually wanted to come and speak to you! I will email you off the list.
>
Also, I'd love to chat with you re the UA implementation thoughts.
The concept of using a user's activity to try to dynamically whittle
down the list of compatible providers to show them is something we've
been doing in AddThis for a while (we have the notion of "preferred"
services, which is based on a combination of a lot of things,
including user activity), so anxious to hear more about the thinking
on how Chrome would/will do it. Also, FWIW, I had seen mention
somewhere of the idea of hijacking in an extension existing buttons to
replace them with intents -- def have some thoughts on that as it
relates to site-owner perception/desires.
Thanks again for the thorough replies, exciting stuff.
W
Will Meyer
That makes sense as a goal, but I still think it should be possible
for the service (what are they "formally" called in WI by the way --
the things that handle intents?) to provide more custom user
experiences to users than just a generic name of the service. For the
sharing case, at least, a lot of the sharing buttons are not really
just sharing buttons, they are extensions of that services' experience
into the page (e.g. Will and 50 of your other friends liked this). To
the extent that services can still accomplish at least a basic level
of this in the context of being an intent provider, I think you'd see
increased support from the services.
Agree that it would be better to be able to offer multiple types than
to require separate initiations for each type. And yes, widgets can
help here. A photo site should be able to specify that it would like
to allow a user to share this image, and provide a basic url to the
image page, and the actual image data, and depending on which services
the user uses, they would get more or less rich options ("Open in
Aperture", "Tweet this image")
> >> * On intent registration, type is listed as optional. What is the
>> >> default — is it defined indirectly by the action/intent in use?
>> >
>> > The service defines the data types it can handle in the intent
>> > registration,
>> > "*" for any, or image/* for example handle any image, or it can be very
>> > specific image/png.
>> > The type filtering on invocation by the client are string matched mime
>> > types. The client will say, I am sending an image/png or of they don't
>> > know
>> > it might be image/* or even worse *. The User agent will then resolve a
>> > list of all the services the can handle that data type. If the client
>> > passes *, then a list of all services that can handle the users intent
>> > are
>> > listed.
>>
>> Sorry, so I can start an intent with a type of *? What do I pass as
>> the data, and how does the service know what it is?
>
> You can, the service will assume it is something, but not what know what it
> is.
> Hmmm, it makes more sense that the service can define it handles "*", but
> the client that starts the Activity has to define the exact data it is
> sending so the service can handle it correctly.
yes exactly.
> Thinking this further, even if the client says I am sending you an image
> "image/*", me as a service would want to know what type it is prior to
> interacting with it. Content sniffing via the UA or Service will bring on a
> whole heap of pain for developers.
Also agree, the service should be able to declare support for multiple
types for the purposes of registration and user preference management,
but when it comes to an individual interaction, it should be "strongly
typed".
I agree it should not be possible necessarily for sites to sniff for
user preferred services as managed by the ua, but I think the
analytics use-case is vitally important. All current "buttons" that
drive real value for site owners support this in some way -- facebook,
twitter, etc. AddThis supports it for rolled-up services as well. If
the model is that there would be widgets, in reality, doing this kind
of thing, then yes they can do the tracking themselves as they are in
the flow (and this is what they do today).
Additionally, it seems odd to define the input to the service but not
the output. The contract should be defined in both ways -- this may
be an area where I'm missing some docs (the link to the "spec" on the
site just goes to the same home page and I couldn't find a detail of
this reverse interaction). If its not defined then as an initiator of
intents I will never inspect it.
>> Also, I'd love to chat with you re the UA implementation thoughts.
>> The concept of using a user's activity to try to dynamically whittle
>> down the list of compatible providers to show them is something we've
>> been doing in AddThis for a while (we have the notion of "preferred"
>> services, which is based on a combination of a lot of things,
>> including user activity), so anxious to hear more about the thinking
>> on how Chrome would/will do it. Also, FWIW, I had seen mention
>> somewhere of the idea of hijacking in an extension existing buttons to
>> replace them with intents -- def have some thoughts on that as it
>> relates to site-owner perception/desires.
>
> We are working on the exact presentation to the user of the services, the
> current thinking is based off metrics such as usage of the service - if a
> user always shares via AddThis, then that should be the first choice. This
> whole process is being left the UA.
To the extent those UA discussions could be bubbled up to this list,
that would be great -- this will either work or not work, ultimately,
depending on that.
