Last Friday I created a FriendFeed Real-Time bridge to XMPP. Over the weekend I’ve had several people receiving their home feed in real time over XMPP (GTalk to be specific). I also wrote a post about what I had done and what I intend to do with this going forward.
One thing I heard from the initial testers was the desire to “make it work like Track”. Consequently – I’ve spent quite a few mental cycles this weekend thinking about Track (as deployed by Twitter) and how that might work for FriendFeed Streams.
There are three basic components of Track
- The ability to track keywords (topics) and receive any tweets containing those keywords.
- The ability to post a new tweet.
- All interaction happens via IM (XMPP to be specific).
As I thought about these three basic components – and how they might be implemented for FriendFeed Streams I quickly realized that Twitter and FriendFeed are very different – and those differences have a huge impact on “Track” for FriendFeed Streams.
Let’s first consider the nature of Twitter.
Twitter is a stream of stateless tweets. Each tweet is an independent entity – bearing no relation to any other tweet in the timeline. Tweets only have relationships to the user that sent the tweet and, optionally, the user the tweet was directed at – via a @ reply. However, even those @ replies are simply stateless tweets – existing as an independent entity in the timeline.
It is that fundamental nature of Twitter that makes Track interesting – and to a certain extent possible. Since all tweets exist as stateless peer entities in a universal timeline – Twitter essentially creates a stateless stream of tweets. Track works by scanning and filtering this stream and injecting tweets into this stream.
Now let’s consider the nature of FriendFeed.
FriendFeed is a social media aggregator. It contains posts created organically (via the create post button in the FriendFeed interface) or via any number of aggregation channels (blogs, RSS Feeds, Twitter, Disqus, Flickr, etc). Each of these posts exist as state-full peer entities on the timeline.
FriendFeed posts are state-full because they exist as containers. They contain a separate groups of entities – Likes and Comments. Likes and Comments change change the state of the Post – and by doing so change the posts place in the timeline. For Example – If I comment on a 4 day old post it will move to the top of the timeline.
The Post as a container creates a conversation. This concept – the conversation – is totally foreign to Twitter.
FriendFeed, then, creates a state-full stream of conversations. Conversations appear in the stream one or more times – each time they are created or added to via a Like or Comment.
Now that we understand how Twitter and FriendFeed are similar and differ we can re-visit Track.
- The ability to track keywords (topics) and receive any tweets containing those keywords.
- The ability to post a new tweet.
- All interaction happens via IM (XMPP to be specific).
What is clear is that component #1 above is still viable and makes sense. It was the fundamental reason I chose to build FFStream. It still solves the problem of information discovery.
What poses a significant challenge is #2. I refer to this as the problem of participation. This is due to the state-fullness of the FriendFeed Post (or conversation). Where FriendFeed is concerned participation is a relative exercise – you can post a new conversation OR you can participate in an existing conversation. It is the relative nature of participation (relative to an existing conversation) that makes participation via IM so problematic.
This schism is completely analogous to the schism between the command line and the graphical user interface. As a matter of fact, an IM/XMPP interface for Social Media streams is simply a Social Media Command Line. You enter commands – often obscure, opaque and archaic commands – and thereby control the behavior of the application. And this model works… until the interaction model becomes so complex that a command line interface becomes impractical.
When the goal is to filter a stateless stream of data (ala grep) and insert data into that stateless stream – a command line works. However, when the stream becomes state-full – and contains entity relationships (i.e., conversations) filtering the stream is sensible – but the complexity of the required command line interface to inject data into the right entity in the stream makes the proposition a fools errand.
In short – FFStream is an ideal information discovery mechanism – far more powerful than Track because the stream is an aggregation of content and because the stream is a stream of conversations. It is not, however, a usable interface (i.e., command line) for participation in Social Media.
So the goal of FFStream will be to enable information discovery and encourage participation by providing a reference to the conversation. That reference will open a browser window with an appropriate interface (i.e., graphical user interface) for the participation in the conversation.
I know some will find this (to put it mildly) lacking. I know some will declare that I don’t get it. But there is a reason people vastly prefer the ease of use provided by a graphical user interface over the command line. If you are one of those who believe I’ve missed the point – please consider the command line vs. graphical user interface schism and how it relates to this conversation before declaring my ignorance.
Brian Roy 
Brian, I am not a developer but seem to respond to the command line-like experience of the Twitter/identi.ca on IM. Dents and Tweets, even in a track situation are a stream, water flowing by. Friendfeed is buckets full of water being dropped on you as they have water added. I'm not sure once you pour all the buckets into the IM client if the experience is manageable, especially going upstream… hard to put it back in the bucket. I've ended up using 3 windows for a time to catch all I can and respond, through various bridges and workarounds. For the upcoming generation who has always existed in the IM/SMS world, this is the logical way to the ocean. This will be the way that information will move around. Can we build on these diverse platforms that didn't anticipate this usage? Not sure, but I hope so. Thank you for the brain power you are putting into this and I hope it doesn't give you too much of a headache.
LikeLike
Headache – nah… this stuff is fun! I think you are right BTW regarding the FF stream. When I think of the command line I cringe when I realize someone will need to type in “comment 7465866484 you are wrong” in order to put water in the bucket (as you put it). First they have to catch the ID (that long number) in the stream… then use it to respond. On the tech side we have to maintain a reference to each FF conversation so we can comment (or Like) back.I fundamentally question the usability of that solution – especially when one considers the “conversation” is a click away via the URL in the IM.Thanks for the input!
LikeLike
Brian, I am not a developer but seem to respond to the command line-like experience of the Twitter/identi.ca on IM. Dents and Tweets, even in a track situation are a stream, water flowing by. Friendfeed is buckets full of water being dropped on you as they have water added. I'm not sure once you pour all the buckets into the IM client if the experience is manageable, especially going upstream… hard to put it back in the bucket. I've ended up using 3 windows for a time to catch all I can and respond, through various bridges and workarounds. For the upcoming generation who has always existed in the IM/SMS world, this is the logical way to the ocean. This will be the way that information will move around. Can we build on these diverse platforms that didn't anticipate this usage? Not sure, but I hope so. Thank you for the brain power you are putting into this and I hope it doesn't give you too much of a headache.
LikeLike
Headache – nah… this stuff is fun! I think you are right BTW regarding the FF stream. When I think of the command line I cringe when I realize someone will need to type in “comment 7465866484 you are wrong” in order to put water in the bucket (as you put it). First they have to catch the ID (that long number) in the stream… then use it to respond. On the tech side we have to maintain a reference to each FF conversation so we can comment (or Like) back.I fundamentally question the usability of that solution – especially when one considers the “conversation” is a click away via the URL in the IM.Thanks for the input!
LikeLike
Brian,You've hit the nail on the head especially the stateless bit of twitter and the conversation as a foreign concept. We've got lots of requests to add “Track” & “ability to reply to a conversation” via IM for kwippy ourselves. While Track makes a lot of sense for the purpose of information discovery but jumping into the conversation isn't particularly an easy problem to solve because of the usability issues(like providing the object/conversation id etc) also another critical issue here is that of maintaining the context, for ex: consider I get a post in my IM and I notice/reply to it after some time. Now if there has been some conversation going on, on that post already, my late reply according to the post might seem stupid/out of context. Hope I made sense š
LikeLike
Brian,You've hit the nail on the head especially the stateless bit of twitter and the conversation as a foreign concept. We've got lots of requests to add “Track” & “ability to reply to a conversation” via IM for kwippy ourselves. While Track makes a lot of sense for the purpose of information discovery but jumping into the conversation isn't particularly an easy problem to solve because of the usability issues(like providing the object/conversation id etc) also another critical issue here is that of maintaining the context, for ex: consider I get a post in my IM and I notice/reply to it after some time. Now if there has been some conversation going on, on that post already, my late reply according to the post might seem stupid/out of context. Hope I made sense š
LikeLike
Brian,You've hit the nail on the head especially the stateless bit of twitter and the conversation as a foreign concept. We've got lots of requests to add “Track” & “ability to reply to a conversation” via IM for kwippy ourselves. While Track makes a lot of sense for the purpose of information discovery but jumping into the conversation isn't particularly an easy problem to solve because of the usability issues(like providing the object/conversation id etc) also another critical issue here is that of maintaining the context, for ex: consider I get a post in my IM and I notice/reply to it after some time. Now if there has been some conversation going on, on that post already, my late reply according to the post might seem stupid/out of context. Hope I made sense š
LikeLike