Earlier, I spoke about my first experiences with Google Buzz and how I think end-users might run into trouble with the new social networking service. Part of that discussion was talking about the behavior of Twitterand FaceBook, and how it compares to Google Buzz.
Having given this some additional thought, it occurred to me that Social Networking as a paradigm has become overly complex and baroque in its implementation. There are too many services, each with their own native APIs, and end-users are forced into maintaining their own “systems architecture” for managing their Social Networking experience.
Click on the “Read the rest of this entry” link below for more.
I decided to take a look at my own Social Networking imprint/usage pattern and translate it into a “simplified” logical architecture diagram — the one you see at the top of this article. After I created it, I realized how awful and half-baked Social Networking really is in terms of service/site interoperability and protocol.
Let’s trace the logic flow a bit in order to fully comprehend the insanity we’ve all now become accustomed to dealing with.Twitter, it seems, has taken the role of what we would call in the Enterprise computing space a Messaging/Service Bus or a very rudimentary transaction engine. As such, it sucks ass. It has a 140-character limit and it’s frequently unreliable, in that the system doesn’t scale very well.
Any number of conditions on the Internet can cause Twitter to stop functioning for extended periods of time, which gums up the entire works. But it’s become so popular that it’s now being used to distribute “updates” to all of the other Social Networking services.
By virtue of Twitter’s popularity we are now using it as the primary mechanism by which we propagate our presence in Social Networking. But in order to do that, we have to employ other services to “Push” updates to Twitter.
In my particular case, I enter direct updates to Twitter via TweetDeck, a popular multi-platform Adobe Air application for Windows, Mac, and Linux. On my Android-based mobile phone, I use Twidroid to do the same thing. When I was a BlackBerry user I used OpenBeak. There’s also the Twitter website itself, but nobody really uses it anymore, particularly on mobiles, as it’s awkward when compared to the specialized clients.
Suffice it to say there are many such apps for PCs and mobiles and having a central UI where status updates can be sent simplifies things, but it’s a big compromise.
The 140-character limit on Twitter can frequently be very frustrating and by the nature of the way the Twitter “Pull” application in FaceBook works, not all updates get propagated out to FaceBook in a timely fashion. By using a Twitter client as my front-end my updates do not always get formatted the way I would like it to look when my friends on FaceBook eventually read it on my Profile page or in their News Feed.
Some people get around this “Twitter as unified message bus” issue with “Multicast” services like Ping.fm, which was recently purchased by Twitter client software vendor Seesmic. I could also “Multicast” my updates from TweetDeck as it supports both Twitter and FaceBook, but that would make my life even more complicated than it is now, and would not address when I’m doing mobile updates or when Twitter is “Pulling” from my blogs.
As we say in the biz, the middleware sucks. But since everyone else who tries to tie these things together are in more or less the same boat that I am, our level of expectations are pretty low in general.
All of that hassle as I have described above is just to address direct updates entered through some sort of client software. Then there’s the issue of Blog updates, as I mentioned earlier.
You’d think the Twitter service itself would have some mechanism for directly pulling updates from blogs, and pushing directly to FaceBook, but it doesn’t. You have to use a 3rd-party service, at least for the Blogs.
For a while, I used Twitterfeed, but it became so consistently unreliable that I had to use something else. Recently, Google’s FeedBurnerintroduced a “Feed Socialize” feature that includes URL shortening so that blog post titles and links can be inserted into your Twitter input stream, so I started to use that.
Feedburner Feed Socializer been fairly reliable since I started using it almost two months ago, but again, it’s stupid that I actually need a 3rd party piece of web-middleware to do this. Dammit Jim, I don’t want to be a Systems Architect in my spare time.
Now that we’ve tied our “messaging bus” together with all sorts of 3rd-party stuff, which now resembles something the Professor put together on Gilligan’s Island, there is also the issue of what happens when you screw up. You know, you put in a typo or a bad link into your Twitter client. This happens to me at least once a day. Since TweetDeck and Twitter and FaceBook have no end-to-end communication, you effectively have to race to delete the Tweet before it propagates to FaceBook.
That propagation can occur almost instantaneously, within 30 seconds or less. Just because you’ve deleted your Tweet, it could have still have been pulled in by FaceBook, and now you have to log into FaceBook to delete the bad update. FAIL.
If this were a true transactional system, TweetDeck/Twitter would be able to make a Remote Procedure Call (RPC) to FaceBook and remove the message, so you wouldn’t have to do that. Oh now guess what, You’ve got Buzz thrown into the mix as well, and you’ve got the Twitter connector enabled. Now you have to log into Buzz and pull the mis-tweet too. BZZZT!
We’ve just covered the hassles of messaging/update issues across Social Networks. I haven’t even gotten into the fact that each social network has unique user IDs and the people who you follow on one aren’t friended/followed on the other.
Now, as I outlined in my previous post on Buzz, there are clearly situations where you wouldn’t want to follow someone on Buzz who you do on Twitter, or friend someone on FaceBook who you follow on Twitter, or FaceBook friend someone who you LinkedIn with, or vice-versa, but it would be good if these systems were somehow “aware” of each other, that you HAD relationships on these foreign systems and they would enable you replicate them, if desired.
0 comments:
Post a Comment