Advice for CMS users

Posted in Accessibility, Site content on May 23, 2007 by Paul Boag

I have been putting together a document for work that provides some basic advice for people who work with content management systems. It covers things like accessibility and writing for the web.

Introduction

Although content management systems enable anybody to publish content to the web, they do not guarantee the quality of what is published. Many content managed websites are hard to use, inaccessible and poorly structured not because of any failure in the design or technology but simply because the quality of content is poor.

This document aims to introduce the reader to good practice for generating web content. In particular it focuses on advice about writing for the web and ensuring that what is produced is accessible to the widest audience possible.

Writing for the web

Writing great web content is a particular skill. Although it shares some characteristics with writing for other medium, there are many unique elements too.

Two traits make writing for the web, particularly challenging. Firstly is the perception that most people have that computers are being cold and impersonal. Many see technology as the enemy and so a good copywriter has to work hard to ensure their copy has a friendly and approachable tone.

Second is the fact that users rarely read pages in their entirety, but rather scan read. The emphasis is on looking for the next link that will take them one step closer to their goal.

Below we investigate these two challenges in more depth and suggest some possible solutions.

Writing style

Well-written copy should be both engaging and accessible. In other words it should overcome people’s inherent suspicion of technology and ensure that, as wide an audience as possible understand what is written.

Engaging with the user

Computers are immensely unfriendly. This is mainly due to their total inability to interpret or communicate the more subtle forms of human communication such as body language and tone of voice.

The result is that most people find interacting with a computer a cold and frustrating experience. However, there are techniques you can use to avoid the problem. These include:

Using a personal tone

By ensuring that your copy is friendly, informal and approachable, you help to counteract the inherent lack of personality associated with computers and the web. Even on a relatively formal site add more informality than you normally would in order to offset the users default perception.

Writing how you speak

If you are experienced in writing more formal offline documentation, writing in a more informal manner can be difficult. Although there is no one catchall solution to this, writing as you speak will certainly aid comprehension and generate a more informal feel.

Avoid being patronizing

The danger of writing in a more informal tone is that you overcompensate and your writing style becomes ‘chummy’ and patronizing. The writing as you speak rule comes in useful here. Picture your audience and ask yourself whether you would speak to them like that in a face-to-face meeting.

Making your copy clear

The W3C accessibility guidelines clearly state:

Use the clearest and simplest language appropriate for a site’s content.

In other words ensure that your reader can understand what you have written.

Many people make huge assumptions about what their audience understands and careful consideration needs to be put into this subject. Particular assumptions are made in regards to:

Jargon

A common pitfall is the use of abbreviations and acronyms within web copy. The assumption is that your target audience will already be aware of the jargon used. However, this is an entirely false assumption.

You cannot always assume that your audience will be aware of every acronym around. For example there are so many acronyms within web design that it would be impossible for one individual to know them all.

Secondly, the reader maybe relative new to your target audience and so still learning much of the ‘lingo’.

When writing copy ensure that whenever possible jargon is avoided and where that is not possible that it is accompanied by an explanation. We discuss acronyms and abbreviations further in the accessibility section.

Reading level

There are reasons why tabloid newspapers like the Sun sell so well. One of those reasons is because they require such a low reading level. As many as 40% of the population have a low literacy level and yet little consideration is given to their accessibility needs.

Even when writing for a well-educated audience you cannot make assumptions about their reading level. Many people suffer from attention deficit disorder, dyslexia or other conditions that could affect their ability to process what you have written.

Below is some advice on how you might go about improving comprehension of your copy:

Simplify punctuation – People suffering from a low literacy levels struggle with long sentences that include a lot of complex punctuation. Keep your sentences short and your punctuation simple.
Be consistent – There is often a desire when writing copy to vary your language to prevent a document appearing repetitive. Although this has its place it does make copy harder to comprehend. Where possible, use terms in a consistent manner across the whole site.
Use numbers not words – By simply referring to 1223 instead of ‘one thousand two hundred and twenty three’ you increase comprehension dramatically as well as shorten sentences and aid scanability.
Specify clear actions – If you wish a user to complete an action (for example to click on a button) clearly specify this. Do not assume the user will instinctively understand what is required of them.
Use imagery – The saying ‘an image speaks a thousand words’ is very true for low literacy users. If an image will help to convey the meaning of a page be sure to use it to support existing copy.

Although the techniques above are of particular benefit to low literacy users, they do actually offer benefits to all users. Ease to comprehend copy aids the speed at which information can be digested and helps users scan copy as we are going to look at next.

Making web pages easy to scan

It can be a depressing realization that users will probably not read your carefully crafted text. However, the sooner you accept this reality the sooner you can start to adapt copy to aid users in their hunt for information.

There are a number of techniques that can be used to help a user quickly scan through a page and identify the information they require:

Front loading

Front loading applies in two different contexts. Firstly, front-load the page by including a summary of the entire page right at the beginning of the document. This helps the user ascertain quickly whether the page is relevant to them or not. Secondly, front-load each individual paragraph so that the main point is first. Ideally a paragraph should only make a single point (see 2.2.2) but if it is longer then the user can get the gist by reading the first sentence.

Keep it short

Usability expert, Steve Krug recommends in his book “Don’t Make Me Think!: A Common Sense Approach to Web Usability” that a copywriter should take his copy, edit it down to half its original length and then half it again. This sounds like an impossible task but it is often easier than it appears. By removing repetition, marketing speak, and ‘happy talk’ (content with no real substance like ‘welcome to this site’) you will quickly find your content substantially reduced.

Keep paragraphs short

As well as keeping the page as a whole sort, you should ensure individual paragraphs are short too. Each paragraph should make a single point as this aids both user scanning and comprehension.

Keep sentences short

At a micro level you should also endeavor to keep each individual sentence as short as possible. Again this aids scanability and comprehension but also helps to remove any unnecessary ‘waffle’.

Break your copy up

As well as breaking up copy into short sentences and paragraphs you can also aid scanability by using other techniques as well. Look at each paragraph and ask yourself the following:

Can I associate a heading or sub heading with this block of text?
Could this paragraph be reduced to an easy to scan bullet point list?
Is there a key message in this paragraph that users need to instantly see?

If the answer to the last question is yes, then you might wish to use a breakout box (also known as a pull out). This is a technique originally introduced in magazines to ‘hook the user’. They would take a key line from an article and highlight it in someway (usually in a separate box) to draw the reader into reading the rest of the article. The same technique can be used on a web page to draw a users attention to a key point that they maybe searching for.

Many good content management systems (including Headscape’s own CMS) provide this functionality.

Accessibility

We have already touched on the importance of accessibility when talking about writing clear copy, however accessibility extends beyond simply the copy you write.

As a content management system user, you are required to go beyond just writing the copy. You are also required to enter the copy into the system so that it can be displayed on the site. This requires you to ‘markup’ your copy correctly.

The importance of markup

So what exactly is markup? Markup is the method by which you tell the browser what the content you are entering is, so that the browser knows how to display it to the user. This markup is usually written as HTML.

So, if for example you want to tell the browser that something is a heading you would mark it up like this:

<h1>This is a heading</h1>

or a paragraph would be marked up like this:

<p>This is a paragraph of text</p>

Of course, one of the main attractions of most content management systems is that you don’t have to know how to write HTML. Instead the content management system will add the code for you.

Historically content management systems didn’t even try to understand what any individual piece of content was. Instead they let you as the content management user, style the content to look however you wanted. So instead of telling the system that this is a heading you simply made it look big and bold so users of the site would know.

Although this sounds like a good approach in principle, it actually opens up a whole load of problems that are too extensive to cover here.

More modern content management systems, such as the ones deployed by Headscape, ask the user to explain what each piece of content is so that the system can add the proper HTML code.

The way the content management user does this is normally through a drop down menu of styles much like you find in Microsoft word. You simply select a block of text and choose the style which best describes that text.

Marking up content in this way brings a whole host of advantages including (but not limited to):

The ability to redesign how an individual style looks universally across the entire site without editing each page.
The ability to change the appearance of styles based on what device is accessing the content (for example a mobile device style).
The ability for screen readers and other assistive technologies to understand the site.

In short, a well marked up piece of content will be available to a much larger audience and is easier to change and adapt.

Text alternatives

Well marked up content is not the only way to improve the accessibility of your site. Another is to provide text alternatives for elements that some users will not be able to access.

The most common example of this is with the inclusion of images into your pages.

There are a number of reasons why a user may not be able to see the images on a page. These could range from viewing the page via a mobile device to the user suffering from some form of visual impairment. However, whatever the reason the solution is the same; add alternative text that describes the image.

Alternative text is only visible to users who cannot see the image and so does not impact the design in anyway. The method of adding alternative text will vary between content management systems but in most cases (including on the Headscape system) you will be asked to add some text when you try and insert an image. A good system will go as far as requiring alternative text before approving an image for insertion.

A common mistake that is made with alternative text is to use it as a caption for the image rather than a description of the image. The difference is subtle but important. An image of Marcus Lillington our sales director might read ‘Marcus Lillington is more than happy to speak to you about your requirements’. This would be a caption rather than alternative text. Alternative text should describe the image and nothing more. So in the case of our example it should read simply; ‘Photograph of Marcus Lillington – sales director’.

Finally it is worth saying that the principle of alternative text does not apply just to images. It should apply to any screen element that can only be understood visually. That includes Flash, video, audio or other plugin.

Meaningful links

Another common accessibility mistake is with link text. When a content management user creates a link between pages it is not uncommon to see links with phrases like ‘click here’ or ‘read more’. This presents a problem for two reasons:

Firstly, users who access the web using screen readers often have all links on a page read back as a list in order to save listening to every piece of text when all they want to do is find the next link. A link like ‘click here’ means nothing when read out of context.

Secondly, many users will scan a page looking specifically at the links. They don’t read the text before or after the link so again they see it out of context. The result is that, like screen reader users, terms like ‘read more’ mean nothing.

This problem is easily avoided by ensuring that all links make sense out of context. So instead of linking the words ‘click here’ in the sentence ‘click here for more news’ you simply link to the phase ‘more news’ or ‘news archive’.

Acronyms and abbreviations

Earlier we talked about how where possible jargon, acronyms and abbreviations should be avoided. However there are occasions where that is not possible.

In such situations your choices are very much dictated by the functionality provided by the CMS you are using. Unfortunately, many content management systems are not particularly helpful in this regard and you maybe limited to typing out a description in brackets each time.

However, more modern content management systems such as that provided by Headscape, allow you to select an abbreviation style. You can then enter the full description and this becomes available to the user without destroying the flow of your text.

This is achieved in a variety of ways but the most common is using a dotted underline. If a piece of text has been marked up as an acronym or abbreviation it will appear to the end user as text with a dotted underline. When the user moves her cursor over the text the cursor changes to a help symbol and displays the full description as a tooltip.

This provides a full description to users encountering a piece of jargon for the first time, without getting in the way of those who already know what it means.

Using tables correctly

Web design has changed a lot over the last few years and so have content management systems. One of the most significant changes has been a move away from table-based layout.

Table-based layout is a technique that uses tables to position content on a page. However this is an abuse of the table feature in HTML and can cause significant accessibility problems especially for users running on older PCs or using mobile devices.

We therefore strongly recommend that using tables for layout is avoided at all costs. Instead clearly markup the content using the descriptive styles provided. The system will do the formatting and positioning.

That said there is still a place for tables. Tables were originally intended for tabular data (data made up of columns and rows, like that found in a spreadsheet). If you have information like this you wish to include on a page, then this is when you should use a table.

Working with imagery

Although we have already spoken about imagery in the context of alternative text it is worth noting that there are other accessibility issues relating to imagery you should be aware of:

Animation

Animation can be a problem area if not handled correctly, so generally speaking it is better to avoid the use of animated imagery unless it helps explain the content in someway.

The main reason that animation can be problematic is because certain forms of cognitive disability can be made worse by flashing animation. It can prove distracting and make it harder to process the content being read.

If animation is to be used we recommend:

That the user is given the ability to disable the animation
That the animation is not too rapid so that it proves less distracting

Colour

Finally, it is worth noting that a considerable proportion of your users will suffer from some form of colour blindness. For example almost 1 in 10 men are colour blind. In addition it is possible that other users will be accessing your site through black and white monitors on mobile devices. It is therefore important to ensure that any imagery you use is not reliant on colour to communicate information and that there is sufficient contrast between foreground and background colours.

These two issues are addressed in the W3C guidelines on accessibility:

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.

2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.

Further information

Hopefully this document has been useful in outlining some of the basics of writing content for a website. However, we have obviously only been able to scratch the surface.

If you would like further information, please do not hesitate to contact Paul Boag (the author of this document) using [email protected].

Getting things done… in web design

Posted in Reviews, Web strategy on May 9, 2007 by Paul Boag

I have just finished reading “Getting Things Done” by David Allen. Not only has it seriously helped me to get control of my workload but its also made me rethink how I approach web design projects.

If you haven’t read “Getting Things Done”(GTD) then I would highly recommend you do so. I know not everybody likes it or implements it, but it definitely gets you thinking about your workflow and processes.

For me personally I have found it an invaluable tool that has enabled me to feel a lot more in control of my life and pack even more into my average day. However, the real reason I am talking about it here is because I believe some of the principles it lays out applies very well to web design.

There is one point in the book when David talks about how to handle new projects you are considering undertaking and in particular a series of steps you should complete. These steps are very generic and can be applied to pretty much any project, including the development of a website.

Step 1: Ask the Question, why?

Why do you need a website? – What is its function, what need does it fulfill?
Why will users choose to visit it? Why will they stay at the site once they visit it?
Why will users choose you over your competition?
Why are you considering redesigning your site?
Why are you considering outsourcing the design work instead of using your in house team?

The list of “why” questions could go on and on. The basic principle is to challenge your assumptions and get you thinking in detail about your motivation. Don’t just flick through vague answers in your head. Rather, record these answers in a format that you can refer back to later, in order to make sure you are on track.

As David Allen says; asking the question why helps define your success criteria, it motivates you, and focuses your projects. In short it is worth asking this basic question before getting too far down the track.

Step 2: Setting your underlying principles

Another interesting question that GTD recommends you ask is; “what are your underlying principles for this project”. In other words, what are the things about this project that you are not willing to compromise over, that are set in stone? This can be a hard question to answer and so David recommends completing the following sentence:

I would be willing to give others totally free rein to do this [website] as long as they…

This sentence is particularly relevant in web design projects when a lot of the work can often be completed by an outside agency rather than the website owner.

In many ways this is not dissimilar to the website constitution proposed by Bruce Lawson.

Step 3: Establishing your vision

David argues in his book that our subconscious is exceptionally good at working out how to achieve an aim. However in order for it to do that you need a clear vision of what it is that you are trying to achieve.

As you have probably already guessed I am no psychologist (!), however the principle of having a clear vision of what your website will finally look like seems extremely sensible to me. I have worked on too many projects where the client (and in some cases the designer) had more of a wish list of disjointed functionality rather than a picture of the final user experience.

Having a clear picture in your mind about the final objective will help everyone have a better sense about how to work towards that goal and what methods to use to achieve it.

Step 4: Brainstorming

The final step David talks about in this section of his book is something I am particularly passionate about; brainstorming. Once you have a picture of the site in your mind, brainstorming can be a marvelous tool for:

Fleshing out that vision
Identifying any potential problem areas
Working out how to best achieve the vision

No idea is too dumb whilst brainstorming. Its important not to censor yourself, but to allow your mind to dig into the problem and add depth to the vision. Only when you have put down literally everything you can think of do you start weeding out the impractical or downright ridiculous and compiling a final list of tasks and functionality.

Too often we jump to the very last part of the process and begin our web design projects by defining lists of functionality and work to be done. I would encourage us all to take a leaf out of GTD and lay proper foundations first.

Show 77: A dream?

Posted in Classic shows on April 30, 2007 by Paul Boag

On this week’s show: Paul talks about how a client’s work is never done, Marcus looks at dealing with scope creep and we review Dreamweaver CS3 (is it really worth upgrading?).

Podcast: Download (20.5MB)

Download this show.

Launch our podcast player

News and events

The web design survey

A List Apart are trying to build up a picture of the web design community by launching their web design survey. In my opinion this is an incredibly valuable project because there is so little statistical data on our profession. We have next to no information on salary levels, job titles, location, type of work done or even educational background. Its a strange situation for what is now a mature industry. Perhaps, as Jeffrey Zeldman suggests, it is largely due to the fact that we work in a hidden profession where the practitioners have meaningless job titles that bear little resemblance to the work we do.

Coding for content

If you listened to the SXSW special we did a while back you may remember me interviewing Garrett Dimon about the recent redesign of his blog. In that interview he talked a lot about his desire to focus on content and that the design should exist only to support that. The results of this effort are truly phenomenal and he has produced one of the most refreshing sites I have seen in ages. It is clean, easy to use and really succeeds in bringing the content to the fore. Well, this week he wrote an article that follows up on previous comments he made about his design approach by talking about how he coded the site. Its a great article and really shows off the fact that an attention to detail and methodical thought process can really generate some amazing results.

Don’t be a hero: Giving up is good

How often have you heard me drone on about return on investment? Well, now you can hear the guys at 37 Signals talk about the same thing but from a slightly different angle. In their post “Don’t be a hero: Giving up is good” they talk about the fact that developers don’t like to be beaten and will continue grappling with a problem long after it ceased to be profitable. The article argues that it is important to know when you cut your loses and drop functionality if it is simply taking too long to implement.

Working with tables and CSS

It’s amazing how many problems you have with tables even after you have moved across to CSS based design. One common problem I see a lot is the data in tables pushing out the tables width which in turn often breaks the design (see an example). Fortunately this week I found a post that seemed to solve the problem. It uses the table-layout property in CSS along with overflow:hidden. Its a useful little technique that is definitely work checking out.

Client corner: A client’s work is never done

In last week’s client corner section I talked about the role of the client and how in many cases it is very poorly defined. This started me thinking in more depth about how clients perceive web projects and how they often fail to grasp the enormity of the undertaking. In this weeks show I explore the ongoing commitment that clients have to make to their websites and look at what exactly they will find themselves doing on a day-to-day basis. As with last week’s client corner, this is a subject I have recently blogged about and so if you want to refresh your memory on what I said in the show check out my blog post on the subject.

Agony uncle: Dealing with scope creep

This week we will be reviewing a question from Bob in Iceland – “How should I deal with clients that keep changing the spec throughout a project?”

I guess the first thing to say is that the spec will change, they always do. Often it is perfectly understandable because people see a new design or piece of functionality and think ‘hey, we could do X or Y as well’.

But… and I have been as guilty of this as anyone… often the scope will creep as the client learns about the web development process as the project goes along. This is avoidable. It can often be seen as pedantic, or possibly even negative, to spell out exactly what a client is getting. For example, design iterations or template styles. Ask yourself when writing the spec – would a layman understand this? If not, then add notes to explain.

So, what to do when the first request outside scope comes in? As with most things, use your brain regarding how to respond!

If it is a 5 minute job then just do it, but make sure that client is aware that it is outside scope so a) you can earn some points with them and b) let them know that you are keeping a tight eye on the scope of the project.

Anything over that, you need to respond in writing (email is fine) stating that the work is outside scope and you estimate it will take X hours to complete… please confirm that you wish us to go ahead with the work. This puts the onus back on the client and makes them think about whether they really do want the work done.

It is good practice to have a change control procedure written into any statement of work. These can sometimes be over the top, demanding contract extensions in writing and the like (which probably is appropriate for a large new piece of work) but usually something like –

As and when issues arise, it is the project manager’s responsibility to raise these with the client and agree any actions to be taken.

If any rescheduling is required, the project manager will be responsible for ensuring that acceptable changes to the schedule are agreed with the client and documented.
The project manager will maintain an issue log and ensure that issues are either closed following discussion with the client or result in an agreed change to the project plan, with associated change documentation including price change where required.

Basically, this is saying ‘use your head’ and make sure you write down whatever is agreed.

Sometimes, however, it is wise to carry out additional work as a gesture of good will. This is usually appropriate if you ‘owe’ the client a ‘favour’ of some sort, for example if you had charged 5 days to produce a design and it took 1 because they signed it off immediately. You don’t necessarily actually owe them anything (assuming a fixed price contract) but they will be aware that you didn’t put in as much effort and probably won’t take a kind view to your charging them for an extra half an hour’s work at the end of the project.

Review: Dreamweaver CS3

I finally got my hands on a copy of Dreamweaver CS3 this week and although I am still taking it all in I thought I would share some of initial thoughts.

I guess the question you want answer is whether it is worth upgrading or not. As normal the answer isn’t black and white. If you are a a strong standards based designer who has worked with things like DOM Scripting or AJAX then this upgrade probably isn’t for you. However if you are still finding your feet with CSS and don’t want to learn Javascript then this upgrade is definitely worth considering.

Obviously Adobe is trying to pursued us that Dreamweaver offers a huge range of reasons to upgrades such as better Photoshop integration and improved browser testing. However, when it comes down to it, I believe it only offers two killer features.

CSS Layout made easy

If you are new to CSS this feature might be useful. It basically allows you to select from a series of CSS layout templates to get you started. Now, this never replaces hand coding it from scratch, however if you are anything like me you find it easier to learn from example and this certainly helps with that.

Spry framework

If you have tried and failed to get your head around DOM Scripting and AJAX then I would suggest you start off by buying “DOM Scripting: Web Design with JavaScript and the Document Object Model” (J. Keith) or “Bulletproof Ajax (Voices That Matter)” (Jeremy Keith). However, if even that fails then you might want to take a look at the Javascript framework now built into Dreamweaver CS3. As with CSS layout I should stress this isn’t as good as hand coding because:

you are stuffed if you want to add or amend functionality not offered from within the framework.
the code is bloated in places meaning it will make the page take longer to download.

However, that said, the functionality offered in Dreamweaver is very impressive. You can achieve all of the following without touching a line of code:

Work with XML datasets (like RSS feeds)
Expand and collapse content areas
Make accordion menus
Validate forms

The code isn’t great but at least from what I have seen it degrades reasonably and isn’t too intrusive.

If you are a confident CSS and DOM Scripting coder then the upgrade offers considerably less. Personally the best thing I saw was the ability to sort my CSS files in a drag and drop approach. Beyond that and copy and paste straight from Photoshop, there really isn’t much to get excited about.

The question is; has Adobe done enough with Dreamweaver CS3 to keep themselves ahead of Microsoft’s Expression Web which reports say is very impressive. Personally the lack of mac support in Expression Web could well be the deciding factor in what otherwise are very equally matched products.

“Adobe Dreamweaver CS3 (PC)” on Amazon

“Microsoft Expression Web (PC)” on Amazon

A client’s work is never done

Posted in Web strategy on April 26, 2007 by Paul Boag

In my last post I talked in very broad terms about responsibilities, but how does that translate into actual tasks that need to be completed?

I recently wrote a post about the role of the client and how poorly defined it is. This started me thinking in more depth about how clients perceive web projects and how they often fail to grasp the enormity of the undertaking. In this post I want to explore the ongoing commitment that clients have to make to their websites.

Building, owning and running a website is a big commitment if you really want the site to succeed. A lot of people have written in the past about the “build it and they will come” mentality, where website owners are under the impression that people will spontaneously find their site with no work on promotion. Equally I believe there is a “build it and it will run” mentality, where clients fail to grasp the amount of work they will have to undertake to make a website successful.

In my last post I talked in very broad terms about responsibilities, but how does that translate into actual tasks that need to be completed? Even if the client has hired a web design agency to build their site, they will still have to commit a lot of time into making it happen. Here are what I perceive as the main tasks that clients need to invest time in:

Defining the scope

The planning stage of a web development project requires significant time and mental commitment from the client. In many cases they are yet to take on a web design agency and even if they have, they will still need to work through the planning stage with that agency.

Before the web design project even begins the client needs to have established:

the business objectives that underpin the project
the success criteria against which the project will be judged
the pros and cons of the existing site (if it exists)
lessons to be learnt from reviewing the competitions websites
a clear understanding of who the target audience is and what they want from the site

All too often these fundamental building blocks are not put in place either because of lack of time or resources internally. However, skimping on these areas can seriously undermine the success of a website.

Driving the build

However, the clients work doesn’t stop when the site starts to be built. If anything the workload now increases. Sure, the web designer is doing the technical and design stuff but that still leaves all the content to be sourced. The website owner is almost always responsible for:

bringing together content from various parts of the organisation
editing the content received to present a consistent tone
ensuring that existing content is written in a form that is suitable for the web
writing the content from scratch where it does not already exist

In addition to responsibilities for content the client is often involved in:

developing the information architecture for the site alongside the agency
signing off templates and designs throughout the development cycle
managing external suppliers such as hosting agencies or third party content providers

Maintaining the momentum

Even once the build is over there is still much for the client to do. Although I believe that the design agency should be working with a client on a continual basis, the reality is that in many situations the client is now left to fend for themselves. This makes the post launch phase particularly burdensome for the client. Often this is added to because the project is considered “over” and they are expected to attend to other responsibilities beyond the website.

However, the post launch stage of a website project is often the most crucial. It is now that the client should be:

looking at ways to promote the site
building up a community of regular site visitors
keeping content fresh and up-to-date
planning for the future of the site

Without that ongoing attention the site will quickly stagnate and die. As I have said before, too many websites go through a constant redesign cycle where everything is thrown out ever three or four years, when in actual fact a website should be evolving continually over time.

Rinse and repeat

The reality is that a web design project never ends. A website is never finished. Even if a client has done all of the work and fulfilled all of the above points, they are still not finished because they should be starting the process all over again. They should be continually redefining and adjusting the scope and role of the website. They should be adding new content, introducing new functionality and they should always be promoting the site and building relationships with their users.

In short; a client’s work really is never done.

Excited about client work

Posted in News on April 12, 2007 by Paul Boag

I don’t talk much about the client work we produce at Headscape, but I am really excited about our latest site and so wanted to share a few thoughts about it with you.

We won the work at least partly due to the boagworld podcast, which in itself is an encouraging start. It proves that guerilla marketing really works and also, clients we win via the podcast tend to be more switch on to the web and our way of working.

The job was to redesign the Visit Thames website from the ground up. New content management system, IA, content, design… everything. It was a big job and a very tight timescale. In fact the deadline was so tight that we initially turns the project down. This is something that we have often talked about doing on the podcast but is hard to do in real life. However, our strategy of not committing ourselves to the impossible proved correct and the client agreed to move the deadline back just enough to get us onboard.
Despite the new deadline this has always been a very tight project and there is still a lot still to do on the site. However, the initial version is a massive improvement on the old site and I wanted to tell you about a few of the cool things we have done.

AJAX goodness

One thing I like about this site is that it uses AJAX and JavaScript but doesn’t rely too heavily on it. The client side code enhances the user experience rather than being an integral part. You can give feedback or send to a friend without leaving the page you were visiting. You can add items to your itinerary without reloading. You can get ideas for trips without jumping from page to page. In short the site implements the principles of progressive enhancement and HIJAX.

Kick ass content management

There are also loads of content management facilities that unfortunately we cannot show you. We have made significant modifications to our in-house content management code base allowing site administrators to do all kinds of cool stuff. Functionality includes:

Permission and workflows
Geocoding points of interest using Google Maps (like Google My Map)
Building up pages from a huge number of modular elements
Building and managing your own forms
Comprehensive reports on all site forms
Personalized dashboard
Powerful image library allowing basic image editing
The ability to create your own domain shortcuts to specific pages
Content expiry alerts

The list goes on and on. All of this is built on .net, which may not be the trendiest language in the world but certainly proved hugely powerful and flexible for our requirements. Another nice technical aspect is the fact that the majority of data is stored as XML rather than in a rigid database table. This allows huge flexibility in the management and organization of data.

Google Maps on steroids

One of the primary functions of the new site was the ability for users to find points of interest, which they may wish to visit when spending a day on the Thames. In total the client had 15000 points of interest that he wanted to give users access to. Not only did the user need to know basic information on these points, he also needed to know geographically where they were. The obvious conclusion was to plot them on Google maps.

Of course the biggest problem with Google maps is that it isn’t very accessible. We therefore also wanted to show the points as a list in addition to plotting them on a map. Our other concern was that it became obvious very quickly that even plotting a fraction of 15000 points was going to create serious performance problems.

Using a big blob of AJAX goodness we managed to overcome both of these problems. Basically, each time the map loads we grab the boundaries of the map and call back to the server, only loading in points that appear within those boundaries. Every time you drag the map it calls back and gets a new set of points. Users that don’t have JavaScript enabled can still use a traditional search option to return points based on postcode or place name. Try it for yourself and see what I mean.

Now, the system isn’t perfect. There is a delay each time you drag (although to be honest most of the time is spent calling back to Google) and we have had to limit the zoom level to stop too many points being called back. However, we are working on ways to improve this and it is still a pretty unique solution.

Task focused functionality

Right from the outset we wanted to focus on the primary goal of most visitors to the site, which was to discover places to visit. If you are spending a long weekend on the Thames for example you might want to find:

Somewhere to stay
Places to visit
Some nice places to eat out

It quickly became apparent that what users needed to do was build an itinerary of points of interest. What is more they needed to print those out in a nicely formatted way including a map to show where those points are.

By concentrating on this primary objective the site has a nicely focused feel, making it much easier to use.

Microformats to boot

Okay, so the code isn’t the cleanest we have ever produced but making the design fluid and scalable with font resizing proved tricky in places. However, all of the points of interest are marked up as Microformats which will allow us to do some cool stuff in future such as downloading them as vcards or integrating them with other systems.

The future

Of course like any site that you produce, all we can see are the bugs and problems. However, I am excited about this site because it has some really cool features and we have a client who is planning for the future. We have some great new things coming soon, which should improve the user experience even further. Oh yes, and it has Poirot sharing his passion for the Thames. Nice.

Show 62: Glitches

Posted in Classic shows on January 8, 2007 by Paul Boag

This week we discuss handling difficult requests from clients, the upcoming boagworld meetup and when to redesign your site. Jeremy Keith also shares his thoughts on when and where to implement Microformats.

Podcast: Download (18.1MB)

Download this show.

To subscribe directly within itunes click here

Digg this podcast

News & events

Marcus and I cover four news stories this week:

Boagworld Meetup

There is going to be a meetup of boagworld listeners in central London on the 25th January. If you fancy joining us then please sign up on the upcoming.org website.

WebDD Conference

On Saturday the 3rd of February 2007 Microsoft are holding a free conference in Reading specifically targeting web developers and web designers in the United Kingdom. Speakers include Patrick Lauke and Bruce Lawson. To sign up visit the WebDD site.

Web Directions North

The Web Directions conference comes to Vancouver between the 6th and 10th of February. The line up is absolutely superb. If you are on that side of the Atlantic I would highly recommend making the effort to attend. More information on the Web Directions North site.

Now you can digg podcasts

Digg.com now offers a great way to find new podcasts. The service is still in Beta so site registration is required, however you can view the most popular podcasts, see what comments people have made and even vote for your own favourite podcast (hint! hint!).

Agony Uncle

The agony uncle section is a new part of the show where we encourage you the listeners to write in with your web design problems. In this week’s show I tackle a forum post by Amorphic that asks how to deal with clients that want ridiculous things on their website. I look at avoiding confrontation, understanding the clients’ requests, and how to justify your position.

Review

Each week we are going to review a book, article, product or conference and this week we look at an article by Jason Santa Maria on working with corporate colours. It’s an excellent article found on the 24 ways website and I highly recommend you take the time to read it.

Client’s corner

In the new client’s corner segment Marcus discusses the unique challenges faced by website owner. This week he starts with the basics… how do you know when to redesign your website. This topic is largely based on an article about redesigning I wrote a while back, so you might want to check that out.

Ask the expert

As part of the new structure we are asking you the listener to send in a question that you would like posed to a web design guru. This week I pose a question I have been having about how to implement Microformats to Jeremy Keith.

Podcast 61: Christmas Special

Posted in Classic shows on December 11, 2006 by Paul Boag

In our Christmas Podcast Special; Skype murders Marcus rendition of Silent Night, Paul shares his list to Santa and they both look at the successes and failures of the web over the last year.

Podcast: Download (24.1MB)

I know what you’re thinking; “not the most riveting subject”. However, don’t let that put you off. Although return on investment might not float your boat, it is still extremely important and you should take the time to listen to this show.

Download this show.

To subscribe directly within itunes click here

So another year is done and boagworld finishes for its Christmas break. We will be back in January but until then you can enjoy this extra special episode of the show.

It’s been a real pleasure working on the show over the last year. We really want to thank you all for listening. We never anticipated that the show would prove such a success and hopefully we can continue to keep it fresh and exciting in the New Year with our new format.

This year’s Christmas special is slightly more structured than last year’s so I figured a few notes on what we covered maybe appropriate. Enjoy!

Special offers to boagworld listeners

A couple of companies that listen to boagworld wanted to give something back to the boagworld community. Although I haven’t purchased from either site yet myself, I thought it was nice they were enthusiastic to share a small token with you all.

Houlton Wines will give you a 10% discount if you quote the coupon code “boagworld” when ordering. Equally Seams will offer 25% off any tshirt if you quote to code “boagworld001” when you checkout with paypal.

News

I tried to give the news a Christmas theme this week by ensuring all the stories had a Christmas slant. Guess which one fails to meet the criteria!

Biggest Tech Mistakes of 2006

Thank you to everybody who nominated a tech mistake of 2006. Below is the shortlist. You will have to listen to the show to hear who Marcus announced as the winner.

Best web applications of 2006

Also in the show we look at the best web sites and applications of the year. Nominations include:

Dear Santa

I thought it might be fun to share some of the gadgets I will be asking Christmas for this year. Of course if you want to buy me any of them I am sure Santa won’t mind!

Finally, we do a quick review of the services offered the Shaw Trust. If you haven’t come across these guys before then definitely check them out. They offer some very interesting web accessibility services which is ideal if you want to test your site with real disabled users.

Thanks for listening, and we will speak to you all in the New Year. Happy Christmas!

Revolution or evolution?

Posted in Web strategy on July 15, 2006 by Paul Boag

In my last podcast, I spoke about choosing the right design for your site. In the past, I have also written about the need for sites to evolve rather than redesign. Therefore, I thought I would put some of my theories to the test, with the redesign of boagworld.

Ever since my podcast co-host (Marcus) joked that it was about time boagworld got a face lift, I have been mulling over what to do with the site. Obviously, I am not going to change the site just because Marcus said so but equally there are a number of reasons why the site needs some attention:

We had a new logo for the boagworld podcast waiting to be launched
The sites code is looking a little dated and doesn’t really reflect the latest techniques I have been using elsewhere
The sites layout is very much like a personal blog and not very reflective of the community aspects of boagworld.
I want to move away from a fixed width site, which is no longer reflective of the approach I take on commercial projects.

A revolution

With all of that in mind, I started the process of redesigning. As it was my site I simply let rip and just had fun rather than worrying too much about things like brand identity. The new design was a radical departure from the current site, with no real continuity. Despite this, I really liked the design. Sometimes it is fun to shake things up and shatters preconceptions, especially when it is your site and you don’t have to worry about "business realities". Without a doubt, this approach was very much a revolution rather than an evolution of the boagworld site.

View the more radical design approach

An evolution

However, the more I looked at it and the more I thought about it, the more I began to worry. This radical departure flew in the face of the advice I gave in my "site evolution" post. In this post, I suggested that a site should gradually evolve over time rather than go through periodic redesigns. One of my reasons for this approach is that it keeps continuity in brand identity and doesn’t leave users feeling overwhelmed when they see the new site. I therefore went back to the drawing board and produced a more conservative design, which was more in line with the existing site.

View the more evolutionary design approach

What do you think?

So how do I decide which approach to adopt? In the end, I have decided to take some of my own advice from my last podcast: "Ask your audience".

If you are reading this post then you are very definitely my audience. So what do you think? Which approach is better and why?

Podcast 34: The roles of the client and the web designer

Posted in Classic shows on May 15, 2006 by Paul Boag

Getting the relationship right between the client and web design agency can make or break a web design project.

In this weeks show Paul and Marcus discuss the sometimes problematic relationship between web design agencies and clients. They also cover how the line between web pages and the browser have been blurred, the evils of speculative work and a great new book by Ian Lloyd.

Download this show.

The roles of the client and the web designer

Getting the relationship right between the client and web design agency can make or break a web design project. Often both parties enter into a project with very different expectations of who will do what. This is partly because there is such a wide range of approaches adopted by the web design community.

In this show Paul and Marcus discusses how clients can find web design agencies that suit their working approach and how to get the most value for money out of the agencies they choose.

They also propose some general principles for improving communication between client and agency:

Advice for clients

Paul and Marcus suggest the following guidelines for clients:

Recognise that the success of your web project is as reliant on you as it is on the web design agency.
Don’t under estimate the time you will need to put into the project, especially when it comes to preparing content.
Try to avoid getting drawn into subjective design discussions. Rely on the expertise of your designer.
Always consider the bottom line and whether additional functionality will generate a return on investment.
Be willing to compromise and take on board the agencies advice.
Clearly state your expectations up front. Don’t presume the agency will approach the project as you would expect.
Remember, the customer is NOT always right!

Advice for agencies

The discussion then moved on to advice for web design agencies when working with clients:

Use the kick off meeting to clearly understand any expectations the client has for the project.
Remember it is the design agencies responsibility to educate and inform the client about what works well online. If a client fails to grasp the logic of your approach it is a failure on your part to communicate it effectively.
Recognise that designing a web site is about compromise. It is sometimes necessary to compromise design and usability for the sake of business drivers.
Pick your battles! The client is ultimately paying you to produce a great website so don’t be afraid to stand your ground when their opinion undermines that objection. However, know when to back down.

Site evolution

Finally, Paul and Marcus wrap up the discussion by touching on the subject of site evolution and the need to change the client/agency relationship from sporadic redesign to ongoing site evolution.

For more on this subject see my site evolution post.

Also this week…

Also in the show:

Marcus rants about speculative work,
Paul reviews Ian Lloyd’s (founder of accessify.com) new book “Build Your Own Website The Right Way Using HTML & CSS“
And they both discuss how emerging technologies like AJAX blur the line between browser and website.

Next week Paul interviews Andy Budd, the author of CSS Mastery, to get his take on the state of web design.

Podcast 32: In-house vs. outsourcing

Posted in Classic shows on May 2, 2006 by Paul Boag

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.

Podcast: Download (23.9MB)

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.

Download this show.

Also in this weeks show:

Search engines vs blogging and RSS
A love song to web standards
Techno-babble: Different layout approaches – Fixed, scalable, elastic, hybrid
Inspiration for designers at www.designmeltdown.com
Support and community for in-house developers: www.designersinhouse.com

In-house vs. outsourcing

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.

In short, an internal development team demonstrates a greater commitment to placing the web at the heart of your business and a vision to ensure your site evolves overtime instead of going through sporadic redesigns.

Outsourcing your web project

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.

Stumbling at the last

Posted in Reviews on December 7, 2005 by Paul Boag

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*

Site evolution

Posted in Web strategy on November 20, 2005 by Paul Boag

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.

A new client/designer relationship

Posted in Web strategy on November 8, 2005 by Paul Boag

Realign your website rather than sporadically redesigning it.

I write many posts for this site, but this one marks a turning point in how I approach web design. It started with an article on the List Apart website about realigning your website rather than sporadically redesigning it. This catalyst has made me completely rethink the way I interact with my clients. It has also forced me to rethink how I sell web design services.

I believe there is a fundamental flaw at the heart of the client / web design agency relationship that needs to be addressed.

The current development model

An average web project runs something like this:

Client identifies the need to redesign their website in someway
Client issues an invitation to tender outlining what they want
Design agency responds to tender with a fixed price proposal
Client agrees to proposal and commissions agency
Agency builds the site and makes it live
Client may make some limited adjustments to the site but basically, it just sits there until…
Client identifies new requirement and then we return to step one.

This all sounds logical enough, but the reality is that it has some deep-seated flaws.

The one thing I have learnt from both the List Apart article and from working long term on websites such as boagworld is that they need to evolve. This cycle of redesign is ultimately counter productive and very expensive. Each time you are almost starting from scratch and reinventing many of the same things. A more sensible approach is to tweak the site continually so it remains fresh and is always improving.

The boagworld.com website is a good example of this process of evolution. I add new functionality to this site on a weekly basis. I look at the site constantly and ask myself what could be improved. Small tweaks keep the site moving forward and ensure people return to it regularly.

To some extent, we have already adopted this approach with content. Most web companies provide clients with content management systems that allow them to update the content themselves and keep it fresh. However, we don’t apply this principle of evolution to site design and functionality.

A better model

A better model for the way clients and web design agencies should work together can be found in the advertising industry. In that industry, the relationship between agency and client is very different. Instead of huge one off expenditures every few years, a client will establish an annual advertising budget, which the advertising agency utilises to generate the best return on investment. The client and agency work together to agree how best that money is spent over the course of the year and plan the long-term marketing strategy. It is a much more cooperative relationship where the client benefits from the agencies expertise on a regular basis rather than for one off projects. This allows the advertising strategy to be much more integrated into the overall business plan.

If this model of “continual relationship” is so good compared to one off project, why has it not already been widely adopted? Well I believe there are a number of reasons:

Expense

There is a perception that this is just another way for web designers to squeeze more revenue out of clients. However, the reality is that in the end this is a much more economical approach to managing your website (not to mention the cash flow benefits). As I have already said, with the old model you were starting over every few years and throwing out what you had before. With this new approach, you are constantly building on the previous investment you have made by evolving the site rather than rebuilding it.

Technology

Until recently it was actually very hard to evolve a website over time. Because content, design, and functionality were all mixed up, it was a headache to make the simplest change throughout an entire site. However, with the new generation of sites built using web standards this is no longer a problem. Global changes can be made across a whole site in a matter of minutes.

Of course, it is possible that your current site is not built using this new methodology. In such cases, the number one priority would be to make this transition. Once this is achieved, site evolution or even total redesign will be considerably easier.

Perception

The web is still very young and until relatively recently I do not believe clients really understood the potential of the web. For a long time, the attitude was that you just put up a website and then walked away. I think we have all moved beyond that now and realise that a website is a valuable marketing tool, which needs to be at the heart of our business strategy. The need for long term planning is now much more apparent.

In house skills

Many companies have in-house web design staff, who are perceived as responsible for the evolution of the website. However, the reality is that in my experience these staff are almost exclusively engaged in the day to day maintenance of the site rather than considering how the site should evolve in the future. If I may return to the advertising agency analogy for a moment, you would not consider the need for an ad agency redundant, just because you had marketing staff internally. Internal marketing staff cannot hope to provide the breadth and depth of service that an ad agency can.

Conclusion

I believe that it is time we moved away from the fixed price, single job model to something that allows for a deeper partnership between web agency and client. We need a model that allows the agency to evolve the client’s site over the long term rather than in intermittent jumps.

What makes good web design?

Posted in Design on September 6, 2005 by Paul Boag

I am in crisis today. Some days I am just not sure what constitutes good web design anymore. Help me see the light.

The never-ending process of redesigning the HTML soup that is headscape.co.uk continues. While seeking inspiration for my copy I came across this site:

Burza

What surprised me was my confused reaction to the site.

Its cool… oh yes it is

To start with I thought, wow this is cool. It looks great, it is built in web standards and it even caters for users who do not have the flash plug-in installed. A great example on modern web design, using semantic code and degrading nicely.

Oh no it isn’t

However, when I got past the technical and design excellence I started to find some confusing features. For a start, it took me a moment to work out what they did. Despite, the big banner saying, "We do web stuff" I had trouble grasping what the site was about. Was it a games site, a site for kids, what?

I loved the little cool figures and even grasped relatively quickly that they were the main navigation. However, I was then left wondering what each section contained. The white arrows everywhere and the spidery yellow text made it hard to interpret what was going on.

In two minds

I am not writing all of this to slag off the site. Quite the contrary, in many respects I am very jealous of the talent behind it. The reason I am writing is that I really do not know if it is a good piece of web design or not. Obviously, in many respects, it is, but from a usability standpoint, I am not so sure. Is it form over function or am I just turning into a grumpy old man? What do you think? How would you rate this site?

New National Trust site about to go live

Posted in Reviews on August 1, 2005 by Paul Boag

Back in 2000, I had the privilege of being the lead developer on the 2nd generation of the National Trust web site. With the third generation of the site about to launch, I am excited to see them move on.

Working on the National Trust web site was one of the most enjoyable sites I have ever done. When the Trust came to us they had little more than a "home made" site put together by some enthusiastic amateurs and a few technical staff at the Trust. We had the privilege of redesigning it from the ground up; information architecture, design, content, the lot.

Our approach

What was particularly enjoyable was there huge archive of photography. They had over 100,000 photos of some of the more amazing architecture and countryside in England and Wales. It did not take us long to realise that these images should rule the design and so everything else was built around that.

Project challenges

Accessibility

Of course, the project was not without its challenges. Firstly, the Trust wanted to ensure the site was accessible by their more elderly members who in many cases had failing vision. At the time, there was still much confusion about accessibility and how to ensure your site was accessible. Very different messages were coming from organisations such as the W3C, the RNIB and the British government. In the end we decided to adopt a similar approach to the "zoom the web" approach which seems to be the way things are moving at the moment. We simply switched to a different stylesheet to increase contrast and font size. Although the site was not WAI compliant, it did demonstrate some initial thinking in the area.

Navigation

The second problem area was navigation and in this, the constraints were much more frustrating. I will not bore you with the details but it is worth explaining that because of internal politics at the time we were only able to add a very basic header to the site that provided primary site navigation by a dropdown! In hindsight, this was my primary failing on the site. I feel I should have really fought for a more user-friendly form of navigation as dropdowns prove especially difficult to older users. However, I was not as knowledgeable as perhaps I am now and the whole industry has become older and wiser.

No content management system

The final problem with the site was totally out of my control. This was that the Trust wanted the entire site built as flat HTML. This was driven by technical constraints at their end and both the Trust and I were very aware of the maintenance problems going forward.

National Trust moves on

About 18 months ago, they finally decided to face the situation and move the entire site across to a content management system. As part of this rebuild, they also wanted to address some of the design issues and so a new look and feel was produced. Unfortunately, due to an internal reorganisation within the Trust and our lack of experience in the particular content management system they had selected, they chose not to employ Headscape to do the new look and feel. I have to say in many ways I feel this was the right decision. The Trust was a very different organisation to the one we first got involved in and I understood their desire to introduce new blood. In many ways, I felt I had done my part moving the organisations website to the centre of their marketing strategy rather than an added extra that received little funding and no serious consideration.

Waiting with baited breath

I have been waiting with baited breath to see the new National Trust site. For some reason they seem to have faced delay after delay in its launch. I do not know the details for this slippage but I would like to think they come from a desire to get the new site perfect before going live.

My hopes for the new National Trust site

So, what are my hopes for the site. Well, firstly I hope they fix the navigational problems the site suffers from. Secondly, I imagine the new site will dramatically improve from an accessibility perspective using the latest techniques and conforming to W3C standards. Thirdly, I hope they will move across to a web standards based build and all the associated benefits that has. Finally, my desire is to see a user interface that really shows off the beauty of the properties they own. The National Trust own some of the most amazing places in the world and I pray that their site captures that awesome architecture and wonderful countryside.

Accessibility for low vision users

Posted in Accessibility on July 28, 2005 by Paul Boag

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.

@Media2005

Posted in News on June 13, 2005 by Paul Boag

@Media 2005 was the first Web standards and accessibility conference here in the UK and only the second worldwide. The conference demonstrated a growing commitment to building accessible and standards friendly web sites.
So what came out of the conference and why will it affect the way we all build web sites.

I was fortunate enough to attend this two day conference and had the opportunity to listen to some of the leading figures in web design. They spoke about how the way we build web sites will change and how it will benefit us all, both users and site owners alike.

I have to confess I was totally inspired by the conference and so here are just some of my initial thoughts:

Taking standards based design the next step

I probably haven’t spoken about standards based design enough on this site before, but what I have written has hopefully explained that web standards are about separating content from design. This has a whole range of benefits including, but not limited to;

faster download time,
sites being easier to maintain or redesign,
greater accessibility,
available to a greater range of browsers and devices,
better print capability.

However what really inspired me was a talk by Jeremy Keith who took the idea one step further and suggested we also separated out behaviour from content.

If you have read my blog before you will know that I try and avoid technical jargon because there are enough people out there providing the technical detail. With that in mind I am not going to get into the specifics of DOM and Javascript and exactly what I mean by behaviour. However what I will say is that by separating out interactive / functional elements from your web site you gain a number of advantages. These include:

the ability to manage all of your functionality (such as popup windows etc.) from one central source,
a cleaner, more accessible web site that will still work even for people without the software to view the extra functionality,
the ability to add new functionality site wide without editing each page that the functionality needs to appear in.

The beauty of Design

Douglas Bowman gave two very inspiring sessions that raised a number of interesting points. One of the issues he touched on is something that is particularly close to my heart and something which I believe is fundamentally important to good web design. He spoke about our tenancy as designers to be constrained by the practicalities of web page construction and that this often stifles our creativity.

So many web sites look the same, not because they are trying to conform to design standards (which is something I whole heartedly support) but because the designers have an inability to think outside of the constraints of the medium. Douglas encouraged innovation where we design first and work out how to build it later. Only by taking this approach can we ensure not only the best design for the job but also that we are constantly pushing back the technical boundaries of web design.

The real face of accessibility

For a long time now I have accepted that we have a responsibility as web designers and indeed web site owners to ensure that our web sites are accessible to the widest possible audience. Indeed I routinely check my sites against web accessibility guidelines and fix individual little problems so they work better with speech browsers. However it wasn’t until a presentation by Robin Christopherson from Ability Net that I fully began to realise how impossible it is to browse the web as a blind user. Robin himself is blind and demonstrated some of the problems faced by blind users. He did a particularly compelling demonstration by attempting to navigate the Amazon.co.uk web site using a standard speech browser. Although I have tested pages before in speech browsers I don’t think I have ever attempted to achieve anything other than basic tasks. Robin’s demonstration was a real eye opener and has galvanised my commitment to creating truly accessible design.

Praise and criticism

For me this conference was a real turning point. I have to be honest that over the last few months I have become disillusioned with web design. As somebody that has been involved in the web since the early days I missed the challenge and excitement of those chaotic times. Somehow things had become very stale and sensible. However @media 2005 has made me realise that I have a real opportunity to shape the way the web develops in the future and make it a much more usable place for everybody.

I have read some comments that have critised the conference and in particular the speakers for being to insular. Some have expressed a sense that those speaking and running the conference were elitist in some way. Certainly they all seemed to be good friends but I would argue that their closeness is one of the reasons they have achieved so much. I have to confess I had a pang of envy that I was not one of the elite who inspired web designers worldwide and is forging the future of the web. However I quickly realised that it is down to people like me and you to implement these new methodologies on a daily basis if we are really going to achieve a more accessible web. You can have all the evangelists in the world but unless they win converts and those converts act on their new found convictions it means nothing. They have certainly made a convert out of me and I thank them for their inspiration and hard work.

How we are relaunching our own website

Posted in Web strategy on July 19, 2004 by Paul Boag

Its a bit embarrassing really. One of the primary things Headscape sells itself on is our experience with accessibility and the fact that we build using web standards. However our current site has a totally separate accessible version and is built with standard HTML. Looks like it is about time we redesigned our website!

I thought it would be good to take a slightly different tactic to most website redesigns where the company keeps the design under wraps until it goes live. Instead I thought I would share some of my experiences as we redesign the site and let you see some of the thought process we have gone through.

Establishing our aims

The first step in any redesign is to be clear about your objectives. Why do you want to redesign your site in the first place. After all in Headscape’s case we have received some very positive feedback about our current site.

Our goals are three fold:

Create one site to meet every bodies needs instead of having a separate accessible version. This will be inline with the position we now take on accessibility.
Create the new site using web standards is order to speed download, improve printability, and make the site easier to update.
Give the site a new look and feel so we can relaunch it and generate some renewed interest in the Headscape brand.

What we didn’t want to do is make huge changes to the content as we don’t have the time internally to do that. We intended to make some minor updates to the case studies section but that was about it.

The design approach

Once we had a clear idea of our goals and knew exactly what our content would be it was time to move on to the design stage. I also knew that the colour scheme should be similar to the existing site and where possible the existing brand should be reflected. I also knew from feedback we have received that the site needed to be lighter in colour. With all of this in mind I produced the following:

Click here to see the new homepage design

Getting some feedback

Before we proceeded too much further we wanted to get some feedback on the site and see if we were heading in the right direction. We weren’t at the stage of full usability testing yet but some initial impressions would be nice. So far I have asked for a web site review from members of a forum I regularly contribute too and this has been very useful. My next step will be to ask some of our clients to take a look at the design and let me know what they think.

A final little twist

A final little idea I wanted to share with you before I close is the banner at the top of the new design. You will notice that it refers to accessibility. The idea of this block is that we are going to detect what people have entered into the search engine and change the banner accordingly. In other words if they have searched on accessibility they will see an accessibility banner while if they typed in usability they will see a usability banner. This not only allows the user to quickly find the content they are after but also makes us appear to specialise in exactly the area they are interested in.

Conclusions

So that is as far as we have got so far. Please feel free to post your comments on the design below. Any feedback is much appreciated. I will keep you updated on how things progress.

Dealing with complex navigation

Posted in User experience on July 1, 2004 by Paul Boag

One of the biggest challenges faced by website designers is how to deal with a sites main navigation. It is a particular challenge on deep complex sites.

The problem

How many levels of navigation do you build into your website? Its a fairly fundermental question. Almost all sites have at least two. The main sites sections and then the sub sections underneath. But is that enough? Probably not and yet many web designers fail to consider how content deeper in the site is going to be shown. But how deep do you go? Three levels, four?

Case study

Headscape have recently been tendering for some work with a large university in the south of england. They want a complete redesign of their web presence and require a site flexible enough to encompass all of the different organisations and departments that make up the university. They also want a site that is able to expand and change over the coming years. This is particularly challenging when it comes to the navigation. It didnt take us long to realise that a conventional approach to navigation was not going to work. After all the site could easily become more than 6 or 7 levels deep by the time you navigate through faculties, departments, research groups, and individual courses. Ignoring the fact that this would be horribly confusing there simply was not enough space of the page for that amount of navigation! Add to this the fact that some pages deeper within the sites structure also acted as homepages in their own right. For example the International students section would be the landing page for most enquiries from abroad and so it was important that the user quickly grasped where they were in the sites structure and could easily see the sub sections of that part of the site.

Breadcrumbs

Traditionally breadcrumbs have been seen as the answer to helping users establish where they are in a sites hierachy however experience from usability sessions I have run over the years has shown me that the average user does not use breadcrumbs as much as we would hope. In many cases users simply do not notice them and even when they do many do not understand the concept. Also even if we used breadcrumbs to help the user identify where they are in the site structure this did not solve the fundermental problem of the size and depth of the navigation.

One possible solution

In desperate need of inspiration we started looking at other large and complex sites to see how they deal with the problem. Once again the BBC website proved itself head and shoulders above the rest. In particular it was the BBC sports website that caught our attention.

When you arrive on the site the left hand navigation shows a list of all the different sports they cover. Where it gets interesting however is that when you click on "football" it does not expand the menu as you would expect. Instead it replaces the first menu with a new one that shows the parent of "football" (in this case "Sport Homepage") and all of its children. When you click on a sub section of "football" the process is repeated. You see the children of the new section and the parents which now includes both the "Sports Homepage" and "Football". In effect they use a vertical form of breadcrumbs as the sites navigation.

Pros and Cons

The obvious benefit of this is that it can expand forever. It doesnt matter how many pages you add to the site or how deep it gets the navigation will never break. However it also gives the user a much clearer idea of where they are in the site. This would work particularly well on one of the landing pages I mentioned earlier because the user can see where they are in the overall site but be primarily focused on the children of that landing page.

The downside is that the user cannot jump from one sibling to another. In other words they cannot move between pages on the same level without first going back up a level. Although this could be annoying on slower connections I think this is a fair compromise for what is a much more flexible approach to navigation.

A better way to build your website

Posted in Development on June 25, 2004 by Paul Boag

Build a site that is accessible to all, look better than ever, is cheaper to build and is compatible with both future & legacy technologies.

The Problem

The root of the problem lies in the way websites have traditionally been built. As I am sure you are aware, websites are constructed in a language called HTML. HTML was created by the World Wide Web Consortium (W3C) which is the body responsible for developing standards on the web. However, when HTML was created, nobody could have possibly imagined what the web would evolve into. HTML was designed to help identify pieces of content in a document, NOT to help the page look well designed. For example the header tags were created to tell a browser that this content was a heading. It wasn’t designed to make that piece of content look bigger on the page. Tables are probably the best example of this. Originally, tables were designed simply to display tabular data. However, web designers soon worked out that tables could be used to help with the layout of web pages. As the web became more commercial and companies became more and more demanding about how their brands were portrayed online, web developers became evermore creative about how they could manipulate HTML to show the effects their clients demanded. Summarising the problem, web developers have been ‘fixing the fix’ by continually manipulating HTML rather than ‘finding the solution’. "How does any of this affect me?" I hear you cry, "my site looks great". The reality is that your site may look great on your machine but what is going on behind the scenes will, in many cases, have the following effects:

1. make your site slower to download (because of excess amounts of code)

2. make you site unavailable to anybody not using mainstream browsers and operating systems

3. make your site inaccessible to those with disabilities. It is often easy to underestimate how serious the above points are. It is easy to say to yourself "as long as it is accessible to most people that is all that matters". However, by saying that, you are potentially excluding more than 20% of your users. That’s like your website being offline for 73 days of the year!

The Solution

So what is the solution? Well, fortunately the W3C are on the ball. They have introduced changes which will revolutionise the way in which websites are built. Without going into the technical details too much, they have created a way to separate the content of a webpage from the style of it by using XHTML and Cascading style sheets (CSS). This has numerous advantages which I will outline below. However, what is really remarkable is that they did all of this back in 1998. The problem has been that it is only relatively recently that it has been properly supported by the major browsers. Of course, the problem is that these same browsers have also got to support traditional websites (otherwise 90% of the internet would be inaccessible) and this means it has been easy for us web designers to carry on working in the way we have done for years. The upshot being that this new approach to web design has been slow to catch on. However, the benefits are enormous, and so I would encourage you to make sure your site adopts this new approach.

The Advantages

So what exactly are the advantages of separating design from content in this new way:

Flexible design

Cascading style sheets, which is the part of the new approach that handles all of the design aspects, offers unparalleled control over the look and feel of the site. This is because it is specifically designed to do that job, unlike HTML. Not only do you have pixel perfect positioning (something that opens up endless possibilities from a design perspective) you can also control how a page looks when it is printed, change the look and feel in an instant and have greater control over the way text appears. In fact you could easily write a whole book on the design benefits of CSS and indeed many books have been written. However, it is sufficient to say the benefits are considerable.

Streamlined code

Because HTML was never designed to create complex page design, web developers had to become ever more creative in the way they used it to achieve the desired effects. As a result, the amount of code and number of images used to build a page grew beyond belief to the point where there was a noticeable increase in download time. The new standards introduced by the W3C have done away with this problem. Pages are reduced to the absolute minimum of code so improving downloading time and reducing bandwidth costs for those that have dedicated servers.

Faster development

The improvements these new web standards offer to development time are almost unbelievable. Imagine being able to completely redesign the look and feel of your site by simply replacing one file! I know, it’s hard to believe but now it is actually possible. What is more if your site is built correctly it is no longer necessary to build different versions for different browsers or to design a separate print friendly version. All of this is handled with a few simple files. The man hours saved on this alone are massive.

Available on more browsers and devices

When most of us build a website we make certain judgements about the minimum specification of browser the site will run on. Most of us go for Netscape & IE version 5 and above. This captures the majority of the potential users. However, we are all too aware that a huge number of people do not use these browsers and therefore won’t be able to view our sites. Budget restrictions usually lead to the conclusion that the investment in building an alternative version for them is just not worth the effort. This problem has been further complicated by more and more devices accessing the web. These might include PDAs, mobile phone, web TV and the like. At the end of the day we have always been forced to draw a line in the sand and leave it at that. However, this no longer needs to be the case. The W3C have designed the new web standards with exactly this problem in mind. One version can now truly fit all. That is not to say they won’t look different in various browsers or on diverse devices but what it does mean is that they will be viewable on all.

Suited to the visually impaired

As we discuss in one of our articles on accessibility it will soon become law that any website offering a service (which potentially is all websites) will need to be accessible by those with disabilities. This obviously has huge consequences and is a topic in its own right. However, adopting the new web standards is a huge leap towards having an accessible-to-all website. I couldn’t possibly go into all the details of why that is the case here but it is enough to say that a well designed web standard built site will also be accessible to the visually impaired.

Future proof

Probably the most important benefit in adopting the new web standards is that you are future proofing your website. By that, I mean you will no longer have to redesign your website every time a new piece of technology comes along. These standards have been created by the W3C who are the official body behind the web and include representatives from all the major browser producers as well as from companies like Macromedia who produce web design tools. Admittedly, you might wish to redesign your site for cosmetic reasons but as I have already said this becomes a matter of replacing a few key files not rebuilding the whole site. Also, apart from the cosmetic changes the underlying content is here to stay. Eventually the majority of the web will be built this way. The question is not ‘shall I implement these changes?’ but rather, when.

Conclusions

So
why don’t all web designer
s build their sites in this way? One day I believe they will. However this is a huge shift in thinking for web developers. In effect we are being asked to throw away years of experience and start again. That is a hard thing to do. Some are burying their heads in the sand while others are just too busy to even discover there is an alternative to the way they have always worked. However, it is inevitable and for once the change is for the good. Unfortunately this article has only scratched the surface of what is possible and I am sure has left you with many questions. Feel free to email me and I would be happy to discuss the possibilities with you further.