Blogging Is Missing Something
Maybe I'm old school, but this flowing diatribe isn't what I think of when I think web site.
I do like the ease with which a post can be made. I also like the automatic method by which it keeps recent posts near the top of the page. I realize all of the previous posts are available, but linking to them is less easy than it should be.
I like the way the wiki works, except for the default "anyone can edit content" mode that they all seem to operate on. Some of the ease with which you can create and link pages makes creating content pretty easy.
I've been looking for some combination of the two. I've got plenty of tidbits of useful information that I'd like to see maintained in a planned manner, and then there are these kinds of blatherings that can flow into the ether as time passes. I did like the promise of Mambo, but it ate my Sparc, crashing the MySQL database server. It may be that my recent upgrade fixes that, but I'm tentative to try again.
Mambo didn't integrate blog and wiki entries, at least not that I saw in my few days of playing with it. It did have some nice ability to manage the look and feel in real time, and had some plug-ins for different content "panes" on the sites; for example, there was mention of a Google ad block, but I couldn't find it--I was trying for experiment sake, not necessarily for ad revenue. I tried to get it to read an RSS feed without having to click on a link first, but that didn't work so well, either.
What I'd like to be able to do is create an entry, perhaps as easily as I am now, perhaps even better with a WYSIWYG editor like HTMLArea.
At the time of publishing the article, it'd be nice to be able to flag it so it'd either fade away (blog), or stick (wiki). Grouping the articles, not unlike this blog does, could help with content management.
Within an article, automatically if possible, links should be able to be generated on-the-fly like a wiki does (a wiki tag reserves a link within the site, clicking the link takes you to the new, blank page) as you edit. Even better would be adding the links retroactively like Trillian can do, where recognized keywords on a post get a link to the page handling that keyword. That way, if a detailed page is added after a post is made, no extra work is required to add those links.
Related pages should be easy to find and manage, too. MediaWiki does have a "what links here" tool, but that should be available automatically. If the purpose of hypertext is to give you paths to enlightenment, maybe those paths should be easy to find.
The look and feel of the site should be easy to maintain, too. CSS Zen Garden shows how powerful CSS can be in changing the look of a site without needing to change the content. Layout and position, color and images, fonts and whatnot are all controllable via CSS. A built-in CSS editor would be slick, especially if it had on-the-fly WYSIWYG capabilities, too.
Comments (blog) as well as cooperative editing (wiki) should be allowed, with authorization and anti-spam capabilities. I've spent the better part of three hours over the last two days cleaning spam crap from this blog site, and no one visits and reads my blathers; it's almost all spam attempts.
Wrappers around other functionality should be available, too. I like the idea of having RSS feeds right on the page. Or having a "plug-in" that would let me add Google ads to the site, or put the ICQ on-line indicator on there. On-site chat would be groovy, thinking of that.
Forums, which are a third content like blogs and wiki, with links between posts and flowing history, should be easy to have, too.
Am I biting off too much? Can I make a small, easy to manage, friendly to view and maintain, content management system that behaves like the best parts of a wiki, blog, forum, and static website?
I'll see if I can find some free time and work on it.
[…] no one visits and reads my blathers […]
Excuse me? (Grin)
Actually, I think you might be onto something. I’m not a Web programmer (I do embedded systems development - blame me for the blinking “12:00″ on your VCR) but it seems to me that the major differences among each of the content types (documents?) you mention are the rules regarding creation, editing, displaying, archiving, and deleting them.
For example, a blog entry can only be created and edited by the creator, can be read by anyone, can be replied to by anyone, is archived on a schedule, and is never deleted.
A wiki can be created and edited by trusted users (which could be anyone - depends on how trusting the admin is), viewed by anyone, never archived, and never deleted.
A forum message (and, apparently, blog feedback) can be created by anyone, edited by the creator (or not), viewed by anyone, archived by the admin, and deleted by the admin.
Certain features like Trillian’s auto-linking can be applied automatically on creation and editing (in the case of a wiki or blog) or manually (for more ephemeral items like blog feedback).
With the proper system, tagging any document with the rules by which it is to be handled (and links to parent documents in the case of replies) determines what it is. If, later on, you want to change it to something else (for example, convert a well-written forum post to a wiki entry) all you need to do is change the attached rules. Having pre-defined rule templates (blog template, feedback template, etc.) makes it easier to automate, too.
Wow, I almost make it sound easy, don’t I? I’m sure there are thousands of things I’ve overlooked or am ignorant of. But if you can define what sorts of things apply to any document (i.e. display rules - I suspects where CSS comes in) versus what is unique to each document type, your system halfway designed already.
Dave