Understanding CMS - Critical to successful web design ?
08 January 2009 - By Sean Fishlock
The lack of information about how visual concept design translates into a dynamic content managed website is something we've taken great pains to address and was recently highlighted by one of my readers. So I decided to look at what is more important for designers to understand - the technology or the concepts.
I thought I'd attempt at an explanation of why building a successful website is not always as simple as ABC, but why some do it better than others.
I'll start here. In the modern web development industry, businesses and consultants operate in the following modes:
A) designing, and;
B) implementing content management systems (CMS)
C) both
Many businesses operate in mode C, simply because they work with a technology (in this case - website content management system) that they are familiar with and understand.
However both A and B are very specialised fields. In fact many designers aren't even experts in web, they often come from print backgrounds, which is a completely different medium. HTML is not only a different medium to print but it also introduces a whole new field of information architecture - defining the content structure of websites. The problem is compunded in that, in this day and age, customers are increasingly the ones who choose the technology.
Few that excel at B are also good at A and few that excel at A are also good at B. Information architects sit somewhere in the middle. Both designers and information architects are rarely programmers that do the nitty gritty work. They think creatively, not logically. Individuals that can do C are a very rare breed indeed and are in high demand (although templating engines and smart APIs are somewhat bridging the gap here). Businesses that only do B have an even tougher challenge deciphering the creative goals of someone who has never attempted to understand the technology.
So my message is that to design a successful content managed website, you need to understand the concepts involved. But the question remains - is it necessary to understand the technology ? It may suprise you to learn that our answer is - not really.
So how does a business like Datalink which operates around 40% of the time purely in mode B, working with "third party" designers achieve a good design result that satisfies both the creatives and the end customer ?
How do you overcome these obstacles ?
Well I have some tips, common examples and advice on how it can be achieved.
The key is not to simply try to make the technology work for a creative concept.
Designer education is paramount. It is important that the designers understand not only the concepts of content management, but the constraints which they need to work in.
Part of Datalink's education to third party designers is what we call a User Interface Guidelines document which is "a practical resource for third party visual designers". It is intended to let designers know only what is necessary to produce a satisfactory implementation in a CMS - in this case, specifically Freestyler CMS. We provide a consulting service to designers based around this, and typically their client is happy for them to undergo this course.
The document does not go into any technical depth. It starts by explaining the elements of a typical page, talking about screen resolutions and real estate, text and fonts, colours and RGB, navigation and menus, fixed and scalable (fluid) layouts. It is the result of years of working out the best way to do things.
We break our checklists down into compulsory, strongly recommended and recommended. This gives the designers the flexibility and choice to rigidly adhere to the guidelines or to take on board only some of the points.
Our compulsory points are related to logical linking, so that content editors don't have to create navigation systems. Not adhering to this, in our opinion, would defeat the purpose of them purchasing a content management system. A website isn't just a heirarchy of pages, but also a flexible, organic document and a balance needs to be struck between both. How this happens can differ greatly between CMS though. A bit of a CMS taxonomy 101 needs to be applied. Don't be daunted by the term, it basically means the capabilities of the system in createing page structure and navigation. The key concept to discover is the nature of a taxonomy for the CMS to be used. Freestyler's taxonomy is dead simple to understand and offers the power of infinite levels of content and methods of crosslinking pages. However the more complex the taxonomy of the CMS, the trickier it is to design for. I have seen inferior and over-engineered content management systems with severe and well documented limitations in taxonomy, though I won't name any names [COUGH - Joomla Drupal Plone - excuse me] which need to be seriously "hacked" by an implementer just to fulfil the basic navigation structures required by most conceptual web designs. Unfortunately these systems are popular, well mainly because they are free. The hidden cost is the expense and frustration for all involved. CMS should separate content from design, and it does in most cases, however in these systems it unnecessarily ties specific implementation knowledge. I'm not going to go too deep into those issues, because I feel that this is a problem with the execution, so let's move on.
The designs should also be to a minimum screen resolution, must indicate how it will fit on the screen and which parts expand to fill the available space. Graphics should always be provided to an implementer in layered or vector, source format, in case additional changes are required.
Our recommendations include supplementary navigation aids for improved user experience, best practice and tips on screen layout.
At the end of the process, you define what can be edited (usually most text and images) and what can't be (usually elements of the design) and that is that.
This is important as some stubbornly push various creative agendas and some originate from the client. A CMS should be a "YES" tool, and not a "NO" tool and we are generally a "YES" company. It is not our place to knock back all of these ideas. We can only do what we can do to steer them in the right direction and set the boundaries in terms of the implementation service. There will also always be clients and designers who still cannot see the benefits of a CMS, despite there being so many, and they may think that visuals is a higher priority than content management and usability. What is important is that the designer is clear to the implementer any areas where they do intend to deviate from the key guidelines and that the implementer has a clear solution for dealing with each case. This must be reached before they start their work and often involves writing what is refered to as a "cut up spec" - a specification for pulling elements of the design into components that the website and content management system can use to fulfil the desired functionality - so that all parties has a clear vision of the final result even before it is built.
In the end what the designer and client gets out of the little education process is completely up to them. If they go with it, then pretty soon they will be designing CMS websites with ease.
I know what you're thinking now - some examples of problems that we've experienced when the recommendations aren't adhered to.
Off the top of my head from projects I've been involved in ...
In one project, a client decided that they could get over one of our mandatory requirements - automatically having a list of links to pages added beneath it. The webmaster of the organisation basically said "it's ok, I know what I'm doing. I'm just after a certain look". They wanted the ability to enable or disable links as desired. Well the request was granted and everything went smoothly until that person left the organisation and a new person tried to manage the website and add a whole lot more content. They soon found that they had to create links to every new page that they created.
Another project insisted on having a certain font that was not web safe. This didn't represent problems with the pages, but because they were after a specific look for the menus, it did mean a significant issue for the main website navigation. The problem was that when pages with larger titles were added, the design would break and they specifically did not wish to use Flash technology.. The only available solutions were to truncate or rename the titles. Of course, the unpredicted result was that the titles of some pages were being misinterpreted by web users. After many headaches, we were finally able to put an end to the madness by insisting that the menu use a different, but very closely matching font. In the end, the users gave them feedback that they preferred the functionality over the look and everyone was happy.
One last example was a project where the designer failed to indicate to their client the way that the would expand to fill the screen. Despite the recommendations, when the site was implemented, the CEO of the company, viewing it on his brand new plasma screen and the whole design looked tiny in one little corner of his screen. Needless to say, he was not impressed and the site had to be re-implemented.
So there you go, these weren't necessarily catastrophes, but weren't instant successes either. The lesson is that there will always be challenges along the way, but if the designer understands the concepts, not necessarily the technology, then everything should at lest be ok. At best it could produce a sensational website. And of course there are other considerations, such as search engine marketing that need to be taken into account. But that is for another story.
We follow the same procedures internally, so that when we hire new designers, we get the best results for our clients.
Designer education is paramount. It is important that the designers understand not only the concepts of content management, but the constraints which they need to work in.
Part of Datalink's education to third party designers is what we call a User Interface Guidelines document which is "a practical resource for third party visual designers". It is intended to let designers know only what is necessary to produce a satisfactory implementation in a CMS - in this case, specifically Freestyler CMS. We provide a consulting service to designers based around this, and typically their client is happy for them to undergo this course.
The document does not go into any technical depth. It starts by explaining the elements of a typical page, talking about screen resolutions and real estate, text and fonts, colours and RGB, navigation and menus, fixed and scalable (fluid) layouts. It is the result of years of working out the best way to do things.
We break our checklists down into compulsory, strongly recommended and recommended. This gives the designers the flexibility and choice to rigidly adhere to the guidelines or to take on board only some of the points.
Our compulsory points are related to logical linking, so that content editors don't have to create navigation systems. Not adhering to this, in our opinion, would defeat the purpose of them purchasing a content management system. A website isn't just a heirarchy of pages, but also a flexible, organic document and a balance needs to be struck between both. How this happens can differ greatly between CMS though. A bit of a CMS taxonomy 101 needs to be applied. Don't be daunted by the term, it basically means the capabilities of the system in createing page structure and navigation. The key concept to discover is the nature of a taxonomy for the CMS to be used. Freestyler's taxonomy is dead simple to understand and offers the power of infinite levels of content and methods of crosslinking pages. However the more complex the taxonomy of the CMS, the trickier it is to design for. I have seen inferior and over-engineered content management systems with severe and well documented limitations in taxonomy, though I won't name any names [COUGH - Joomla Drupal Plone - excuse me] which need to be seriously "hacked" by an implementer just to fulfil the basic navigation structures required by most conceptual web designs. Unfortunately these systems are popular, well mainly because they are free. The hidden cost is the expense and frustration for all involved. CMS should separate content from design, and it does in most cases, however in these systems it unnecessarily ties specific implementation knowledge. I'm not going to go too deep into those issues, because I feel that this is a problem with the execution, so let's move on.
The designs should also be to a minimum screen resolution, must indicate how it will fit on the screen and which parts expand to fill the available space. Graphics should always be provided to an implementer in layered or vector, source format, in case additional changes are required.
Our recommendations include supplementary navigation aids for improved user experience, best practice and tips on screen layout.
At the end of the process, you define what can be edited (usually most text and images) and what can't be (usually elements of the design) and that is that.
This is important as some stubbornly push various creative agendas and some originate from the client. A CMS should be a "YES" tool, and not a "NO" tool and we are generally a "YES" company. It is not our place to knock back all of these ideas. We can only do what we can do to steer them in the right direction and set the boundaries in terms of the implementation service. There will also always be clients and designers who still cannot see the benefits of a CMS, despite there being so many, and they may think that visuals is a higher priority than content management and usability. What is important is that the designer is clear to the implementer any areas where they do intend to deviate from the key guidelines and that the implementer has a clear solution for dealing with each case. This must be reached before they start their work and often involves writing what is refered to as a "cut up spec" - a specification for pulling elements of the design into components that the website and content management system can use to fulfil the desired functionality - so that all parties has a clear vision of the final result even before it is built.
In the end what the designer and client gets out of the little education process is completely up to them. If they go with it, then pretty soon they will be designing CMS websites with ease.
I know what you're thinking now - some examples of problems that we've experienced when the recommendations aren't adhered to.
Off the top of my head from projects I've been involved in ...
In one project, a client decided that they could get over one of our mandatory requirements - automatically having a list of links to pages added beneath it. The webmaster of the organisation basically said "it's ok, I know what I'm doing. I'm just after a certain look". They wanted the ability to enable or disable links as desired. Well the request was granted and everything went smoothly until that person left the organisation and a new person tried to manage the website and add a whole lot more content. They soon found that they had to create links to every new page that they created.
Another project insisted on having a certain font that was not web safe. This didn't represent problems with the pages, but because they were after a specific look for the menus, it did mean a significant issue for the main website navigation. The problem was that when pages with larger titles were added, the design would break and they specifically did not wish to use Flash technology.. The only available solutions were to truncate or rename the titles. Of course, the unpredicted result was that the titles of some pages were being misinterpreted by web users. After many headaches, we were finally able to put an end to the madness by insisting that the menu use a different, but very closely matching font. In the end, the users gave them feedback that they preferred the functionality over the look and everyone was happy.
One last example was a project where the designer failed to indicate to their client the way that the would expand to fill the screen. Despite the recommendations, when the site was implemented, the CEO of the company, viewing it on his brand new plasma screen and the whole design looked tiny in one little corner of his screen. Needless to say, he was not impressed and the site had to be re-implemented.
So there you go, these weren't necessarily catastrophes, but weren't instant successes either. The lesson is that there will always be challenges along the way, but if the designer understands the concepts, not necessarily the technology, then everything should at lest be ok. At best it could produce a sensational website. And of course there are other considerations, such as search engine marketing that need to be taken into account. But that is for another story.
We follow the same procedures internally, so that when we hire new designers, we get the best results for our clients.
Comments
There are no comments.
Categories
- Datalink News (24)
- Datalink Project News (39)
- People @ Datalink (6)
- Emerging Technologies and Trends (21)
- Best Practice and Strategy (15)
- Web Design & Development (17)
- Internet Marketing (31)
- Website Watch (11)
- Book Reviews (6)
- Datalink Ramblings (17)
- Industry News (5)
- Freestyler CMS News (13)
- Freestyler Designer Network (4)
- All Categories
