Brian Roy’s Blog

JustSignal - Turn down the noise and just get the signal.

Saturday, November 22nd, 2008 | AZ Small Business, AZ Tech, Innovation, cosinity | Comments

On Friday, November 21st cosinity released JustSignal - a combined FriendFeed and Twitter application that allows you to turn down the noise and focus in on just those topics or users you find most interesting.

As much as I love Twitter and FriendFeed, they can become a giant distraction. Too much noise, not enough signal. JustSignal is the solution. It allows you to get your entire home feed from FriendFeed and near real-time “Track” from Twitter - all in one user interface. JustSignal’s filtering solution allows you to only receive the information you care most about - in real-time.

While that alone is a powerful solution for the individual user… JustSignal delivers so much more.

JustSignal Brand Monitor tracks your brand across Twitter and FriendFeed - allowing you to monitor what is said about your brand - and react in real time. Our robust solution queues Tweets, FriendFeed Posts, Comments and Likes that refer to your brand. Anyone in your company can log in and respond to those Social Media brand messages as they happen.

JustSignal Brand Monitor also archives everything said about your company - allowing you to analyze the data and determine what the perception is and how it is trending.

This combination of real-time monitoring and response, and historical data analysis is transformative for your company. Stop sending out surveys and start listening to your customers, prospects and influencers.

You can contact me directly for more information.

Tags: AZ Tech, communications, friendfeed, information discovery, PR, social media, technology, track

Are you looking to hit a 5 run homer?

Tuesday, October 28th, 2008 | AZ Tech, Innovation | Comments

I love a good baseball metaphor. There is nothing better than using the lens of baseball to make a point simple, clear and biting.

So let me tell you what I’ve been thinking today. You can’t hit a 5 run homer - it just can’t be done. Doesn’t matter how smart you are; doesn’t matter how talented you are; doesn’t matter how many twitter friends you’ve got.

I’m an optimist - some would say annoyingly so. I believe the best developers among us can code just about anything we want them to. But that isn’t really the point - is it? The point should be bringing the greatest value to the largest number of people possible.

Often, however, you are faced with a dilemma. Your “power users” want functionality that no one but a power user will ever be able to (or more importantly willing to) use. In short - they want you to hit a 5 run homer.

Why is that a 5 run homer? Because you can’t exert 80% of your effort satisfying 5% of the target market. You can’t convert the masses by catering to the few.

So you make a choice - you swing for the fences, or you shorten up and take the ball back up the middle. But no matter how hard you swing… you aren’t driving in 5 runs with one swing.

Tags: AZ Tech, innovator dillema, technology, useful technology, value and price

XMPP, Track and the Social Media Command Line

Monday, October 27th, 2008 | AZ Tech, Emerging Technology Practice, Experimentation | Comments

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

1. The ability to track keywords (topics) and receive any tweets containing those keywords.
2. The ability to post a new tweet.
3. 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.

1. The ability to track keywords (topics) and receive any tweets containing those keywords.
2. The ability to post a new tweet.
3. 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.

Tags: AZ Tech, friendfeed, information discovery, social media, twitter, useful technology

FriendFeed to XMPP Bridge - Why, how and the plan.

Saturday, October 25th, 2008 | AZ Small Business, AZ Tech, Experimentation | Comments

Yesterday I took about and hour and created a FriendFeed to XMPP bridge. The advantage I had was that I was already running a XMPP server and had a working XMPP bot - these existed for my own personal use as well as for cosinity.

Why?

Primarily this is about information discovery. The ability to participate is challenging (see below) as FriendFeed is an aggregator.

As I said in an earlier post - I believe FriendFeed’s Real-Time functionality is missing two important capabilities.

1. The ability to filter the feed by keyword(s).
2. The ability to get real-time for the public timeline.

While there is nothing I can do about access to the public timeline - I can, via the API, create the ability to filter a feed by keyword(s).

Additionally, XMPP is a clean way to distribute the information - so why not have it published via XMPP?

How?

Since FriendFeed had not released any sample code or a Python/PHP library for real-time yet I had to modify the existing libraries to support real time. This turned out to be trivial - I simply made a new {fetch_RT} function which looks much like the existing {fetch} function. With that complete I could simply use this modified PHP library to grab a user’s real-time stream.

As I mentioned earlier I already had an XMPP server running and had created a bot for other reasons. I simply re-used that bot and the over the network XML API defined by the bot to send the FriendFeed stream out as XMPP messages.

There are several important things to note here about the architecture:

1. De-Coupling the FriendFeed real-time processes from the XMPP bot processes is a very efficient model.
2. Keeping the XMPP stream bot a “dumb pipe” (i.e., outbound message streaming only) is also very efficient.
   1. Clicking on the link at the front of the XMPP message opens the FriendFeed “conversation” in a browser.
3. Since FriendFeed is an aggregator, participation via XMPP will be very problematic.
   1. For Example: If the message is a tweet do you want to reply with a tweet - or comment on the tweet in FriendFeed’s conversation?
   2. The bot would have to track a large number of variables for each message in order to properly distribute your comment/message/etc.
   3. This overhead would directly affect the ability of the service to scale.
4. The scope of the feed (e.g., the apple room or My Home feed or my “the cool people list”) and the keywords for which you’d like an XMPP notification would be configured via a web interface.
   1. This - again - goes directly to keeping the service as scalable as possible.
   2. The down side is you can’t change scope or keywords via XMPP messages.
   3. There is the possibility of creating a separate “ffstreamcontrol” bot which would take these commands. It remains to seen if this is really required or a nice to have.
5. Since the stream bot acts as a dumb pipe - it can rapidly scale by running multiple instances with the same UID and a different resource string. You won’t know (or care) which bot you are connected to - they all look the same. If one dies - the FriendFeed real-time processes will be programed to try the next one… and the next one… etc.
   1. Again - this is a very efficient model.
   2. Will provide high levels of redundancy
6. The bots will all connect to a dedicated XMPP server - the XMPP messages will then be distributed via XMPP federation.
   1. XMPP federation protocols are very efficient.

The Plan:

My current plan is to build something similar to what you see below. The user will create XMPP streams based on scope (i.e., FriendFeed scope - For Example: the Debates 2008 room) and keyword(s). The user will be allowed multiple XMPP streams. All XMPP stream creation, deletion and modification will be done via a web interface.

The XMPP bot(s) will serve as a dumb pipe for content delivery.

Participation is problematic - and as such will be set aside for now. User’s can still participate by clicking on the link in the XMPP message - this link will open the FriendFeed conversation (here is one for example). This will allow the user to participate, subscribe to the user’s involved in the conversation, etc.

Please feel free to comment - let me know if you think this is headed in the right direction.
NOTE: This was written very quickly based on a prototype made yesterday. Please excuse any less than completely thought through concepts… it is a work in progress.

Tags: AZ Tech, communications, friendfeed, information discovery, social media

54 Hours To Build A Company: A Look At Startup Weekend Phoenix

Tuesday, October 21st, 2008 | AZ Small Business, AZ Tech, Emerging Technology Practice | Comments

TechCrunch coverage of Phoenix Startup Weekend… Yeah - I was there working on Reserve Chute!!!

Twitrratr gets a nice bump… nice job guys.

Go Phoenix!

It’s been some time since we last covered Startup Weekend, a series of events that bring a roomful of developers and entrepreneurs together to develop new startups in only 54 hours. When the program originally launched last year, each weekend was geared towards building a single application, of which every participating member was a cofounder. Since then the format has changed - multiple companies are created at each event, and they don’t have to incorporate at the end of the weekend. Here’s a handful of the companies founded at last weekend’s event, which was held in Phoenix.

ReserveChute

With so much of our essential data making its way to the cloud, it’s becoming increasingly difficult to quickly make a local backup. Reserve Chute, an open source web app that will be available for use in the next few weeks, will automatically make backups of popular cloud based services including Gmail, Twitter, and Basecamp.

It’s unlikely that any of these services will be going out of business in the foreseeable future, and they almost certainly have redundant backup systems in place. But the prospect of having my entire photo collection or Email history wiped out is unnerving - having an easy way to back up these services would definitely give users some peace of mind, even if they never had to use it.

My Shelter Helper

My Shelter Helper is web page builder aimed to help animal shelters establish a presence on the web. Shelters can logon and after entering some basic information like their address and telephone number will be presented with a functional and good looking website. It’s a great idea, and I love the tagline: “Helping save animal’s lives.”

For now the service is generating some pretty barebones sites, but will introduce support for donations so that shelters can easily collect from benevolent animal lovers worldwide. I hope the team keeps working on this - anything that helps animals is a good thing, and plenty of people (like my mother, for example) would love to donate to their local animal shelter along with the national organizations.

Twittrratr

Awful domain name aside, the Twittrratr team has actually built a pretty cool Twitter site. After entering any keyword, Twittrratr will find related tweets and attempt to figure out if the subject is being spoke about in a positive or negative light. It’s a good idea but unfortunately it doesn’t work very well - oftentimes words that Twittrratr associates with a negative tweet aren’t being used to describe the keyword that was searched for. The team acknowledges that the system isn’t perfect and is open to suggestions (it’s still pretty impressive for 54 hours from conception to launch).

[From 54 Hours To Build A Company: A Look At Startup Weekend Phoenix]

Tags: AZ Tech, phoenix startup weekend, Reserve Chute