's brand new social media feedCode Name "SMI"

It is always up to date, looks good on all browsers and devices, loads super fast, displays Facebook and Twitter contents within one stream and is uncritical for even the most sensitive privacy advocate: the new social media feed on

Just like when developing the new aiticon website, our starting point was a chic draft from our London-based designer Gavin Johnson. It showed our blog page as displayed on an average desktop - the teasers linking to the individual articles, however, were not structured in three columns any more, but in two. As a third, rightmost, column, the social media feed was to be seen.

Which technology?

The first question that our developers Verzhiniya Kostadinov (web development) and Claus Stümke (Java) asked themselves was which technology was to be utilized. "There are several layers here that you can build upon", says Java developer Claus Stümke. "Visualizing this kind of feed can be done directly within your browser - with a ready-made plugin distributed by the social network in question.

No plugin

That is easy, but not without its disadvantages. Browser and device compatibility, for instance, is not always perfect - that, though, is non-negotiable for us (mobile friendliness being the operative word). Plus, those plugins are highly questionable from a privacy point of view. Especially older computers and browsers might also have performance issues.

Just one feed

And last but not least, our goal was to display Facebook and Twitter within one and the same feed - for that, obviously, none of the two offers a plugin."

A plugin, consequently, was out of the question for us. The alternative was to natively integrate the feeds into our website. We download our social media channels' contents to our server and process them there, before displaying them on our website.

Key advantages

This procedure has some crucial advantages. Most importantly: We are totally flexible in the way we present our content - so we can optimize for the most frequently used browsers, smartphones and tablets.

Requests to Twitter and Facebook, additionally, only come from our server - and not from our website visitors. Thus, he or she cannot be identified by the social networks - which is the case with the prevalent plugins (German IT news website Heise's "Shariff" solution being the notable exception - it does not, however, offer the exact functionality we wished for).

Privacy, from a user's perspective, is totally isolated from the social networks; even if you as a visitor to the site are logged into Facebook at the same time, there is no chance for the network to "monitor" your visit to us. Your requests will land exclusively on our server, which itself is located in Germany and therefore complies to extremely strict privacy regulations.

Technically, it all looks like this:

Content from the "SMI" application, looks from the Management Server: This is how our social media feed works.
Content from the "SMI" application, looks from the Management Server: This is how our social media feed works.

What the feed looks like is handled through the Management Server, meaning our CMS (Content Management System) OpenText Web Site Management. It publishes a content page, in this case, our blog's overview page (JSP page). On the one hand, it comprises both static content that can be edited through the CMS, like for example our blog articles.

Taglet calls API

At the same time, though, dynamic content is embedded in this page, via a taglet from our application platform appNG. This taglet causes our application "SMI" "Social Media Integration" to be called up via the appNG API.

This application requests the data from Facebook's and Twitter's public programming interfaces (APIs) and converts them into a uniform, internal data structure. For communicating with the social media networks, we use the Java library SpringSocial.

Faster by Caching

The tweets and posts get buffered again in a cache, so that they don't need to be re-loaded on every call to the site - this improves response time and saves server resources. The data thusly loaded and converted are provided in the shape of a representationally neutral XML structure for further processing.

XSL transformation

Upon request to the SMI application, several parameters are transmitted: references to the Twitter and Facebook accounts, as well as, a reference to the XSL transformation stylesheet to be used, among others. That stylesheet is published by the Management Server to the appNG file system, so that it can be used by the SMI application. An XSL transformation stylesheet serves to transform representationally neutral XML data into HTML.

Integrated competencies

So the site's looks are exclusively taken care of by the Management Server, even if the dynamically created HTML originates from within the SMI application.This is how strongly web and software development competencies are interrelated with aiticon: Verzhiniya Kostadinov is responsible for CMS integration of the appNG taglet as well as the XSLT style sheet; Claus Stümke takes care of generating and processing the feed data, the actual "SMI" application.

Looks from the content page

"With this architecture, we manage to integrate dynamically created HTML into our site. HTML, whose "look and feel", still, is 100 per cent determined by our content page", says software developer Claus Stümke.

Obviously, our social media integration, too, had to be authorized - just like any other application accessing the social networks' API. That's not too complicated and also well described in Facebook's and Twitter's developer documentation.

Pitfall: linking posts

What turned out to be an, if not too big, but completely surprising cause for headache was actually linking individual posts. As a matter of fact, we wanted the user to be taken to the respective post or tweet within the respective social network by simply clicking on that post in our feed. That was to enable sharing, liking and retweeting via one's own social profile.

No link from the API

"The interface itself does not return direct links to tweets or posts", says Verzhiniya Kostadinov. She solved this problem with XSLT: the transformation language generates the correct URL from the post or tweet ID, according to a certain pattern. That way, the user finally ends up in the right spot and can "retweet" away.

Changes with the interface

There is but one minor risk, though: Facebook especially is known for its inclination to change its programming practice without much ado from time to time. "We should write a monitoring job to measure whether our implementation is still working with the API", Claus Stümke considers.

We think, this deserves a "Like" as well as a "Retweet".

This code snippet shows the generic data structure as provided by the appNG application:

        aiticon GmbH
        #Hibernate, #MySQL ...
        Fri Dec 11 17:04:34 CET 2015

        Compatibility issues ....
        Fri Dec 11 17:03:26 CET 2015
The field named "text" in this example piece of code contains the Tweet or post (we abbreviated a little for clarity's sake).

Are you interested? Please get in touch!