Chris Morrell

This post is a follow-up to my previous post about video platforms.  I didn’t get to check out all of the platforms on my list, but here’s what I did find.  We ended up choosing Ooyala for a number of reasons, which I’ll touch on below.

Continue reading “Video Platform Roundup (follow up)” »

Ajaxian just recently posted a great summary of Clay Shirky’s In Praise of Evolvable Systems.  In it he talks about how all the poor design decisions that went into making the World Wide Web were overcome by its ability to evolve and survive in less-than-ideal scenarios.  Shirky’s theory is that because the Web’s infrastucture is so versitle, and because it’s so easy to implement enough to have something, it was able to develop into what it is today.

At the end of the article, Shirky establishes three rules for evolvable (and thus potentially successful) systems:

1. Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. Think VMS vs. Unix, cc:Mail vs. RFC-822, Token Ring vs. Ethernet.
2. What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
3. Finally, Orgel’s Rule, named for the evolutionary biologist Leslie Orgel — “Evolution is cleverer than you are”. As with the list of the Web’s obvious deficiencies above, it is easy to point out what is wrong with any evolvable system at any point in its life. No one seeing Lotus Notes and the NCSA server side-by-side in 1994 could doubt that Lotus had the superior technology; ditto ActiveX vs. Java or Marimba vs. HTTP. However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.

I’ve been thinking a lot about decentralized/distributed microblogging, and when I read this article it really hit home.  Shirky’s advice rings true for a lot of things, but it particularly resonated with my feelings about decentralizing microblogging.  But before I continue I need to give an example:

Microblogging may be, at its core, a system for distributing 140(ish) character messages to various “followers.”  But there have been a lot of services around microblogging that are definitely part of the same idea, but not quite.  DailyMile is a great example of this.  You’re still essentially sending out short messages to your friends/followers, but those messages have some additional meaning/metadata (such as workout type, time, etc).  BrightKite is another example—you’re still sending out short status messages, but they’ve got a location attached.

The beauty of an open source, decentralized microblogging system is that you could build a system that does the core of microblogging well, and build it in such a way that those of us who also want to send out workout updates can extend the system to include workout metadata, and those of us who want to send out location updates and extend the system to include location metadata.  That is, if the system is built to evolve, it can benefit from Orgel’s Rule.  Anyone who comes up with a clever idea can implement it while tapping intro the existing infrastructure.

This has always been an important element for me, but Shirky’s article really solidified in my mind how important it is.  If a system isn’t easy to implement in some way, it will fail.  And if a system can’t evolve, it will fail.

Right now I have a few pages of notes/thoughts about decentralizing microblogging.  Hopefully I’ll find some time to make them a bit more coherent and post ‘em.  If you’ve got any specific ideas, feel free to get in touch with me or comment below.

Update: it was bugging me, so I went ahead and wrote the greasemonkey script.  It highlights replies in yellow, and the last message you read in green.  Here’s the Userscripts.org page.

I just recently started using Twitter, and so far I like it a lot more than I ever thought I would.  This is a problem, though, because I now use it enough to be very frustrated with its faults.  Obviously their scaling problems are an issue that many, many people have talked about, and there are a number of core changes that might make the service better (location-based tweets, additional tweet “types,” etc).  But I’m not talking about anything so grandiose—these are just two simple changes to the UI that would make me very happy.

1. Show Where I Left Off

Every time I refresh my twitter home page, I have to scroll down and find where I left off.  Wouldn’t it be nice if twitter remembered that for you and added a nice little separator in your timeline?  It’s a very simple interface tweak, but could save you a few seconds each time you check twitter.

2. Highlight Replies

Often, even after I’ve found the last tweet I’ve seen, I don’t have time to read through everything posted since then, so I skim.  Normally I’m looking for conversations that I’m either watching or a part of, or I’m looking for replies to my tweets.  Now conversations/threading is an issue that goes into the “bigger problem” category (an issue that Plurk has solved nicely, by the way), but showing replies should be easy as pie.  If a tweet has @inxilpro in it, just highlight it or use some icon to differentiate it.

Solution: Greasemonkey?

I realize that both of these UI changes could be solved with a little Greasemonkey script.  In fact, I plan on writing such a script when I have a spare moment (hah!).  I also realize that both these problems are solved by a number of Twitter clients out there, so maybe I’ll give Twitterific another chance.