It's been a while since wrote anything about how my blog platform was progressing. There has been many small refinements as well as some major new features. The ultimate goal remains to provide a minimalist blogging platform with a minimum of dependencies.

Editing

Initially I was using a basic html editor to prepare content, but after experimenting and in some cases wrestling with Javascript html editors, I finally settled on FCKEditor with some crafty tricks to make it work with the blog like I wanted.

There is a risk that what I am having to do to make it work will be prone to breakages since it depends on the HTTP_REFERRER which may be blocked or faked. Fortunately the way I setup the site should avoid any security risks from this as it isn't even available on the public site.

The editing / management interface is simply a separate site (which may be protected in many ways including IP restrictions, SSL and authentication) which serves up the editor and management tools.

I have basic version control built in so I can roll things back if I mess things up while writing articles.

No comment

Up until now I have avoided adding a comment system as I didn't want to have to deal with spammers or have the slack jawed masses adding annoying comments to my blog.

A friend of mine pointed me to Jeff Atwood's opinion on Blog Comments. I think Jeff makes a good argument for having comments enabled and also discusses why they may not be relevant. I have no doubt that allowing comments increases the popularity of the blog - readers help create content which search engines harvest, plus intelligent people thrive on healthy discussion.

The risk is that unhealthy discussion kicks off and the whole lot degrades into thuggery. While it may still increase search engine traffic, it reduces the value of the blog and discourages healthy discussion.

This is a fundamental problem in social networking sites.

Encouraging healthy discussion

If I am going to implement comments at some stage then I need some basic rules to keep it healthy:

A Captcha

These are the obfiscated blocks of text that are widely used for blocking automated form fillers. Although not completely foolproof, they will discourage automated spamming. ReCAPTCHA provides an easy to use captcha and helps digitise old books in the process so is good all round.

Reveal yourself

Trouble makers are often cowards. If every post has to have a validated email address (not published) then I expect many trouble makers to move on.

The risk here may be that validating the email address becomes too much hassle for everyone and everyone moves on. For now this is simply an experiment and I am doing all the validation I can without involving more user interaction.

Community policing

If a site has reached a point where there are enough hits regular visitors, chances are that the community around that site will be able to collectively moderate comments. I definitely haven't reached that point yet.

This doesn't directly discourage bad behaviour - the posts still make it onto the site. What it does mean is that there is little point in posting something that is going to get taken down quickly. That may not discourage some, but will help.

Another place it helps is to involve the community in removal of bad behaviour and establishing a healthy status quo.

Automatic filters

SPAM filters have become very effective and I am currently experimenting with applying Bayesian inference based filters to similar situations where there are signal to noise ratio problems.

It's likely that filters can be trained to draw my attention to posts that need moderation, but again, this requires a critical mass of training material before the filter will start working properly.

Back to Table Layout

Originally I went all the way and used a pure CSS based page layout. With current CSS this was quite a challenge for this particular page layout, but with enough fiddling with the CSS, I eventually managed it.

The reality is that although the idea sounds good, the fundamental problem is that current CSS isn't much good for laying out pages. The lack of a table-like construct makes it very difficult.

When I started adding new features, I ran into the layout problems once again. It was starting to become a real pain so in the end I decided to scrap the CSS layout and go back to HTML table based layout. This has made things much simpler and I have been able to simplify the CSS loads.

The idea of CSS based layouts is neat: separating the layout and appearance of the page from the content. This means that CSS effectively ends up looking like a complete template for the site. In the case of the blog, the content is separated anyway by the platform - every part of the page is brought in by calling the appropriate method. The main PHP file effectively becomes a template anyway, so CSS layout or not, I already separate the content from the layout and the appearance.

Databases

Right now the blog uses a completely minimalist approach of using a simple file to store each article. Comments make things far more difficult using such simple storage. A full SQL database starts to look much more attractive once comments go on.

I have managed to build the comment system using plain files still, but it isn't elegant. This latest feature creep changes the equation, and I have begun looking at porting the back end over to using a SQL database server  (eg. MySQL) to store the articles and comments.