Developing Social Rendering Lists

I started to pull together a static post about modifying a Social Rendering list, but the post was becoming unruly. With a special thank you to Matt Dull who graciously acted as my editor, we proudly present a video instead.

Be kind... this is my first video endeavor on my Mac.

Dressing Up Connections - Social Rendering

I recently worked on a project where we had to service two different user types with one deployment of Connections.  The customer had extensive UI and feature changes for the smaller of the two groups of users.  To achieve this goal, I decided to solve their particular challenge with Social Rendering and API portlets to develop the extranet UX and enable the internal users to use Connections virtually out-of-the-box.

Social Rendering is a feature of Portal / WCM released with the 8.0.0.1 update.  It enables developers and integrators to surface lists of Connections content using WCM conventions (presentation template, authoring template, PZN & HTML components, piece of content, and a web content portlet) and then quickly or easily modify the UI to match the Portal design.  This is a significant enhancement to the traditional pattern of developing API portlets to do this very task because the API query is built for you in the piece of content that represents your list.  It also separates the design from the logic so that when making edits or changes to the HTML components for UI changes, there is no risk of ruining the business logic behind the list.

*NOTE* As of the time of this writing, the default behavior of Social Rendering is not real time.  It operates on a delay of ~15 minutes do to the architecture.  Workarounds may be employed, but to do so there may be harmful side effects.  Tuning and optimization of Social Rendering is not going to be covered in this post.

The first step for our team, however, was to get our arms around Social Rending.  How does it work?  What are the pieces and parts we need?  Which component in WCM do I use to control which aspect of this solution?  These answers were critical to our success and once we realized how these pieces all fit together, the flexibility that it truly affords, the possibilities became numerous quite quickly.  As is often the case, I wanted to capture these important points of information somewhere and my blog is the place for such things so I can refer back later and maybe even a few others will learn from my struggles as well.

Once you install Portal 8.0.0.1 and make sure the 8.0.0.1 features are all enabled, a series of portlets will now be available to be added to your Portal pages.  These portlets are all lists of something, such as the "List of Blogs" portlet.  These are all special instances of a web content portlet preconfigured to also setup a piece of content that represents a search against Connections.  Staying with the List of Blogs example, this particular list should display all of the blog posts that the current user has access to.  It is the equivalent of searching for everything and then changing the scope to Blogs in Connections.

This leads me to the next important point, which is Social Rendering makes use of the Connections Search API to find the content it displays.  It truly is a search operation, the results of which are what is displayed in the portlet.

Now that we know how we obtain the data, the second half of the equation is what is responsible for rendering the list.  This is a bit more complex of an answer.  In the WCM Library Explorer you should be able to find the IBM Connections library.  This is the library that is setup when Social Rendering is enabled that includes the components which are responsible for the design of the Social Rendering lists.  There are the expected authoring and presentation templates, but these are very generic and point to secondary components with reference another level of component.  I have found ti generally safe to use these same components for most lists.  The magic really happens when the content is run through the PZN engine and the PZN component applied.  The PZN component functions like a standard WCM navigator in that it has a header, body, and footer design block.  These blogs call HTML components which contain the markup that is applied to the search results.  This would be the injection point for customization as you can have the component reference a custom PZN component that links to custom HTML components.

In short, Social Rendering is a search result from Connections that is then handed to the PZN engine where UI elements are applied to the list of results.  The search type / criteria can be manipulated in the piece of content and the UI controlled with the PZN and associated HTML components.  These are then displayed with the standard web content portlets that are used for all WCM content on a Portal page.

The out-of-the-box lists all make use of the OneUI standard and are responsive UI friendly to fit into the Portal default UI.  Your cusotmizations may change this or not require the OneUI standard, but it is good to note this fact.

Hopefully this is more helpful than confusing to those looking in from the outside.  For some specific information about social rendering, refer to the Portal Wiki.

As an additional tip, one should also note that there are synergies between the Social Rendering lists and the IBM Connections Portlets for WebSphere Portal from IBM Greenhouse.  I intended to cover that in a bit more detail in a subsequent post.  Just be sure to grab the correct version of the portlets as the older versions do not have the same support for Social Rendering.