Content Management and the irritation of interface compromise
Published by on April 4th, 2006
The problem with most low to mid range content management systems (CMS) is that in striving for ease of template creation, they force frustrating compromises in information organisation structures and most importantly for business websites, look and feel. So often one can immediately tell the CMS used on a site merely by looking at it’s visual layout.
So my aim when creating a CMS for a client last year was to find a system which not only made it relatively straightforward to manage the site structure and content, but also to provide an almost no-compromise approach to site design and layout. The result was a multi-site capable content management system with a modular plug-in approach to capability and providing the template layout does not have any tricky cross-platform CSS, about a day to set up a site from scratch (sans content, of course). It works well but like everything in tech-land could always be improved.
What I learned from the design and build process is being implemented into my own CMS, which finally has a name: Aquarium.
Utilising the Code Igniter framework (just turned V1.3), AquariumCMS is designed to further reduce the need to compromise a site’s visual layout, though at a small cost in added complexity at the template creation end - a necessary evil. Sadly, a desire for truly open and free content placement within a site template is tempered by the technical demands of creating cross-browser/platform standards compliant XHTML/CSS. The hacks, tricks and fiddles needed to ensure everything works mean sometimes oddly structured CSS code - can you say “clear floats“?
The template layout principle looks something like this (left). Each page contains a standard header and footer - which in their basic form can consist merely of the opening and closing HTML, HEAD and BODY tags, but can also include hooks to call CMS generated interface elements such as site navigation menus or site search boxes.
Between the header and footer files are any number of blocks of managed content. These blocks are themselves grouped into a ‘Content Group’ to ensure a proper relationship between the blocks when outputting compliant and compatible CSS. As any CSS guru will know, where and how you output floating layers in relation to other floating layers is sometimes critical to achieving the desired result.
Content Groups, Headers and Footers are themselves organised into ‘Page Templates’, enabling complete flexibility to give different site pages, different layouts (e.g. a page displaying a product catalogue may require a different layout to one containing a list of latest news items).
In its simplest form, a site template consists of merely a header file, a footer file and a CSS file (the content blocks themselves are derived from specially tagged CSS id’s) - plus a handful of completed fields in the database to glue everything together (though I am pondering moving that out into a simple XML file to improve portability - comments on the pros and cons anyone..?).
I have a couple of content managed business websites to create in the coming months so I am hoping there will be time during April to hammer away and get AquariumCMS into a state as a viable option for those projects. At the moment, during the initial client discussions, it looks likely AquariumCMS V1 will fit the bill. It will be so satisfying to be building content managed websites without having to compromise visual design.
Technorati Tags: content management, cms, user interface
4 Responses to “Content Management and the irritation of interface compromise”
April 5th, 2006 at 7:37 am
I would have thought that many people have built a CMS for themselves and I always worry that they do not get enough of a critical mass for their users to really test them. IN the end the customer ends up with a CMS that is almost there but not quite.
I would have thought that by now, an open source CMS would be about that would do more of what you want, with it being better debugged.
But then again, just cause my site designer did not does not mean you will do that..
April 5th, 2006 at 9:18 am
A couple of good points there.
I’ve worked with several CMS now, both commercial and open source. The biggest problem with many is that they either specialise in a site type (i.e. blogs, or e-commerce) or they try to spread the net so wide that they have too many compromises in too many areas. This creates double trouble when a developer proposes a CMS for a client based on what they know rather than what is the most appropriate solution for the client’s requirement.
Open Source solutions are generally led by programmers and techies and so have a tech-driven focus with generally poor usability, and also tend to over react to the masses of feature requests from users when they should simply be setting a development roadmap. OS apps may well be in wide usage, but the knee-jerking developer reaction to try and keep everyone happy merely injects bug after bug after instability and the applications rarely find a truly stable position (then they realise they built the thing wrong from scratch and produce a brand new all singing all dancing version which is incompatible with previous versions!).
I am using Drupal for an intranet project right now and although in the longer term I will be saving the client time and money, right now every time I have a new request from the client I have to learn and work around how that application does things (often illogically) and then make it play ball because the client just doesn’t like the way the system forces them to work with it. Quite a frustrating process.
The key for a CMS is to focus on a target market and develop a core feature set which fits that market’s needs. Developers rarely understand such a principle and far too frequently try and shoe-horn an inappropriate CMS to fit a client requirement.
I would be interested in hearing more about your experience with your CMS, it would perhaps help me to avoid issues with mine!
April 21st, 2006 at 3:46 am
I’ve had these same exact problems with CMS systems. I’m just starting a project that is supposed to use some open source CMS-system and I feel the head ache allready. Looking forward to this Aquarium-project!
Code Igniter is a great framework. I’m pretty sure that it will breed lots of interesting software in near future.
April 21st, 2006 at 9:47 am
My only reservation about CodeIgniter is that it is still a relatively new product and will likely need some re-coding of my code as it grows and some function calls change. Still, with my initial tests it looks like with the initial time-saving to build with this framework, plus the logical MVC code structure, future tweaks and adjustments will be far easier.
As for Aquarium, I have finally conceived and feasibility tested, the concepts I had for simplifying the template/theme structure, and enhancing CodeIgniter’s search engine friendly URL system to make it search engine super-friendly - essential for a CMS these days. Things are looking good!