Site Architecture

Originally published September 15th, 2004

Too often I find myself struggling with the integration of horribly built content management systems, poor at best templating systems, and user expectation as it relates to ease of use. The point of a CMS is to facilitate the implementation of site content, often by non-(web) savvy ‘backend users’. This is meant to create a workflow which supports the communication of information (visual, written or otherwise) effectively to a site’s end user. I have yet to see this happen seamlessly, and I have used quite a few systems. For those interested I think I can identify clearly some of the major stumbling blocks inherent in most systems (in no particular order):

• it is easier for someone (not necessarily the site producer, but someone on their team) to hand code most material
• the CMS was built to meet certain requirements which were never implemented or are no longer needed that intrinsically hamper its effectiveness in other areas
• the vast database functionality makes smaller jobs a nightmare, particularly when it comes to throwaway content (i.e. entry fields for information that will never be accessed)
• the templates which the CMS spits out into are useless or ineffective

I think as a designer, it’s really important to address the final point, the functionality of your system being moot if you have a site which doesn’t communicate effectively. A perfect example is a site’s homepage. If the homepage is a custom environment, displaying content in a specific template, the navigation must carry through to the rest of your site. If it doesn’t you run the risk of stranding, even burying brand new content. You could be populating thousands of story, game and video templates, but if your user can’t find them, you’re SOL, and believe me, your traffic, ad revenue and user satisfaction will suffer. Ah, you say, “this is simply common sense, everyone knows better then to bury their content”.

Well, from the standpoint of both building for, and surfing the web, by example, this must be as far from common sense as you can get. Almost no one with large reams of information to communicate does so effectively from their homepage or even their hub pages; hence the profusion of (often useless) site search engines. For some reason, most of us have trouble archiving past material and even showcasing daily material. I think this is a result of poorly conceived templating more often than not. Marketing-based corporate sites don’t really encounter this problem mind you*, but any site claiming to have any modicum of customer support does. Again, more often than not, implemented poorly.

The process needs to begin not with a breakdown of what the CMS can do for you or your site, but how it can effectively populate your templates and/or design. Spending two weeks developing your site architecture and then eight months configuring your site for your CMS is ridiculous and backwards, and too often the process of note.

What if one were to spend two days writing, designing and proofing a magazine ad, and then had to expect a five month printing process? Obviously that’s a stretch and probably a poor metaphor, but the time spent building a site should be divided equally between 1) implementation and 2) development of the site architecture; otherwise you wind up asking your CMS to be the wings which make your Pinto fly.

*meaning a site built simply to showcase a company’s brand or services