Tag Archives: forms

Show 81: Money Matters

Posted in Classic shows on by Paul Boag

This week on Boagworld: Paul gives advice to those who work with content management systems. Marcus finally talks about charge out rates and we talk to Dan Mall and Mark Huot about swfIR.

Download this show.

Launch our podcast player

News and events

37signals in Time Magazine

I notice that 37signals have made it to Time Magazine. This is exciting stuff because it shows the growing awareness in mainstream media of the explosion of web 2.0 businesses. However, the real reason I mention this article is because of what it tells us about how 37signals work. You get to learn about their focus on simplicity, the fact that innovation can happen outside of Silicon valley and their approach to a distributed company.

The one part of the article I personally found particularly interesting is how 37signals’ current suite of products was born out of a need they had to communicate across a distributed company. The idea of building a product that meet a personal need is a good one. It is particularly interesting to me as Headscape has started development of a product which does exactly that. I don’t want to say much more at the moment (as it might never happen), but this article contained a lot of valuable lessons for us.

AJAX tools

I seem to find myself doing more and more ajax and javascript these days. One of the more tricky areas is keeping the user informed about what is going on. I am encountering two specific problems:

  • How to draw the users attention to content that has changed
  • How to inform the user that content is still loading

The latter is fairly straightforward as you simply display a loading graphic. However, I am a lazy sod and can’t be bothered to hand craft a beautiful animated gif. Fortunately this week I came across AJAXload which generates those pretty web 2.0. loading graphics for you. Very nice.

Informing users of changing content is a bit more tricky. I have been aware of the fade to yellow technique for a while but that requires a white background, which my designs don’t ways have. What I didn’t know until I finished Jeremy Keith’s “Bulletproof Ajax” is that there is also a fade to anything technique. This is basically the same as the fade to yellow approach but the background colour doesn’t matter. Simply download the code and away you go :)

Waves of creativity

I stumbled across an article this week talking about the relationship between brain waves and creativity. This explained a lot about my own personal creativity! The gist of the article is that your brain needs to be relaxed in order to be at its most creative. This makes sense for me personally as inevitably I am at my most creative when I am lying in my bed at night.

The sad truth is that we spend most of our lives in a more agitated state and so creativity is hard to achieve. This dove tales nicely with my experience of implementing “Getting Things Done: The Art of Stress-free Productivity” (David Allen). Since reading that book I have felt much more relaxed and in control and hence I have been considerably more creative.

Eric Meyer explain why forms controls can’t be styled

A big thanks to Eric Meyer who has been kind enough to look into the incredibly confusing area of form controls and then explained it to the rest of us. Many web designers express a real frustration with the fact that you cannot consistently style form elements. Although personally I think it is generally unwise from a usability perspective to start mucking around with form elements, I have still always wondered why browser developers have chosen to give us so little control. In a recent post Eric goes into extensive detail about why form controls are “weird” but the upshot is that you are simply better off not styling them.

Agony uncle: Web Design rates

Another question from Bob in Iceland:

“Hi guys, I am becoming increasingly bewildered with what I should charge for web design work. I also do a fair amount of copywriting and content research. What should I charge? Should my rates change for different work? I am a one man band.”

Firstly, I should say that there is no real fixed figure for web design related work. It depends very much on a number of factors, such as:

  • Experience e.g. proven capability to deliver
  • Ability to deliver specialist services e.g. usability testing
  • Size
  • Diversity of staff
  • Location
  • Portfolio

However, to use a real example as a baseline, a survey carried out by eConsultancy a couple of years ago showed that English web design agencies employing 10 to 20 people with a turnover of approximately £1M, charged between £500 and £800 per day for most services. I expect this gone up a little since then.

Setting your rates is partly science, partly weighing up what the market will bear for what you offer.

You do need to work out to the best of your ability what your daily break even cost is but in, in theory, your annual figures should be able to tell you that. The biggest drain on any web agency, unless you have marble and gold clad offices in central London, will be your staff. Good creative/technical people don’t come cheap.

Be realistic from a number of different angles:

  • Don’t try and charge a grand a day if you’re straight out of uni with no experience under your belt
  • Don’t expect to have 100% effort allocation – 70% is excellent
  • Price projects as honestly as you can but remember that clients are human beings and really don’t like paying for project manager anywhere near as much as they do technical development

So should you charge different rates for different services. Again… it depends. Some jobs require a lower level of skill as part of the project. For example, recruitment (though an absolute pain) for any type of testing requires basic organisational skills and not,say, years of experience in project management. If you can outsource that work at a lower rate, then charge a lower rate, but if your PM ends up doing it then you have to charge at your PM rate.

For years we charged a flat rate across the board because it was simpler to manage and we felt clients liked it. Over the past couple of years we have done a lot more consultative work that has placed pressure on the timetables of the directors. This has led us to having the following rate categories:

  • Creative director – Paul
  • Consultancy – IA, business analysis, testing etc
  • Standard – design, technical, pm

We charge a fixed uplift (per client dependent on geographic location) for on site work – kick off meetings, testing etc.

Client corner: Advice for CMS users

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 so I thought there might be some value in sharing it on the show. For complete notes on everything I cover check out the CMS user blog post.

Ask the expert: Dan Mall and Mark Huot on SWF image replacement

I was fortunate enough to get some time to chat with Dan Mall and Mark Huot the creators of SWF image replacement. We talked about:

  • What exactly swfIR is and how it works
  • What kind of scenarios they imagine it being used in
  • What inspired them to create swfIR in the first place
  • A little bit about the process of applying it to a site
  • What the future holds for swfIR
  • What it is like working at Happy Cog

No show next week

Just a quick note to say there will be no show next week as I am off on holiday to sunny cornwall. However, please continue to send in your suggestions for the show and don’t forget you can always check out the forums if you want your boagworld fix :)

Advice for CMS users

Posted in Accessibility, Site content on 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].

Show 78: POSH?

Posted in Classic shows on by Paul Boag

This week on Boagworld: Paul redesigns the way clients and designers interact, Marcus asks if you really need a content management system, and Garrett Dimon sharings his experiences of information architecture.

Download this show.

Launch our podcast player

News and events

Breadcrumbs are good, its official

When Jakob Nielsen speaks the world listens. This week he has come out with the shocking revelation that Breadcrumbs are good. Okay, so this doesn’t come as a surprise to most of us, but its still an interesting read. Apparently more and more people have come to rely on this secondary navigation tool and notice if it isn’t there. Jakob believes that breadcrumbs never cause problems in user testing (although sometimes they are not seen) and provide a wealth of benefits to visitors that do use them. Finally, he goes on to talk about the fact that breadcrumbs should always show a sites hierarchy rather than the path a user has taken through a site.

Techcrunch drool over Silverlight

So the guys over at Techcrunch have spent the last week at MIX07 and seem to have been brainwashed by the nice fellows at Microsoft. They are positively drooling over Silverlight, Microsoft’s challenge to Flash. In one post they say:

“It makes Flash/Flex look like an absolute toy… without exaggeration, Ajax looks like a bicycle next to a Ferrari when compared to Silverlight”

Personally, I haven’t had a chance to look at Silverlight yet so cannot express much of an opinion. However, I find it hard to believe that Silverlight will topple Flashes dominance before Adobe responds with something equally impressive.

Although competition can never be a bad thing, it strikes me that this is yet another plugin for people to download and another platform we have to worry about developing for.

RSS in plain english

RSS can be a difficult concept to get your head around the first time you encounter it. Its still a good idea to explain what RSS is on your site for those that don’t know. Obviously you can create a page yourself explaining or sometimes I link to the BBC website which provides an excellent description. Of course if you want something a little more exciting you might want to link to this superb video that explains exactly what RSS is and how it works. Its just a shame they don’t offer the option to embed it directly into your own site.

How POSH are you?

I have to say I was very cynical about this news story when I first encountered it but after hearing Jeremy Keith’s argument on the last .net podcast I have to say I am coming around. POSH is yet another another “catchy” web acronym. It stands for “plain old semantic HTML”. So why do we need yet another acronym? Well the argument goes that nobody is getting excited about semantic HTML these days. Its just not cool. Instead we are obsessed with Microformats or AJAX, things that are perceived as being “in” and “trendy”. The POSH acronym is designed to get us talking about semantic HTML again. The idea is that we start blogging about how we mark stuff up and sharing ideas with one another. The example Jeremy gave on the show was; what is the best way to mark up a conservation in HTML? He suggested that it was simply an ordered list of blockquotes. Do you put that much thought into your code? I can’t say I always do.

So with that in mind I have opened a new section on the Boagworld forum where you can post your examples of good code. You can ask questions like; what is the best way to markup… or simply post how you choose to markup different elements. Whatever the case lets start sharing our good practice in HTML.

Client corner: Do you really need a CMS

Apart from a few ‘design only’ projects we get involved in, every tender that comes through the door includes the words “control over content is a must have”… or words to that effect.

But thinking about all the ‘full’ CMS based projects we have delivered, is that really what the client wanted/needed?

So what types of CMS solutions are there? Here’s a quick summary:

Limited CMS (non-structural) e.g.
  • News
  • Events
  • Popular a few years ago when ‘full’ CMS was a much more expensive.
  • Pros – simple to understand (and build)
  • Cons – clients tend to request more and more areas of the site become CMS controlled and you can end up with a bit of a mess and the cost of replacing can be prohibitive.
Blogging tools
  • Article based
  • With commenting
Full CMS
  • Control over structure: move pages, edit pages, create news pages (and sections) and the front end navigation updates automatically
  • Usually modular: news, events, downloads, forms (dynamic), lists, newsletter, etc
  • User management: Roles, permissions, preview, workflow
  • Licensed or bespoke?

You need to ask yourself a couple of fundamental questions:

Even if I have these tools, will I have time to use them? All websites need to have an owner or editor. Someone who’s job it is to manage all content sources and keep the site up to date. We have been asked many times to carry out work content population work on a CMS that we built…

How much of my content needs updating more than monthly and how often do I need to add new pages to my site? It seems that having the ability to extend a site is often seen as a ‘must have’ when in reality new pages are only added, say, quarterly at most. Added to that, the only content that changes regularly is, for example, news, events and case studies. Employing an agency to add new pages and manage site structure/navigation is not a big job (though some seem to charge extortionate rates). Added to that, clients who do not use a CMS very often tend to forget how to use it and then go back to the agency simply because of that.

To summarise, think very carefully about your requirements in this area and talk to prospective agencies about what they recommend. You could end up making a costly mistake.

Ask the expert: Garrett Dimon on Information Architecture

I am a huge fan of Garrett Dimon’s work and so I am really excited to have him on the show this week. Garrett’s job title is “information architect” and so unsuprisingly he joins us to share some of his experiences on working with information architecture. His advice includes:

  • Embrace constraints
  • Know when to challenge the constraints
  • Explore lots of ideas
  • Work in conjunction with clients
  • Don’t use your computer
  • Throw away more than you keep
  • Don’t worry about the details until later on
  • Simplify and cut back on details
  • Communicating is more important than documentation
  • Make your IA deliverables visual as they are easier to understand

Agony uncle: The wish list brief

This week I am back on Agony Uncle duty with an email from Dan in Swansea:

I am increasingly frustrated by the briefs I am getting through from potential clients. They read more like wishlists than real briefs. They lack focus and often ask for functionality they just don’t need. How do you respond to briefs like that?

Its a great question and set me thinking a lot about the web design process. In fact it was the primary motivation for a recent blog post on the subject which we talk about on the show. I think the key to this question is to not be afraid to go back to the client and challenge them. Perhaps propose a rough costing based on some of the items in their list but suggest that the first step (if you are taken on) would be to define and price a more accurate brief. I think most clients will respect you for suggesting an alternative and more effective strategy. In many ways its like the speculative design argument, it may feel scary to challenge the client before anything is signed but in my experience clients respond positively to a carefully thought through argument.

Review: Spoken Text

A while back I asked people to submit their own reviews. I didn’t specify that people couldn’t review their own product and so I recently received a review from Mark promoting Spoken Text. Now, I don’t want to open the flood gates to shameless self promotion but I like spoken text so much that I want to include it on the show. It is basically a free, text to speech system that allows you to convert multiple file types into audio files.

Mark shares four great reasons why he thinks we might be interested in it as web designers:

  • Use spoken text to provide alternative audio versions of the content on your website
  • Allow users to record and save any content from your website they want
  • Create a podcast of your websites content
  • Create your own podcast of other people’s content that you want to listen to while on the go

There are two things that excite me most about this service (beyond the fact that it is free). First is the accessibility benefits it could bring for visually impaired users and secondly the ability to make instant podcasts of new stories from your site without the complication of finding somebody to present it.

This isn’t a service that is useful to everyone but I think in certain circumstances this could be a killer app.

Show 77: A dream?

Posted in Classic shows on 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?).

Play

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

Show 75: Christian Bears

Posted in Classic shows on by Paul Boag

Marcus is back and talks about what to do if a client doesn’t pay. I look at clearing floats in CSS and we have Richard Rutter on the show giving us the lowdown on good web typography.

Play

Podcast: Download (22.9MB)

Download this show.

News and Events

Blogger’s code of conduct

This week has seen Tim O’Reilly pushing hard for a code of conduct among bloggers following the vicious online attacks against Kathy Sierra. Although, like everybody else, I was shocked by what Kathy has been through and although I respect Tim’s endeavors to change the current situation, I struggle to see what good a code of conduct will really do.

Tips for Bloggers

Tom Johnson has drawn together 20 principles for a successful blog based on feedback he has received from numerous top bloggers. If you are new to blogging or trying to revive a failing blog this article is definitely worth checking out.

120 Adobe Photoshop tips

Talking of tech tips, check out this superb document of over 100 things you never knew you could do in Photoshop. As a regular Photoshop user I was shocked by just how many of these I was unaware of. For example did you know that you could:

  • Straighten a crooked image using the measure tool?
  • Access key image function by right clicking the top bar of an image?
  • Modify the text on multiple text layers at the same time?

CSS Vista

The wonderful folks over at Site Vista has released a superb new tool that allows you to edit CSS files and instantly see the changes in both Firefox and Internet Explorer simultaneously. Very useful indeed although currently it is only available under windows.

Client corner: Resolving payment disputes

This week Marcus answers a question from Dan in Texas. Dan has a client who hasn’t paid and so is asking whether he should take their site down or not.

The core of Marcus’ approach is to ensure good dialogue with the client. He covers the idea that prevention is better than cure by establishing clear contracts up front but then looks at what steps can be taken if things do go wrong. We also when this happened to us at Headscape and how we resolved the dispute.

Marcus also broadens the discussion to look at it from the client’s perspective. He investigates when a client should withhold payment and how this should be discussed with the web agency.

Ask the expert: Richard Rutter on web typography

Richard Rutter is one of the three founders of Clear:Left and is passionate about typography. In fact he is so passionate that he has produced a practical guide to web typography which is freely available at webtypography.net. He therefore seemed the logical choice to introduce us to the basics of using typography on the web.

Agony Uncle: Clearing Floats

I got sent a question by Dan in Texas ages ago and I promised him we would tackle it on the show. Unfortunately I totally forgot about it until I read this recent article by Robert Nyman a couple of days back. Dan was asking about dealing with floats in CSS and how to ensure that the parent of a floated item contained it. This was exactly what Robert was talking about in his post and so I have shamelessly used his thoughts in the show to answer Dan’s question. Thanks Robert ;)

Review: Question Form

I am a great believer in giving users the chance to feedback their thoughts on a site. However its not always that easy. Online forms and email are hard to collate and all of the survey services I have found online in the past are crap. However, recently I came across a site called Question Form which really does stand head and shoulders above the competition

  • It is incredibly quick and easy to put a survey together
  • It provides a painless user experience to the user
  • You have complete customizable control over how your form looks
  • It provides excellent statistics as well as access to individual responses
  • It offers alerts of new responses via email, RSS and even SMS

The basic account is absolutely free and the pro accounts start from as little as $10. If you are thinking of adding a survey to your site then you should definitely check these guys out.

If you fancy trying a form out then take a second to complete the boagworld podcast survey.

Show 75 Script

In last week’s show I posted the rather muddled notes I use when recording the show. This was to make up for the less than perfect show notes I provide here. This idea seemed popular so here is my script from this week’s show.

Excited about client work

Posted in News on 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.

Keep it simple stupid

Posted in Web strategy on by Paul Boag

The KISS acronym has become such a cliché that we so often ignore it. After all why “keep it simple” when we can play with the latest cool bit of technology.

I often feel somewhat isolated from the web community. While everybody else is writing about AJAX and CSS techniques, I am talking about the humble hypertext link and building better forms. For a long time I have felt that as web designers we lose interest in the mundane and would much prefer to spend our time pushing the boundaries of CSS or integrating the latest Javascript widget.

You can therefore imagine my delight to read an excellent article by Gerry McGovern in which he wrote the following:

"Again and again, I meet web teams that are excited by the exceptional task, and are bored with the common task. The common task on a website may indeed be boring and often inconsequential to you because you have completed this task so often. You have learned it inside out and to you it seems simple. It seems like there is no more work needs to be done on it.

The exceptional task is much more likely to be exciting and intellectually challenging. Beware. Every time you add an exceptional task to a webpage, you make the environment more cluttered; you make it more difficult to complete the common task."

I couldn’t agree more. We need to be careful that we don’t let our attention to the basics slip in our desire to constantly push the web forward. I can understand that we find the common tasks boring. However, the very fact that they are common means that they are by far the most important, simply because users are encountering them more regularly.

Podcast 41: Building better forms

Posted in Classic shows on by Paul Boag

This week on boagworld Paul and Marcus discuss how to create better forms and how to avoid damaging your search engine rankings when launching a site redesign.

Play

Podcast: Download (20.9MB)

Download this show.

Forms are the primary method visitors use to interact with your site. They are used for everything from logging in to completing surveys. However, despite their importance, they are often not given the attention they deserve. In this week’s show we look at how to improve the usability and accessibility of your website’s forms as well as recommending some great resources on the subject.

The discussion about forms is based on a post I wrote a while back on getting forms right. If you want a blow by blow account of what was covered in this episode then that is the place to start:

Getting online forms right

I also go on to highlight three excellent resources for those interested in improving the forms on their site. The first is a site called simply accessible which provides some wonderful advice about ensuring your forms are as accessible as possible, especially for those using screen readers. The second site I recommend is an article from particle tree on 10 ways to make better forms. Although similar to my own post on the subject the content does differ so it is worth a look. Finally I also recommend you check out Form Assembly, that allows you to create and host forms while receiving responses via rss and email.

Can you help?

In this weeks show we also mentioned a couple of ways you might be able to help us out.

Headscape lead developer

The first was the fact that Headscape is looking for a new lead developer. Do you know somebody who might fit the bill? Is this a position you would be interested in applying for? For more information visit the Headscape website.

Boagworld survey

The second area we need help with is our online survey. Producing and hosting boagworld takes a lot of time and costs a lot of money. We are therefore looking at finding sponsors for the show. In order to do that we need to know more about you the listener. If you like the show and want to support it then take a few minutes to complete our online survey.

Odeon wise up

Posted in News on by Paul Boag

Credit where create it due. It is easy to criticise when there are problems but we should also be full of praise when people get it right.

No doubt, you remember the hail of criticism that Odeon cinemas received when they forced an accessible version of their cinema listings offline. The main Odeon site was so inaccessible that only users of Internet Explorer could access it. In response, an enthusiastic web developer created a more accessible alternative. Unfortunately, Odeon viewed this as a "breach of their intellectual property" and forced the owner to take it down.

I was quick at the time to add my voice to the criticism, so I feel it is only right for me to praise Odeon’s new site, which is an excellent example of good web design. The new site is built using web standards, conforms to basic accessibility guidelines and even works with Javascript and CSS disabled. They really have done an excellent job.

Like all sites, there is room for improvement. They do use flash for the selection of seats but at least they provide an alternative version (admittedly with slightly less functionality) for those without flash installed. They could conform to a higher level of accessibility and maybe even consider a low vision version. However, all of that is nit picking. They are now setting an excellent example that other large corporate would do well to follow. It is just a shame that they handled the initial dispute so badly.

Podcast 29: The great flash debate

Posted in Classic shows on by Paul Boag

Flash is one of those web technologies that always generate a lot of debate. In this episode of boagworld.com Marcus and Paul go head to head arguing the pros and cons of this controversial plug-in.

Play

Podcast: Download (21.1MB)

Download this show.

Marcus and I have never really agreed when it comes to flash. Marcus is easily seduced by anything that animates or "shows off" in someway. I on the other hand take a much more balanced view, believing that flash is the spawn of the devil adding nothing to the web but accessibility and usability problems (hell its my blog, I can be completely bias if I want!). So with that in mind we decide to fight it out in the great flash debate:

The case in favour of flash

To be frank Marcus’ argument was appallingly weak and I can barely bring myself to repeat it in these notes. However, in the interests of fairness here is the crux of his argument.

  • Macromedia claim that Flash is available on well over 90% of the world’s computers.
  • That unlike HTML, CSS and even to some degree JavaScript, Flash renders fairly consistently across all browsers. This makes it a dependable and consistent development environment.
  • There are something’s that Flash just does better or that are simply impossible using other technologies.
  • That flash is the ultimate attention grabber with flash sites being far more visually engaging than HTML sites.
  • Flash advertising has a 5 times higher click through rate than HTML adverts. This demonstrates that people respond to it better.
  • With the number of people on broadband continuing to rise there is an ever greater demand for rich media content which utilises the increased bandwidth.

The case against flash

Although I was forced to grudgingly agree with some of Marcus’ points I wasn’t willing to give up without a fight. My valiant response went something like this:

  • Despite Macromedia’s outrageous claims about availability, ultimately Flash is a plug-in and so not everybody has it.
  • Search engines find it hard to spider flash files and so can have an adverse effect on your sites ranking.
  • Flash encourages poor practices including (but not limited to):
    • Mystery meat navigation
    • Annoying animation and sound
    • The "its art damn it" argument against making the things usable
    • A failure to test across different operating systems and browsers
    • As well as being hard to spider for search engines, flash also creates all kinds of accessibility problems for speech browsers.
    • By default flash breaks the back button in your browser
    • By default flash breaks bookmarking of specific parts of your flash application.
    • It is a closed format (no view source) preventing the cross fertilisation of techniques and ideas.
    • It doesn’t print well using the default browser print functionality.
    • Flash is often bandwidth intensive so penalising dial up users.
    • A lot of corporate environments actively block flash.
    • Flash is also often reliant on JavaScript creating even more accessibility problems.

I could have gone on. For example I could have mentioned IE’s latest problems supporting flash. But I guess I had made my point :)

The happy middle ground

Although we had a lot of fun arguing our corners, the reality is far less black and white. Like all technologies Flash can be used for good or evil. It is how you use it that matters not the technology itself. Flash is great for complex applications like mapping or horrendously long forms. It’s incredible at communicating complex ideas through audio, video or animation but even in these situations it can be used badly. Unless you know exactly the audience and user platform (like for some corporate intranets) you should always offer a more accessible alternative. You should avoid making entire sites in flash and using it too heavily for navigation which can not only cause accessibility problems but also search engine ranking issues.

Have your say

So what do you think? If you had your way would you ban flash from the web. Or do you believe that flash is the next natural evolution and we can all throw our HTML books away. Let’s see if we can’t start a flame war in the comments ;)

Designing for an older audience

Posted in Design on by Paul Boag

If the average user on your site is what we would politely referred to as “mature�, then you definitely need to check out this excellent report from webCredibles.

I don’t know how it happened but somewhere along the line Headscape has ended up doing a disproportionately large amount of design work for an older audience. Perhaps this is something to do with the fact that we are an aging population with the number of people over 60 dramatically out numbering those under 16. Whatever the case, the fact that I design regularly for an older audience meant that this report from webCredibles caught my eye.

webCredibles compared 16 usability test sessions, 8 using an older audience (over 65) and 8 with a younger audience (under 40). The comparison led to a number of interesting observations as well as some excellent advice on designing for an older audience.

The recommedations

Their recommendations (with which I totally agree) included:

  • Designers should investigate innovative ways to communicate the fact that a page had not finished and requires scrolling
  • Technical terms should be avoided if possible – and where they have to be used, a clear explanation must be easily accessible (including examples wherever appropriate)
  • Links should be identified in a consistent and obvious way (e.g. blue, bold, underline, red on mouse-over)
  • The attention-grabbing features on a page (e.g. headings, pictures, icons, instructions and bullets) should be links
  • Visited links should change colour
  • Provide an HTML-version of as much content as possible and do not require users to install software (even Adobe Acrobat) in order to be able to access information
  • Make content as concise and clear as possible – consider providing two versions of the same content (‘simple’ and ‘detailed’) and allow users to decide which they want to access
  • Sites should provide a ‘Make the writing bigger’ link with accompanying illustrations/icons and always use high contrast to display text e.g. black text on an off-white background (N.B. using an off-white background is preferable to white because it reduces the chances of eyestrain for people who are slow readers)
  • Provide explicit instructions by using the imperative forms of verbs (e.g. ‘Go to more details on…’, ‘Find a…’, etc.)

Dealing with scrolling

All good advice and particularly relevant for me as I am currently working on a site aimed specifically at the over 65 market. One particular problem that I am working on is how to encourage users to scroll. It is interesting to note that although webCredibles raise this as an issue they offer no real solutions.

One possibility I am currently working on is adding a fixed position (doesn’t move when the page scrolls) message explaining there is more content below the fold. When the user clicks the message, the page automatically scrolls down revealing more content. There is a whole bunch of usability and technical problems associated with this, but it might just be a viable solution. I will let you know if I get it working.

I would be interested in hearing your thoughts on encouraging scrolling. If you have any great ideas, post a comment here.

Ecommerce 2.0?

Posted in Web strategy on by Paul Boag

There is a lot of hype surrounding the new generation of websites that are emerging. Collectively they are labelled web 2.0 applications, largely because they behave more like desktop applications than websites. The question is how the underlying principles of web 2.0 will expand beyond the current raft of “web applications” to encompass more traditional websites. For example, how can web 2.0 principles and technologies benefit a typical ecommerce site?

Google Suggest.

  • The ability to filter products on the fly without page reloads in order to narrow the selection of possible products.
  • A slicker "compare and contrast" facility that enable the user to look at products side by side.
  • The option to sort product listings by price, size or any other criteria without page reloads.
  • The option to tag favourite products or hide unwanted products from the listings
  • Saved searches that notify you by RSS when new products are realised meeting your search criteria.

    • The list could go on and may even include an open architecture that allows you to compare products across sites.

    Managing your shopping basket

    We all know that a huge percentage of shopping baskets are abandoned before checkout. The reasons for this are many and varied but a significant factor is the usability of the shopping cart process. All too often shopping baskets are unwieldy and distract from the shopping experience. Once again, Web 2.0 technologies can provide significant improvements.

    • The ability to add products to a shopping basket using drag and drop as well as the conventional "add to basket" button.
    • Persistent shopping baskets that are on screen all the time but do not need page refreshes to update.
    • Shopping baskets that are saved automatically, like draft emails in Gmail. This prevents users loosing shopping carts due to dropped connections or timeouts.
    • The ability to save shopping baskets instantly, for future repeat ordering without interrupting the current shopping process.

    The checkout process

    The checkout process is often the most painful part of the user experience and can often make or break an ecommerce site. Large ecommerce players have gone to great lengths to shorten this process with systems such as "one click ordering". However, at the end of the day you cannot avoid those forms requesting user details if you are going to fulfil your orders. Out of the three parts of the ordering process, Web 2.0 has the most to offer the checkout process:

    • Postcode auto address completion, can be taken to a completely new level that no longer required page reload.
    • Forms can be validated instantly giving the user detailed feedback about any problems with their submission.
    • Repeat purchases can be sped up dramatically, with the ability to quickly and easily change shipping address and credit card details.
    • Fewer page refreshes means less chances of information being lost in transit.
    • Greater control over the functionality of forms allows unnecessary fields to be hidden until required. Why for example display the shipping address fields unless a user specifies their billing address is different.

    I am sure that the ideas I have outlined above only scratch the surface of how "Web 2.0" can help the average ecommerce site. The point is that there is a real opportunity here to improve the user experience and in doing so the conversion rate of these sites.

    What’s new?

    A lot of the functionality I outline here already exists on ecommerce websites. Indeed, you are probably asking what makes any of this original or different. In some senses you are right, much like Web 2.0 as a whole, none of this is new. However, what I hoped to highlight in this entry is that a small group of new sites are implementing existing technologies in new and existing ways and that these techniques can be easily transferred into traditional websites to improve functionality and increase return on investment. By using a small amount of "web 2.0 technology" on top of your existing ecommerce site, you can improve your conversion rate and increase profits. Whether you like the Web 2.0 buzzword or not, surely this is worth considering.

    Stuart Langridge on Javascript

    Posted in Reviews on by Paul Boag

    Yet another live blog from the d.Construct conference here in Brighton UK. I have just been listening to Stuart Langridge speak on DOM scripting and found myself slightly concerned with some of the things he said.

    Stuart seemed to be saying at times in his presentation that DOM scripting (Javascript to you and me) gives you the opportunity to change the user experience to suit your "designs".

    AJAX can cause confusion

    I have to say this concept of creating unique user experiences for your own site concerns me somewhat. I have seen too many examples of where Javascript causes confusion instead of enhancing the user experience. I think I have already mentioned before on this blog the "drag and drop" shopping basket which contradicts peoples expectations of how to add content to your basket.

    People expect page reloads

    However, the problem is actually even more fundamental than that. The shopping basket example is a problem caused by changing the way people interact with a familiar site function. It is not surprising that something like that causes confusion. What has been more worrying are the results I have been seeing from usability testing on AJAX sites. I have seen users confused because they have expected a page to reload and it hasn’t. It is not uncommon to hear comments like "I have clicked the button but nothing has happened". Because there is not the familiar page update, users presume their requested action has not been completed. Another example was from a user testing session we recently ran on an intranet. On that site, you could add documents to the homepage by ticking a series of checkboxes. Because it was intended this form would use AJAX we didn’t need a save button. After all every time you checked or unchecked an option it was automatically saved. However, in testing we found that users were constantly looking for the option to save. They were so used to having to submit forms that it confused them when that functionality changed.

    The importance of keeping the user informed

    So although I agree with Stuart that JavaScript can be used to enhance the user experience I am not so sure we should be making fundamental changes to it just yet. When we do decide to use AJAX and JavaScript we need to keep a particular eye on ensuring the user gets the feedback they need to understand exactly what is going on.

    A grumpy old man

    I have just read through this post and realised what a miserable old sod I am. Most of the posts I have made on this site about Web 2.0 have been kind of negative and yet that is not how I feel at all. I am actually very excited about the possibilities of this new generation of sites. However, I do have a lot of questions which I need to work through. If you are reading my posts thinking I am a doom sayer I would encourage you to stick with it. I can guarantee that as I have more time to think things through my posts will become more positive!

    Getting online forms right

    Posted in Design on by Paul Boag

    At the end of last week, I was integrating an online survey into a client’s site. It started me thinking about how difficult it can be to get online forms right. In this post, I outline just some of the many things you should take into consideration.

    With the exception of the home page, online forms are probably the biggest challenge to us as web interface designers. This is largely because online forms require a higher degree of interaction than any other part of a site and so there is more room for error.

    Web Forms Checklist

    With that in mind, here is my checklist for designing an effective web form:

    Make a form look like a form

    Too many designers mess with form fields so that it is nearly impossible to identify them as editable. Sure, form fields can look ugly but there visual appearance helps people identify them as a form. Some styling is fine but don’t make them unrecognisable.

    Stay focused

    Everybody hates getting spam. We are suspicious of giving out personal information online for fear that the information will be used to send us junk. Do not ask users for information that you do not absolutely require. They will tend to see anything extra as an invasion of their privacy and an attempt to spam them.

    Keep it short

    Marketing departments have a habit of wanting to know everything about their visitors. The result is that forms become overwhelmingly long and users just don’t bother completing them.

    Turn long forms into applications

    Once an online form goes beyond two screens, it’s often a sign that the underlying functionality is better supported by an application, which offers a more interactive user experience.

    Provide timescales

    If the user cannot see how long the form is, they will assume it takes a long time to complete. In many cases, they give up before they begin. Reassure the user that the form will take only a few minutes of their time.

    Inform of progress

    If a form is split over multiple pages, the user can be left wondering how many more screens there are to go. I have seen people give up only one click away from finishing! By telling them how much of the form is left, you encourage them to persevere.

    Only show relevant fields

    Some fields in your form maybe conditional on other answers given. For example, you may have a question "Do you have children?" and a second question "How many children do you have?" Obviously if they answer no to the first question then the second becomes irrelevant. Make your form appear shorter by either combining these questions or only revealing the second one if they answer yes to the first.

    Use the mandatory fields sparingly

    Forms failing to submit properly because mandatory fields were not completed can be an annoying experience. It is therefore advisable to use required fields only when entirely necessary and to mark clearly, which fields are required.

    Avoid re-entry

    There is nothing more annoying than constantly inputting the same information. Store users details so that reoccurring fields are pre populated. Also make sure that information is not lost if the user accidentally navigates away from the page.

    Clear validation

    It can often be hard to spot which fields you failed to complete correctly. By clearly marking the problem fields, you dramatically improve the user’s experience.

    Avoid reset buttons

    Personally, I don’t think it is worth having a reset button on a form anyway, but when you do ensure you don’t put it near the submit button. It is very easy for users to click the wrong one and find themselves back at square one.

    Highlight the current field

    On long complex forms, it can sometimes be hard to spot which field contains your cursor. Use CSS or JavaScript to highlight visually the current field.

    Ensure a logical tab order

    Many visitors use the tab key to move between fields in a form. Make sure the fields tab through in a logical order and where possible remove tabs from elements such as labels or links where that interrupts the flow of the tab order.

    Use fieldsets and labels

    Usability for speech and text browsers is dramatically improved by marking up your form with the relevant fieldsets and labels.

    Place labels before fields

    Because visually impaired users cannot see a form field, they are reliant on the label associated with the field to describe it. However, if the label appears after the field they are not told what the field is for until they have moved past the field itself.

    Offer an incentive

    Because forms often require users to part with personal details, they are naturally reluctant to complete them. Users need a clear incentive to part with their information. What that incentive is depends on your site. For some it could be as simple as access to site features such as a forum, for others it might be an entry into a price draw or a free reward of some kind.

    Explain the need for information

    When you are requesting personal information, explain why you require it. For example, if you request an email address for an ecommerce purchase, explain that it is required for informing the user of their orders status and nothing more. If you don’t explain, they will presume the worst.

    Clear help

    For more complex fields make sure you provide clear instructions. For example if you require the security number from a credit card, explain where this can be found and what part of the number you require.

    Saving forms

    It is generally good practice to allow users to save forms and return to them later. This is particularly true of longer forms where the user might have to look up some of the information required.

    Your opinion

    So, that is my checklist for designing forms. Did I miss anything? Do you disagree with anything I have said? Let me know what you think.

    Print designers and the web

    Posted in Design on by Paul Boag

    I often find myself working along side traditional marketing agencies when developing websites. However, today is the first time that I have seen a client’s website suffer because of it.

    I like to think Headscape are a talented bunch. Certainly based on the feedback from our clients we do a reasonable job. However, for the first time ever we have come across a client who we seem incapable of pleasing.

    Currently we are working on a project where we have produced three separate designs for the client. We have gone through endless iterations and have really tried to take onboard their comments. I can honestly say that the design work we have produced for them is some of the best we have done. However, despite all of that we have failed. We have failed to find something the client likes.

    Although we still have a good working relationship with the client, they have decided to get their marketing agency to do the design work for the site. Today I got my first look at what they have produced and frankly, my heart sank.

    Print designers failings

    Okay, we all know that design is subjective. Just because I visually don’t like the design a lot, doesn’t mean it is actually bad. However, it does suffer from some of the classic problems associated with a print agency producing screen based design. Here are a few of the issues I have spotted:

    Resolution

    One of the most common mistakes made by print agencies working on web design is that they take no account of screen resolution. The design proposed by this agency would involve sideward scrolling at 800 by 600. Not a problem you face with a nice printed brochure!

    Colour palette

    Colours that work well in print just don’t always work on screen. Reading online is bad enough anyway without choosing colours that buzz or just break up at low resolutions.

    Accessibility

    Accessibility isn’t something that is often considered in print material but is vitally important on the web. Forms without submit buttons, designs that can only be built with JavaScript and form fields that don’t look like form fields are just a few of the mistakes often made by print designers.

    Technological constraints

    Print designers just don’t have a grasp of the technological constraints on the web. The limited number of fonts, the layout restrictions of content management systems, the quirks of different browsers (in rendering HTML & CSS), the list could go on. Understanding your medium is vital to creating a successful design.

    Usability

    Probably the biggest failing of print designers who work on websites is their failure to understand how users interact with websites. Print designers often just try and replicate a brochure online. They don’t take into account that users don’t like to read big blocks of text, or hate to scroll. They don’t grasp that web users skim read pages trying to quickly find key content. The result is that you see designs that use multiple columns of text with little to break it up into blocks.

    For me using columns of text, such as you would find in a printed publication, is the ultimate print designer’s failing. Not only is it hard to scan but also involves constant scrolling up and down the page.

    Our failings

    I would love to be able to post the design here and allow you to compare it to the ones we produced but that would be unfair on the client. The problem is that the client is more used to offline printed material than the web and so they are heavily influenced by what the print agency produces. That’s not the clients fault, that is a failing on our part to educate the client about the realities of web design.

    So what about you? Have you come across similar problems? Are their other common mistakes I have missed? Add your comments.

    The role of automated accessibility testing

    Posted in Accessibility on by Paul Boag

    Many tools on the market automate the process of checking for website accessibility. However, there are some serious question marks over the value of such tools.

    There are many different reasons why automated checkers have limited value. However, the forthcoming Government Guidelines on Accessibility provide a very neat summary:

    "…automated tools are like spell checkers – they look for obvious problems within a web page, and then generate a list of possible problems. They cannot give a straightforward statement of whether your website meets certain accessibility standards. The list of possible problems needs to be interpreted by an experienced person and matched against what your site is actually doing. There is a substantial list of accessibility issues (at least 50%) that cannot be assessed by current automatic tools…"

    Subjective decision making

    The Government Guidelines on Accessibility show us that automated checking alone cannot be trusted. Computers are great at answering questions with yes/no answer. They are not so good at making subjective decisions. So for example a computer can easily tell you if an image has an associated alt tag but it cannot tell you if that alt tag is really descriptive of the image or not. As is stated above at least 50% of the WAI guidelines require subjective decision-making and so require a manual check.

    It is this need for manual checking that undermines the primary, timesaving benefits of automated tools. An automated checker can scan a page and give it the "all clear" but you still need to visit that page to ensure it conforms to the subjective checkpoints.

    Can even the automated checks be trusted?

    It is also important to question the reliability of checks made by automated tools. I believe that practically all of the checks made by accessibility checkers also need to be checked manually. This is because automated tools are based on certain assumptions. The algorithm that the tools uses to assess a website are entirely dependent on the developers own interpretation of guidelines which are often entirely subjective.

    When an automated tool flags up an error, it is the developer’s interpretation of the checkpoint that is being tested, and not necessarily the checkpoint itself. It is important when using automated testing tools to have an informed opinion on all web accessibility issues in order to be able to verify results.

    Some accessibility issues are not covered by WCAG guidelines
    It is possible to create a website that complies with WCAG guidelines and still presents accessibility barriers. A site that has text that is not fixed in size but scales between "1pt" and "4pt" technically meets Web Content Accessibility Guidelines. It will incidentally pass through most automated testing tools. Yet it would not only make the site inaccessible to disabled people, it would be inaccessible to most people. Ironically, the only people likely to be able to use the site without altering their browser settings would be screen reader users who would not be affected by text size. So while measuring accessibility using WCAG guidelines is undeniably the best starting point, there is more to accessibility than a list of checkboxes.

    There is still a place for automated testing

    So is there no place for automated tools? Well personally, I cannot bring myself to claim they are redundant. After all, my first tentative step into the world of accessibility was to use Bobby. If it had not been for that automated checker I could well have been put off by the intimidating WAI checkpoints. Surely, if all you do is check your site using an automated tool then this is still better than doing nothing at all. The danger is that you never move beyond that and recognise that web accessibility is a much more complex and subjective than a set of automated checkpoints.

    My thanks to Ian Dunmore of Public Sector Forums and Grant Broome from the Shaw Trust for their contribution to this post.

    Fact: Users take their time purchasing

    Posted in Marketing on by Paul Boag

    There is nothing like cold hard facts. For years, most of us that work with ecommerce sites have known that users do not always purchase on their first visit. Now we have the facts to back it up… enter clever boffin Dr. Alan Rimm-Kaufman.

    Dr. Alan Rimm-Kaufman from the Rimm-Kaufman Group recently tracked one million clicks (boy that must have been fun!) on search ads on Google and Yahoo. His results showed some interesting stuff:

    • 50% of the conversions occurred within 28 minutes
    • 75% of the conversions had occurred within 24 hours
    • 95% of the conversions had occurred within 12 days
    • The remaining 5% took as long as four weeks after the initial click

    Unsurprisingly the larger the value of goods being purchased, the greater the delay to conversion. For items costing less than $100, 90% of orders were received within eleven days. For items costing more than $300, it took eighteen days to reach that level.

    This is because people needed time to view the competition and consider their choice before purchasing.

    Design implications

    Jakob Neilsen, who commented on this report, identified a number of design implications worth taking into account:

    • If you use cookies to track users make sure you set an expiry date of at least 90 days otherwise you will loose track of some conversions.
    • Users will often need to visit your site multiple times before making a purchase so make sure you have provided incentives to keep them coming back.
    • Don’t make premature demands on users who aren’t ready to buy. For example, don’t require registration to see a demo.
    • Make sure that a users shopping cart is available across multiple visits.
    • Retain the special landing pages for search ads and other campaigns for at least three months after the campaign ends.

    Jakob concludes with this:

    In general, the slow tail tells you that not all users are ready to commit on the spot. Don’t rush them. Let users browse your site and gradually learn about your products, while making it easy for them to buy during future visits.

    Good advice that I would encourage all to stick with.

    Web design podcast episode 3

    Posted in Classic shows on by Paul Boag

    On this weeks boagworld.com I am joined by Marcus Lillington. Not because he has anything particularly insightful to share but simply to avoid you having to listen to me droning on for half an hour unaccompanied! Our main subject for this week is the top ten mistakes made by clients.

    Play

    Podcast: Download (28.7MB)

    To download the latest podcast click here.

    Below is a brief outline of the things covered in this week’s podcast as well as links to some of the articles mentioned:

    Top 10 client mistakes

    In no particular order here is our top ten mistakes made by clients:

    Marketing departments gone mad

    Why is it marketing departments are obsessed with collecting personal details even at the cost of alienating potential customers… read my article on marketing department and forms.

    Unrealistic deadlines

    Clients should not consider their website as an afterthought that is left to the last minute. Developing a decent website takes longer than you think!

    Budget

    Clients need to be willing to discuss budget with web design companies. Firstly, this will enable them to see if their budget is realistic and secondly it will allow the web design company to work around budgetary constraints.

    Design by committee

    Design is subjective so the more people involved in choosing the greater the chance of ending up compromising on the lowest common denominator.

    Copying the competition

    Although it is good to keep consistency of terminology and navigation with the competition in order to help users who are "shopping around", it is also important to stand out from the crowd.

    Creeping specifications

    It is inevitable that a client will think of more features they wish to add to their website during development. However, we encourage them to implement these ideas in a second phase. This will stop the deadline for the project slipping and give them a second chance to promote the site when the new features are added.

    Failing to consider the breath of platforms

    Many clients only care what their website looks like on their own PC presuming that the site will look the same for everybody. It is important to remember that resolution, monitor type, device, operating system and video drivers all effect the appearance of your site.

    Not considering site promotion

    It is amazing how many people still do not consider promoting their site but rather expect people to magically find it. Still more believe that search engine placement is all that matters. A website should be integrated into your overall marketing strategy… read more about promoting your site.

    Under estimating the clients role

    It is easy to forget just how much a client has to contribute to a sites development. From copy to review and testing, the client’s role is vital and they need to set aside sufficient time to focus on the websites development.

    Failing to keep content fresh

    Many clients allow their sites to stagnate once it goes live. By doing so they undermine the companies credibility and fail to provide motivation for users to return to the site again to see what has changed… read more about generating repeat traffic.

    News

    A new web design podcast almost!

    I thought I had found a new podcast dedicated to web design on itunes but it appears it is not yet live. Keep an eye on Livemotionstudio. Since recording episode three I have spotted another new podcast called ericd.netwhich is dedicated to the more technical side of web design.

    Accessibility business case

    If you are looking for a water tight business case for making your site accessible then check out the new W3C article on web accessibility.

    A new live chat system is launched

    There is a new flash-based live chat system. Not only can you chat with visitors to your site using instant messaging but you can also see them and here them too! If you haven’t encountered live chat before read my article on the subject.

    Macromedia Podcast

    Macromedia has launched a podcast that provides help and support to users of their Studio suite of products.

    Review

    Did not have time for a review this week because Marcus talks too much :)

    Using forms with care

    Posted in User experience on by Paul Boag

    Marketers, know your limits! Why is it that so many marketing departments seem determined to make it difficult for people to contact them?

    The majority of clients I work for come from a marketing background and it is surprising how often I find myself having the same discussion with them time and again.

    Unhealthy obsession

    Marketing departments often become obsessed with gathering contact and demographic information on potential visitors at the cost of all else. The problem is, we the public know this and that the more personal information we provide the more junk correspondence we will receive. As a result, we hate giving out any information at all and only recognise the need to do so if we can directly relate the information being provided with getting what we want.

    This conflict between what marketers want and what the public is willing to give manifests itself in two key ways:

    Access all areas

    Don’t you just hate it when you have to complete a form before you are given access to certain content on a site? You are often required to do it before you are allowed access to an online demo of a product. Why? The marketer might try to convince you they are doing it to make sure you are not the competition trying to steal their ideas. However, we know the truth; we know they are going to plague us with endless calls and emails if we hand over our contact details. The majority of users understand that their contact information is of value and do not see why they should hand it over in return for you being allowed to sell to them through your online demo. It is the equivalent to paying a used car sales man to sell you a car! It is a one sided deal where the user gets nothing.

    From a marketers perspective it is beyond me why any marketer would want to put barriers between potential customers and the opportunity of them seeing what you have to sell!

    Putting barriers like this up also sucks from a "quality of lead" perspective. Forcing a user to provide contact information at such an early stage of the sales process (while the user just wants to browse your site) means they are not ready for the final sale. When a user chooses to contact you, it means they are ready to make more of a commitment.

    Tell us the name of your dog

    The second mistake is the contact us form. When a user arrives at a contact us form they see it as a way to say, "I’m ready to talk now, get in touch with me". With that in mind, they anticipate providing the minimum amount of information to make that possible; name, telephone number, email address and possibly a comments field. Marketers on the other hand see this as an opportunity to find out everything there is to know about the customer from their shoe size to the name of their dog. The user will resent giving information that does not directly relate to their enquiry.

    Recently I had a client who wanted seventeen fields on their contact us form! Seventeen! Setting aside the users’ annoyance at having to complete all those fields, I very much doubt they could be bothered to fill them all in. The marketers answer to this problem, make all the fields compulsory! The result is that you cannot contact this company unless you have a mobile, an email address, and a landline. If you do not own a mobile, you are not worthy of their attention.

    And the morale of this story

    So if you are a marketer, learn these four simple lessons:

    • Users hate forms and providing personal information
    • Do not ask for more than is absolutely necessary to answer the users query
    • Use required fields for good, not evil.
    • Never ask user to complete a form to access your sales information

    If you follow these simple steps, you may see a decline in sales leads but you will see a dramatic jump in the quality of those leads and therefore an increase in sales.