I didn't mean to (even trivially) offend my few readers. Thanks Di for the links...voluntary or otherwise; I do appreciate the other wandering eyes.

This article is based on the comments on the previous article. I started editing this as a comment on that comment, but as the content grew, I figured I should just create a new article.

In that article, I didn't mean to imply that "no one" reads my blog. I know there are a few out there. I meant to comment instead that of the 800-odd "viewers" listed in the blog's stats page, over 700-some were spam attempts. This was mucking up the "recent referrers" list because those entries weren't being filtered by the anti-spam, like the comments are. This meant that the top few referrers shown were links to porn, casinos, medicine, and other unwanted, and unjustified crap. It was worse for Di's site, because she gets very heavy traffic by comparison.

I have altered the hit-logging script and added the same bit of checking that the comment-adding script has. Now each hit is checked for spam keywords in the URL of the referring website, if there is one. This is because evil-doers were making HTTP requests with invalid referring sites to get their sites on this site's recent and most popular referring site lists. This may lead to a few false negatives as otherwise valid referrers might be not counted, if their site includes text not approved by the anti-spam. That statement isn't entirely correct, either--the hit will be counted as an unrecognized referral, it just won't be listed. This'll meet my goal of keeping the unwanted out of the list provided by the site.

A quick aside; I want to thank you, Hinermad, for the blinking 12:00; I find it serves two purposes. First, it lets me know there's been a disruption in power at my house. Second, it lets me know to whom I should downplay my computer savvy lest they try to convince me to help them with their computer problems (that is when I visit a house with a blinking 12:00 on the VCR, I know the owners probably shouldn't know I know how to fix their computers). Note that on my new VCR there's a signal sent by my cable provider that updates the on-screen display (the VCR has a little TV Guide on it) and the time, so I don't get the blinking 12:00 too much any more.

I appreciate the feedback on my blathering idea, too. It helps to know what the experiences of others are, and what expectations might be. I think you touched on some of the foundations of the differences between the articles, strengths and weaknesses alike. It makes me think I might need to undertake the blending of the blog, forum, and wiki.

I think the key element I was looking for was trying to combine the desirable elements of each, with respect to the content generation and management, increasing the features of each, while trying to maintain the desired separation.

Take this post, for example. Since it's in a blog, the main article can only be maintained by me. Technically it can be maintained by anyone the blog software recognizes as a user with the appropriate security level, but on this installation, that's just me. This management does include editing (if I notice something awry after the fact) and deletion. I also have control over the comments posted on my articles.

The comments, however, show a strong possibility for blending into a forum. With this blog software, any comment will be posted as a comment to the article, not a comment on a previous comment. As the comment author, there is no choice. On forums, comment-on-comment threads can be spawned so conversations can take wild turns, and other comments don't have to follow the same bend in thought.

Comment authors also have no access to the other editing tools provided to me as an article author (a little tag helper, spell checker, and such), nor can I return and edit the comment if I notice an error. Some of that is just shortcomings of this particular software, but they're common shortcomings of blogs and not so much of forums.

Additionally, any one who comments on an article won't be notified of additional comments being added to the post, as far as I know, because comments are assumed to be on articles not on comments on articles. Authors are notified of the changes to the posts on which they're participating. To some extent, in most cases, an author can return to their post and correct it.

The chronological entry method of blogs seem to match forums with respect to article creation. Forums, however, have the added ability to order articles based on activity, bringing back the past more easily than this blog software will; someone can post a comment to any article, but they'll need to be searched for. It'd be nice to be able to elevate a recently commented on, but old article somehow.

Now, are these truly weaknesses of a blog and strengths of a forum? This site happens to be centered around me; movies I've seen, commentary on the news, things I've decided to reflect on, and other blatherings I've chosen to create. I enjoy the comments, but I don't want to be faced with dealing with content created by someone else, at least not under my name. Therefore, tacking comments on the end of articles as the only cooperative information sharing works in a blog. If I were one user on a multiple-user blog site, I'd still expect my space to behave this way.

Most forums, however, typically allow anyone to post a "top level" discussion, opening a topic for comment by the other forum participants. This isn't entirely disallowed by the blog, but in the blogsphere, it is generally the case that each user has their own blog. It'd be nice to be able to cross these together so that perhaps the "same" topics on different blogs on the same server could be combined and presented like forum topics are. Either each blog user could create a topic or category with the same name as other users, or pick from a common list...something to bridge that gap would make multi-blog sites forum like. There's a boundary here that needs to be recognized by forum-like sites, and bridged by blog-like sites.

So when thinking blog or forum, I think a blog with forum-like comments would be dandy. I think in a multi-user kind of site, keeping some of the blog tendencies could be handy, too. Keeping the chronological list over the participation-based list could help with maintaining a flow. Allowing authors to maintain control over comments under their articles might be handy. Sure, for some kinds of sites it might make it easier to control the content and make it seem like everyone agrees, but maybe that's OK sometimes.

It seems to me that the differences between the styles are small, and could be configured on a per-article basis. When creating the content, the author could offer it up as a forum topic, cutting off their ability to control the content of the commentary on it. An article could likewise be kept as a personal log entry, with optional commentary, and total control maintained by the author. Whether the comments are threaded or not shouldn't matter on the initial article content, and the editor features and additional niceties like notifying previous participants when changes are made, could be made to both kinds of articles.

The site base could be configured as a personal blog site (single or multi-user), or open as a forum site, however the organization of users might be (e.g., invitation, e-mail confirmation, total trust when one creates an account). This would simply identify the ability to create and maintain articles, without discussing user permissions for overlapping into another author's content for now. Assume a hierarchy of management and trust—anyone deemed an “admin” or “manager” could affect all content, trusted users could affect each other's content (by explicit trust or group trust, for example), and untrusted users could only affect their own content. Even “anonymous” access, like the comments on this blog, could be allowed, not requiring any user management (although something would have to be considered to ensure the correct anonymous user was the only one able to maintain their comments, if allowed).

That's a touch on how I thought blogs and forums could be blended. In a fuzzy view, they're not necessarily too different. The variety of topics and headlining articles can be controlled similarly in each. The order in which they're maintained (entirely by clock or by latest modification), could be handled the same way for each. The handling of commentary and article content management could be controlled, and could be the real distinguishing bit between the two.

Bringing a wiki into the mix, that's a tough animal.

My first thought on wikis is the ease with which articles are connected. The most easy wiki article linking example is to tag some text as a wiki link when creating an article (with MediaWiki, for example, put three single-quotes around a word or phrase). The link doesn't need to exist at the time of article creation, and could, in fact, be changed later if needed. The newly created article is saved when complete, and when the link is selected, the user is taken to either previously existing content, or they're taken to a page wherein they may be offered to create the new content.

It's this simple tagging I was first thinking of; for example, as I create one of my cheesy movie reviews, it'd be nice to be able to throw a simple “find it” tag in there if I needed to refer to another article. With the blog, it may be the case that I've seen a movie with the same actors in it. I can make the links, but I have to find the permanent link, and then insert that—tedious, at the least. If I can refer between articles easily, it'd make my trivial reviews more useful (and maybe prompt me to make them more interesting), as they'd string together better.

The mention of the Trillian client's ability to automatically insert wiki links in chats was to extend this simple tagging that much farther. As articles are added, their content could be scanned to see if they have links to wiki-like keyworded entries. If this is further extended, blog/forum articles and even comments could be similarly linked-to by title or other keywords. This would mean, to follow my movie example from before, that when I added a movie with the same actor, the site may be able to link the articles together, or even create a page to which both articles would like, providing a “tweener” to which future similar articles would link. This “tweener” page would in turn have (optionally) its own content (managed by the blog owner, or one of the trusted users, or in wiki form by anyone) and links to the pages which reference it. Past articles would either have to be re-scanned at the time any article is created (which I think would be daunting for the server), or when the article is next recalled (perhaps re-saving it with the links, with care to ensure an infinite loop of such checking isn't created).

As for the other aspect of the wikis, the one where anyone can alter the article, this can also be controlled, and I think get blended with the blog/forum stuff above. On the most open, there aren't comments, instead later posters simply change the content of the article. There is, on MediaWiki, a “talk” feature where anonymous persons can comment on articles, but I've not played with it enough to see if those are limited to the author's view or if they're added to the site when viewed by anyone else. This has a benefit (when it's worked right) so that the articles are “corrected” or completed by as many “experts” as may be necessary. This is a great workgroup tool, or like the wikipedia project, great for huge knowledge base attempts.

As mentioned, the alteration can be controlled. Like with the blog and forum discussion above, this can be based on trust and the user hierarchy. An author could begin an article, and anyone in their group, trusted by them, or in a maintenance group above them could alter the article. Comments could be added to the wiki idea, allowing for anonymous addition or discussion.

There is change management in the wiki, so a previous version of an article could easily be retrieved and replace a malicious alteration. The various authors who provide edits to an article are accounted for, and this replacement control could also be managed with the aforementioned user hierarchy. This could be opened up some, so that viewers could see the alterations, perhaps stepping through the article's lifespan.

Where a wiki has strengths over blogs and forums is the relative permanence of the articles. While blog and forum articles flow with changes, wikis have controlled starts and integrated links. The content is more easily managed and dynamic, but maintains a closer link to the old-school web content. One site I maintain mostly as an experiment right now, SoftwareByJeff.com, has a main page from which the user can start down different paths. When I add an article, it only affects the main page if I want it to; specifically, I either have to replace the main page, or alter the content on it. Generally, articles are edited to include a link to a new page, then the new page is created from that new link, using the easy method above.

It could be the case that our now blended blog/forum from the above discussion simply has a tag that makes the placement of the article permanent. This could remove the flowing of time and activity on an article, or enhance it, keeping an article handy or in its predetermined place.

This static placement is also a weakness of the wiki. While there are special pages to list the recent entries; it'd be nice to be able to offer a blog- or forum-like view of that automatically. That is, when an article is added or updated, it'd move to the top of a list that might be displayed, if so desired.

This might be handy for adding an RSS feed to a wiki. RSS is a handy way to distribute content in a quick format, with links back to the site. The blogs are trivial to envision in RSS format; the last configured number of articles is published. Forums could be a little less trivial; either the last added articles or the recently updated, or the most active, but still somewhat related to the flow of articles through time. Wikis could benefit from some of the same logic; a set of static (like the main) pages could be referenced in the RSS, as well as enabling recent additions or updates.

Wiki entries can be removed from the wiki. I'm not sure how the public wikis do it; MediaWiki requires the correct access rights to remove an article. Articles are also re-nameable without loosing all of the former references, or completely movable, making the previous references now refer to an empty page, without loosing their content. I imagine this would have to be controlled if multiple users affected an article.

What is missing from all three of these mangement systems is the ability to add some completely dynamic content. I can see the difficulty in making a wide-open web form that populates a database or performs some other server-side function, but these sites all prohibit scripting to be embedded in the pages. Certainly that's for protection against abuse. It isn't a trivial matter to insert script in a page, until you have some experience; then it should be trivial. A key example of this that I'd want is to include headers or articles from an external RSS feed on my site, add a poll, or insert some dynamic HTML to “switchblade” some bits of text, or insert something lame like the Google Adsense bits. There's a lot of power in server-side dynamic stuff, a lot of which is disallowed by these content management systems.

The promise of the Mambo project was that it contained all of these elements. True, it offered the three of them separately. It did this with a menu or pane system. A menu would take you to a page, and a page would have one or more panes made of a particular kind of content. One of the panes may be a blog, one a forum, and one a wiki. Multiple blogs, forums, and wikis could be created. The panes could contain the plug-ins, too. You could make a page with whatever kind of panes you wanted.

The downside, as I mentioned, is that they weren't blended. It'd be sweet if a user could design a “home page” that contained the static content they might want, within the static text would be integrated flows of information, with or without the panel idea. The ability to create the content, establish its place in the site (“static” or as a passing flow), allowing additional commentary or alteration as desired, on a per-article basis, with the benefit of external information, too, would be outstanding.

On the left, for example, a tree-view of the bits of my site that I think are important. Some of those bits are static (e.g., wiki page links), and some are dynamic (e.g., blog/forum page links). In the middle is the current article (content, whatever you want to call it). The pinnacle content would be something with static bits interlaced with different dynamic content. On the right could be a flow of external information, controlled perhaps by the page or just by the site—Google finds the Adsense pages, RSS feeds related to the page are configured with the page, static elements leading off the site added by the author. Across the bottom or top or both are similar bits; site graphics, counters, calendar, whatever.

The whole site could be affected by CSS. If done right, the site's design would technically be separate from any HTML specifics, pushing those off instead to the CSS. There should also be a CSS editor available for the site authors to have access to allow them to create the CSS pages. The bit I think is missing here is that currently all of the aspects of the CSS used in the blog and wiki software are based on files on the system; the content is in the database, why aren't the CSS settings? Sure, the images and fonts and other elements might need to be uploaded somewhere, but by keeping the CSS files on the server in static text, the ability to maintain them is greatly reduced by webserver security.

I'm going to give Mambo another look, now that I've upgraded my database. After I found it on-line I read about it in a couple magazines that end up in my PO box; and both articles exclaimed its virtues. Other open-source management systems were outlined, too, so I might have more places to look before I give up and write my own.