10 ways to orientate users on your site

Imagine you’re driving along and due to a road closure you have to follow those conspicuous yellow detour signs. You’re now on an unfamiliar road, but because of the signs you confidently proceed, comfortable in trusting the arrows to tell you where you need to go.

Then there’s a roundabout and no sign. Do you turn left? Right? You’re lost and have two choices; turn back and find an alternate road you know well or blindly drive around and hope for the best.

Websites are very similar, no matter what their ultimate goal is, your site visitors need to intuitively find their way around. Too often, general website navigation and orientation disappears or changes on internal pages.

In fact, with websites this point is even more pertinent as users can just ‘evaporate’ and leave your site, instead of being forced to drive around aimlessly!

Usability Testing Guidelines

In professional web design circles, the usability testing session has become an essential component of any major project. Similar to focus groups in brand development and product launches, usability testing offers a rare opportunity to receive feedback from the very people the website is aimed at – before it’s too late to do anything about it.But how can you get the most from these usability testing sessions?

1. Choosing your subjects

As with any market research project, the results will only be as good as the people you test. Do not test people from your own company, or friends and family. Go to a market research firm or temp agency and ask them to source participants to a certain profile. Make sure the market research firm does not provide the name of the company or any other details that will cloud the judgement of the participants.

2. Before the usability testing

As with everything in life, first impressions are vital. Each participant must be put at ease. Remember, the usability testing session is often an extremely artificial environment and, for the most beneficial and informative results, we want them to behave as if they were using the site at home or work. Provide clear instructions on how to get to the usability testing location, and if necessary meet the participants at local stations. Do not use terms such as ?usability testing? or ?market research?, as these can confuse and put people on edge. Also, ensure that participants know how long the usability testing will take, and the type of tasks they will be expected to perform. After the initial greeting and welcoming drinks, there are always legal forms that must be signed. It is essential that these are written in plain English, and are as short as possible. The last thing any nervous usability testing subject wants is to be given a contract that looks like they’re signing their soul away. All you want is for them to be reassured that the tests are completely confidential, and for permission to use the data generated during the test as part of our results. So tell them that.

Why Usability?

This tutorial brought to you by Webnauts Net

The Usability Expert Jakob Nielsen says: “On the Web, usability is a necessary condition for survival. If a web site is difficult to use, people leave. If the homepage fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a web site, they leave. If a web site’s information is hard to read or doesn’t answer users’ key questions, they leave. Note a pattern here? There’s no such thing as a user reading a web site manual or otherwise spending much time trying to figure out an interface. There are plenty of other web sites available; leaving is the first line of defense when users encounter a difficulty.” –

Full Story: http://www.useit.com/alertbox/20030825.html

Is your web site usable?

There are several definitions for usability, but basically products which have the following 6 characteristics, can be considered as usable.

  • Quick and easy to learn
  • Efficient to use
  • Allows rapid recovery from errors
  • Easy to remember
  • Using is enjoyable
  • Aesthetically pleasing

Does your product have the above characteristics?

User and Provider benefits:

Usability increases benefits for both parties: the User and the web site Provider.

Users benefits:

  • Users are satisfied, instead of being frustrated when interacting over the web site.
  • They achieve their goals effectively and efficiently.
  • They cultivate confidence and trust in the product.

In other words, satisfied users, become loyal, going on using the web site, and also recommend to others.

Providers benefits:

  • Reduced development time and costs.
  • Reduced support costs.
  • Reduced user errors.
  • Reduced training time and costs.
  • Return on Investment.

Usability Can Save Your Company!

John S. Rhodes, Editor and Webmaster at WebWorldPro says: “Data indicate that usability offers a better return on investment than almost any other business action. When times get rough, usability shines. The benefits are huge. Usability is a weapon that can save you money, improve your competitive position, and improve customer loyalty. Now is the time to invest in the research.” –

Full Story: http://webword.com/moving/savecompany.html

After all, making your web site usable, you will make your visitors and your wallet more comfortable and happier!

WCAG 2.0: W3C accessibility guidelines evaluated

The second version of the Web Content Accessibility Guidelines (WCAG) is in final working draft and will soon be officially released. Version 1 of the guidelines came under much criticism for being vague, full of jargon and extremely difficult to use. The W3C has been working on version 2.0 of the guidelines for over 5 years now, but has it been worth the wait?

What’s good about WCAG 2.0?

There have certainly been a number of improvements made to the new guidelines. This is of course to be expected – after 5 years you would expect some improvement! Some of these improvements include:

Outdated guidelines removed

A number of guidelines from WCAG 1.0 are well out-of-date. Unfortunately, web developers still implement these out-dated guidelines because they don’t know otherwise. Rather than go on an accessibility training course and learn ‘real-world’ accessibility, many web developers and manager tick boxes against guidelines.

Some of the out-of-date WCAG 1.0 guidelines, which have been removed from WCAG 2.0 include:

  • 1.5 – Provide equivalent text links for links within client-side image maps
  • 5.6 – Provide abbreviations for table header labels, if you use these
  • 9.5 – Use accesskeys (keyboard shortcuts) for important links
  • 10.3 – Don’t use tables with more than one column for layout
  • 10.4 – Make sure form fields aren’t empty by default
  • 10.5 – Ensure different links have non-link text between them

(Please note, the above isn’t the exact wording of the guidelines – each of the original guidelines has been translated from the official W3C guideline into more easy-to-understand language.)

The above guidelines have all been removed from WCAG 2.0, so shouldn’t be adhered to.

Good real world techniques provided

The document, Techniques for WCAG 2.0 replaces the previous techniques document, and is actually much better. It provides a list of common failures, which the previous version didn’t, and actually offers some excellent examples of common errors.

The other major improvement in this techniques document is that the examples provided are far more real-world. The WCAG 1.0 techniques document used text such as PortMaster 3 with ComOS 3.7.1 in their examples, but who has any idea what this means? The new document is far better in this respect, using examples such as phone numbers and calendars, for example.

The techniques document also provides some clever recommendations, which accessibility guideline box-ticking developers wouldn’t perhaps have thought have. For example:

  • How to open a link in a new window using unobtrusive JavaScript
  • Displaying decorative images through CSS
  • Combining text and its adjacent image in the same link
  • Providing a heading at the beginning of each section on the page

…And many more! Do have a good look at the WCAG 2.0 techniques document as there’s lots of useful guidance here using quite easy-to-understand examples.

New guidelines included

A number of new guidelines have been brought into WCAG 2.0. Some of these guidelines are totally new whereas others were hinted at, but not specifically stated, in WCAG 1.0. Some examples include:

  • Providing text-based error messages for forms
  • Ensure all pages have a descriptive title
  • Background noise can be turned off

For a full list of brand new guidelines that don’t map to any version 1 guidelines, have a look at the W3C‘s Comparison of WCAG 1.0 checkpoints to WCAG 2.0.

What’s not good about WCAG 2.0?

So there certainly have been some improvements made to the W3C accessibility guidelines. But is it all good news? Have the problems associated with WCAG 1.0 been eliminated for this version 2 of the guidelines? Well not quite, as there are still a number of problems…

Verbose and jargon-filled language

One of the main criticisms aimed at WCAG 1.0 was the complexity of the language used. Have things improved? Hardly! Pretty much every paragraph is littered with jargon that the average web developer or web manager would be left with no clue as to the meaning.

Clearly aware of the level of jargon, the W3C have made complex terms green underlined links, linking to definitions. This is all well and good in theory, but when most sentences are broken up with one or two links it makes reading these sentences quite difficult.

Even worse though, is that the definitions are just as jargon-filled and difficult to understand as the term being defined! For example:

  • Authored unit – Set of material created as a single body by an author
  • Programmatically determined – Determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users in different modalities
  • Specific sensory experience – A sensory experience that is not purely decorative and does not primarily convey important information or perform a function
  • Web unit – A collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

Ironically, there’s even a definition provided for the word ‘jargon’!

Furthermore, it seems that some jargon used in WCAG 1.0, which webmasters have gotten used to, has been replaced with equally incomprehensible words. For example, we no longer have Priority 1, 2 and 3 to aim for – instead we now have success criteria level 1, 2 and 3.

Awful usability

Another major criticism of the WCAG 1.0 guidelines was how difficult it is to find specific guidance and answers. It doesn’t take too long to discover that the WCAG 2.0 guidelines quite clearly offer the same low level of usability.

Reasons for this poor usability include:

  • The level of jargon and complexity of language is truly phenomenal (as outlined above)
  • The text is littered with links making it very difficult to read
  • The two main documents, Understanding WCAG 2.0 and Techniques for WCAG 2.0 are 164 and 363 pages long in total (when doing a print preview)

If only the W3C carried out basic usability testing of how people actually use (or are unable to use) these guidelines! What they’d undoubtedly find is that users won’t understand most guidelines and will end up blindly clicking links to find out how to meet these guidelines.

As with WCAG 1.0, clicking on most links from the WCAG 2.0 guidelines simply takes users into the middle of massive pages full of difficult-to-understand text. The text, of course, is densely littered with links. Users will probably click on a link again in the desperate hope that they’ll somehow find some text that clearly and succinctly explains what they need to do. They’ll usually be disappointed.

Organising the massive amount of content available is certainly not an easy task – but why not, as a start, split up these massive documents into more manageable and less intimidating sets of smaller documents? Then, carry out some usability testing, refine, and test again.

Useful guidelines gone

Although there are a number of useful, new guidelines in WCAG 2.0, a number of important guidelines from WCAG 1.0 have been removed or are only vaguely referred to. These include, but aren’t limited to:

  • 3.1 – Avoid embedding text within images.
  • 3.2 – Create documents that validate.
  • 3.3 – Use CSS and not tables for layout.
  • 3.4 – Ensure text is resizable.
  • 12.3 – Divide large blocks of information into more manageable groups where natural and appropriate.
  • 13.8 – Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
  • 14.1 – Use clear and simple language.

(Please note, the above isn’t the exact wording of the guidelines – each of the original guidelines has been translated from the official W3C guideline into more easy-to-understand language.)

Particularly worrying is the removal of the final three guidelines, all of which relate to the accessibility of content. A major part of any website’s accessibility, and one that’s often overlooked, is the site’s usability and how the content is written and structured.

Accessible content is crucial for all special needs users, particularly those with learning difficulties and dyslexia. Perhaps the reason these guidelines have been removed is because content guidelines are fluffier and harder to measure than technical accessibility guidelines. Whatever the reason, this is not a good step for accessibility.

Technology neutral and the concept of the baseline

WCAG 1.0 states quite clearly that alternatives to JavaScript, PDFs and Flash must all be provided, as assistive technologies such as screen readers can’t access these. Although this was generally true in 1999, it’s not the case now, and nowadays JavaScript, PDFs and Flash can all be made accessible to most assistive technologies. (Remember, ‘can be’ is not the same as ‘are’.)

Version 1 of the accessibility guidelines became quite outdated rather quickly. To prevent this from happening to version 2 of the accessibility guidelines, the W3C have attempted to make WCAG 2.0 technology-neutral. Sounds sensible as now the guidelines won’t become outdated so quickly, right?

In practice, what this means is that the WCAG 2.0 guidelines are extremely vague. So vague, in fact, that they’re almost unusable as they talk in such generic terms.

Additionally, the concept of the baseline has now been introduced, where by webmasters can claim which technologies they assume are supported by site visitors’ browsers. So, if you build a website entirely in Flash and say that Flash is part of your baseline, your website can conform with all the guidelines despite the fact that some people won’t be able to access your site at all!

Discussion

So, was the wait worth it? We’ve waited over 5 years for WCAG 2.0 and certainly a number of improvements have been made. Worryingly though, the guidelines continue to be very difficult to actually use, further discouraging webmasters from reading them. The extra vagueness of these new guidelines certainly doesn’t help either.

The W3C just doesn’t seem to get it: People don’t generally want to read through hundreds of pages of text to find out how to implement accessible solutions – they just want answers and specific guidance. For most people, accessibility is just one small part of their job and they don’t have time for all this.

Webmasters are also now being asked to choose a baseline for their website but how do they even begin to go about doing this!? How would you as a web developer explain the concept of a baseline to senior management? How do you decide what you should do so as to comply with any legal requirements? Unfortunately there’s no correct answer to either of these questions.

Solution?

A solution could be that the W3C simply provides specific guidelines for what web developers and managers actually have to do. Much of this information is already there on their website, but it’s hidden away in the enormous and intimidating Techniques for WCAG 2.0 document. This document could be broken down into manageable chunks, added to and refined, and focus on providing specific, real world guidelines.

Guidelines should be relevant and specific to today’s technology, but would be updated on an on-going basis so as to make sure they don’t become too dated. Why did we have to wait over five years for version 2.0? Why couldn’t we have received versions 1.1, 1.2, 1.3 and so on during this time? This would surely have prevented WCAG 1.0 becoming out-dated as quickly as it did?

Most importantly though, the whole WCAG 2.0 section on the W3C website needs to have usability testing carried out on it. The benefits of usability testing are pretty well known by now, and it’s quite clear that the W3C has very little idea how real users are interacting with the website. By carrying out ongoing usability testing, the W3C can learn about its users and ultimately aim for an easy-to-understand and intuitive website.

This article was written by Trenton Moss. Trenton’s crazy about web usability and accessibility – so crazy that he went and started his own web usability and accessibility consultancy to help make the Internet a better place for everyone. He’s extremely good at accessibility consulting and spends much of his time doing DOM scripting & accessible JavaScript.

Usability Testing with Children

Usability testing with children is similar in many respects to usability testing with adults. In order to get the most out of the sessions, and ensure the child is comfortable and happy, there are a few differences that you need to be aware of.

Stress of new people and surroundings

Children are far more likely than adults to find encountering new places and people stressful. You should always remember this, so try to find as many ways as possible to relax the child. Some things you could do are:

  • Allow a significant period of time – at least 10 minutes – to meet the child. This is critical in putting them at ease before beginning the session. Some easy things to talk about might be computer games, cartoons, sports or school. Trying to make all the equipment used during the session match that which the child uses at home/school (phone up their parents/teachers beforehand to check).
  • Try to be as comforting and reassuring as possible. It’s especially important to make it clear to the child that you want their views on the site and that you’re not testing them.
  • Plan for the fact that younger children may prefer their parents to remain in the testing room with them. Make sure that parents know that they should stay out of the child’s line-of-sight and not help or distract them.

Asking for help

Children are far more used to asking for – and receiving – help than adults, so it’s very important for the moderator to:

  • Clearly explain at the beginning of the test that you want the child to use the site on their own
  • Make a sustained effort to deflect any such questioning during the session itself

Good ways of deflecting questions can include:

  • Answering a question with a question (e.g. What do you think [you should do now]?)
  • Re-stating that you want the child to use the site ‘on their own’
  • Asking the child to have ‘one last go’ before you move on to something else

Children get tired, bored and discouraged more easily

Children (especially of younger ages) are less inclined – and/or able – to apply themselves to a single task for a prolonged period. Some ways to work around this are:

  • Limiting sessions to 1 hour or less.
  • Taking short breaks during sessions if the child becomes tired or irritable.
  • Ensuring that sessions cover the intended tasks/scenarios in a different order – this will make sure that the same scenarios are not always tested by tired children, who are less likely to succeed/persevere.
  • Asking the child for help so as to provide them with motivation (e.g. asking ‘Could you please find out for me how to…’, or by actually pretending to not be able find/do something on the site).
  • Keeping up a steady stream of encouragement and positive feedback (“You’re doing really well and telling us lots of useful things – it will really help make the site better. Keep it up!”).

The importance of non-verbal cues

Children can’t always be relied upon to verbally articulate their thoughts/feelings, either due to their:

  • Not being articulate enough
  • Being too shy
  • Not wanting to say the wrong thing and displease an adult
  • Saying things they don’t believe just to please the adult

This makes it particularly important that the usability expert be sensitive to children’s non-verbal cues, such as:

  • Sighs
  • Smiles
  • Frowns
  • Yawns
  • Fidgeting
  • Laughing
  • Swaying
  • Body angle and posture

Physical differences

A couple of very obvious – but easily forgotten – differences which need to be taken into account are:

  • Chair and table settings – Make sure you have a chair/table setting that allows the child to comfortably use the equipment during the session.
  • Microphone positioning – Children tend to have quieter voices than adults, so microphones should be placed slightly nearer to the participant than normal.

Levels of literacy and understanding

It is critical to ensure that a session’s participant has an accurate understanding of the scenario being presented to them. Some ways to do this include:

  • Asking participants to re-phrase scenarios/goals in their own words.
  • Asking participants to repeat a scenario (i.e. what they are trying to achieve) if the task has gone on for some time and you suspect they may have forgotten it.

This article was written by Tim Fidgeon, Head of Usability at Webcredible. He’s crazy about usability and runs Webcredible’s writing for the web training and is passionate about user centered design.

Usability Page Breakdown

You know exactly what your organisation does and what your website offers its users. This information has probably become second nature to you, but first-time visitors to your site won’t know this. As such, make sure you don’t forget to tell them what you do.

As soon as new site visitors arrive at your website the first thing they need to know, before anything else, is what you do. You can talk all you like about how great you are, but unless you spell out what you actually do, they won’t even know what you’re so great at! This oh-so-overlooked yet such basic of information can be communicated to your site visitors in a number of different ways:

Page title

Don’t just use the page title to tell me who you are; tell me what you do too. If your company is called Bloggs Ltd don’t only place the words, ‘Bloggs Ltd’ in the page title as there’s plenty of room for more information. If Bloggs Ltd sells widgets, a good page title might be: ‘Bloggs Ltd – Buy widgets online‘.

Note in this example, ‘Buy widgets online‘ was used to describe what Bloggs Ltd does, and not ‘Widget seller’. When describing what it is you do be sure to speak the language of your users, and don’t talk from your point of view. From your point of view you sell widgets, but from their point of view they want to buy widgets online, so do bear this in mind when authoring the page title.

The page title is the first thing that appears on screen, and especially on dial-up modems can be the only thing that displays for the first 10 seconds or so. For many web users this is the first piece of content they’ll read on your site.

The page title is also very important for search engines, which place more importance on the page title than any other on-page element. Descriptive page titles are also essential for blind web users utilising screen readers, as it’s the first thing that gets read aloud to them upon arriving at the page.

Tagline

A good tagline is one of the most important usability features on any website. A good tagline should be explanatory and not vague, clear and informative and about four to eight words in length. A tagline is different to a company slogan, in that the former describes what the organisation/website does whereas the latter is designed to evoke certain feeling or create a brand.

‘Priceless’ and ‘I’m loving it’ are slogans by Mastercard and McDonald’s respectively – they differ from taglines because they don’t describe what the organisation does.

Taglines are so important because no matter on what page site visitors enter your website, they’ll always be able to quickly gain an understanding of what your organisation and website offers. This can be especially true for site visitors coming into internal pages from search engines – by telling these site visitors what you do through the tagline, they may be more likely to explore your site beyond the initial page on which they enter.

Taglines are also good for search engine optimisation, as they appear on every page right at the top of the page, an area on to which search engines place importance.

Main heading

The main heading on the homepage is one of the first pieces of text web users notice, especially on clean well laid out websites. Sticking a ‘Welcome to our website’ may seem to be friendly and welcoming to you, but to task-driven site visitors it doesn’t help in any way shape or form. A quick summary of what you do and/or what the website offers, in just four or five words can be highly effective (and very search engine friendly too!).

Opening paragraph

Perhaps the most important place on the homepage to tell your site visitors what you do, the opening paragraph must be short, succinct and straight-to-the-point. Just one sentence is enough to put across this most basic yet fundamental of information.

When writing this opening paragraph, remember to front-load the content (this rule actually applies to every paragraph on the website). Front-loading means putting the conclusion first, followed by the when, what, where and how.

Don’t write a story with a start, middle and conclusion – generally speaking on the web, we scan looking for the information that we’re after so put the conclusion first. This way, site visitors can read the conclusion first, which in this case is what your organisation actually does. If they want to know any more, they can then continue reading or jump to another section of the page. (To see front-loading in action, read any newspaper article.)

Exceptions

So, does every website need to tell users what the organisation does in these four different places? Well, not necessarily. We all know what Mastercard and McDonalds do, so it could definitely be argued that websites for household names need not explicitly say what they do. What these sites should do instead is tell us what the website offers, and this message can (and should) be put across in any of the above four ways – how else will site visitors quickly be able to find this out?

Conclusion

People are going to visit your site who don’t know what you do. Before you can even begin selling to them you must tell them what your organisation and website does. In addition to fulfilling site visitors’ immediate need (finding out what you do) you’ll also be boosting your search engine rankings. If your organisation is a household name, then instead of explaining what you do, it may be wise to tell site visitors what they can do on your website.

This article was written by Trenton Moss, founder of Webcredible, a web usability and accessibility consultancy. He’s extremely good at usability testing and running CSS training courses.

Pages: