Jon Udell: Radio UserLand 8

Tangled in the Threads
Jon Udell, January 21, 2002
Radio UserLand 8

The next turn of the wheel

Radio UserLand 8 is the latest installment in a story that began almost 15 years ago. The plot has taken twists and turns that have left many people (including me, at times) bewildered. Sailing on a tumultuous sea, UserLand's founder, Dave Winer, has had to tack frequently -- towards the GUI then the web, towards the server then the client. Along the way, certain principles have remained constant:

The Frontier scripting engine. Frontier does things differently than Perl or Python, but it can do the same things -- including, notably, client- and server-side web services using SOAP or XML-RPC.

The Frontier framework. Frontier's scripting engine is embedded in a framework which includes an object database and an HTTP server. Frontier's scripting engine is to its surrounding framework as Python is to Zope.

Writing and outlining. Radio's tree-oriented editor has roots even deeper than Frontier's. Its ancestry dates back to Living Videotext's Macintosh outliner/wordprocessor, MORE. Radio developers continue to use this editor to write and edit scripts or HTML, and to manage the database. Radio users can also use it to write and edit HTML documents, though I'll bet most will prefer the MS DHTML edit control that's integrated with the product. In a previous Napster-inspired incarnation of Radio, the editor was featured as a tool for organizing and publishing song lists, and also as a tool for organizing and publishing web directories.

Local HTTP service. Back in 1998, I got really excited about the possibilities of a local web server as a development platform. So did Dave, and he's been experimenting ever since. In this incarnation of Radio, the primary interface for managing content is no longer the GUI-based editor (though it's still available), but instead, a browser-based editor that interacts with Radio's local httpd. Why the shift of emphasis? Radio aims to radically democratize its approach to web writing and publishing. Some people may prefer the GUI outliner/editor, but UserLand has figured out that for most people, a browser interface is the easiest to adopt and use.

Web content management. Radio ($40) is a web CMS (content management system), like its big brother, Manila ($899). The two products approach content management from different perspectives, but share a common ability to process content through templates, and to serve it (directly, in the case of Manila, and indirectly, in the case of Radio) to the web.

Content syndication. Radio, like Manila, is a blogger. But I prefer to talk about content syndication because I think when people from outside the blogging world look in, they tend to get confused. In an earlier column on weblogging as a project management tool, I tried to refine an earlier distinction I had made between blogging as a form of entertainment, and blogging as a business communication tool. Don't get me wrong, if you're blogging for entertainment, that's great. But my own interest comes from a longstanding urge to marry groupware to knowledge management. And for that purpose, this incarnation of Radio is the best UserLand product yet. That said, entertainment and groupware/KM are far from mutually exclusive. Blogging is fun, and it can also be competitive: bloggers, like open source hackers, are motivated by public recognition. Savvy CIOs who can make KM feel like a game may be the ones to finally surmount the high activation threshold that has forever plagued the KM world.

Community. Both Radio and Manila are community-oriented. Here too, they approach the subject from different perspectives. As a Radio user, you join a community. When you run a Manila site, you host a community. For UserLand, I believe, the union of these two worlds -- as yet unclear -- defines a great opportunity to consummate the aforementioned marriage of groupware and knowledge management. At the same time, both Manila and Radio -- being HTTP- and FTP- and XML-RPC- and SOAP-enabled -- can interact with other things. So for example, I've blogged to Manila using Simon Kettle's TextRouter. And while Radio, out of the box, upstreams its HTML renderings to a UserLand community server (which runs Apache, by the way), you can configure it to upstream to your own site as well.

Ease of use. This can mean all sorts of things. For Radio 8, the acid test is: "First successful post within 5 minutes of download." It passes that test. What's more, it makes the following things trivial:

Aggregating and monitoring external RSS feeds.

Selecting items from those feeds, and routing them back out through your own blog.

Making your blog into its own RSS feed.

Categorizing the items in your blog, and expressing those categories not only in the rendered HTML, but also -- crucially -- as independent outbound RSS feeds.

For me, that last point is huge. Doing this kind of thing manually is something that a few geeks, like me, will undertake. But doing it automatically, as Radio does, makes the technique accessible to lots of people. That, I think, is the key to knowledge networking.

Tuning into Radio's big picture

My own Radio blog documents my first few days of fiddling with Radio 8, so you can check there for the blow-by-blow. Here, I want to focus on broader themes and tell the big story. There's so much history behind this product, and there are so many layers to it, that it can be hard to discern the basic storyline. Here are some key plot elements.

Writing for the web

Dave's premise, and mine too, is that the web has been in a state of arrested development since shortly after its birth. It was meant, from the start, to be a two-way collaborative writing environment, not a one-way publisher-to-reader environment. Tim Berners-Lee's ur-browser was, like the W3C's testbed browser Amaya still is, an HTML editor as well as viewer.

I've written elsewhere about the universal canvas. There are many deep issues here that won't be fully resolved for a long time. But things are moving, on several fronts, in the right direction. Part of the answer is consensus around XML as a common data format, and we're getting there. Part of the answer is a ubiquitous replacement for the browser's hopelessly primitive TEXTAREA widget. The Microsoft DHTML edit control, exploited by Radio and other web-writing systems, is a flawed solution in several ways -- IE-only, producing HTML rather than XHTML or XML. But the fact is that for the 90% of users who are running IE browsers, it works well enough -- and (to my taste) better than the Java-based alternatives I've tried. By that I mean: well enough so that, once other pieces of the puzzle fall into place (like content management, syndication, and community), the resulting network effect will, I hope, force the issue and make native XML-capable WYSIWYG editing a first-class capability of all browsers (or whatever replaces what we now call browsers). That said, writing off 10% of the world's web-writing population isn't OK.¹ Interim options could include a Mozilla native solution, a Java-based solution, or (since Radio is a commercial product), an industrial-strength and Netscape-capable implementation of the edit control, such as Ektron's eWebEditPro.

Although I haven't focused here on Radio's built-in outline-oriented editor, I don't discount it either. In the new version of Radio, it's pushed far into the background -- wisely, I think, since it confused many more new users than it delighted. But this is an old technology which has lots of future use left in it, and room for growth. Once we take writing in XML for granted, we'll need and want structure-aware editors. Meanwhile, long-time Frontier users -- and I am admittedly not one -- can do outline-oriented HTML editing today in Radio.

Integration

Like other script-and-template-driven web programming environments, Radio is extensible in a million different ways. Since it does not function primarily as a server, but rather as a client-based tool for writing and website management, it may not be immediately obvious why, never mind how, to extend it. Here's why: because optimization and customization of our writing and communication tools is one of the great challenges of the decade. None of the web's amazing programmability does us a lick of good when it comes to improving how we communicate, since we still communicate mainly in fixed-function email clients that we can't layer interesting applications on top of. Bringing the httpd to the client, and harnessing the web's programmability for client-side apps, was what inspired my dhttp project years ago, and Radio has this same vision.

Now what about the how? One approach is to use Radio's built-in scripting language. For example, a few days after Radio 8 shipped, a Radio version of a Manila-oriented bookmarklet appeared. If you poke through that script, you'll get an excellent idea of how Frontier scripting can interact with the local httpd to improve the experience of writing for the web -- in this case, by jump-starting a blog posting directly from the web page that you want to cite and annotate.

Honestly, though, I'm unlikely to become a serious Frontier hacker. But that's OK. Radio is open at a couple of other levels too. One is the filesystem. Although Radio has an object database at its core, it is also filesystem-driven in useful ways. So for example, the category display in my Radio blog is controlled by a file called /radio/www/#navigatorLinks.xml. When Radio 8 shipped, this file didn't automatically update to reflect newly-added categories. A tool that will do that bit of synchronization could be written in Radio, but needn't be. An external process can as easily notice changes in /radio/www/categories, and synch the #navigatorLinks file accordingly. This kind of openness is really convenient.

The icing on the cake, though, is the SOAP support. It's easy for Radio 8 to to consume, or produce, SOAP services. So a developer who's happiest in Perl, Python, or Ruby can connect into and out of Radio without needing to become a Frontier expert. What matters (as Microsoft, with .NET, also deeply understands) is that you can script integration, not in what language.

Flow

The currency of blogging communities is awareness. It flows within these communities, and increasingly (thanks to RSS channels and cross-posting APIs) it flows across them too. This mode of communication can resemble email, yet differs from email in ways that are important but hard to describe. Nevertheless, I'll try. Email is a message addressed to a person or group, whereas blogging is a message addressed to a space. The relationship of people to spaces is many-to-many, and fluid. Blogging communities wired together with publish/subscribe technology form knowledge networks, and the people joined to those networks are the routers. What happens in a network whose routing function is governed by human intelligence? Lots of people, me included, expect powerful emergent behaviors. But we won't know until the phenomenon reaches critical mass. Getting us there is UserLand's unwavering mission, and with Radio 8 the company has taken another big step forward.

¹ Speaking of that 10% write-off, a longstanding gripe of mine regarding Frontier-generated sites is their table-heavy and thus Netscape-4.x--unfriendly formatting. When Radio 8 debuted, and attracted broader interest than earlier versions had, this issue resurfaced. Dave says he'll fix this, and also make the generated HTML valid and CSS-oriented for the benefit of Mozilla as well as IE. Good!

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/

This work is licensed under a Creative Commons License.