Skip to Content

A new release of StreamWork came out last weekend. If you look at the press release, you’ll see that the main focus was the integration of GoogleDocs and the new “People-related” functionality.

A Twitter message, however, alerted me that an even bigger change had occured – support for OpenSocial was now available via a new StreamWork API

This change means that it is much easier to embed external content in StreamWork. In addition, this embedding of external content is based on a standard. There are an amazing number of existing OpenSocial Gadgets that can now be emdedded in StreamWork activitities.

Why is the new functionality important? Let’s say that you are working on a decision in StreamWork that concerns the acquisition of a new company. With the ability to embed OpenSocial Gadgets, you can now add such content as an RSS feed of currents news about the acquisition target, a stock market ticket measuring the share price of that company, its twitter feed, etc. All in the one activity.  This additional information should allow you to make a better decision. Furthermore, you could save this activity with its OpenSocial gadgets as a template so that future acquisition decisions could be set up more quickly.

Although I haven’t tried yet, I’m assuming that StreamWork organizations can restrict access to certain gadgets to prevent users from adding potentially harmful or non-work related gadgets

As my video demonstrates there are a variety of consumer-oriented OpenSocial Gadgets already available.  There are fewer OpenSocial Gadgets that focus more on the enterprise.  Imagine, however, what will happen when you can create a OpenSocial Gadget in River that you can drop in StreamWork or BusinessByDesign (by the way, I have no idea if ByD has this functionality on its Road-map but it is definitely an important feature). Rapid integration across both Core and Edge OnDemand applications. Now that would be cool.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Robert Horne
    My biggest mistake,was not supporting OpenSocial earlier. Their are lots of OpenSocial gadgets that are pretty useless. This is the feedback we got when we first investigated OpenSocial. But when you look past some of the funny apps, you find a nice standard framework for building applications that cross multiple boundaries. OpenSocial has the backing of a number of enterprise vendors. We’ve still got some work to do, to provide deeper support for all the APIs, but its a great v1.
    1. Richard Hirsch Post author
      I agree completely. Some of the existing OpenSocial Gadgets are worthless and don’t belong in SW. Having the ability to easily embed external content, however, is IMHO critical for SW acceptance.

      You guys are doing a great job supporting OpenSocial – good to hear as well that you are using Apache Shindig as well. Most of Google Gadgets don’t even exploit the full potential of the OpenSocial APIs. I can’t wait to see (and perhaps develop on my own) gadgets that use the full potential of the “people-related” OpenSocial APIs.

      It might be useful to have a list somewhere of more “enterprisey” Gadgets that the SW team has found.


  2. Former Member
    Hi Dick,

    Thanks for bringing this to more peoples attention – I share your excitement about the possibilites for opensocial in Streamwork.

    As you already found out (from Juergen Schmerder – via twitter) we are already have some Streamwork methods built in River. We will move them to OpenSocial now as soon as we can – it should not be a major problem.

    I think the combination of Streamwork and a PaaS (River) can be really powerful for edge applications. With the support of the River and Streamwork teams, we (Technology Strategy CoInnovation team) are exploring design patterns and best practices for doing this, and no doubt will be blogging on this in the near future.

    We will keep you posted.


    1. Richard Hirsch Post author

      Sounds great.

      StreamWork + River via OpenSocial will be great but even more important will be the combination of SW + River + AppX (be it another SaaS app or an On-Premise application).

      Once we get the technology working, the next step will be to describe when to use this functionality.  I’m pleased to hear that the Technology Strategy CoInnovation team is creating best practices and can’t wait to see the related content.


Leave a Reply