Here is the announcement letter for the latest version of WebSphere Message Broker.

I’m currently working on a draft for a proposed new standard on developing user documentation in an agile environment. There is a lot of information out there about agile software development, but most of it is focused towards code developers, and possibly project managers. What I have noticed is there is very little advice out there for information developers, technical authors, and information architects like myself. I have also spent the last 18 months or so going through the somewhat painful experience of changing from a waterfall style development methodology to a more agile approach.

One of the things that really worried me about agile development when I was first introduced to it, in a two day education course, was the statement that ‘we prefer working software over comprehensive documentation’ from the agile manifesto. Now I know that what they mean is they prefer to make the software work rather than write detailed specifications about how it will work. The trouble is ‘user-documentation’ is often seen as secondary to the software product, and I was nervous that documentation in this case would be read as including user-documentation. I think it is a valid concern, and the lack of the role ‘technical writer’ or ‘information developer’ out there in the world of agile articles also worries me.

After some initial scepticism, I can see the value of it. And I also have a much better idea of how it can work, and also how it can fail to work. Because the emphasis in agile is on reducing life cycle documentation, then there is a risk that if the user-documentation development team are not a part of the agile process, either because they are not included, or because they are trying to hang on to the ‘old way’ of doing things, then they are going to lose out. Partly because they will struggle much harder to know what they should be writing, and partly because they will miss out on a new opportunity to actually work much closely with their team and gain the chance to either learn from or represent the users, and actually influence their product for the better.

This is the writeup for the presentation: Making information technology accessible to people with disabilities given at Southampton University March 2009. These views are entirely my own and do not represent those of the IBM corporation.

It is important for anyone who is developing software or IT services such as websites to understand the concepts and the importance of accessibility. This article covers a number of topics that can help give you an understanding of accessibility issues, and how software and the web can be made more accessible to users with different types of disabilities

If you do an internet search for definitions of accessibility, you will come across a large number and variety of definitions. Many legal definitions relate to limitations that a person may have in their ability to carry out ‘normal’ tasks due to a congenital condition, an illness or injury. These legal definitions also often focus on a person’s ability to earn a wage or carry out specific types of employment. The following descriptions of disability and related terms are provided by the UN (U.N. Decade of Disabled Persons 1983-1992. 1983. World Programme of Action Concerning Disabled Persons. New York: United Nations.):

• Impairment: Any loss of abnormality of psychological or anatomical structure or function.
• Disability: Any restriction or lack (resulting from an impairment) of ability to perform an activity in the manner or within the range considered normal for a human being.
• Handicap: A disadvantage for a given individual, resulting from an impairment or disability, that limits or prevents the fulfilment of a role that is normal, depending on age, sex, social and cultural factors, for that individual.

When discussing accessibility, especially in IT, it is important to understand the relationship between accessibility and assistive technology. Accessibility is an attribute of information technology that allows it to be used by anyone with varying abilities. On the other hand, assistive technology is specialized technology that someone with disability will use in order to access your information technology. The relationship between accessibility and assistive technology is described in the following section.

A word that is often associated with and sometimes confused with accessibility is usability. Accessibility in IT does not imply usability. It is possible for a solution in software or a webpage to be technically accessible, without actually being usability for people with and without disabilities. For example, a piece of software might have keyboard shortcuts, so that it can be used without a mouse, but the navigation and use of the software with those keyboard shortcuts may be very complicated, and therefore not usable. In fact, there have been cases where websites have followed accessibility guidelines, but legal action has still been brought against them because of usability problems for users with disabilities. In order for IT to be truly accessible it must also be usable. Important to ensure that software and website are both accessible, this is helpful to all of your users.

The relationship of accessibility with assistive technologies is very important. If IT such as software, web pages or hardware is inaccessible, then assistive technologies are unable to help users with disabilities to access them. The underlying IT needs to be designed and developed with accessibility in mind. For example, if software uses static font sizes and colours, then someone who needs larger fonts or a different colour contrast will not be able to see the application. If an application requires the user to use a mouse, and doesn’t provide any alternative methods of using it, then any users with mobility problems or blind users will not be able to use that application. Hardware can also be inaccessible, for example if there are hard to reach buttons or latches, then a user in a wheelchair, for example, will not be able to use the hardware. Assistive technology such as screen readers, magnifiers, speech recognition software, special keyboards and switches can only work if the end permission technology they are interacting with has been designed to be accessible.

Information technology that has been designed and developed to be accessible, works together with assistive technology for users with disabilities. If you have an application that has colour and font settings that can be adjusted by the user where the mouse is optional and someone can use the keyboard, where there is text for graphics such as alternative text and where latches and controls are easy to reach it can work successfully with assistive technology. The key to this relationship are to use standards and APIs designed for accessibility when you develop software, web pages or other IT.

Although making IT accessible may seem costly, it is in fact easier and more effective to design accessibility in from the start, rather than trying to solve the problem at a late stage in development.

There are many good reasons to develop accessible IT. Some of these relate to the needs of users:

• The number of potential users with disabilities is very high. The UN estimates there are between 750 million and 1 billion people work-wide with disabilities relating to vision, hearing, mobility and cognition.
• Aging populations have increasing numbers of impaired or disabled people, 7% of people world-wide are over 65, with 14% over 65 in developed countries. Many of us will need accessible IT in the future, even if we don’t need it now.
• Anyone can be affected by a temporary or situational disability. Temporary disabilities last a short time, rather than being permanent, for example, if you break you arm, or forget your glasses. Situational disabilities are also usually short term and relate to your current situation, for example if you are in a very loud environment, you might not be able to hear sounds or words produced by an IT application; or if you are working in a situation where your hands are full, or you are wearing gloves, then you might not be able to use a mouse or a keyboard.
• Often a less considered issue for accessibility is with changing user needs. These relate to skills that a user may have. A user may be inexperienced with IT or with a particular application, or may be using an application that is presented to the user in a language that is not their first language. This can be an area where the boundaries between accessibility and usability can be blurred, as changes made to help users with disabilities can also help users who are less experienced, or working in a new language.

Including accessibility in IT can help with inclusion and improving the experience for many users, including those without disabilities.

A key factor in making IT accessible is through the existence of both regulations relating to accessibility, and to standards relating to accessibility. These are often linked together as demonstrated by the most significant standard and regulation for accessibility in IT in the United States. Section 508 is the most comprehensive legislation addressing information technology. It requires that the US government and other agencies must purchase accessible products. Businesses must declare that their products are accessible as defined by the Section 508 accessibility standards. These standards are not only for the web but for software and hardware such as printers and copiers.

Lawsuits for businesses that do not comply can be brought by federal employees or members of the public. Criminal prosecution is possible if the accessibility status is misrepresented to the government. As a result of Section 508, a number of companies have been forced to make their websites accessible.

In the United Kingdom, the Disability Discrimination Act is the main regulation dealing with accessibility. Although the act does not mention accessibility of software or websites specifically, the practice guidelines use the example of a business providing a service using a booking service via their website as an example. The regulations require an individual or organisation to make a complaint and the RNIB has approached a number of organisations and threatened them with legal action to get their websites made accessible.

Similar regulations based on standards such as the Web Content Accessibility Guidelines (WCAG) are implemented or planned across the world including Canada, Japan, Australia and New Zealand.

Making accessible software has benefits for business and marketing, as new opportunities are available to sell to governments and private industry that must comply with the accessibility legislation. The need for accessible IT is a growing market in both government and the private section. , and the need for accessible Information Technology is a growing market.

Many of the guidelines that are designed to make software and websites accessibility are helpful to other users, because users have different backgrounds, goals, abilities and work in different environments. All these users have different needs, and accessibility can help address these different needs, promoting inclusion.

In order to understand the requirements and needs of users with disabilities, it is helpful to know some of the issues faced by these users. For different types of impairments or disabilities there are different kinds of accessibility and assistive technology that can be used in IT to help these users. There are four major categories of disabilities, and these are described below:

• Eyesight: including people with no vision, or some functional vision. In some cases assistive technology such as screen readers are needed, for example by the blind to read web pages or a screen magnifier to make an area of the screen easier to read for a user with visual impairments. In some cases a user with a visual impairment may be able to adjust their browser settings to make reading more comfortable. This group also includes people with colour blindness and those with eyesight problems related to ageing.

• Hearing: including people who are completely deaf or have partial hearing in one or both ears and require the use of a hearing aid.

• Mobility: including a wide range of people with varying types of physical disabilities. In IT accessibility this category is often associated with those with upper limb mobility, manual dexterity and co-ordination problems. These problems may be a result of a disability and individual is born with or one that develops due to illness such as Multiple Sclerosis (MS), Parkinson’s or a stroke. People with a broken bone, for example, would also temporarily fall into the category.

• Cognitive: includes people with dyslexia and learning difficulties. Dyslexia is a condition where people have difficulties with reading, writing or spelling. Learning problems can range from someone who has a serious mental impairment, or may be due to more common factors as poor literacy, a low level of skill using a computer, having to use the web in a second language, or problems understanding information.

The following section describes the needs of users with visual impairments. Users with low vision need to be able to enlarge fonts on the screen and select high contrast settings. Some users with low vision only need to be able to enlarge the font size, and often this capability is provided in the operating system. Other users may need only to change the colour contrast setting. For example if the default colour options are for a  light blue text on a dark blue, many users with a visual impairment will not be able to read the writing. However, if they can change the colour scheme, so that it is yellow text on a black background, this provides a higher contrast. Some users with low vision need both larger text and high contrast. When the capabilities they need go beyond what the operating system provides, then users must use assistive technology such as a screen magnifier to enlarge the fonts and create greater contrast.

A visual impairment that many developers often overlook is colour blindness, despite the fact that it is estimated that approximately 8% of men have some colour blindness. Although colour can be an effective way of communicating information to users with normal colour vision, it can not be relied up to convey information to colour blind users. A common way that colour is used in applications is the use of the colour red to indicate that something has stopped running, or is offline, and the use of the colour green to indicate that something is running or is online. Of course, red-green colour blindness is also the most common form, and for these users they cannot distinguish between red and green, and therefore the different objects appear the same. Screen readers also cannot pick up the colour information here. The right way to make it accessible is to provide another way to convey the information.

Colour can be used for those users who can see it, but additional information has to be provided – for example by the use of ‘online’ and ‘offline’ text, or using a suitable formatting that can be easily be seen by users with a visual impairment, and be recognised by a screen reader.

Blind users must use assistive technology called a screen reader a keyboard to access information technology. The screen reader reads out the text on the screen. The text that is read out includes text in web pages and documents for example, but it also reads out the controls and contexts of dialog boxes and application menus. The controls on applications have to be coded in a particular way to meaningful include the right information for the blind user, such as the application title, the items on the menu, the labels on buttons, and the keyboard keys to activate them. It is important that this information is coded carefully and meaningfully so that the screen reader can convey to the user the same information that a user without a visual impairment can see and access on the screen. There are programming APIs and tools to help code and test application interfaces like these for accessibility.

There are a number of ways of improving software and web pages for users who are blind or visually impaired. Text can be read by screen readers but controls and other media content have to be adapted to be used by assistive technology. If the content includes images, graphs or charts, then a text description needs to be given, so that a blind user can understand it. Navigation and some visual content of web pages can be a problem as they may have no useful meaning to a blind person so it is important for the user to be able to skip to the main content. Blind and visually impaired users should be able to access the controls or elements of a web site without a mouse, so menu or keyboard shortcuts should be available as alternatives to using a mouse. Tables, forms and pop-up windows must be designed so that they can be read by a screen reader. Allowing visually impaired users to resize the text and use high contrast or other personal settings is important.

Deaf and hard of hearing users are often forgotten in designing applications and websites to be accessible, but with an increasing amount of information being provided in an audio or video format, it is important to remember to provide alternatives or assistance for these users. Captions and visual equivalents are required to make audio content accessible to someone who is deaf. Transcripts can be used if there is no important visual information associated with the audio, but captions must be used if it is important to see the visual information concurrent with the audio. In addition someone who is hard of hearing needs to be able to increase the volume of that content so they can hear it; one way of addressing this is for applications to provide a volume control. As with conveying information using colour, it is also important to ensure that sound is not the only way that any information is conveyed to the user. For example, historically some applications have used only sound to signal an error in an application, or the action that the user is trying to perform. Provide a visual clue, as well as sound for users. This is also helpful to users working in a noisy environment where they cannot hear or distinguish sounds, or in a quiet environment, where the sound may be turned off.

Users with limited or no use of their hands need keyboard accessibility features and alternative input methods. The alternative methods could include speech recognition software which takes spoken words as input, instead of the user needing to type into the keyboard.

Other alternative hardware devices to enter data including joysticks, switches, mouth sticks and specially designed keyboards. In addition there are many accessibility features included in the operating system including mouse key which allows you use the arrow key from the keyboard to move the mouse pointer, sticky keys, slow keys and repeat keys.

You can also change the design of your application interfaces and web pages to use larger fonts on buttons and menus and to space menu items and links further apart so that the user can more accurately select item that they want to use.

Users with cognitive disabilities need a variety of technologies to make information accessible. There are a number of common problems that users with cognitive disabilities have with software including web pages. A major problem that many users have is difficulty in being able to enter text accurately and provide other input into an application. Users may make spelling mistakes and other errors when typing using a keyboard, and for some users this can be a very tiring way to enter data or perform actions. Methods to help users enter error free input include reducing the need to provide input, using voice synthesis for input and output, and using word prediction.

Some users with cognitive disabilities often have problems with concentration and memory difficulties. These users can be overwhelmed by choice or too much information and cluttered page design. Ways of helping these users are to reduce slow loading content; and use a simple, clear layout. You can provide pictures or photos that are useful to these users as comprehension aids, which help to break up the page, and provide an interesting focus for the user. This can help the user with information retention and navigating the application or page in the future.

Dyslexic users can also be helped by simplifying the page layout, and other page design features such as the use of narrow columns, unjustified text and not using a pure white or patterned background. A background colour changer is a useful feature, as dyslexic users often find that they can read text better against a different colour background. Using simple larger fonts and avoiding italics can also help. Short sentences and short paragraphs also help these users, as well as those with other cognitive disabilities. Providing an option to display more simple sentences can help these users, for example by having sentences that are shorter, and with fewer technical terms.

All users with cognitive disabilities are helped by being provided with simple navigation, for example, a simple list of links. It is also important to make it clear which elements of the page are clickable, as many of these users find it difficult to distinguish which elements on a page are clickable.

Many users are helped by the ability to customise the preferences they use with software or web pages, for example changing font colours, sizes and styles, background colours, whether to use audio as an alternative, speed of reading, complexity of the information on the page, language, the number and complexity of pictures and so on. As an example, these links are to a couple of websites that allow the user to set their own preferences for accessibility:

http://www.equalityhumanrights.com/pages/eocdrccre.aspx

http://english.navigabile.it/NavigabileWA/Perso00.aspx

The advent of Web 2.0 technologies on the web brings a number of issues for accessibility. One of the major technologies associated with Web 2.0 are AJAX applications. AJAX applications are written in JavaScript and therefore require a JavaScript enabled web browser. This is a problem for compliance with accessibility standards as the Web Content Accessibility Guidelines (WCAG 1.0), which requires that websites must be able to function with JavaScript turned off. However, new standards are emerging that address the accessibility of “Rich Internet Applications (RIA)s including AJAX applications, for example WCAG 2.0. There is the suggestion in some areas that the guidelines are becoming vaguer, and therefore web accessibility will become fewer guidelines driven.

The way that AJAX is used to provide dynamic incremental updates on web pages represents a paradigm shift in web usage and many inexperienced users do not expect the behaviour. A user may not notice updates to a page, or that part of the page has changed. Automatic update may be unexpected, and instead a page refresh on submit is expected. The behaviour of the Back button is also changed with dynamic updates. These issues are especially relevant for users of assistive technology such as screen readers and magnifiers, for example, if an update occurs in area of the page that the user is not interacting with, the user may not be aware that an update has occurred. Screen readers generally read from the top of the page, if an update occurs above the point in the page that the screen reader is at, the user needs to initiate a refresh of the page to read the change. These issues can be addressed by providing notification that updates have been made, or an option to allow the user to request updates manually for example, or to set an automatic page refresh when a request to update has been made.

AJAX applications can often have quite advanced interfaces, for example the Amazon Diamond Search application which can be difficult for blind users, and users with a mobility disability to use. The answer to producing inaccessible web page applications is often to produce an accessible alternative, which often loses some of the interesting and interactive nature of the applications. In the past this tactic has also been resented by users with disabilities.

One of the important aspects of Web 2.0 is the collaborative and user generated content such as social-networking sites, blogs, wikis, and media sharing sites such as flickr and youtube. How do you enforce accessibility on user generated content? Can you force users to add adequate text descriptions to photographs or captions to video?

Other media content common on websites such as Adobe Flash and PDF are constantly being updated to improve their accessibility, and to make it easier for web designers and developers to make their web sites and resources accessible. However, the needs of disabled users still need to be considered for accessibility to be built into IT.

There are many resources available on the web to learn about accessibility and how to make applications accessible, especially for web development. A good starting point for finding out more about accessibility and IT is the IBM Human Ability and Accessibility Centre website which is a comprehensive guide of many resources and references on the topic. The website is

www.ibm.com/able

Another useful reference is the guide to section 508 standards for electronic and information technology.  This can be found on their website at www.access-board.gov/sec508/guide.

There are also a number of free high quality tutorials available on the subject of web accessibility including:

• www.jimthatcher.com
• www.webaim.org
• www.section508.gov

The IBM Human Ability and Accessibility Center website also includes a trail version of Easy Web Browsing which can be used to assist users with reading websites. This can be found at http://www-06.ibm.com/jp/accessibility/raku2web/jp/start_en.html. There are also accessibility checklists containing development and testing techniques for developers of software, hardware and documentation. These, and other checklists, can be found here: http://www-03.ibm.com/able/guidelines/index.html

Information about the UK Disability Discrimination Act can be found here:

http://www.opsi.gov.uk/ACTS/acts1995/ukpga_19950050_en_

This is the writeup for the presentation: What is usability, and how can you test for it? given at Southampton University March 2009. These views are entirely my own and do not represent those of the IBM corporation.

Products are developed to be used by users.  However, if products are not designed with usability in mind, then users may not be able to get the best out of that product, or even want to buy it in the first place.  This article discusses what usability is, provides tips on designing for usability, ways that you can test for usability, and how you can get feedback from users.  This article is mostly focused on usability for software and web applications, but some of the techniques could also apply to other products and technologies.

Many people have different ideas about what usability is, and what it applies to. Before defining what usability is, it is useful to talk about what usability isn’t.

A common misconception about usability is that is applies only to simple applications, gadgets and websites. In fact usability applies to almost everything! It is actually hard when you start thinking about it to find an everyday object that is a very good example of usability.  An example of an everyday object which appears to have very good usability is a light switch.  A light switch has a simple button that can either be on or off.  But when you start to think about it a bit more, it can be hard to know which way is on or off.  And if you have multiple light switches, you have to turn them all on or off to know which switch belongs to each light!

An example of good and bad usability in an everyday object is the usability of milk cartoons. When milk cartoons were first developed they had an old fashioned fold-back opening. You had to push the cardboard back in a specific way, and these were hard to open, and when you did open them the milk usually spilt when you poured it. These were so difficult to use I remember adverts showing you how to open them, and the manufacturers appearing on news shows to demonstrate how to do it! Modern milk cartoons have mostly abandoned this design, and instead there is a screw-top on the top of the cartoon. This is much more obvious how to use, and you don’t get the problem of spilt milk. They are also better for maintaining the freshness of the milk.  These may not be perfect usability – someone with arthritis might have trouble using them for example, but the improvement in terms of usability for most users is clear.

When you apply usability to software and technology, many people believe that usability is aimed at ‘basic’ users and everyday technology. The assumption is that you only need to think about usability if you are designing a website or a gadget that is aimed at ‘home’ technology. Some people’s assumption is that complex business software does not need to be usable. After all, businesses employ technical specialists, can send their people on courses, or will read the manuals before they try and us it. These assumptions are wrong for a number of reasons that will be discussed later.

Another assumption about usability and technology is that it only applies to graphical user interfaces. This is not in fact true; usability can be applied to any interface. It doesn’t matter how complex the technology is, the usability can be improved, and in fact an effort should be made to improve it.

Another common belief is that ‘slick design’ equates to good usability. In some cases good visual design does enhance usability. Products developed by the company Apple are well known for their good design and are also regarded as being more usable. However, slick design and pretty graphics alone do not provide usability.

You can find examples of this principle quite easily on the web. Many web design companies have very cool and very slick looking websites as you may expect. A common problem with these design heavy websites is their loading time. One web design company I cam across had a very slick design based upon the Apple iPhone. This in fact was a website that had won an award for the graphic design. And it was an impressive website if you just looked at the graphics, but there were a number of problems that severely impacted the usability of the website, and meant that many users would not get the information or value out of the website that they wanted.

The first problem with the website was the loading time. When you enter the website there is a loading screen. Graphical very nice, but it takes over 50 seconds to move from this page to the actual content of the site. Research has shown that users get bored if content on the website does not load in 4 seconds! Yes it is pretty, but why would I wait for nearly a minute to see the rest?

When you do eventually get to the main content, again there are more pretty graphics with a realistic looking office with a girl sat at a reception desk. The room in the background is interactive, so you can move the mouse around and there are things to click on, and every so often the girl stretches. The problem is that there is no indication of what will happen when you click on the elements, and in fact the behaviour on the webpage is not what the user would expect! Also there are green circles on the screen, but they don’t seem to do anything. Why are they there? There are some icons on the bottom of the page that look to be navigation links, but they do not behave in the way a user would expect them. For example, clicking on these does not move you to a new page, or result in a change to the background. This is a website for a design company, and yes it is a very nice design, but the usability is not so slick. As a user I don’t know what to do with this site, and it doesn’t behave in the way I would expect. And as an average user I would never have waited long enough to try and find out more about the company!

Usability is also not just about market research, and asking people’s opinions about whether they like something or not. Usability is not just about assessing whether it works for people once it has been developed. Usability needs to be considered all the way through the development process. There is a misconception that including usability in a product is expensive and time consuming, but as discussed later in this article, having usability as part of the initial design and planning stages for a product is much more effective and in fact cheaper than finding out there is a problem once you have provided your product to your customers. With the web design companies website as an example, to change that website now to make it usable will be both difficult and costly, whereas if they had considered how people were going to use the website at the design stage it the usability could have been built in for little extra cost.

So what is usability? The following definitions are useful when describing usability:

• Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use
• Effectiveness is the accuracy and completeness with which users achieve specified goals
• Efficiency is the resources expended in relation to the accuracy and completeness with which users achieve goals
• Satisfaction is the freedom from discomfort, and positive attitudes to the use of the product
• Context of use is the users, tasks, equipment (hardware, software and materials), and the physical and social environments in which a product is used

Usability is all about a user’s ability to use a product to achieve their specific goals. The user must be able to achieve that in an effective and efficient way. The most important measure of usability is user satisfaction. Could the user do what they wanted? Did it take a reasonable amount of time? Was it difficult? Did the user enjoy using the product?

The context of use is also important. The user must be able to use the product in the conditions and situations that they need to use it in. Does the user have the skills to perform the task or would they have needed special training? Could they use it in the environment that they needed to use it in? Will the product work on the equipment that they have available, for example if the product is aimed to be used by school-teachers, will it work on laptops, or do you have to run it on a mainframe? As another example, if the users are using a device to record measurements made in a lab, could they use it wearing gloves? What if the users want to use a device on an archaeological dig, can it be used in muddy and rainy conditions? The product has to work for the target users and in the environments that those users want to work.

So the big question usability asks for a product is can the user easily use the product for the goals they want to achieve without being shown how? Is it intuitive for the users you are aiming the product at?

Usability encompasses more than just the product, it is everything involved with the product. Every product has a lifecycle for the user, and the usability of each stage contributes to the usability of the product: from finding the product, ordering it, receiving it, setting it up, everyday use, upgrading it and replacing it. This is known as ‘The total user experience’. Often people just think about the usability of the product itself, but a failure of usability in any of these areas can prevent people buying the product in the first place, getting value from the product when they have it, and choosing not to replace it in the future.

The primary importance of usability is increased customer satisfaction. A usable product is likely to help the user to get value quickly out of a product through increased user efficiency and increased productivity. For software in particular this leads to a faster return on investment, reduced training and support costs. Customers like spending less money; this is obviously good for their business. Good usability also reduces the number of mistakes people make and can therefore improve the safety and security of the software, and the data it is used with. If users enjoy using the tool, productivity is better, and promotes a more positive work environment. Increased user satisfaction leads to happy customers! This has obvious benefits for the company selling the product.

Happy customers lead to higher revenues; you will sell more software especially if your usability is better than your competitors. If customers have high satisfaction, customer loyalty is increased, meaning that the customers will want to purchase from your company next time. These customers will also recommend your product to others.

Thinking about usability when you develop a product is very important in reducing development costs. To change a product at design time is very inexpensive. By the time development of a product is in progress it becomes more expensive. If a product has been released to customers and a usability problem is discovered, this is extremely expensive to fix. As an example, think about how much more it costs to change the colour of a car once it has been given to the customer, than if it was done at the factory in the first place. Again, think about the website design, if you discover after you have made your website public that users cannot use it, you will lose customers and it will be costly to fix.

Customer support is expensive for a developer of a product, and if a customer does not know understand a product, know how to make it do what they want, or makes a mistake because it was complex to use, they will expect the developer to solve the problem for them.

In software the usability of a product in the field can be determined by analysing the calls from service. As an example, for one of the complex software products I have worked on, approximately 90% of the calls to service did not result in defects being raised on the code. The problem was that the software did something the user didn’t expect. Improved usability would enable the user to better understand the software and make fewer mistakes or know what the correct behaviour would be. A further analysis of these calls shows that the majority of these problems relate to customer knowledge or understanding. The users didn’t know or understand how to use the software. This clearly indicates a usability failing. A much smaller percentage relates to the customer having made a mistake in their own code or configuration. Again, this could be solved by making the software easier to use.

So how does this happen and what needs to be done to improve the usability of products?

In some development organisations there is the belief in a so-called ‘Perfect User’. This is where the developer of a technology believes that the user has the same experience and knowledge as they do. Not only do they have the same skills as the developer, but also they have a clairvoyant understanding of how this technology should work, and therefore how to use it. This is often reflected in documentation associated with the product, which describes how the software works under the covers, rather than how to actually use it! I like to call this “developer-think”, and this idea of the perfect user is a common belief I come across in my work. Of course, in reality the user of a piece of software or other technology is often very different to the person who developed it, and the user has very different goals. There are certainly cases where the user is equally skilled and knowledgeable, but there is a lot of evidence to suggest that technical skills are declining within organisations. Also people with deep technical skills and expertise are very expensive, and it in the interest of organisations to employ people with less skills, or to choose products that require less training for their staff. An organisation wants to quickly get up and running with a product, and to quickly start to make a return on their investment.

You have to understand the real users, what they are trying to achieve, what their capabilities and experiences are, and the environment they are working in. Also there are different types of user with different needs. An experienced user will have different goals and requirements than a novice user. How often is someone using your product? If they only have to use it once every six months for example, a complex procedure to perform a task will force them to re-learn the product every time they use it, whereas a more user friendly procedure will enable them to remember it, and quickly achieve the task.

The following section includes tips to help you include usability in your designs.

Using familiar concepts help a user to understand the software better and how to use it. For example office software often uses concepts such as filing cabinets full of records for databases, and the trash bin for deleting files. Naming objects or components sensibly in software can help a user work with them, for example servers in systems management, tables in information management. Making up new terms and using abstract references can make software more complex and difficult to understand.

Keep it simple. Some developers want to show the complexity, almost as a way of saying ‘look how hard this was to do’. Hide the complexity from the user, allow them to do the tasks they need to do with the minimum interaction. For example, just because there are 50 properties an object could have, if it only actually needs 5 to make it work then show the user just the properties they need.

Give easy access to the features that most users will use. There are some tasks that every user of a product will perform. For example, you will have heard the saying that 90% of the people will use 10% of a product. For example in a word-processing program all users will use the basic text editing and formatting capability, but only 5% might use the mail merge functionality. More advanced features can be made less visible to users. You should optimize the design for the most frequent or important tasks. It is critically important to understand how users are going to use the software, and why they want to use it. What are the tasks that the user wants to perform? Focus on the tasks that they want to do.

Design your web site or application so that users can view and directly manipulate objects or information within the interface. Choices should be visible to users rather than hidden with cryptic key sequences. When objects and choices are immediately visible, users learn and complete work tasks efficiently.

Provide the user with sensible default values when they are carrying out complex tasks. If the user has to enter information into an interface, for example a web form or a properties dialog, they are more likely to understand what to enter and make less mistakes if you provide good examples and sensible default values.

Feedback is very important to a user, particular in software or a web site. For example, if a user clicks on a button and there will be a wait, use a message, an egg timer or progress bar to indicate something is happening. Otherwise the user might repeatedly click on a button and cause unexpected results, or give up waiting altogether.

Provide meaningful information in responses, for example if an error occurs display an error message explaining what went wrong, any consequences, and what they need to do next or to fix the problem. If they need to go elsewhere such as an error log to find information, then make sure the message tells them where to find it. There is nothing more frustrating than getting a message telling you something went wrong but you have to go somewhere else to find out what, and then you don’t know where to find it! Ideally put logs in a standard easy to find location on a file system.

Be consistent. Make sure that objects that look similar behave in similar ways, and an action should always produce the same result. Also provide a way for the user to get out of a situation, for example some way to reset the settings to default, and in software provide undo and redo actions. A user should be able to make mistakes without fearing causing permanent damage, such as permanently changed settings, or data loss. Don’t let your user be in a position to actually damage their system or data. Users will do things you don’t expect them to!

Provide help to the users where they need it. For example when the user is configuring something, for example a new camera, a small ‘get started’ type of booklet or card can help. On a software interface, providing sensible labels, and a sentence explaining what an interface element is, can make it more intuitive to use, with the user having to resort to reading the online documentation to know what to do next.

Good visual design on its own is not usability, but it can help the usability and should be included in the design process. For example, a cramped interface can be difficult to understand, and may overwhelm the user. Tiny buttons that all look the same are equally not useful, whereas the use of sensible space and well designed icons placed in a logical order can help to lead a user through a task.

You can’t talk to every customer, but there are various techniques that are used in the design process to help understand users better. These techniques described in the following section.

The first is to define and understand user roles. For any given product there is likely to be one or more user roles that will use that product. Each user role will have particular tasks they perform or goals that they want to achieve. They may also have a set of associated skills, and they may work in a particular environment. Examples of user roles might be:

• Web developer
• Systems administrator
• Technical support officer
• Lab assistant

Personas are an extension of user roles where you create a fictional character that represents a group of your users. A persona typically includes the following types of information about the fictional user:

the user’s name and information about their age, education, experience, and possibly even include a picture and more demographic details.

• the user’s job title and major responsibilities are included, and details of relevant skills, and other related product use – for example, software, hardware, platforms?
• what their goals and tasks are with using your product, what is their organisation, why do they want the product, what’s the problem/business opportunity that it solves?
• the user’s physical and social environment. Where do they work, with what facilities, how many sites, how many people, how many servers, and so on?

A story is used to detail what a user wants to do with your product, or a part of your product. It describes just what the goals and tasks are, and not how a particular user might use the product.

Scenarios extend stories by using a specific user, for example based on a persona, to detail specific requirements that that user may have, or a specific way that this user uses your product based on their existing knowledge and experience, or particular environment. A story tends to focus on the so-called ‘golden path’. A user wants to achieve a particular goal, and the steps for them to do that are likely to be considered. With the scenario problems with the golden path may be highlighted, and alternate paths may need to be explored to support users with the same requirements as the persona.

There are a number of ways that you can get feedback from users at each stage of the development process. Questionnaires and market research can be used to find out about customer satisfaction for products that have already been released. Questionnaires can also be used in association with early release programs and prototypes of software, websites or other products. At this stage though, it may be too late to make major changes, but it can be useful to get ideas for improvements in a new release.

Design walkthroughs are used at the design and planning stage in development to get feed back on plans for a new product or early prototypes. This is the most effective time to get feedback from users because there is the opportunity to change the design and plan of a product. Users can tell you at this stage if a proposed function is useful or not, you can even save time by not developing something users have told you they don’t want or don’t like.

Decision support centres can be used at any stage in the process to get anonymous feedback and priorities from users. The idea is you can capture input from users anonymously and the users can then comment on other people’s ideas, and vote to determine popularity and priorities. In the design stage this can be used to capture feedback on proposed new features in a product, and find out which ones users like best, or think are the most important. In a testing or post-release evaluation stage you can find out what users like and dislike, what their priorities are, and what their ideas for improvements might be.

There are various techniques for evaluating the usability of products that are already released to customers or still under development. The effectiveness of the techniques is variable. Usability inspection is essentially comparing the software against various checklists that measure whether the product has been implemented in a way that would promote usability. For example in a checklist for assessing the usability of a website it might have items such as:

• Is there a navigation menu?
• Is the text readable?
• Are links underlined?
• Does the text all fit on the screen without needing to scroll

The problem with usability inspection is that just following usability guidelines like this doesn’t mean that something is usable. The goals that the user wants to achieve need to be considered, thought about and designed in addition to following good practice. This is the same as with graphical design on its own not being enough to make something usable.

Heuristic evaluation by a usability specialist is a better technique as the individual can make an assessment of a product based on their experience of other products and testing. A specialist is more likely to find usability problems and suggest more usable solutions.

Alpha and Beta programs, and remote user evaluations can help to get feedback from real users, at a time in the development process when there might be time to make changes. Feedback can be received individually through questionnaires, or open discussion where the users are invited to discuss their feedback together. To ensure that the feedback from the users gets into the product defects or requirements are raised.

Ideally a product will be evaluated at an earlier stage in the development cycle. The most effective way to get feedback on the usability of a product at any point in the cycle is with proper user testing. User testing can be used to get feedback on the usability of a product, even before development has begun. Ideally user testing will be performed with real users, but where this is not possible then other users can take the place of the real users. These test subjects should have similar skills or experience to user type required in the test, or a persona can be used to guide the test subjects in how to behave in the test.

Paper prototyping can be used at a very early stage. Drawings or words on paper are used to represent the interface that will be presented to the user. The developers can move paper parts of the prototype around during the test to demonstrate the interaction with the system the user will have. For example if the user presses a button, a new piece of paper may be placed in front of the first to indicate that a new window or page is displayed. If the user does an action that the developer hasn’t anticipated, then the paper prototype will quickly and inexpensively highlight the problem.

Other tools are available for more sophisticated prototyping such as smart board software, where a user can click an object on the smart-board and the image displayed on the smart-board changes to the correct image. Using tools such as Photoshop or PowerPoint interactive representations can be developed that look like a real interface. The user can interact with them in the same way they would with a real piece of software or web site. Using this more sophisticated prototyping is helpful because it is like using the real product, but is quicker to change. Feedback from one user can be used in the prototype for the next user in the test.

A proof of concept can be used to take a product and demonstrate how it can be used for a specific user. The full product does not need to be available for the proof of concept, but how it could work is being demonstrated. A product can also be taken to users in their own environment to get real feedback of how it will work for the specific goals and environment of those users.

Facilities for user testing can be as simple as a room and a facilitator with some paper for prototyping at its most basic level. User testing can however be much more elaborate depending on the needs of the product, and the time in the product life cycle where the test is being performed.

Different types of evaluation and usability testing techniques should be used at different points in the lifecycle of a product. The later in the cycle, the more expensive it is to fix any usability problems. The black section of the rectangle shows the stage when the product has been released and it is  very difficult to fix the problems.

There are a number of considerations to make when planning usability tests.

The first consideration is the users to use in your usability test. If you have real users then you will want to ensure you have a representative cross section. If you have other individuals then they will need to represent the real users you have, or your intended audience. It can be valuable to find users with a mix of experience, for example having some novice and some experienced users so that you can see how previous experience has an affect on use of the product. It has been suggested by Jacob Nielsen that the optimum number of users to run usability tests with is 5. I would agree that 5 is a good number for a usability test, and more than 10 is not useful, particularly if the product under test does not change between tests. You might think that carrying out lots of tests would be a good idea, but in fact what you find is that all users find the same problems, and after identifying these common problems what you see is individual user preferences.

Usability tests benefit from having at least one observer in addition to the specialist running the test. Having multiple observers is useful, as each person will spot different issues and can more affectively record them. You can also record the session, and play it back later to record all of the individual points. Having the product developers present as observers for the test is very valuable, because they get the opportunity to see first hand how their development decisions affect the user. The developers can also talk through alternatives with the user after the session to solve specific issues. Other individuals involved with the product can also benefit, for example testers and writers, because it is useful for these roles to understand how the user expects to use a product.

If the observers are visible to the user it is a good idea to keep the numbers down so as not to intimidate or distract them during the test. It is important that the observers do not interfere with the test, it can be very tempting to shout out the answer to the user when they are stuck – which does not help improve the usability.

For a usability test you need to have realistic tasks for the users to complete. It helps to have a scenario that includes details of the background goals of the task. Why the user wants to perform the task, and any details of their environment of significance to the task. If the test is not with a real user, then including the persona information is useful.

For the test the system or prototype should be set up in the state that the user needs it to start the task. It might be that the task involves installing and configuring a product, but you should ensure they can do this without encountering unrelated problems. For example, check that the network works correctly and the user-id has the appropriate access.

It is important to explain to the user what the test is about, and what you will do with the results. Real users in particular feel valued when their opinions are used to improve the products they have purchased.

It is also important to ensure that the user knows that they are not under test, but that the product is. Users feel stupid if they cannot work out how to use products. I have known people getting very upset and angry during usability tests when the poor usability caused them to feel stupid or frustrated. If a user from the target audience cannot use a piece of software is not their fault, it is the fault of the software, and the software’s developers. It can be a real eye opener for a developer when someone storms out of a session or ends up in tears because they can’t use their code! The user should fill out a background questionnaire on their role and experience. The user must be encouraged to talk through their session as they do it to explain what they are thinking, why they perform a particular action and what they are expecting to happen, if what they expected doesn’t happen and how they feel as they are performing the task.

In the test you need to observe and record comments and actions that the user took. You can also take measurements of efficiency, effectiveness and satisfaction. Time on task, number of clicks and numbers of errors made are examples of measures that you can make for a usability test on software. Talk the user through their experience with each task, and ask in person or using a questionnaire, what they liked, what they didn’t, what they would change, and how satisfied they feel, for example as a mark out of 10.

The results from user tests can be very effective ways of making improvements and getting changes made to a product. Observational results often have the biggest impact, especially if the product developers see the test, either as observers or on video. Quotes and emotional responses are very powerful. ‘I don’t know what to do here’, ‘This is rubbish’, ‘I expected xxx to happen when I clicked that’, ‘I’m pulling my hair out here’ and so on are examples of an emotional response which demonstrates the users frustration. Quotes and observations are good to communicate the results in a presentation or report.

Charts are also an effective way of reporting the results of a usability test. For example a chart showing a comparison of the average time users spent trying to complete a particular task can indicate which tasks are easier to complete. If you have more than one prototype you can ask a user or different users to perform the same tasks using the different prototypes and then compare them. You can also produce charts showing number of defects found, number of mistakes the user made, the number of mouse clicks to achieve tasks, and the user’s satisfaction with particular tasks.

A usability test should produce a list of usability defects, or usability requirements. You can take an iterative approach to usability testing where the defects from the first few sessions are fixed, and then more usability tests are performed with the updated prototype or system. This enables you to more quickly and effectively improve the usability, and get feedback on a new interface.

When you develop a product you should always be considering who your users are, what goals they are trying to achieve, and how you can develop your product in a way that makes it easier for those users to achieve those goals. It may be tempting to expose the complexity to the users to show how clever the product is, but your users won’t thank you for it. You can test the usability of a product at any time in the lifecycle of that product using a number of techniques, but the most effective way is to get real or representative users in a room with a realistic scenario for them to complete. Real users do not necessarily follow the golden-path when they use a product, and they will try and use your product in ways you did not expect. If you can spot the problems early in the development cycle it will make it much easier and cheaper to fix, and help you create products leading to happy, satisfied customers.

Is anyone else getting Russian spam, or is it because I have my name published on Russian websites?

WebSphere Message Broker FixPack 3 is now available, and adds quite a lot of new function and support, including support for WebSphere MQ v7.0, Vista, and extended database support. There are also enhancements to mapping, monitoring, and xpath, plus some new nodes. To see the  full list of what ’s new in FixPack 3 see New function added in Version 6.1 fix packs. Note, for some of these features you need to explicitly enable them.

The information center for WebSphere Message Broker v6.1 was updated last week. Here are the links to the latest information centers:

WebSphere Message Broker v6.0

WebSphere Message Broker v6.1

When you do a search using Google for WMB documentation, you are likely to get hits in the v6.0 message center, ensure the url contains v6r1m0 rather than v6r0m0 like the following if you want v6.1 docs:

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp

There is a hiccup in the WebSphere Message Broker documentation in the topics that talk about putting and getting test messages from within the WebSphere Message Broker toolkit. The topics that talk about putting and getting test messages in the debugging section haven’t been properly updated for changes in v6.1. The enqueue and dequeue functions are still available, but they are now within the much more powerful Test Client interface. If you are used to using enqueue and dequeue you can get to them by right clicking on a message flow, and clicking Test Message Flow to open the Test Client. In the Test Client editor there is a toolbar of buttons in the top right, these have an Enqueue and a Dequeue button. You can click on these to view the settings you are familiar with.

The Test Client itself has a lot more functionality than the Enqueue and Dequeue editors, and can put and get messages from nodes other than WMQ. See, Testing Messages Using the Test Client.

The current problems are being fixed, but the changes won’t be visible until the next documentation update.

You can run a fully featured 90 day trial of WebSphere Message Broker v6.1 from here.

I’ve just spent the last week on a course to learn some skills that should be pretty useful in the fairly near future. The first two days were a course covering HTML, CSS and Javascript. The HTML side was revision really. I’ve been playing with HTML for quite a long time, and even more recently as a technical author. I’ve also dabbled with CSS and JavaScript in this role, although to a much lesser extent. Fortunately I do play a lot with Actionscript in Flash, so the JavaScript stuff at least makes some sense. The final three days covered ‘ajax’ – looking in more depth at javascript, interacting with the server and looking at a couple of toolkits – the prototype toolkit and dojo.

I’ve had lots of people I work with raving about Dojo, but from the little play I had before with it, I wasn’t that impressed. Although to be fair it makes a lot more sense now. Certainly it seems pretty powerful, but then it really should be for a 15MB sized library of javascript files. I’m still not entirely convinced by it though.. I found some of the widget behaviour was rather strange and I was very unimpressed with the documentation. I did like the simplicity of the event handling and xhr request/reply though.

Having a quick look at the other toolsets out there, mootools does look rather interesting. And this is built on the protoptype toolkit which I did actually quite like.

I’ve recently acquired a new domain, so I’m intending to have a play with javascript to build a new website. Although I have to admit, I still haven’t seen anything I can do which wouldn’t be a lot nicer and simpler in Flash. The week has really reinforced for me the fact that Flash really is a very cool and very powerful tool. And I probably need to update my version too.. I bet there is some cool new functionality I’m missing! Yikes, I’m starting to sound like a developer!