Re: Actions Use Case

Thanks James, very helpful background!

Do you have some notes from your analysis of all those technologies
mentioned?

I also wonder if you plan to republish information from previous Action
Handlers draft? IMO just the vocab doesn't really explain it all that well.

preview of this previous draft:
http://elf-pavlik.wwelves.org/w3c-socialwg-activitystreams/activitystreams2-actions.html

On 10/21/2014 10:10 PM, James M Snell wrote:
> 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 Wednesday, 22 October 2014 03:27:47 UTC