Spec comments from a tools implementor
Will Meyer
Some spec feedback based on efforts building service proxies and
examples, and mapping through some production cases. Excited about
all the potential and wondering if we can smooth out a few cases.
1) Awareness of the service via events
Sites want to know what happens to their content, and they could do so
with well-defined events indicating which intents were executed on
which providers. The abstraction goal is good, but all major existing
in-page sharing implementations include analytics and I don't think
sites will give that up. FB/Twitter/GOOG are all moving aggressively
on providing rich analytics for their own tools, for example. Is
there a way to meet both goals? Could the UA allow the user to decide
whether the fact that they use a given intent provider is known to
apps or not?
2) Simple action negotiation
The simpler the verb set can be, the better. If its too specific and
tied to something too semantically structured, you lose the "any
website will let you interact with any service you know and love"
value prop. Either you end up with too many things on the page --
activity initiations for each of e.g.
save/bookmark/share/post/favorite since page devs just want to cover
their bases -- or you end up with pages having to be updated when new
services are released that support some variation of the original
activity known by the page at design time. If I'm a video site, for
example, am I supposed to allow my users to initiate activities for
almost all supported activities in the spec, and each one the user
chooses gives them a subset of the services they care about? Just
seems really clunky in practice.
Multiple actions being supported in intents might work, or else just
much simpler actions (even something more like http verbs seems more
sustainable).
3) UX influence for the service
Services need to be able to do things like tailor their prompt vs what
they are called. Wouldn't StumbleUpon want both StumbleUpon the
service name, and Stumble This the prompt to be surfaced to the user?
How would facebook's Like button work, where they would want the thumb
and the like text to show up in the picker, not just the Facebook logo
and "Facebook" (which they also want)?
4) Simple content negotiation and default typing
The discussion on verbs can also be applied to the types. As a page
dev I really would like to be able to provide multiple types, because
frankly I don't know exactly what every possible service on the web
will be capable of handling, and I'd rather not invoke 10 different
activities to make sure they are all covered. Services will always be
enhancing their support, and at some point a service that might
initially only accept urls for bookmarking might decide to start
allowing images to be saved in a special album treatment. When that
happens, the page and the user's preferences shouldn't have to change.
Making sure that every service can take a uri, and giving that uri
some logical meaning per verb, would be one way to go after the widest
possible interoperability at the expense of some power (this is what
we did with OExchange). I'd rather see occasional failure cases once
the service is invoked than have lesser options for the user on any
given activity, or have too many activities starting from the page.
5) More well-defined returns/responses
I might be missing a part of the spec but I don't see that the result
the service posts is defined concretely, nor that there are other
callbacks for known error or exception cases. A fire-and-forget model
works, or a model with a specific rich state and data set, I'm a bit
confused as to whether WI is in the middle at this point.
W