Content
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.
October 10th, 2005 at 8:12 pm
it’s funny that you post this tonight. i’ve been considering moving the individual format of connecting*the*dots to a collaborative format over the next few months. of course, i was thinking “collaborative” from a perspective of muliple bloggers, using comments as the binding threads of updates or discourse, but in actuality, your idea fits the thinking i’ve been running with recently (it *really* takes a while to shake off the controlled, corporate grips!).
if you need any help with this, let me know. i’d love to be the second person running his content off of an unto-developed blwog!
October 10th, 2005 at 8:14 pm
Have you taken a look at http://swik.net ?
I’ve been working on how to reconcile blogs and wikis, and in the SWiK model, a blog is just a wiki page with discrete entries attached
October 10th, 2005 at 8:38 pm
Alex, yes! Something very much like that. There is an inherent openness (in terms of adding and syndicating content) and flexibility in what you’ve done with SWiK. And as you have obviously intended, managing software projects is just one application for this technology.
The idea of template pages is great, btw. I believe that MediaWiki does something like this, but I’m not sure how general it is.
Have you considered using SWiK for your own personal site?
October 10th, 2005 at 8:45 pm
Sean, not sure how I left you out of the list of guest-editors!
These ideas all tie back into the new project. At the end of the day, it is all just data (in this case wiki-like data), users, relationships, and views.
My current plan is to go ahead and code Orchard (the identity server) in my spare time over the next week or two. I’ll make that OpenID compliant, but it will have hooks into a more robust relationship model. I think I’m going to pass on a “groups” model for now — I think I’d have more fun working out some ideas on implicit relationships. Explicit relationships are probably far more useful in the real world, but unto.net isn’t important.
Once the groups are done it should be pretty trivial to whip up a single-user (or several-user) datastore for wiki data. Using an idea like Alex’s for page templates, it should be pretty easy to build a straightforward homepage out of it, while still leaving the door open for the original idea of sticky notes.
That said, if anyone comes along and wants to make suggestions about a starting point, I’m always listening.
October 11th, 2005 at 1:29 am
I’ve been thinking about this for 3 months. I’ve tried using JotSpot which isn’t bad but isn’t nearly ready enough to go prime time. A wiki with blog capability makes an ideal repository for the kinds of things that professional types do all the time. Both internal and external. You’d need a means of classifying users so that internal users would access wiki material as an ongoing work in progress but with the ability to punch out a fresh version if there were major updates.
Now think of all the gazillions of $$ Gartner et al get for flogging stale information. Makes you think doesn’t it?
October 14th, 2005 at 8:17 pm
Nice to see other ephs thinking about this.
Now, filed away in a folder, I occasionally edit my own history of such systems and comments on where to go. Someday, perhaps, it will have value.
Now, my first perspective is that I grew up on USENET. As far as I’m concerned, the political structure of USENET solved many of the collaboration problems above. And USENET is a better solution for many of the things that, for instance, David Kane would like to start over on ephNet. And finally, though I’m piping in here and there, blogging is very unnatural for me because it doesn’t incorporate effective threading of responses, etc., and because it does not encourage long-term development of conversations and knowledge.
My next perspective would be one of my favorite comments from Ted Nelson (who coined ‘hypertext’): “The Internet is what we spent our lives trying to prevent.” For me, as with Howard Rheingold, ‘85 to ‘95 was more-or-less the Golden Age of the Internet; the current Internet is an unstructured cesspool with every error that Ted and his crew predicted (and tried to solve) in the Swarthmore Summer of ‘72.
Finally, as noted above, there are some very interesting and large markets here. As I was going to note in an email to David Kane, companies (and people from the Swarthmore Summer) have been designing collaboration, knowledge sharing and publishing systems for years– and from designing better public platforms and re-forming the InterNet (which I owe to Ted), to building better corporate systems, there are dollars to be made from connecting people to knowledge. Not to mention a new world and century to be made.
To make this entirely reflexive, how do we build a better system to carry on this conversation?
K
November 19th, 2005 at 11:22 am
Cool design..!
Joe