It’s a fact that the number of Social Networking Services is becoming so high that it is increasingly difficult to manage them appropriately. Of course, there is no need nor obligation to have an account on each of them.
It is also true that we all have preferences and these preferences change with time. Consequently, we can’t find everybody on the same place, be either physical or digital. Here is when we start considering on becoming part of the communities our friends, relatives, colleagues, workmates, or, simply, “interests” belong to.
The questions, then, are quite simple: What if we want to be where our people really is? How we can achieve it in a sustainable way? How can we make “The System” work for ourselves instead of the opposite? Which are our alternatives? Is there any strategy? Fortunately, the answer is yes: “Just Connect them All”.
Basically, there are three main interconnection implementations:
- Client-based: it requires a client with the ability to connect to multiple Social Networks from the same UI.
- Cloud-based: it tries to create an interconnection mesh of Social Network Services that connect directly among them.
- A custom combination of client and cloud-based implementations.
Defining the Goal for our Mashup
First of all we need to have a complete inventory of Social Networks that we want to consider in our Interconnection Strategy.
Once we have our list of Services, we have to decide the role each one will play in our mashup. This may take some time and effort, because we have to analyze each of the available functionalities and decide which one defines the role that it will play for us.
The main goal of our mashup is to spread our content as much as possible. To do so, we will sort out our Social Networks in four categories:
- Content Generators: services that allow us to publish our activity as an RSS/Atom feed.
- Hubs: services where we can aggregate our RSS/Atom feeds and create a new one gathering them all.
- Distributors: services that allow us to take RSS/Atom feeds and re-post them on different Social Networks using their open APIs.
- Target Services: interactive communities where we want to share or publish our content.
The following picture reflects one potential distribution of Services:
This is a good time to identify which Social Networks are private and which roles have on our scheme. This information will be key on future design stages but it is, over all, a substantial element when defining our goal. The golden rules are:
- Define Private Sites as Target Services.
- If a Content Generator happen to be a Private Site be sure to avoid connections to Public Target Services when defining your mashup.
As you might have discovered, our mashup goal can now be described as ”the transition from Content Generators to Target Services”. This goal also defines our high-level topology: The Content Pipeline.
Here, we should be aware of a systemic implementation risk: the Content Endless Loop. Whatever our final implementation is, we need to be sure that we are not creating content loops. This risk is particularly high when we assign more than one role to a Social Network.
In the the previous picture you can see that this is the Twitter’s case as it is, not only defined as a Content Generator, but also as a Hub and a Target Service.
The bottom line it is that the Implementation matters, at least, as much as the Topological Pattern of your mashup.
The Client-based Implementation
Over the last year or so, we’ve seen an explosion of Rich Social Network Clients as the most visual example of what a RIA application looks like. There is a huge competition among the different underlying technologies and this has contributed positively to an expansive movement on this particular market.
You can find multi-network applications like Tweetdeck, Seesmic, Twhirl, HootSuite or Windows Live Messenger. Most of them are, usually, multi-platform. Single Service clients, on the other hand, are far more common on the different mobile platforms. Nevertheless, they also exist on the Desktop: Fishbowl, Telerik f!acedeck and a variety of browser-dependant extensions and applications are just some examples.
The main underlying technologies competing for The RIA Platform Crown are Adobe AIR, Microsoft SilverLight and HTML 5.
JavaFX and XUL used to complete this list not long ago… But, sincerely, I’m not sure if they can be considered mainstream technologies today… Of course, I can be wrong and/or this may change tomorrow… Anyway, we have to remember that this market segment is moving very quickly and we should expect significant changes in just a two year timeframe.
Particularly, I consider Tweetdeck, Seesmic, HootSuite and Windows Live Messenger as the best positioned to implement this strategy. Of course, this is only my current opinion and it is neither a definite list nor a closed one.
From a user perspective, the dos and don’ts of this approach can be resumed as follows:
The Cloud-based Implementation
The “Connect them All” Strategy shows its full potential is when it is completely Cloud-based. Once implemented, your mashup will do everything for you. Let’s see an example:
Unfortunately, there are a number of risks that you must be aware of:
- Unsecure Transport Protocol. Besides security issues, you might experience reliability problems in your mashup if you define your URLs as HTTPS.
- Remote Credential Storage. Some services don’t use OAuth, OpenID or similar technologies. Therefore, you will have to give your credentials away to these services.
- Unmanaged delay. Defining sequential steps on your pipeline comes with the price of latency. Be aware of potential “social side-effects”. For example: you post something at a time you were supposed not to be able to do it…
- Reliability. Things go wrong. Let’s face it. Sometimes a Content Adapter gets stuck on FriendFeed.com, Ping.fm or HootSuite.com and the whole pipeline stops working.
- Lack of Monitoring. Today and to my knowledge, there is no automated way o manage pipeline failures in an automated way.
- Change and Evolution. The Content Pipeline is based on free services that might eventually change, evolve or disappear. So, it is good to have a contingency plan ready and working in order to be prepared for any disruptive event.
- Format Transformations. Each hop in the pipeline can potentially add some transformations to your content. Some of them are desired, but others may be not.
- Complexity. The more services we add to our mesh, the more complex it becomes and higher the risk of creating a Content Endless Loop is.
Conclusion
It is hard to tell what is more convenient: manage isolated Social Networks or make them work together. One has to self-analyze its own situation and needs, try and, finally, decide. If it works for you, it’s fine; definitely.
Either way, we need to be conscious that whatever solution we might happen to implement, it will change. It is also very likely to increase in diversity, complexity and sophistication.
I wish these brief notes on this thrilling subject have helped you in any way. But, what’s more important. What do you think?
Picture: “Facebook Connections” by Michael Coghlan. Licensed under CC-BY-SA-20.
