Last spring a group (of which I was a member) began to explore the concept of a “bliki”, a piece of software that combined the alleged advantages of a blog with the supposed strengths of a wiki.
We looked at this from several angles: the cultural, and conceptual, as well as the technical. What follows are my personal reflections on this process, and my tentative conclusions. These are based on discussions and exchanges of information with my fellow group members Ralf Appelt, Eeva Melvasalo, and Leslo Wanders, and with Johnny Bistrom and Aki Virmalainen at Arcada. They also draw upon my experiments in customising WikkaWiki, a wiki software, to function as (my current conception of) a bliki.
I have already discussed some aspects of this experiment on this site, including thoughts about the nature of blog posts as well as issues with getting RSS feeds to work, and linking successfully to Technorati – a process that is currently only half-complete.
In the first part of the essay I have deliberately avoided technical discussions about RSS and Technorati tags and so on, because I want to discuss the fundamental question of what a bliki might be, and what it might be used for, in terms of the uses of social software and collective knowledge-building. In the second part, however, when I discuss the functions that I believe will need to be added to WikkaWikiâˆž in order for it to function as the kind of bliki I describe I do talk in more technical terms.
The differences between blogs and wikis
Before discussing the supposed advantages of combining a blog with a wiki we should, perhaps, begin by trying to define what the salient features of blogs and wikis actually are. We need not start this process from scratch because there is already much debate online about this exact subject.
According to one of the contributions to A Wiki or a Blog (a wiki page discussing these differences) blogs and wikis cannot be logically compared at all since they “serve two different purposes: Blogs are diaries and wikis are for collective discussion of different subjects. It’s like choosing between bringing the kids to a theatre performance or to the movies. Each has its own value”
This would suggest that the difference between a blog and a wiki might be merely a matter of style. Diaries, discussions and academic discourse are usually recognisable by their different sentence structures; their formality or lack of formality in terms of grammar and syntax; their use of references; and their differing need to draw conclusions and tie up loose ends.
However, it would take less than fifteen minutes on the web to produce a range of examples that demonstrate that this difference is far too blurred to be useful. There are blogs that read with the grace and style of SMS messages, and there are other blogs that could be written by an online Henry James. There are wikis filled with short, terse notes, and other wikis full of lengthy, carefully referenced essays. There are blogs written in a range of styles by a team of people, and blogs that reflect a single authorial voice, and there are wikis that span exactly the same range of approaches.
The response to this contribution is more helpful for our purposes. “You can compare wikis and blogs, although it is like comparing movies and theatre performances. However, the difference is not between “diaries” (blogs) and “collective discussions” (wikis). There are many blogs that are 1) not diaries and 2) designed to act as “collective discussions” via commenting. Most politician-supported blogs (such as BlogForAmerica) are like this.
The main difference between wikis and blogs is the authoring model. Blogs have a top-down authoring approach, meaning that a relatively small number people have 100% control over the creation and editing of new content, which is then read and commented upon by the masses. Wikis, on the other hand, are read, edited, and managed by the masses, making it a bottom-up authoring approach.”
This answer is coherent and provides a useful starting point for a discussion. The first response, though, might well be: “who says so, and by what authority?” It is very easy to provide counter-examples to show that there are many wikis that do not allow “the masses” 100%, or in some cases any, control over their management. There are blogs that demand that users register, and there are company blogs that are used for documentation and as help files. Wikipediaâˆž, for example, demands registration for some editing purposes, and gives certain people the right to lock pages were the editing of “the masses” is proving contentious.
Another response suggests that “the salient difference is that Blogs are linear by date and wikis are hypertext”, and cites Martin Fowler and his bliki as an example of how the two can be combined. This point echoes Ralf’s persuasive arguments that blogs tend to be ordered primarily by date, and to have the majority of their links pointing outwards to other blogs on the web, while wikis tend to be ordered by category and have the majority of their links pointing inwards to other entries in the same wiki.
Ralf’s phrasing seems to me to be persuasive because he positions the differences as being more a matter of convention than an absolute split. The fact that the majority of links in most blogs tend to point outwards does not preclude me from creating a blog for my own purposes that has exclusively inward pointing links. It would be an unusual blog, perhaps, but still recognisable as a blog, especially if it was primarily ordered by date.
The similarities between blogs and wikis
If one compares blogging and wiki software with, say, a standard word processor then it is readily apparent that blogs and wikis share many features in common.
Both are server based, and almost all of the leading examples in both categories store their data in a structured database. Both allow, and indeed encourage, users to bookmark and link their entries, and both make it possible to share these with others on the web.
Both have the same (albeit differently named) basic unit: the single post or entry that is stored as a separate record in a table in the database. Both store one or more time fields as part of this record, marking the time the record was first created or most recently edited, or both.
As I shall discuss later, blog and wiki software have different characteristic strengths and weaknesses, and effectively suggest different uses. Nonetheless there is no reason that someone could not be able to write a blog successfully using wiki software, and no reason why a wiki could not be created using blog software. (The second option would actually be harder and less obviously attractive, but nonetheless it would still be possible.)
Given the above, it is not surprising that some people have indeed attempted to combine these into “blikis”.
Jason Nocks, foe example, has explained his adoption of a blikiâˆž like this: “Why use a Bliki? Why not just use a Blog? Well, if you really want feedback about a Blog, you might welcome actual changes to that Blog (more of a Wiki-centric view). Also, I might need to use a Bliki because I need to restructure and clarify my ideas over time, rather than just express it clearly the first time. Why not just use a Wiki? Blogging is a little less Wiki-centric. Blogs are typically more single-author mode, with comments at the end, as opposed to anyone can edit any page. Bliki seems like a happy medium.”
This definition could be said to describe a personal knowledge-base: a single point on the web where somebody enters material that they believe they will find useful later. This material might take the form of personal reflections; quotations from books and newspapers; links to interesting material online; saved versions of published essays;favourite recipes; bibliographies of favourite authors; media clips and photographs; downloadable music; and much else. This material is stored on the web because it is intended to be linked to and commented on, and used by other people.
This kind of knowledge-base does indeed combine a blog and a wiki, although not necessarily in a technical sense. It posits a social web in which I collect what is important to me, and you collect what is important to you, and through a process of bookmarking and linking we connect our collections with each other (and with many other people); and thus find and explore more than we would be likely to by means of individual research alone.
If we accept this as a contingent definition of a bliki then questions arise immediately as to what kind of software we need to enact this definition.
Could what I have described by created using only a blog software or a bliki software?
I believe that the answer is yes, but I also think that it would require too much effort to maintain to be useful in most circumstances. In my experiments with WikkaWiki, which I describe later, I have found myself having to do manually many tasks that blogging software would perform automatically. This is useful for me for research purposes but nothing I would wish to inflict on anybody else.
Could what I have described be created by hooking a blog and a wiki together in some way?
Yes, and this has been attempted by different people with different amounts of apparent success. However, I believe that this approach faces a fundamental difficulty, drastically limits the utility of the resulting hybrid: a problem I shall describe as the problem of graceful degradation.
The problem of graceful degradation
Blogs tend to be sorted by date, which enables the reader to follow the author’s adventures in China, to track their train of thought as they grapple with a problem, or to trace the narrative of their love affair. It also enables the reader to see which elements of current affairs the author picks up on and which she does not.
Wikis tend to be sorted by category and posts are thus to be found according to whether they are about “architecture”, or “My adventure in China”, or whatever.
Blogs show hot news (the hotter the news the nearer the top it is) while wikis show cold facts and considered reflection. The problem with this is that “hard news” and “cold facts” do not form the basis of a logical taxonomy. Hot news is always hot news about something, and its topicality is only one fleeting aspect of it. Topicality is never the whole of a post, since even the most banal and trivial gossip cools into (c)old news, something that can later be used as an element in a social history.
If we combine a blog and a wiki at the level of presentation, by incorporating them into the same website, we are almost certainly going to end up using two databases. However similar they look, we will have two sets of entries: some are “blog posts” and some are “wiki entries” and the two can only be linked by external links across the web. The search engine in the blog will not find entries in the wiki and vice versa.
The problem with this is that this is exactly the opposite of what I want, and thus what I think a bliki needs.
I want the blog entries to degrade gracefully into wiki entries. That is to say, I want an article that I wrote today to appear on the front page because it was posted this morning; to remain on the front page for a week or so, catalogued as being about China or architecture; and then to degrade into being an “ordinary” article about China or architecture in the main body of the wiki.
There is a genuine benefit, for example, in being able to copy and paste current quotations, predictions and judgements into a knowledge base, and then have them available later as research material. To do this means being able to find them all, not by date but by subject.
If this arrangement involves a fixed taxonomy of categories (as opposed to an ad hoc system of tags) then the categories should cover all the entries in the database; and they should be related to the topics covered in the entries. This will enable readers to find entries in a logical manner, while also allowing them to surf and navigate intuitively by means of hypertext links within the entries.
To achieve this we need to have a single searchable database, and to do that we need to do much more than link a blog and a wiki under the same url. We need to have a single, database-driven software combining whatever blog-like and wiki-like characteristics we need to form the online knowledge-base.
The tyranny of rich features and default settings
In July I began to build a prototype bliki to test some of these ideas, in the belief that I would learn best through a process of action research. I began by exploring a variety ofblogging and wiki software, including TikiWikiâˆž, which is a wiki that also includes built-in blogging software as well as many other features such as threaded discussion boards, and many services such as RSS feeds.
I ignored these and opted instead to use WikkaWikiâˆž, which is relatively poor in features but coded well, in a clean modular style that can be modified and extended easily. This is made possible by its “primitive” simplicity. It does not have “dashboards” or control panels, which was perfect for my purpose. I was trying to avoid being imprisoned by the tyranny of rich features.
I realised that if I used TikiWiki (which is a popular piece of software I have heard spoken about in the highest terms) I would have to learn how to use it. It has so many features that by the time I had mastered it sufficiently I would have come, in the process of learning, to accept its limitations (all software, however good, has limitations) as natural, and its strengths as necessary features I could not live without. I would not then be researching imaginative design possibilities so much as treading an already walked path.
I realised that this was even truer of the blogging software WordPress. It has so many features, with easy default settings, that it is possible to set up a blog, configure trackback, set up RSS feeds, configure links to Del.icio.us and Technorati without even needing to pause to ask why you would want to do this. After less than ten minutes you can type your first post and sit back, content to know that you are now hooked in and officially part of the blogosphere.
It is my contention, which I will develop further, that it is this subtle tyranny that actually maintains the division between blogs and wikis. Blogs come with built-in links to Technorati and wikis don’t, and so by and large there is a blogosphere and not a wikisphere. This is sociality at the level of software choice, not at the level of content and social intention, although these are the reasons that are usually broadcast and debated. At this level the blogosphere is a consumer association not a conducer alliance.
The possibilities of creating WikkaBliki
If the above is broadly correct, then the aim of creating a bliki is to be able to place a searchable knowledge base online, allowing readers to edit and comment at the owners discretion. This knowledge base should have one database, with one kind of record, organised in two complementary ways. There should be a chronological listing, placing the entries in “blog order”, and there should be the possibility of seeing them by category “wiki style”. In addition there might be an ad hoc tagging system that enables the reader to find articles about topics that span categories.
It might be argued that not every item should necessarily appear when the site was treated like a blog. Instead the author should be given the opportunity when saving an entry to have it placed in the timeline or not.
Having spent three months working with WikkaWikiâˆž, and examining its structure in detail, I do not believe that these steps should pose much difficulty. I believe that it could be extended quite easily without interfering with any of its core functions.
I also believe that it should never, ever be called WikkaBliki, for reasons both trivial and serious. Trivially the name sounds horrible. Seriously, it sounds dangerously like an attempt to fork the code, which would serve no purpose at all that I can imagine. What follows is therefore a description of how I envisage WikkaWiki could be extended without interfering with its present or future development, leaving the bliki aspect as an additional set of features for those who wanted them.
Developing the knowledge-base
Here is a numbered list of the changes that I believe will be necessary to enable WikkaWiki to be used to run the kind of knowledge-base that I have been describing. They may not make sense to anyone who is not familiar with content management systems in general and WikkaWiki in particular, but I am including them for those who are.
1. At the moment WikaWiki collects the date and time of every update made to a page. It does not maintain the original creation time and date of an entry. This must be changed by the addition of a creation field to the page table in the database.
2. A second new field needs to be added: a Boolean named timeline. The page entry action needs to be modified so that the page edit screen displays a check box marked “Add entry to timeline”. The result of this will be stored in the timeline field whenever the page is saved, allowing pages to be moved in and out of the timeline at will.
3. A third new field called synopsis should be created. When the timeline field is checked a small entry field should appear to allow the author to insert a one paragraph synopsis of the entry into the record.
4. A new blog-entries action needs to be written. This should select all the entries with timeline set to “yes”, sort them in reverse chronological order using the creation field, and then display the most recent X entries in the form of date, title, synopsis and link to full entry, where X is a number stored in the config.php file. This action should be used in the same way as the current category action.
When these extensions have been added to WikkaWiki’s current functionality then it should operate as a functional timelined knowledge-base of the kind I have been describing. Core functions will be automated and this will be enough to use it as a workable proof-of-concept. These changes would be sufficient to (at the very least) automate all the tasks I am currently doing manually here, and that alone would make it usable as far as I am concerned.
Many additional improvements could no doubt be made, but these should be developed as separate extensions in the style utilised by the WikkaWiki development team. They should plug into the core functionality and interfere with it as little as possible.
Improvements include writing actions to create automatic Technorati links, RSS feeds that spiders can read easily, trackbacks and so on. These would duplicate the functions available in the leading blog software, such as Blogger and WordPress, and thus enable the knowledge-base to be integrated into the blogosphere. Because services like Technorati use open and well-documented APIs this should not require superhuman effort. It will require understanding what the intended purpose is, how Technorati or Yahoo implement the service, and how calls to this implementation can be incorporated as an action into WikkaWiki.
Later the whole business of creating and using keywords could be automated. WikkaWiki’s category system is fully automated in the standard installation but the complementary keyword system that I introduced is currently manual at every stage, and a complete drag to use as anything other than an experiment.
In this essay I have tried to demonstrate that a so-called bliki has a functional value over and above the benefits provided by owning both a blog and a wiki. I have tried to describe this additional value and to situate it within a wider context. Finally I have sketched out a road-map for implementing these ideas inside a specific wiki software that I find especially suitable for this. (I also find it an especially good wiki software and would recommend it to anyone who wants to set up a wiki that is easy to maintain, and easy to customise.)
I welcome any and all comments, and will attempt to respond to them as much as I possibly can. I will update this essay from time to time as and when my experimentation produces further results.
I have posted another (much shorter) piece about my methodology because, in rereading this essay, I became aware that some of the conclusions might seem self-evident. Being reminded of Jeff Hawkins’ wooden blocks, I decided to explain how I got from there (where nothing was obvious at all) to here (where the shape of the problem, at least, is quite clear).
Of course, everything is obvious with enough hindsight…