Matt Gemmell

My new book CHANGER is out now!

An action-thriller novel — book 1 in the KESTREL series.

★★★★★ — Amazon

Blog Wiki Blog

general 6 min read

Andrew Chen <a href="http://www.andrewsw.com/news/index.php?p=154">posted a response</a> to 
my previous article on <a href="http://www.scotlandsoftware.com/blog/?post=/meta/we_hates_blogs.html">what I want to see in blogging software</a>.
In his post, entitled "<strong>Blogs and Wikis - Blogs for dynamic content and Wikis for static content</strong>", he said:
I'm trying to address some of the exact same issues as mentioned in the Irate Scotsman's "We hate blogs" "musings". That's why I'm trying to push/evangelize WikiBlogIntegration. By using a wiki for static content and blogs for dynamic content, one gets well defined content.
Be sure to follow that link about wiki-blog integration, particularly some of the "Other implementations/discussions" links on that page. 
It's an interesting alternative to what I discussed before as a solution to the fusing of dynamic-content convenience with the need for 
static content and special-cases.



&nbsp;
Of course, what it sounds like the Irate Scotsman wants to to do is turn Thistle into the (conceptual confusing) result of effectively having every wiki page be a possible weblog - only not having it be a wiki page....
I'm not entirely sure what that means, but I'm going to say: nope!



Let's get some basic principles set down. Firstly, I don't accept the implication that "wiki page" is a good general 
synonym for "static content". I'm talking about a generic chunk of content which isn't contained within any one post (where a post 
is a piece of content with a primary topic and a strongly-associated date, time and - usually - an organisational category).



Now, I'll be the first to admit that I don't know too much about Wikis, (for those in the same boat, here's 
<a href="http://www.wiki.org/wiki.cgi?WhatIsWiki">the definition</a>), but I <em>think</em> 
that the basic principles are:
  1. Collaboration. The pages of a wiki are web-editable, often by any visitor.
  2. Easy creation of new pages. Any WordsLikeThis you enter which don't already have page, can have one created readily.
  3. Easy interlinking. Any text in a certain format (usually WordsLikeThis) gets linked to a page of that name.
I'm sure there are some more subtleties, but hopefully that's the general idea. Wikis are a great thing. They make amassing 
a collection of related content, or some kind of knowledge-base, incredibly straightforward. Because it's easy, it actually gets done - 
there are some great wikis out there (including <a href="http://www.cocoadev.com/">cocoadev.com</a>). Wikis have a definite 
function and purpose, and I'm glad they exist.



&nbsp;



However, wikis are not blogs, and I don't think they're particularly well-suited to be hacked into <em>being</em> blogs (which is the main gist 
of the links from Andrew's <a href="http://www.andrewsw.com/wiki/moin.cgi/WikiBlogIntegration">WikiBlogIntegration</a> page). Sure, they <em>can</em> 
be used as (or made into) blogs, but the question is whether or not it's a valid approach. The problem lies with the basic concept of a blog. 
A (modern) blog is:
  • Ordered (by the chronology of posts)
  • Temporaly aggregated (a page displays the 10 or so most recent posts at any time)
  • Dynamic (the pages change constantly, due to the temporal aggregation)
  • Categorised (most modern blogs strongly rely on the use of various categories for posts)
  • Contemporary (a blog's primary external value lies in its current posts, or current topics)
A blog is a <em>time-stream</em> of information, which inherently understands the concepts of <strong>past</strong>, <strong>present</strong>, 
<strong>updating</strong>, <strong>recency</strong> and <strong>progress</strong>.



&nbsp;



By contrast, Wikis seem to be more about the <em>timeless <strong>accretion</strong></em> of static data. To my mind, a wiki is:
  • Principally unordered (wikis only care in a very secondary way about the most recent edits; recency is not core to the concept of what a wiki is)
  • Logically aggregated (content is within a mass of related material)
  • Primarily static (each individual page mostly contains its own relevant content and nothing else)
  • Not intrinsically categorised (categorisation in wikis seems to be human-enforced; internally, all pages exist at the root level, with no subdivisions or priorities)
  • Timeless (wiki content is long-term; rarely is it associated with a single point in time)
So, if you're looking to combine static with dynamic content, do you start out with a blog or a wiki? 
It's a matter of what you specifically need to do. For example, I need to post my views on current trends in the computer industry. 
I also need to keep a log of my software's development, and invite others to participate in that process. I need to respond to whatever 
sliver of the outer edge of the zeitgeist crosses into my personal interest zone, and to do so in a timely fashion. 
The blog metaphor is the best tool around at the moment to allow me to do that. Using a wiki would be utterly wrong for me.



&nbsp;



Here's the thing: I want <strong>a blog with some static content</strong>. I do <em>not</em> want <strong>static content with some blog posts</strong>. 
Therein lies the key misunderstanding here. I'm already sold on the blogging metaphor and basic architecture. I need chronologies, temporal aggregation, 
and strong categorisation. I very much want flexible syndication, trackbacks and comments. I'm sold on that; I need to extend it a little bit to incorporate 
static content. I don't need to jump to the other side of the blog-wiki spectrum and start again from there.



&nbsp;



Andrew continues:
I know I'm not describing how I see his talk of "Per-category flavor overrides" and "Static includes" as exemplified by "category info" files as being essentially just wiki page content very well.
I don't see how the two are related at all. Let me explain what I mean by both "Per-category flavor overrides" and "static includes":

Per-category flavor overrides

Blogs typically organise their posts into categories, for the benefit of both author and reader. For example, this post is in my 
"<a href="http://www.scotlandsoftware.com/blog/?cat=/meta">meta</a>" category (about blogging itself). A "flavor" (in Blosxom-speak), or 
"template" as it's more commonly known, is a framework page into which formatted blog-posts are inserted for display. Thistle calls these 
"types", but it's all the same thing. For example, this blog has a default type (which you're probably viewing now), an "archive" type (which only shows 
the title, date and category for each post - you can see it by clicking the <a href="http://www.scotlandsoftware.com/blog/?type=archive">Archive</a> 
link in the sidebar), and a "print" type (which shows printable versions of posts - try clicking the "printable" link at the top-right of any post).



Ordinarily, the template currently being used for display is entirely independent of the blog-category you're viewing. You can view any category in 
any template, and there's a globally-set "default" template to use when no other template is explicitly requested. What I want is for a category to 
be able to have it's <em>own</em> preferred (default) template. In other words, I want to be able to say (for example) that when viewing the posts in 
my "dev/thistle" category, the "print" template should be used by default, instead of the regular default template. That's all.

Static includes

Simply put, I also want to be able to automatically include certain static content in a page of blog-posts. I want the content to be external to the templates, 
so it can be effortlessly persistent regardless of the template currently being used to view the posts. Again, that's all.



&nbsp;
But I think that with some "and here's where the blog entries go" notion on a wiki page this is effectively what he wants.
Granted that you <em>could</em> do things that way, but again this side-steps the point that I want my <em>primary metaphor</em> to be <strong>blogging</strong>. 
I need everything that a blog provides, and a little bit more from the world of static content - not the other way around. I don't want 
a different blog on each otherwise-static wiki page. I definitely don't want some nightmare hack that extracts appropriate posts from a blog 
to show in each wiki page.



&nbsp;
I also see "Sticky posts" as just really lazy shortcuts for template editing that confuse what the semantics of a post is. SIPS had something much more along the lines of what I think "Sticky posts" should be via what it called "boxes" - still content that is easily editted, but distinctly not a post - because they aren't intended to be temporally bound - whereas posts correspond to a moment in time.
I didn't really explain properly what I meant by Sticky Posts. It's simply a feature whereby a post can say "ignore my actual post-date or modification date; 
I insist on being listed at the top of the most recent entries". It's <em>not</em> like the "boxes" as found in 
<a href="http://www.geeklog.net/">GeekLog</a> and so on (you've probably seen examples 
of these boxes at <a href="http://www.macosxhints.com/">MacOSXHints</a>; they use them to hold polls and so on).



Sticky Posts are still located in the time-stream; they are merely instructing a template to (perhaps temporarily) bump them to the top of the list 
<strong>for display purposes</strong>.



&nbsp;



If there are any general conclusions to draw from all this, I suppose they might be:
  • We must all beware the Hammer Truism.
  • There's room for multiple intermediate steps between a collection of HTML pages and a CMS-driven website.
  • There are even multiple parallel paths between HTML pages and CMS.
  • Before considering any abstract "ideal architecture", it's important to think first of what you actually want to do.
  • I should probably read more about Wikis.
  • I think I'll add Andrew's blog to my blogroll.
No doubt you'll be hearing more about all this!