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.
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:
- Collaboration. The pages of a wiki are web-editable, often by any visitor.
- Easy creation of new pages. Any WordsLikeThis you enter which don't already have page, can have one created readily.
- 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.
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>.
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.
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.
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.
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.
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.
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>.
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
No doubt you'll be hearing more about all this!