In my spare time, I sometimes do web designs for friends and NGO’s alike. I finished one such design roughly one month ago. The residual problem with this page is: How to update it? Ideally, the client would be able to do it himself, so I had to look at possible content editing systems.
The following list gives an overview of solutions I could imagine:
From these, most fall short of some kind of feature or user-friendliness:
This was somehow the first idea that I had in mind when thinking of solutions. I tried the Mac Contribute trial and was generally impressed by the functionality. Among the most compelling features I found are
- Template based editing The user can only edit real content. Menus and the like can be tagged as “untouchable”.
- CSS Style enforcement You can define what classes/kinds of elements & styling are available. Word-like CSS styling can be avoided and people will create beautiful pages.
- Images and the like are integrated in the workflow
- Rights controlled
Unfortunately, the design I did (which looks good where it must :)) has some glitches in Opera, and worse, the Editing Window of Contribute completely messes up the layout. Pages on the site can simply not be edited with these two tools.
And of course, it’s quite a bit of a price just for occasionally editing a page or two.
Some CMS monstrosity#
I have a long-term relationship with CMS systems like Typo3 and Drupal and even programmed my own. While there are definitely use-cases for these CMS’, I am reluctant for this particular project. Most obviously, these sytems are just huge. Setting them up requires a great deal of planning and some IA principles applied to them.
Moreover, most of these systems sport only source-code editing and previewing the written code in the browser is just – slow. Nothing you would seriously throw at a client that only has little or no knowledge of HTML. (Of course, I could add some in-line WYSIWYG widget but that’s not without a lot of effort as well.)
The more I think about it, the more WordPress seems the logical choice. Different reasons make me come to that conclusion.
A web-page with only a few pages and a simple menu structure will typically sport some kind of “Microcontent”: A few words here, some paragraphs there. It won’t have complicated stuff like shops or whatever you need (And if it does, never mind, that are exceptions to the rule).
- Hierarchical Menus = Categories
Hierarchical Menus can perfectly be mapped onto Categories in WordPress. You only need to force WordPress to allow only one article per category and/or only one category per article. A piece of cake! A new page merely is created by adding a new category (Why not add an XML-RPC interface for that, btw?)
It’s rather easy to write extensions for WordPress. Just throw a bunch of PHP code into it’s plugin directory and you’re done.
- The XML-RPC interface
Lately, I started very much liking the XML-RPC interface (despite the problems I had) because it is a very elegant way of accessing articles (pages) and media (/images, movies et al). This is especially true with stuff like Ecto and other blogging tools that support the MT API.
- Search is included for free, as can be a sitemap :)
Given these points, WordPress seems to be the logical and most elegant choice for the given problem.
The client’s interface#
Obviously there need to be means for my client to create and edit pages on the site. That is, some client software must be used if I want to overcome the limitations of editing the stuff online (That is, access to instant preview and the like).
Currently, I am aware of two solutions that work on Windows (My client’s platform of choice … ):
Regular readers should know that I am acquainted with the first one – there also exists a Windows Port. The second is a discovery of late: w.bloggar is fast and free. The other two are recent discoveries as well. PowerBlog seems a valid candidate, however Zempt is less feature rich than w.bloggar and is too much MovableType oriented.
I’ll have to do some more research, yes, but an initial assessment shows that w.bloggar is perfect for the task I intend it. Several of it’s drawbacks (with respect to Ecto) turn out to be advantages.
- Category support
w.bloggar only supports one category per post. That’s just perfect, as I can attribute one category per menu. I’ll just have to tweak the XML-RPC such that the client can’t add new articles on his own before the corresponding category has been created. Similar, it must be avoided that the user adds a new article to an already existing category.
- There’s nothing like a point number “2” :)
If there is another candidate I’ll have to consider, then it is PowerBlog. It costs money but is a tad more powerful as well.
- WYSIWYG support
It sports a (DHTML) WYSIWYG editing interface. I think my client could like this!
- No second point as well.
I certainly’ll have to consider some points before deploying this solution to my client. However, I am convinced that a careful layout of the whole WP install and some tweaking will ultimately help me meet that client’s requirements.
Furthermore, I think of ways to implement client-side editing for the CMS monsters as well. It might even be that Typo3 already has a XML-RPC interface … :)