Barely a week goes by that I fail to rant about why we should banish table based design and yet here I sit struggling because I failed to heed my own advice.
I am working on an old website that I built a couple of years ago and I am having a hell of a time with it, all because of my own laziness.
I would like to tell you that I built this site before I knew about web standards and the concept of separating design from layout. I would like to blame the presence of a table to set the basic layout as a mistake born out of ignorance. I would like to tell you that… but I can’t.
When I built this site I knew exactly what I was doing. We had been working with standards for well over a year and I had a fairly good handle on what I was doing. However for one reason or another I cut a corner. I introduced one tiny little table. So small you could argue it hardly counted. All this table did was set the basic two column layout. I argued that the time saved from taking this approach out weighed any "purist" arguments I might have against it. And indeed it did make life a lot easier and we turned the project around remarkably quickly considering its size.
Of course, like all good shortcuts it eventually came back to bite me. Recently the client requested a low vision version of the site like the one we offer on our company website. The problem is that one of the basic principles of low vision design is that content is sorted into a single column to aid readability by those with poor eyesight. Suddenly that little insignificant table has become a real pain.
The morale of the story is two fold, dump those table based designs and don’t cut corners for a quick win.
Decisions, decisions… develop in house or use a third party web design company? This is discussed in this weeks podcast along with other bits and pieces.
The decision of whether to develop your website in house (by taking on additional staff) or outsource it to the third party web design company can be a tricky. This week Paul and Marcus look at the pros and cons of both approaches as well as throwing in some additional options for good measure.
The decision of how you are going to resource your web project will radically affect not only the price of the project but also how that website develops in the future. It is therefore important to understand the options available to you and to know the pros and cons of each.
Although there are some alternative approaches that I will discuss later, you basically have two options available:
You can use internal resources within your organisation to develop your new web project. This can either be existing staff or new employees that have been recruited specifically to work on the website.
You can outsource the project to a specialist web design agency who can work either on a fixed price or time and material basis.
Either option has both its advantages and disadvantages:
In-house development
In short, an internal development team demonstrates a greater commitment to placing the web at the heart of your business
If you envisage that your site is going to need ongoing support and development (beyond basic text amendments that could be completed via a CMS) then hiring in-house staff may well be the best way to proceed. Although this does produce an ongoing financial commitment in the form of salary, equipment and training, it will ultimately be cheaper than the higher rates you will be forced to pay an external agency. An in-house development team will not only understand your business better than an external agency but will also be in a position to push the virtues of the web internally on an ongoing basis.
External agencies are often better placed for dealing with more challenging sites.
Of course having an in-house team isn’t always appropriate. For a start the ongoing financial commitment may simply not be an option even where site evolution is the preferred approach. Secondly, external agencies can sometimes have the advantage when it comes to complex and cutting edge sites. External agencies are normally larger than in-house teams including more specialists in specific fields (e.g. accessibility, usability etc). In addition because of the competitive nature of external agencies there is more pressure on them to keep up-to-date with the latest innovations and developments. As a result they are often better placed for dealing with more challenging sites.
Finally there is a danger in some organisations that the in-house web team can become “institutionalised” whereas an external agency will bring a fresh perspective that can challenge internal preconceptions.
Management mistakes
Of course the biggest factor in undermining in-house teams can often be mistakes made by management and not anything to do with the team itself. One such problem is recruiting the wrong person for the job. Often smaller organisations will recruit a web developer when what they really need is a web strategist and evangelist. Although coding and design are important skills, a smaller organisation needs to have somebody with business acumen that can help the organisation identify opportunities to utilise the web and to promote its use internally.
However, probably the biggest mistake made my management is ignoring the internal team they have. As a member of an external agency who works with in-house teams on a regular basis, I am constantly amazed how often we are brought in only to validate what the in-house team has already been saying. It is as if our presence is required simply to mediate in the internal politics that can often be found in larger organisations.
Other approaches
Of course choosing how to develop your website doesn’t need to be a black and white choice between in-house or outsource. There are in fact a number of other options to suit different organisations:
Ad-hoc specialists
For larger organisations it may sometimes be appropriate to bring in specialists to compliment an existing in-house team. For example specialists in accessibility, usability or design can often work well alongside an in-house team primarily made up of coders.
Part time contractors
For smaller organisations that cannot afford fulltime in-house staff but who wish to enjoy the benefits that come with that approach, there is the option to take on a part-time contractor. These individuals will probably have 2 or 3 websites they manage on a regular basis but still will be able to work more closely with you than an external agency.
Maintenance contract with an external agency
Although probably the most expensive approach, maintenance contract with an external agency does provide the best level of service. If the agency provide the right kind of service this can be very much like working with an in-house team. The agency will really get to understand the business, evolve your website on a regular basis and still provide all of the benefits of an external agency.
Conclusion
In many ways the title of this entry is somewhat misleading. The decision between development in-house or outsourcing is not a black and white one. Different solutions are right for different organisations. However I believe one thing is universally true, whether you use an external agency or in-house staff, you need a “website owner” within your organisation who is the project manager for any work done and the evangelist for the site within your company.
A number of things have happened recently that have got me thinking about the state of web design. I find myself increasingly concerned about the mentality that is developing within certain parts of the industry.
I guess a recent interview I did for Dustin Diaz started me thinking. We found ourselves on the subject of whether I ever got sick of talking about good practice in web design (things like web standards, progressive enhancement etc.). I explained that this is where my real passion lies and that boagworld.com exists to communicate best practice in a way that isn’t patronising or full of technbabble, which nobody understands.
I have become increasingly concerned that there is a growing divide between those who have grasped this new methodology for designing websites and those who have not. The problem is that many of the "Standardites" have a holy-than-thou attitude, which can seem very condescending to those that aren’t "in the know". In our desire to promote standards we have made those who are not yet using them, feel ignorant.
Not me too!
What has disturbed me most is that I have found myself doing the same thing. In my last podcast, I ranted about another web design show that promoted all kinds of bad practice. In next weeks show I moan about the "ignorance" of some designers when it comes to accessibility (following comments made on sitepoint.com about the target case). In both cases, I may have (and probably did) come across as very dogmatic and arrogant. This kind of approach only builds walls making it harder to educate and inform.
Those people still delivering nested table layout, spacer gifs or ignoring accessibility can no longer call themselves web professionals.
In the past, I have praised Andy for these comments and I still believe that they are in essence true. However, now I find myself wondering if comments like that actually help. If I wasn’t using web standards and had not yet faced the challenges of accessibility, I would find those comments very demoralising. There can be all kinds of reasons why people haven’t adopted these new "best practices". Whether it is a lack of time and training, or simply that they find them too challenging, when in the past they have relied on a WYSIWYG editor like Dreamweaver. Whatever the case we should be aiming to encourage and not condemn these people.
The web standards gang
There is a definite web standards community who all read the same blogs and go to the same conferences. When you are in this group it is hard to conceive that people have not yet grasped the concepts of standards and we are in serious danger of becoming increasingly insular.
My hope is that boagworld.com can bridge that gap and convince people about "web design good practice" without bashing them around the head with it.
With next weeks podcast being on content management systems I have been thinking a lot about how they work. In particular, I have been mulling over the unique challenges they create when it comes to the front-end design.
One of the biggest areas of business for us at Headscape is the creation of design templates for content management systems. A lot of organisations have in house developers who purchase or build their own CMS but don’t have the skills to do the design work involved in the front end of the site. As a result, they come to us looking for help.
Over the years, I must have worked with dozens of different content management systems, all with their own unique constraints. I really have seen every quirk imaginable, from systems that only allow colours chosen from the web safe palette, to a CMS that insisted on a strict three-column layout for all sites.
However, probably the most universal problem with any CMS is that it gives the website administrator limitless control. "Isn’t that half the point of a CMS?" I hear you cry. Well yes, it is, but that doesn’t mean it can’t prove annoying if you’re trying to design the interface. Let me explain what I mean:
Limitless sections
Many content management systems give website owners complete control over the structure of their site including the top-level sections. This means they can continue to add sections until inevitably they break the design. This is especially true of horizontal navigation because you obviously want to avoid horizontal scrolling. To be honest your options are limited:
You instruct the users not to add top level sections or disable that feature.
You avoid horizontal menu’s entirely and design your site in such a way to allow for expanding of vertical navigation.
You create a horizontal navigation that wraps nicely when there are too many sections.
None of these options are particularly elegant, nevertheless this is something you need to consider carefully in the design stage.
Deep navigational structure
Of course, the problems don’t stop there. If a user has control over the structure of the site, it is also possible for them to create sections, within sections. With this kind of limitless flexibility, you cannot presume in your design that you only need to display one or two levels of navigation. In theory, your navigation has to be limitless.
This problem can be solved in a couple of different ways. One option is to show only the siblings, parent and children of any particular page. This works very well particularly when used in conjunction with breadcrumbs, however it does have some drawbacks.
Another approach is to use a breadcrumbs style of navigation. This is something I have covered before in my entry entitled "Dealing with complex navigation" so I won’t go into anymore details here.
Varying column heights
Of course as well as expandable navigation, there is also potentially endless content! With few clients following Steve Krug’s rule of taking your content and halving it, pages can get incredibly long. However, on other occasions it is common to find the navigation being longer than the body copy. With content and navigation being so flexible it is important that your design can comfortable expand or contract to fit what is there. The golden rule here is to test endlessly with different content and different navigation to see if your design breaks.
Ever-expanding names
With users having control over naming pages, another problem arises. As web designers, we have learnt that short snappy names for sections are much easier to read and digest. As a result, we tend to design on the assumption page names will be relatively short. However, you cannot guarantee this if the client has control over the site structure. Make sure you check that page names wrap nicely whether they appear at the top of the page or in your main navigation. Always design for the worst-case scenario and remember if your site is multi-lingual that some languages can have words considerably longer than their English equivalents.
Interchangeable boxes
Not only can the user control the site structure and page content but in many content management systems, they also have some control over the layout. This is often particularly true on the homepage where they can often reorder content "modules". This means any design that you propose has to be flexible enough to allow these "modules" to be moved around. The trick is to do this without the design becoming too blocky. I have found that using curved corners, overlaid imagery and removing borders can help to blur the lines between these "modules", creating a less boxy feel.
The evils of the WYSIWYG
Probably the biggest area of concern is the dreaded WYSIWYG editor. With this, a client can ignore all your lovely design rules and do whatever the hell they like with your page. This is probably the biggest danger area in content management design.
My recommendation is to try and persuade the client to swap out their CMS default editor with something like Xstandard. With this WYSIWYG the client enters content semantically rather than worrying about the design. In other words they tell the WYSIWYG that something is a heading and the CSS file defines its look, rather than the user defining the font, styling and colour themselves. Failing that it is important that the designer provide a very clear style guide covering exactly what is acceptable and what is not.
What’s your experience?
These are just a few of the challenges that I have discovered over the years but I would be interested to hear what your experiences have been? Which content management systems have you used and what problems have you encountered. What advise would you give to somebody designing for a content management system for the first time? Post your comments here.
Semantic code is a term that is thrown around a lot at the moment, but what is it and why should you care? I try to explain to Marcus in very small words what it’s all about!
Carefully planning your website before you start to build might not sound like the most exciting theme for a podcast but it is fundamental to a successful website project. I know from bitter experience that not doing so can lead to a world of pain for both the developer and the client. In this weeks show we share loads of tips that we have learnt over the years. Here are just a few of them:
Take the long view
Many clients force agencies to start projects before they are fully prepared, either because they are unwilling to pay for a scoping phase or because they have a tight deadline to meet. This kind of short-term view does nobody any favours. If a project is not properly defined at the outset, it will inevitably lead to slippages and additional expense. A developer needs time to understand the requirements before they begin to build. If they don’t, they will be unprepared when they encounter unforeseen technical issues.
Everybody has to sign off
Having a statement of work that everybody has signed off on is a great way to ensure client, developer and designer are all singing off of the same hymn sheet. It avoids miscommunication and misunderstanding by clearly defining what is going to be delivered.
Do you really need that?
The scoping phase should not only identify what tasks need to be done, it should also take a long hard look at what functionality is being considered. If you are not careful, your statement of work can turn into a wish list of functionality rather than a considered document which factors in return on investment. Ask yourself, if I spend all of this time building a certain piece of functionality, will it pay dividends for my organisation.
Be specific
It is easy to be vague about your scope, but if you do, there is room for confusion. The statement of work should cover everything from how many design iterations there should be, to what browsers the site is going to be tested on. Make sure your list of tasks is as detailed as possible, that way you will avoid any nasty surprises half way through the project.
Phased development
Don’t be afraid to phase a project especially when faced with a tight deadline. If your website has to be live by a certain date, it might be wise to leave out some of the "bells and whistles" until post launch. It is easy to forget that your website should be an evolving animal that can grow over time. After all, saving some of the functionality and rolling it out later gives you a good PR opportunity.
The hidden technology killers
Beware of those little technology issues that are so easy to overlook. For example, pay particular attention to which browsers you are going to support and what accessibility level you will be conforming to. Finally don’t forget to factor in time to deal with those extra style sheets for print, mobile or low vision users.
Web resources: Getting your layout right
This week I picked two sites that help designers develop the perfect layout.
Web Design Practices A great site that shows you the trends in layout based on an analysis of several hundred websites. This site answers invaluable questions such as; "where does the search box normally appear" and "do most sites use side or top navigation?"
Although slightly out of date and centred largely on ecommerce sites, this is still an excellent resource. However, remember, just because a lot of sites do something a certain way doesn’t make it good practice!
Layout cookbooks Have you ever had a client who knows what they like when they see it? If so, send them over to the layout cookbook and get them to look through the hundreds of different screen layouts available there. It’s also a great place to get some inspiration when you feel like all your designs are using the same basic layout!
So, Target is being sued by the American National Federation for the Blind because of their inaccessible website. I have received a number of emails asking for my opinion, so here it is…..
I suppose I could say that my Christian morals demand that if society is able to help somebody they have an obligation to do so. I could also argue that the "free market" economy (which appears to be the main argument in support of Target’s actions) is one step away from Social Darwinism. Of course, were I to say that, I would just be spoiling for a fight! ;)
The truth is I don’t believe that my personal opinions on the subject (or the opinion of any other web designer) matter that much. There seems to be a huge amount of debate among web designers on the topic and yet few seem to be grasping the reality of the situation.
"I am a web designer Jim, not a politician!"
Web designers are not politicians, lawyers or judges. It is not our job to form government policy or write legislation. We are debating a subject which has long since been done to death by the people appointed to shape America’s social justice system. I don’t claim to be an expert on American law but it would seem to me that legislation already exists in the states outlining disability discrimination. It is not for us to argue as web designers the rights or wrongs of that legislation.
Equally we are not business owners. We do not have to balance PR concerns, with social responsibility and return on investment. We don’t get to say what makes good business sense and what doesn’t.
We are web designers damn it, act like it!
However we are web designer. It is our job to advise our clients on the practical implications of making their sites accessible and leave the final decision to them. If Target had called me when the American National Federation for the Blind first contacted them, my advice would have been straightforward. Ensuring your website meets basic accessibility requirements is a quick, simple job that will be a hell of a lot cheaper than any bad publicity or litigation you could potentially face.
If I was forced to point fingers here it would be at the web designers who produced this site. At Headscape, we don’t ask our clients if they want their sites to be accessible, we just make them that way. As web designers we should be building in at least basic accessibility features by default because the cost of doing so is negligible.
With the launch of the new and somewhat improved Headscape site only days away, I find myself debating whether my approach has been the right one.
The reason I haven’t been posting much over the last couple of weeks is due to the fact that my every waking moment is being spent obsessing over the new Headscape website. I want it to be perfect, I want it to stand out from the crowd, I want it to be beyond criticism. Of course, I can want that until I am blue in the face but it is never going to happen.
No such thing as perfection
There is no such thing as perfection on the web. The problem is that things change so fast that best practice one minute is sadly out of date the next. Take for example the new dynamic resolution approach that everybody is discussing. I so wish that I had used this on the Headscape site, but I didn’t because it wasn’t around at the time.
Not settling for second best
There is a fine line to walk where you accept the site is never going to be perfect but where you don’t settle for second best.
Of course, if you read this blog regularly, you know that I am a great believer in evolving sites rather than redesigning them every few years. But, I cant help wondering if I have paired back my ideas for the Headscape site so far (by saying I will add that later), that the site on launch is going to be a bit of a disappointment.
What have I missed?
My other major concern is that I so desperately want this out of the door, that I might be cutting corners not only with the functionality but also with the quality of the coding & content. Is the site as accessible as it could be? Am I sure it will work in all major browsers? Have I caught all of the typos? What have I missed? What has slipped through the net?
And the morale of the story?
So what conclusions do I draw from my concerns about the Headscape site.
I remain convinced that launching a competent, well tested, well built site is more important than having all the extra bells and whistles in place. I believe that too many web projects fail because they want to deliver the world on day one and so the site never gets finished. However, I also recognise that you only get one chance to impress and so the site has to be good enough to shout about even from the outset.
I also believe that the last few days before launch are critical. Web designers are notoriously bad for picking up details and yet it is exactly that which can undermine an otherwise good site. As they say, the devil is in the detail *gulp*
Web designers like to throw around a lot of jargon. With that in mind, I want to focus on the more popular techno babble and try to dispel some of the mystery. First up: semantic code.
What is semantic code?
Even if you are not a web designer, you are probably aware that your site has been written in HTML. HTML was originally intended as a means of describing the content of a document, not as a means to make it appear visually pleasing. Semantic code returns to this original concept and encourages web designers to write code that describes the content rather than how that content should look. For example, the title of a page could be coded like this:
<font size="6"><b>This is the page title</b></font>
This would make the title large and bold giving it the appearance of a page title, but there is nothing that describes it as a title in the code. This means a computer is unable to identify this as being the page title.
To write the same title semantically so that a computer understands that this is a title, you would use the following code:
<h1>This is a heading</h1>
The appearance of your heading can then be defined in a separate file called a "cascading style sheet" without interfering with your descriptive (semantic) HTML code.
Why is semantic code important?
I have already hinted at one reason why semantic code is important when I said that without explaining what a piece of content is, a computer has no way of identifying it. The ability for a computer to be able to understand your content is important for a number of reasons:
Many visually impaired people rely on speech browsers to read pages back to them. These programs cannot interpret pages very well unless they are clearly explained. In other words semantic code aids accessibility
Search engines need to understand what your content is about in order to rank you properly on search engines. Semantic code tends to improve your placement on search engines, as it is easier for the "search engine spiders" to understand.
However, semantic code has other benefits too:
As you can see from the example above, semantic code is shorter and so downloads faster.
Semantic code makes site updates easier because you can apply design style to headings across an entire site instead of on a per page basis.
Semantic code is easier for people to understand too so if a new web designer picks up the code they can learn it much faster.
Because semantic code does not contain design elements it is possible to change the look and feel of your site without recoding all of the HTML.
Once again, because design is held separately from your content, semantic code allows anybody to add or edit pages without having to have a good eye for design. You simply describe the content and the cascading style sheet defines what that content looks like.
How to ensure a site uses semantic code?
There is no tool that can check for semantic code. It is a matter of looking at the code and seeing if it refers to colours, fonts or layout instead of describing what the content is. If looking at code all sounds a bit too scary then a good place to start is by asking your web designer if he codes semantically. If he looks at you blankly or starts waffling, you can be sure he does not. At that point you need to decide if you wish to pressure him into getting up to speed or if you want to find yourself a new designer!
I made a tough decision yesterday by taking the current Headscape website offline and replacing it with a holding page. Obviously, a web design company without its own website is bad news. However, I believe that leaving the site up would have been even more detrimental.
As you may already know if you read this blog regularly, we have been working on a new Headscape website for sometime. The current site is over three years old and was built in the days before many of us were aware of things like web standards and accessibility. Although, at the time, the site did conform to best practices in web design and accessibility, it now appears horribly out of date.
At Headscape, we work with extremely switched-on clients who specifically ask for sites to be built with standards and accessibility in mind. We were beginning to notice a definite impact on the quality of leads from our site. Although the numbers were still high we were finding that, the values of projects were lower as large clients were put off by our legacy site.
The final nail in the coffin was an interview Andy Clarke gave to Accessify.com in which he said:
"Those people still delivering nested table layout, spacer gifs or ignoring accessibility can no longer call themselves web professionals."
I passionately agree with Andy on this one and Headscape has been working with standards for over two years now. The problem is that our site does not reflect this and I was concerned about how others would perceive us based on our site only. In the end I became convinced that a single page that validated, conformed to the highest standards in accessibility and was built using web standards reflected better on our brand than a whole site of invalid, inaccessible code.
Was it the right decision?
What do you think? Do you think it was the right decision? Which is more damaging; a web standards built holding page or a complete site using out of date development techniques? What would you have done faced with the same dilemma.
In this post I look at how a site can be enhanced over time rather than redesigned intermittently.
In a previous article I talked about changing the client/web designer relationship from a “per project relationship”, to a more dynamic continual association, allowing for site evolution rather than site redesign. In this entry, I want to unpack that concept a little further and look at how a site can be enhanced over time rather than redesigned intermittently.
Benefits of evolution
Before we look at how site evolution can be achieved, let’s take a moment to examine why it is worth doing in the first case.
Why throw money away?
As I indicated in my last article on the subject, there are significant cost savings to make by evolving rather than redesigning your website. Most organisations redesign their website every three years or so. The old site is thrown away, and a new better site is put in its place. This demands a significant investment each time as the entire site is rebuilt from scratch. By taking a more evolutionary approach, each financial investment into the website builds upon the previous work done. With evolution, it is about building on what has gone before not replacing it.
Something to shout about
From a marketing perspective, evolution offers some exciting opportunities. With periodic redesign, you get one decent chance to shout about your site every few years when it undergoes a major relaunch. However, evolution allows you to go back to your users continually, telling them about the latest developments on the site. Each time you make a usability enhancement or improve the sites accessibility you can inform your customers. Every time you add a new piece of functionality, you have something new to shout about. Evolution provides a continual stream of marketing opportunities even for the most unexciting site.
Keep them coming back for more
I have written before about the importance of generating repeat traffic and keeping users engaged. Traditionally this has been achieved through updates to the content. Things like regular news stories, constantly updating events and new product ranges are all great ways to keep users checking your site. However, site evolution now offering the opportunity to engage users through improvements in the functionality and appearance of the site. User return to the site to see how it has been enhanced as much as to see what content has changed. Small tweaks to the site are a good way of demonstrating that your site is constantly maintained and worth regular visits.
Laying the right foundation
The benefits of site evolution are obvious but how do you practically go about evolving your website over time? The key lies in laying the right foundation. Too many sites are built with redesign instead of evolution in mind. They are built with the expectation that not much will change on the site for two or three years and then it will be built again from scratch. Sites built with this mindset will be difficult to evolve because the fundamental building blocks of evolution will not be there.
If you are commissioning a website build, it is vital that you ensure your designers and developers build with evolution rather than redesign in mind. Only if they do this can be hope to move your site forward in incremental steps rather than periodic redesigns.
Building blocks of evolution
These “building blocks for evolution” can be summarised as follows:
Separation of content from design
I have talked about web standards many times before in this blog. Standards primarily revolve around separating the content of your site from its visual appearance.
This approach provides many benefits but the one that applies the most to site evolution is the ability to make global design changes simply and easily. Site evolution works on the assumption that you cannot guess how your site will change over time. It is therefore vital to make everything as easy to alter as possible. By separating design from content, you can adapt the look and feel of your site from a central location instead of editing each individual page. Without this separation, design changes become a painful process of find and replace across every page on your site.
Let’s say for example you change your corporate colours and your website needs to reflect this. With standards, you can edit your central design files (CSS) and these changes are shown instantly across your whole site. Without web standards, you would have to edit manually every page of your entire site in order to achieve the same result. The time involved in such an undertaking would almost be as significant as a complete site rebuild!
Separation of behaviour from content
In the same way, you separate content from design because you cannot predict what changes you may wish to make in the future, so you should also separate behaviour. For example, just because you currently want all links to external websites to open in a new window, doesn’t mean you will always want that to be the case. By putting this kind of behavioural functionality in a separate file, it is easy to edit them centrally rather than updating each page individually where the behaviour is used.
Well defined content
As important as it is to separate out the design and behaviour from the content, it is equally important to ensure the content is clearly “marked up”. “Mark up” refers to how the content on your site is defined. This definition is how your web browser knows what to do with it. For example, an important heading on your site would be “marked up” as follows:
<h1>This is an important heading</h1>
Without those tags, the browser would have no way of knowing that particular piece of text is a heading. However, more importantly without this clean, uncomplicated definition of content you cannot easily define how that content should look or behave. For example without the H1 tag you see above it would be impossible for you to change the appearance of all your major headings.
I know this is in danger of getting technical, something I try to avoid on this site. However, as a website owner you need to be aware that many web designers do not produce this kind of well “marked up” content. If they don’t do it on your site, then evolving the appearance or functionality is going to be that much more difficult.
Templates and content management
Most of the web pages on your site look the same. They have the same navigation, the same branding, and the same layout. Normally, it is only the content that changes. It is therefore sensible that these common areas in each page are built using a template. That way when you change the template you update all occurrences of these consistent elements across the whole site. Once again, this approach allows you to make site wide changes ease.
The only slight complication to this approach is that some special technology is required. In affect, each page needs to be built automatically from the template when the user goes to that page. In most cases, this process is handled by a content management system. If you are considering evolving your site overtime then a content management system is probably a good investment. Not only does it allow pages to use templates it also gives you (the site owner) a lot more control over the structure and content of your site. Typically, a content management system will allow you to edit pages, add new pages and reorganise the structure of your site. In short, a content management system allows you to evolve the content and structure of your site without the need for web designers.
Design flexibility
The final principle of site evolution is ensuring flexibility in the look and feel of your site. Although I have already outlined how separation of content from design enables you to make gl
obal changes to the look an
d feel of your site, you still want a design that is as flexible as possible. You do not want to be in a position where you are making major changes to a sites appearance just because you add a new top-level section or a new type of content. A design should be flexible enough to accommodate these kinds of additions without a major overhaul. This makes for a better user experience as dramatic changes in a sites layout and design can cause confusion and frustration. Far better that a sites look and feel evolves through a series of small changes that the user has time to assimilate.
Conclusions
There are obvious benefits to evolving a site over time rather than undertaking sporadic redesigns. However, it is important to remember that the foundations need to be in place before you can successfully follow this approach. It will be hard to evolve a site that has not been built with this approach in mind. Ensuring content, design, and functionality are all maintained separately is key to the success of a constantly evolving website. Without those the overheads of evolving your site will be too high.
I often find myself working along side traditional marketing agencies when developing websites. However, today is the first time that I have seen a client’s website suffer because of it.
I like to think Headscape are a talented bunch. Certainly based on the feedback from our clients we do a reasonable job. However, for the first time ever we have come across a client who we seem incapable of pleasing.
Currently we are working on a project where we have produced three separate designs for the client. We have gone through endless iterations and have really tried to take onboard their comments. I can honestly say that the design work we have produced for them is some of the best we have done. However, despite all of that we have failed. We have failed to find something the client likes.
Although we still have a good working relationship with the client, they have decided to get their marketing agency to do the design work for the site. Today I got my first look at what they have produced and frankly, my heart sank.
Print designers failings
Okay, we all know that design is subjective. Just because I visually don’t like the design a lot, doesn’t mean it is actually bad. However, it does suffer from some of the classic problems associated with a print agency producing screen based design. Here are a few of the issues I have spotted:
Resolution
One of the most common mistakes made by print agencies working on web design is that they take no account of screen resolution. The design proposed by this agency would involve sideward scrolling at 800 by 600. Not a problem you face with a nice printed brochure!
Colour palette
Colours that work well in print just don’t always work on screen. Reading online is bad enough anyway without choosing colours that buzz or just break up at low resolutions.
Accessibility
Accessibility isn’t something that is often considered in print material but is vitally important on the web. Forms without submit buttons, designs that can only be built with JavaScript and form fields that don’t look like form fields are just a few of the mistakes often made by print designers.
Technological constraints
Print designers just don’t have a grasp of the technological constraints on the web. The limited number of fonts, the layout restrictions of content management systems, the quirks of different browsers (in rendering HTML & CSS), the list could go on. Understanding your medium is vital to creating a successful design.
Usability
Probably the biggest failing of print designers who work on websites is their failure to understand how users interact with websites. Print designers often just try and replicate a brochure online. They don’t take into account that users don’t like to read big blocks of text, or hate to scroll. They don’t grasp that web users skim read pages trying to quickly find key content. The result is that you see designs that use multiple columns of text with little to break it up into blocks.
For me using columns of text, such as you would find in a printed publication, is the ultimate print designer’s failing. Not only is it hard to scan but also involves constant scrolling up and down the page.
Our failings
I would love to be able to post the design here and allow you to compare it to the ones we produced but that would be unfair on the client. The problem is that the client is more used to offline printed material than the web and so they are heavily influenced by what the print agency produces. That’s not the clients fault, that is a failing on our part to educate the client about the realities of web design.
So what about you? Have you come across similar problems? Are their other common mistakes I have missed? Add your comments.
So should you always build sites using web standards? Should tables really only be used for tabular data? Is it CSS at all costs?
I received an email today from a web designer called Keir with a question for the podcast. It is a question I have heard many times before, but because of work I am currently doing for Headscape, I have had to think twice about the answer.
Here is what Keir wrote:
Why would I want to design using CSS considering the amount of work that has to go into building a CSS site that is compatible with all major browsers, using hacks and work arounds when I could build one straight forward design through tables in a fraction of the time that would look practically identical in all browsers (aside from the ease of updating design?)
Actually taking time to think about the answer
Under normal circumstances, I would have just referred Keir to the article I wrote on the benefits of web standards, but today was different. Today I was building a disposable wireframe for usability testing, which for the sake of speed was being produced using tables for layout. Today, I have also been thinking about Headscape’s business strategy and the impact of web standards on some aspects of our productivity.
Not all approaches suit everybody
Sure, web standards have a huge list of benefits but is it always the right solution for every web design agency? Possibly not. Let’s live in the real world here, building table based sites is quicker for small, flat sites that rarely (if ever) change. Okay, you might have headaches later on but for some web design companies that is not an issue. Take for example a small web design company that is building cheap, flat sites for estate agents. Estate agents are not willing to pay more than a few hundred pounds for their site and care little about accessibility, or future proofing. All they care is whether it looks okay in Internet Explorer. Now, the web design company has a choice. They can do one of the following:
Explain to the client the benefits of web standards and why they should pay more for their site to be built properly
Take the risk of running at a loss and build the site with web standards anyway while still keeping the price low.
Churn the site out, tables and all, using a WYSIWYG like Dreamweaver
Commercial reality matters
I am sure some of the web standards evangelist would argue that the web design company should take the first option. I would suggest that in the real world of commercial design this would be a mistake. Not only would they probably loose the work but also even if they did win it I am not convinced that the estate agent would really feel the benefit. After all, will it help to sell more houses? Possibly, but I doubt it would generate a big enough return on investment to justify the extra expenditure.
So what am I saying?
I am not suggesting that if you are a small web design agency (or freelancer) who works on small websites, you should not bother with web standards. What I am saying is that you have to be pragmatic and that you can introduce some elements of web standards while leaving others aside. For example, probably the majority of delays with web standards come from positioning. Having to use floats and absolute/relative positioning can sometimes prove a lot trickier than simply adding the odd table.
Mix and match
Maybe for some it is simply easier to use tables for the basic layout and then use web standards for things like fonts, colours and design details. This does not have to be an either or decision. The transition from odd school design to web standards can be a gradual process and you can judge how far down the web standards root you go on a per project basis. Like all aspects of web design, the use of web standards has to be a compromise and it should be used as and when appropriate. However, remember, you cannot choose when you use web standards if you have never taken the time to learn it. Web standards should be another tool in your tool belt that you choose to use when appropriate.
For more on getting the balance right between business drivers and technical considerations read "the missing pillar of web design"
As you have probably gathered by now I am in the process of redesigning the new Headscape website. As part of it a lot of thought has been given to our approach to accessibility. This is what we have come up with.
We really wanted to demonstrate through our web presence that a site could be both visually appealing and accessible.
We wanted to show that flash could be used on a site without making it inaccessible. We wanted to show that a content management system could ensure a site remains accessible even when used by people with no coding knowledge. Finally, we wanted to make the world a happier, more loving place!
Did we achieve all of this, probably not!
The trouble is that most web designers agree web accessibility is important but few can agree on the best way of making a site accessible. That is mainly because it is still an evolving area and new ways to improve accessibility are being found all the time. As of now, we believe that the techniques used on this site are some of the best but no doubt, this will be out of date in a matter of weeks!
So what is the approach we have adopted?
Flash
A quick word on flash before we move on to things that are more important. Some hard line accessibility zealots will no doubt disapprove of our use of flash on this site. However, we believe that if used correctly flash and accessibility can sit comfortably side by side. Whenever we have used flash we have ensure it is accompanied by a clearly marked description and alternative ways of accessing the same information it provides.
WAI guidelines
If you are bothering to read this page, you have probably already heard of the WAI guidelines which layout three levels of accessibility. This site has been designed to be level three compliant (the highest level), with one notable exception.
Use relative rather than absolute units in markup language attribute values and stylesheet property values.
In short, this means that everything should be scalable. That includes fonts and layout. Although in our default style, we have made the body text scalable, the rest of the interface is not. It was our feeling that, after experimenting with both scalable and elastic sites, complying with this checkpoint would undermine the design. This would jeopardise our first objective, which was to show sites could be both accessible AND visually appealing. Obviously, this decision is a subjective one, but it should not be interpreted as a lack of commitment to people with a visual impairment and who require the ability to resize text. We have just chosen to solve the problem in another way (see below).
Low vision version
Because we have largely conformed with the WAI guidelines and built the site using web standards we are hopefully that users of speech browsers will not encounter any serious problems. Of course, you can make no guarantees as speech browser have more options than you can shake a stick at, and it is possible one of these will screw up the site.
However, there is a much larger group of visually impaired people, which do not use speech browsers, but do require an enhanced interface. One option is to make all the fonts on your site resizable as explained above, but this fails to tackle some of the other issues faced by visually impaired users. We have therefore introduced a low vision style for the site that is designed specifically to meet these users’ needs without compromising the default user interface.
No doubt some of you reading this page are thinking; "but hang on, doesn’t this fly in the face of RNIB policy on web accessibility?" This refers to a statement on the RNIB site that says:
At RNIB, we recommend against providing a text only version as much as possible, simply because being treated differently can reinforce the feeling of marginalisation that someone with a disability experiences.
However, we are not talking about a separate text only version of the site that quickly becomes out of date because it is poorly maintained. What we have done is create a secondary interface to the same content designed specifically for a visually impaired audience. They are accessing exactly the same content, simply displayed in a way that suits them.
Using web standards, many web designers have become a lot better at ensuring their sites are readable by speech browsers but what about the much larger audience that have some limited vision.
Feeling smug about accessibility
As I continue to work on the redesign of the Headscape website, it would be easy for me to become rather complacent about accessibility. After all, I have separated content from design ensuring the site degrades nicely on older browsers and works well for most speech browsers. I have even ensured all my XHTML is valid and the code passes a bobby check. What more could be asked of me?
The trouble with accessibility
The trouble is accessibility is about more than fulfilling a series of checkpoints or building to a certain set of standards. Sometimes things are more complex than that and sometimes there are no clear answers at all.
Low vision users
Take for example low vision users. Unlike speech browser users it is not enough to create clean code which their browsers can easily read (although even that has a whole bunch of issues I will not bore you with here). Low vision users have a number of requirements that need to be specifically catered for. For example:
They require a simplified interface free of anything but the most essential navigational elements.
They need a single column layout as content can be pushed off screen at large font size.
It is imperative the user can scale the font to any size without the design breaking.
So what are the options?
Remove the site sheet
The quickest and easiest option would be to allow the user to strip out all the styling of the site and see the raw content. It would not look very pretty but at least they would be able to scales it or even change the colours using their browser settings.
The downside of this approach is that this goes no way to meeting the first of our three criteria listed above because it just shows everything to the user.
Make the site scalable
Another option is to make the site scalable. This means that the interface adapts to compensate for increases in font size. However even the best scalable site is going to be hard pushed to accommodate some of the font sizes visually impaired users require. One option is to make the site elastic which means the whole interface magnifies with the text. The downside of this approach is that it can push elements off screen and as a result low vision users often fail to see them.
Of course using a single design approach to fit all also has an impact on the visual styling of the site as well as the usability. For example, a user who does not have a visual impairment is going to find a single column design frustrating and unattractive. It smacks of designing for the lowest common denominator where nobody wins.
Alternative stylesheet
The third option and my current favourite, is to create an alternative stylesheet for visually impaired users. Because we have separated content from design, it is easy to create a new style that can accommodate all of a visually impaired users requirements without compromising the standard design.
In some ways this feels like going full circle back to the days were we used an alternative accessible version. This approach was generally frowned upon especially by organisations such as the RNIB because these accessible sites often had less content and were poorly maintained. There was a feeling that disabled users were being treated as second class citizens.
The zoom layout is not like a ghettoized text-only page. It remains as fresh and updated as the regular page because the content is the same. All that has changed is the style sheet.
I tried to speak to the RNIB about this issue, but unfortunately despite assurances they would respond, have heard nothing. However, I then discussed it with Robin Christopherson at AbilityNet who specialise in assistive technology and he agreed that alternative stylesheets was the best option currently available:
If done properly they can radically alter the experience for different groups. This is quite different from ‘ghetoising’ groups by offering them an alternative site with, in most cases, less content or functionality (your ‘Text only’ link). It’s this that we and the RNIB object to.
The problems
Unfortunately, at the moment even this approach is not without its problem. The biggest and most obvious of which is the fact that when a user arrives at your site they have to first find the accessible version. This can be incredibly challenging and there is no simple solution. Obviously, a prominent link will help but at the sizes some visually impaired users would require this will totally dominate the design.
I am currently working on a JavaScript approach that would detect the font sizes specified in the users browser and change style if they are not the default setting. Of course not every person who happens not to be using the default settings are visually impaired and anyway there are significant browser compatibility issues to overcome.
The ideal world
In an ideal world there would be a way of telling the browser that a zoomed version is available. The user could then configure the browser to use this alternative version if it is found. Although there is some talk about making this happen it is still a long way from being a reality. In the meantime we might have to accept there is no ideal solution and endeavour to find a happy medium that provides the best possible to all users.
So what’s your approach?
So how does your site cater for low vision users? Do you do anything at all? I would love to hear how other people tackle the issue.
Further reading
If you want to know more about creating alternative low vision versions of your site I would highly recommend these two pages:
Today sees the launch of the Countryside Agency’s flagship website about the network of National Trails. This site is the culmination of month’s worth of work by the team at Headscape and I thought I would share with you a few of the highlights and lowlights of the project.
The brief
It was a challenging brief. Take twelve separate trail web sites and unify them under a common brand while still maintaining some sense of individuality. In addition to this, we had to conform to basic levels of accessibility, integrate a content management system that allowed individual trail officers to manage their own sites and come up with a user-friendly way of accessing a large database of accommodation and services.
Problems of interface
For me personally the number one problem to solve was the inconsistent user experience across these multiple trail sites. Users were faced with inconsistent positioning of navigation, different information architectures and conflicting terminology. The only sensible solution was to standardise the interface across all sites. Not only would this solve the user experience problems it would avoid the overwhelming challenge of having to come up with designs for twelve different sites!
Of course, there were two downsides to this approach:
This did not solve the briefs demand for a sense of individually on each site
It made it harder for the user to instantly tell which trail they were on
The solution was to give each site its own unique colour scheme. By doing this, you could associate very different feels with each site while also giving the user clear visual clues when they moved between different trails.
Web standards, the cornerstone of this project
Once I had decided upon on the approach it became obvious that a web standards approach would rapidly accelerate the development cycle. By separating content from design, I could create one basic layout and use cascading style sheets to change the colour palette of each site.
Web standards brought other benefits too. By separating design from content, we could easily address the need to conform to single ‘A’ compliancy in regards to accessibility. What is more we could easily supply an alternative printable style that ensured the site only printed certain page elements. I felt this was particularly important, as much of the information on the site would actually be useful to visitors while physically visiting the trail.
Finally, web standards allow us the ability to continually tweak and refine the design through the life cycle of the project and indeed after launch. This enables us to be much more responsive to feedback and work out any user interface bugs that might be spotted along the way.
The lowlights
I have to confess that normally I get to the end of the project like this hating the site because I have just worked with it too long. However, in the case of this site I do not feel that way. Of course that is not to say there aren’t a few things that still annoy me about it.
One of the biggest problems we have yet to overcome (although we are looking into some options) is the WYSIWYG editor we are using in the content management system. We seem unable to find an appropriate editor that produces clean code, which does not invalidate the occasional page. What is more there does not seem to be an editor on the market that forces the user into ensuring any content they add is accessible.
Another annoyance for me is that I have been forced to use some table layout on the homepage. This does not in anyway cause problems it is just a matter of principle on my part.
A crowning glory
Despite the odd annoyance listed above and a few hundred little bits and pieces, I am actually incredibly pleased with how this site has turned out. It truly is a crowning glory for Headscape and easily the best piece of work we have done to date (in my opinion). The size and complexity of the site as much as anything else makes it an incredible achievement. I have particular respect for Charlie Allen the project manager on the site who has dealt with 12 individual clients, and been responsible for the population of over 75000 web pages worth of content.
Another feature I particularly like are the flash maps created by Chris Sanderson one of our team of designers. He has come up with a brilliant way of giving people access to a large database of accommodation and services while also giving them a sense of the route the trail takes. This is an excellent example of how flash should be used rather than for nasty animated introduction with no skip button! Of course, in order to maintain accessibility we also had to provide a way of accessing the same information without flash.
Not that this is the end of our work with the National Trails site. There is always more to be done. The site will need tweaking and maintaining. There is site promotion to consider as well as new functionality to consider. Just because a site goes live does not mean it is ever truly finished.
The clients verdict
I couldn’t finish this entry without including a quote from an email I have just received from the client at National Trails:
I just wanted to give you my personal thanks for all your hard work on this site. I think its fabulous. I’m so proud of it and of the fact that we made the right choice of contractors to do the work!
Here is my controversial point for the day. A point I am not sure if I agree with or not: It is impossible to conform to anything but the most basic level of accessibility if you are using tables to control layout.
As anybody who reads this blog regularly already knows, there are two basic approaches to building a web site:
The traditionally used, table based design approach
The officially approved, web standards methodology
Tables based design
Tables based design uses tables to slice up a design into grids and then reassemble it like a jigsaw. Unfortunately, the vast majority of web designers still use this method to construct web pages even though it is unnecessary and highly inefficient.
Web standards
The web standards approach involves separating content from design. Content is held in your (X)HTML page while the layout and presentation is held in a file called a cascading style sheet (CSS).
Short guide to accessibility
Especially here, in the UK the W3C guidelines on web site accessibility (WAI) are the defining standard in web accessibility. These guidelines are broken into three levels:
Priority One – All sites must conform to this level
Priority Two – All sites should conform to this level
Priority Three – All site can conform to this level
The controversial bit
Checkpoint 3.3, which is a priority two issue states:
Use style sheets to control layout and presentation.
In short, this is saying that you cannot use tables to control layout. This checkpoint may well demonstrate that the W3C does not live in the real world where many web designers only know how to design using tables, but nevertheless there seems to be no getting around what the checkpoint says.
I would be interested in other people’s interpretation of this guideline. Am I missing something here?
One of my clients recently requested a redesign of their web site so they could move from a fixed width site to a liquid layout. As we discussed the issue, I came to realise that the pros and cons of each were not obvious to all so I thought it was worth laying them out here.
Definitions
Traditionally there have been two basic layouts for the web: fixed or liquid. A fixed design is one that has a specific width and does not scale to fit the browser window. Fixed width sites can be aligned to the left, centred or occasionally aligned to the right.
A liquid design (also referred to as a fluid or dynamic design) fills the entire browser window by using percentages rather than pixel values to define the width.
To complicate things still further you also get a hybrid approach that uses both fixed and liquid elements. Take for example a three-column layout where the left and right columns might have a fixed width while the central column scales to fill the intervening space. This central column would expand and contract as you resize the browser, or when viewed at different screen resolution.
Pros and Cons
Each approach has its own benefits and drawbacks. As with many things in life, the trend for different approaches has changed over the years. Personally, my preference has always been towards fixed width design but it liquid design has many benefits too.
Liquid layout
One of the main advantages I perceive in liquid design is one of accessibility. Liquid design adapts better to whatever screen resolution or device a user happens to be working with (within limits). It makes use of the entire browser window and so maximises the amount of content being shown on screen at any one time. A consequence of this is that you do not have empty space like that found on fixed width sites, especially when viewed at higher resolution.
Liquid layout does have its downsides. Unlike fixed width design, you lose control over line length, flow and placement of page items. Line length in particular can create serious legibility problems at high resolutions when the eye scans back and forth repeatedly. In addition, the loss of control over layout means that it is very hard to lead the user visually to the content you wish them to focus on.
Fixed design
In contrast, a fixed design gives the designer significantly more control, in that he or she has fixed space to work with. Text line lengths are easy to control as are the placement of text and images.
On the downside, fixed design does tend to leave empty space either side of the design especially at higher resolution. This can give the impression the design is floating on the screen or that it appears dwarfed by the browser window.
Hybrid approach
In many cases, a hybrid approach works best. This is where the majority of the design is actually fixed but the design visually tricks the user into thinking that it fills the whole screen by having background elements scale. Take for example the page you are reading now. Although there is a fixed reading area, the blue fade in the background helps to give the illusion that the design scales.
So there you are. Pay your money and take your choice. Both approaches have clear advantages, both have obvious drawbacks. I will leave it to you to decide.
I am currently working with our lead developer at Headscape to streamline the process of building and deploying content managed web sites. Part of this process revolves around seperating out the different aspects of a sites development to make it easier for multiple people to work on the site at the same time and to standardise some elements which had previously been bespoke to individual projects.
Current working process
Normally a web project runs something like this:
Establish initial design concepts
Work on the Information architecture
Create the site templates (XHTML) and style (CSS) for the site based on the designs and information architecture
Populate the site with content
Make the site live
Obviously this is hugely over simplified but you get the idea. However the problem with this approach is two fold:
It is a fairly linear process which involves each phase being dependant on the previous steps being completed
The site templates (XHTML) and style (CSS) have to be made bespoke each time to fit the project
A new working process
The process we are moving to helps to solve both of these problem areas. By seperating not only the presentation from the content but also the content from the structure you can start to standardise even more of the process. Let me explain:
Standardising the structure
As all the content is held in the content management system there is no need for the site templates (XHTML) to be bespoke for every project. These site templates no longer contain content but rather only define the structure of the site. After all the majority of sites contain the same basic structural content such as navigation bars, content areas and the like. By consistantly naming these areas you can then just use style sheets to change the way this structure is presented.
This approach means that instead of having to build the site templates and styles from scratch each time, you can have a basic predefined template which are then tweak accordingly. Obviously some changes will need to be made. The style in particular would have to be altered quite considerably for each project, nevertheless basic features such as column layouts could be predefined. The site templates would require only minor tweaking on a per project basis to take into account issues such as some clients wanting their news templates categorised by subject while others would want it organised by date.
Working independantly
This approach would also allow a lot more stages of the project to happen independantly. For example the person populating the content can do so even before the design is finalised because they can still navigate the unstyled site and see the content they have entered. The added bonus of this is that the designer can play around with different designs directly on the final structure and content. This means he can see exactly how his designs will work with real content instead of endless blocks of dummy text.
The result
The result of all of this is that an average content managed web site could be produced considerably faster and using less internal resources to do it.
Further reading
If you are interested in knowing more about seperating out the different layers of web design I highly recommend this article on the subject.
In the first of my series on the basics of good web design I tackled how to handle branding. In this article I want to deal with the more subjective issue of colour. How do you choose the right colour palette?
A subjective decision
The biggest problem with choosing the right colour palette is that it is all down to individual taste. Colour is a matter of opinion and there is no right or wrong answer. As a result you will get as many opinions on your colour palette as people you ask.
Differences in colour
Part of the problem is that we all perceive colour in slightly different ways. Also roughly 1 in 20 people have some form of colour vision deficiency.
However that is just the beginning. In addition to the differences that exist between people in the way we perceive colour, there is also differences in the way our computers show colour.
There are a whole range of factors which affect the way our computers display colour. These include:
Monitor type
Monitor brightness and contrast settings
Graphics card used
Operating system being used
Colour depth
Gamma settings
Colour theory
Because the choice of colour is so subjective and because you cannot guarantee exactly how a colour is going to be finally displayed to the end user it is important to remove the choice of palette from the realms of personal opinion. One way to do this is to use colour theory.
A lot of research has been done in how users respond to colour and what emotional connections they make. We all know the basics like red means danger or blue is cold. However this area of research has gone much further.
An excellent book on the subject is Shigenobu Kobayashi’s book Color Image Scale. This book provides over 1000 colour palettes organised by mood, taste and lifestyle. What this book allows you to do is look up a concept such as "Urban" and find an appropriate colour palette.
I know that many people are skeptical of books like this but I believe they have real value. Kobayashi’s book was based on research done over 3 years involving analysing responses to colour from a large sample audience. Surely this is preferable to a few individuals debating the subject based on personal preference.
Corporate colours
Of course in many situations you don’t have the luxury of starting with a blank palette. Often you will be required to work with an existing corporate colour such as IBM blue. In these cases it is a matter of finding complimentary colours that work well with your corporate colour.
Again, in order to avoid descending into the world of personal opinion, I prefer to use colour theory as a base on which to build.
Fortunately there are some excellent tools out there that will help you build a palette based on a single corporate colour.
However by far my favourite is a piece of software called Color Schemer Studio. This brilliant tool allows you to create a variety of colour palettes based on long standing colour theory principles. It also exports them in a variety of formats and provides RGB and HEX values. It even helps you ensure high contrast for the best web site readability.
Conclusions
This article just scratches the surface of an enormous subject but hopefully it provides a few useful tips to get you started on creating effective colour palettes while avoiding the squabbles of personal preference. In my next article in the Design 101 series we will look at structure and layout.
The majority of our clients now run content management systems on their sites but is a CMS really the answer to all our site management woes?
What makes content management systems attractive
It is easy to see why organisations find content management system attractive. So many web sites are full of out of date content, as well as being difficult to edit. A content management system appears to be the ideal solution because it allows anybody within the organisation to update web pages without the need for technical skills. Marketing departments can control the message being projected through their site while overworked IT departments don’t have to deal with a constant stream of changes. In larger organisations it is even possible to decentralise the running of the web site so that responsibility for sections within the site are deligated to individual departments.
The reality
Why is it then that only 27% of organisations using content management systems are not intending to make changes to the way it is used. Using a content management system to run your web site is good in theory but in reality it is not always that straightforward.
Content management is about more than technology
The problem lies in the fact that organisations perceive the implementation of a content management system as an answer in its own right. However a CMS is simply a tool that still requires people to use it correctly in order to maximise its potential. It is how a CMS is used within an organisation that determines it success, not the technology itself. There are three classic mistakes made when it comes to the use of content management systems:
Responsibilities
One of the most common problems is that responsibility for the web site is not clearly defined. It is rarely made clear to those expected to update the web site that this is a key part of their job. It is considered an additional chore that gets pushed to the bottom of the priority list. In many cases the web site is updated no more frequently than before a CMS was implemented simply because people dont have the time and motivation to do it. In my experience the time when CMS works best is when the individuals responsible for the web site have their role as web editor clearly defined in their job decsription and time is cleared in their schedules to allow them to undertake this role.
A single focus
Another common mistake is the lack of any single evangelist. There needs to be a single web master that not only ensures that other individuals contribute to the site when they are meant to, but also ensures that the contributions are consistant in language, style and message. Without this person there is no sense of "whole" in the message being communicated through the site. It will contain different writing styles and in some cases even contridictory content. You need one person that can set a style for the site as well as establish a vision for its future direction and development.
Training
Obviously there is a need to ensure that people know how to use the content management system, but that cannot be the end of the story. Its important to remember that many of those editing the web site might not be doing so on a regular basis. It is therefore important that they receive refresher training periodically to make sure they feel confident using the system. If they lack confidence they will avoid using it and once again content will become out of date.
Also training on the use of the content management system is only the tip of the iceberg. Web site editors need to have an understanding of how to write effective copy for the web. They need to know the basics of good layout and design as well as an understanding of how to structure the web site to ensure it is easy to find information.
Conclusions
So what is the lesson here? I guess it would be to invest as much time and money into the people who will run your web site as into the technology that will drive it. Make sure that there is somebody within your organisation who is a real evanglist for your web site. Somebody with a clear vision of where your site is going and the resources to make it happen.