Part of this weekend was spent working on an article on how to use open source technology to build enterprise applications. The article focused on cost-effective way of putting the "enterprise" in your project -- i.e., planning for and implementing the redundancy, scalability, monitoring, etc., that differentiates small projects from projects that are ready for thousands of users.
But as I drove to work today I began wonder if I was going about publishing the article in the right way. As a regular blog post on unto.net the article would be destined for a relatively short life-span. Perhaps a few hundred people would read it. Some would link to it, it might circulate around for a while. Search engines would index it, and depending on the particular phrases, it might surface in keyword-based search results. Ultimately, however, the article would gradually disappear along with every other blog post ever written. Which seems like a shame, as the information contained within could have been updated and improved over time, growing in readership rather than declining.
So I've been thinking about ways to solve that problem, and ways to improve unto.net as a whole. Specifically, I have been wondering about two things: how can I better surface older articles that continue to offer high-value content? And how can I foster a spirit of cooperation and community in improving the content itself?
Take a look at the unto.net homepage. It is pretty simple, containing just a running list of articles, with the most recent at the top. There is a simple navigation menu off to the left containing pointers to archives and categories and links to more information. A simple search box at the top of every page helps people find content if they know what they are looking for. Emperically, roughly 50% of the total visitors on unto.net arrive via search engines. And nearly all traffic to content more than a month old arrives via search -- almost no referrers on old content from other blogs, websites, or internal links. And as far as community goes, readers can comment on articles, and thus add value to unto.net with their insights, but those comments don't surface unless the article is individually viewed.
For the most part, unto.net is very structured. New content is added serially, old content is pushed down. I add new posts via the blog's WordPress administration screens. I do my best to add links between pages, but that's a haphazard and manual process. And in reality, not all content is created equal. For example, I can spend hours writing longer pieces, such as the articles on great engineers or on music store reviews, or only spend 30 seconds adding a quick note about something that just came up. For someone reading unto.net in a blog aggregator this probably works out fine -- the amount of time they spend reading each post roughly corresponds to the effort expended and the value of the content. The problem is that the better older content largely disappears as it is given equal weight with the more ephemeral content.
Search engine link ranking partly mitigates this problem. Better articles are linked to more frequently and surface more frequently in broad web searches. But is it necessarily a good idea to rely exclusively on third parties to dictate how content is accessed? (The whole theory behind OpenSearch and similar technologies is that vertical search can sometimes do a better job at domain-specific indexing and relevance.)
And the second issue is that some content becomes stale over time. Not only do I personally want to go back and fix or improve articles (and sometimes chose not to, simply to avoid tickling the feed aggregators over trivial changes), but other people often write and make suggestions, point out typographical errors, and provide additional information.
When all of this is taken into consideration I am gradually arriving at the conclusion that I really want unto.net to be more of a wiki than a blog. Or rather, I'd like unto.net to be a repository that blends the best of the wiki philosophies with the best features of a blog.
Here's what I am imagining:
Every article currently on unto.net would become its own wiki page. Each page would be addressable via permanent URLs similar to the way the WordPress permalinks work (and similar to the way WikiWords work). The content space would be effectively flat, insofar as each page's location relative to another would be dynamically determined by multiple factors. Structure would be malleable and fluid, changing depending on the particular perspective of the viewer. Factors that influcence structure would include explicit/manual links between pages, category-wide grouping according to per-page tags/labels, temporal grouping according to date/time-stamps, and popularity-biased link-ranking.
The blog-like view of the content would be retained but significantly expanded. Currently, content on unto.net is syndicated via RSS and Atom feeds along a single axis (i.e., by category). In the new model, content would be syndicated according to any number of axes -- tag, date, author, popularity, etc. Using OpenSearch, each axis could be filtered according to keyword or other contraint.
Editorial control over any particular page could be restricted to a subset of users. Certain articles could be limited to a single author (me, in this case). Other articles could be open to editorial changes by friends -- for example, I would happily let Chris, Greg, Eric, or Stephen make all the improvements on unto.net they wanted to. And other articles would be open to the public for editing, Wikipedia-style. (Or along those lines, invidual posts could be read by only certain individuals or groups.)
Ultimately, the hybrid wiki/blog (blwog? bliki?) should be interoperable with other Web 2.0 technologies. For example, links between articles shouldn't be limited to unto.net -- a link to any wiki should be just as easy to build. And authorship shouldn't be limited to just local unto.net users (i.e., me) -- identity protocols such as OpenID (and Orchard) would allow users from around the web to contribute and edit content. Clearly mechanisms would need to be put in place to clarify what is content is internal vs. external (e.g., articles vs. comments in today's world), but the more organic the interoperability the better.
All content should be made available in as many formats as possible. From a rich DHTML-enhanced experience for the modern browser, to standards-compliant XHTML for the thin client, to WAP for the mobile client, to PDF for the printed page. The homepage itself would be more of enhanced portal into the site. Dynamic navigation elements would assist the reader find the content they were interested in, taking particular care to guide the individual that stumbles across the site for the first time. That's not to say the homepage should become cluttered -- on the contrary, the homepage could be even lighter than it is today.
So is this feasible? Without a doubt. And my intuition tells me that the best place to start is with a wiki, not a blog. The blog-like aspects can be added to a wiki easier than the reverse is true. If you took your average wiki -- many of which already support at leats a subset of this functionality -- and added per-article tags, syndication feeds along arbitrary axes, a user model, multiple output/export formats, and dynamic/scriptable elements on a per-page basis, then you would have a personal publishing platform that offered the best of both worlds.
Migrating existing content to the new platform would be tricky. One would need to make a considerable investment in maintaining existing external URLs, as web search engines tend to react poorly to wholesale changes in a site's structure. Each page must be carefully moved into the new system, updating internal links and validating integrity. Comments must be migrated and meta-data preserved. The look and feel would need to be written again, probably from scratch. Third-party tools and plugins would need to be replaced (such as the gallery plugin on unto.net). And those are just the issues that are coming to mind off the top of my head -- the real migration would no doubt reveal dozens of other challenges.
The next step is to identify the best candiate wiki to start tweaking. While one could certainly write a completely new wiki engine, there are so many wiki projects available today that it hardly makes sense not to at least look for something to build off of. Ideally that project would have clean code, a modular structure, and adhere to web and content standards. If anyone has any recommendations, please let me know. I am most familiar with Twiki and MediaWiki, but I know there are hundreds out there already.
Let the blwogging begin.