Venture Geek

OK, so the word “stream” is probably not the right one here because it already has a reasonably specific meaning in the technology world — perhaps “channels” is a better metaphor. What I want on YouTube (and its ilk) is a way to create my own “channel” of programming. As I’m watching a particular video they do a decent job of showing “related” videos in the side bar, and after a video they now give you proactive suggestions on where to go next. However, there’s no good way to just line up a bunch of different videos, then sit back and watch them all. As someone who uses a computer as his television, that would go a long way to make true convergence a reality in my world. Ideally, you might even be able to create more than one “channel” and just add videos as you’re browsing around YouTube (or see one out on a blog somewhere) to any of those channels — you can then decide at a later time to just watch that channel. This might be possible just using an RSS feed, but it would be a better business opportunity for YouTube to have me come back to their site to watch my channels.

Remember once upon a time, when people debated the relative merits of and predicted the future prevalence of thin vs. fat clients? I remember when I first used the “fat” client of Federal Express — at the time I thought such clients would become increasingly popular. My thinking was that the complexity of developing web-based applications was increasing (this was years before Jesse gave us “AJAX” as a moniker — though, of course, not years before all the technologies behind AJAX were being used) quickly enough that the cost of building a truly interesting web interface was starting to approach that of “regular” software. At the same time, bandwidth was increasing, so downloading and installing actual software didn’t seem that onerous anymore. Sitting here today I can’t say I was necessarily right, though certainly the iTunes Music Store or any client-based news reader are prime examples of what we would have then called a “fat” client in action.

I recently downloaded Pyro, an application that provides an interface for Campfire (the chat application from the good folks at 37signals). But, Pyro isn’t really what would have been called a “fat” client — sure, sure, it’s a full-blown, separate download that goes into my /Applications folder (for those who don’t use Macs, that’s basically the equivalent of your “c:\Program Files” directory — and please don’t leave comments explaining that I don’t need to be installing my applications in either of those folders), but Pyro is really just a web browser. A web browser specifically tailored to be used for one application only. Now, as something of a web purist myself, this might have offended my sensibilities, but I think it just might be genius. You see, for an application that you use frequently, especially one like chat where you will care that you are notified about incoming messages and such, it’s nice to have a separate item you can “Alt-Tab” to, see bouncing in your Dock (like the Taskbar, for you Windows-only folks), and generally separate visually and conceptually from your normal web browsing (as I said yesterday, I tend to have way too many windows/tabs open in my main browser to have any one of those tabs be useful as an always-on application). The Pyro approach is extremely lightweight, using Apple’s WebKit with a thin wrapper of Campfire specific preferences/features. So, I think of it as a “big-boned” client more than a “fat” client. This is a very different approach than the Widget I use to access another 37signals product, Backpack, where I keep all of my TODO lists. In that case, the Widget is using the Backpack API on a custom web interface (though, of course, the OS X Dashboard Widgets are built using XHTML/CSS/Javascript anyway, so it’s sort of the same concept — not a full-blown custom application).

What I’d love to have is an application that lets me spawn these custom applications — a “meta application” if you will. It would basically let me configure a few things about what kinds of information needs to be stored for authentication, let’s me tweak the UI and choose various menu/toolbar options, and then creates a stand-alone application that would be specialized to a specific web-based application. For someone versed in the ways of Objective-C and XCode, building something like Pyro would be a breeze, but even for someone like me, with some reasonable experience hacking at web scripting and databases, grocking all of that is too high a learning curve to make a productive contribution (and, more importantly, it would likely have lots of bugs that would be time consuming for someone new to the platform to work on) without really getting into it (and my heads-down days of coding, especially in new environments, are pretty much behind me). The geek in me is rolling his eyes at the person who just wrote that line, though…