Actions Use Case

There's been some question on the mailing list regarding the use cases
driving the Actions work.

Let's set some context. When putting the Actions proposal together,
I've drawn on an extensive body of experience with *many* other
similar non-standardized mechanisms, including (but not limited to):

* OpenSocial Gadgets & Embedded Experiences
(http://www.w3.org/Submission/osapi/)
* OEmbed (http://oembed.com/)
* Web Components (http://www.w3.org/TR/components-intro/)
* Social Plugins (e.g. https://developers.facebook.com/docs/plugins/)
* Push Notifications (e.g.
http://developer.xtify.com/display/APIs/API+Reference, iOS Interactive
Notifications, Android Rich Notifications, etc,
https://parse.com/docs/push_guide#top/iOS, ec)
* Schema.org/Actions, Google's Actions in the Inbox, Google Now,
Microsoft's Cortana
* Various widget frameworks, etc
* Many more...

The list can go on. The fundamental point is this: The general notion
of a "Potential Action" plays a very critical role in the notion of
"Social" software. Any particular piece of content, for instance, can
be Shared, Saved, Liked, Starred, Tweeted, Retweeted, Reported,
Approved, Moderated, Commented-On, Referred-To, etc.

The Actions Vocabulary proposal that we've put on the table
(http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-actions.html)
attempts to distill a broad body of experience down to a minimal core
bit of functionality that directly captures the absolutely most common
use cases without introducing dependencies on other existing
non-standardized vocabularies.

The Actions Vocabulary defines four specific types of "Potential
Action Handlers", these include: HTTP Request, Browser View, Embedded
View and Intent. The definition of each is straight forward:

  * HTTP Request --> describes an HTTP request/response flow that is
independent of a browser context... in other words, this describes
REST API calls.

  * Browser View --> describes an HTTP request/response flow tied to a
browser context. In other words, this is opening links in a browser or
submitting an HTML Form with results displays in a Web View

  * Embedded View --> describes embedded content. This can be
something like static HTML, a Web Component, an embedded Video, etc

  * Intent --> describes a reference to a native application... This
is essentially a Deep Link.

Let's explore a few cases.

A. Cards/Actions

A common use case currently seen in real world applications such as
Facebook, Twitter and Gmail is to include embedded metadata in an HTML
page that describes additional semantic characteristics of a page.
Twitter, for instance, has the notion of a "Twitter Card", which the
service uses to display information-rich tweets with embedded content.
Some of these can even be used to allow users to directly interact
with content in-context, without leaving their twitter stream.
Facebook does something similar with OpenGraph, and Google makes
direct use of Actions in their "Gmail Actions-in-the-Inbox" feature.
Unfortunately, each of these are vendor-driven and non-standardized
mechanisms. We can accomplish the same functionality using the
proposed Actions vocabulary. For instance:

<html>
  <body>
    <script type="application/activity+json">
{
  "@type": "urn:example:objects:note",
  "displayName": "A Simple Note",
  "action": {
    "@type": "urn:example:object:ShareAction",
    "confirm": true,
    "using": {
      "@type": "http://activitystrea.ms/2.0/BrowserView",
      "browserContext": "_new",
      "method": "GET",
      "url": "http://example.org/share?id=123"
    }
  }
}
    </script>
    <h2>A Simple Note</h2>
    ...
  </body>
</html>

Because of how the Actions Vocabulary is defined, we can easily use
HTML5 microdata or RDFa to represent the Potential Actions as well.


B. Embedded Experiences

The OpenSocial Embedded Experiences model (which is part of the
original submission that helped launch this working group and is
called out specifically in the WG charter) was originally designed to
allow applications to attach application-specific functionality to
Activities and Email that would allow a user to interact with an
application in-context... that is, without leaving the Inbox. A quick
google search reveals a number of solid references on the use cases
behind Embedded Experiences. I won't go into extensive detail here. A
couple of good references I've found include
https://opensocial.atlassian.net/wiki/display/OSREF/Embedded+Experiences+Tutorial
and http://www.slideshare.net/ryanjbaxter/hands-on-with-opensocial-and-embedded-experiences-9196859.

The downside with the OpenSocial Embedded Experiences approach is that
it directly depends on the OpenSocial Gadget Model, which is a
heavyweight, server-dependent mechanism that requires a complex
rendering lifecycle. While there are quite a few implementations on
the market, and we have quite a few customers making great use of
this, things can be better, and implementation has shown that a less
complicated model would be idea. So we took lessons learned from this
and derived the Actions model... specifically, the EmbeddedView, which
allows us to achieve many of the original goals of Embedded
Experiences in a much more efficient way.

C. Deep Links

Social applications obviously have to consider the Mobile platform. If
we look at the tends around Interactive Notifications on Android and
iOS, Deep Links, Application Indexing, Intelligent Agents such as
Siri, Cortana and Google Now, etc, it becomes quite obvious that
Potential Actions are a Thing. Unfortunately, there are very few
actual standards in this space right now. We have incompatible vendor
specific approaches. The Actions Vocabulary at least takes a step
towards a common, standardized approach. There's a ways to go before
we get there.

The bottom line on all this is that arguments that Actions have never
been implemented and that there is no experience or use cases
documented is completely false. There is a very broad basis upon which
we can draw. Unfortunately, that base is entirely dominated by
incompatible, vendor-specific or poorly documented non-standardized
options. Are there implementations of the Actions Vocabulary we've
proposed? There are a couple in progress, yes, but nothing that's
ready for prime time yet. Is that a problem? No, absolutely not. It
just means we won't be going to Proposed Recommendation any time soon.
That doesn't mean we can't get to work on it.

- James

Received on Tuesday, 21 October 2014 20:11:34 UTC