Google has recently made some pretty comprehensive changes to their Gmail interface. One change that I found interesting is what Google are calling ‘Display Density’, which automatically adjusts the layout of the page based on the size of the browser window. Google have also provided three settings that can be used to adjust the density of information on the page and afford users a level of control over how the page looks. While I don’t think the implementation is quite right, it is an interesting way to solve the problem of designing interfaces that will be used on devices with screens of all shapes and sizes.

The issue of what resolution to assume for a user group is one that we come up against regularly and will become more of an issue as the use of multiple devices to access the same interface by the same user becomes more common. Imagine accessing Gmail from a 21 inch widescreen in work, a 13 inch notebook in the home office and on an iPad on the train.

I feel that this type of functionality is a really positive step and will help to preserve the integrity of the overall experience across devices while optimizing it for the screen size being used at any one time and I hope to see more of this type of functionality.

After spending a day performing about 500 Google searches of various businesses for a recent project, we made the observation that many organisations are not optimizing the metadata tags in their websites for their users; namely neglecting to use metadata to communicate the nature and content of the website and to encourage people to click on their link.

(Note: don’t know what metadata is? It’s essentially ‘data about data’, and is entered into the head tags of your HTML content. It is made up of a number of tags, including “description”, “keywords” and “language”. Search engines essentially read metadata to ‘understand’ what a page is about).

Our observation about metadata was inspired by the search results of a large business, who had not edited the descriptive metadata tags in their website after it was created with a template, leaving the ‘lorem ipsum’ filler text to display in their search results. Metadata is the foundation of all information retrieval processes and its importance in good user experience should not be taken lightly. It is possible that certain metadata tags have been both neglected or abused over the years, due to aggressive black-hat SEO tactics, or theories about SEO and the relevance of the metadata tags. Despite the rumours and the SEO myths, metadata is still a critical step in correctly identifying and defining the content and structure of a website.

Descriptive metadata entered in a website source code is important because it is the first port of call for users to gain an understanding of a website (this is the metadata entered in the meta “description” tag of your website code). It is the text that is displayed in search results and is generally all a user will refer to when they determine if they want to click on that link. If the metadata gives the users false expectations of the content of a website, than user dissatisfaction can occur. Users do not want to have to click around to find information they expected to see elsewhere, or be taken to a dead end. Descriptive metadata needs to be a brief, accurate and keyword rich description of the site’s content. No more than 250 characters will be displayed in search engine results, so keep it short and to the point so users don’t miss out on vital content.

Metadata within a website should also be consistent; a unified metadata structure also indicates a clean and intuitive taxonomy within your website. Using a metadata vocabulary such as Dublin Core can ensure your website’s metadata is thorough and aids in content retrieval and management. When evaluating the information architecture of your website, look beyond your navigational structure and ensure your metadata is also intuitive, relevant and matches your target audience’s expectations of content and classification. Good information architecture structure encompasses all elements of the page, including those the users don’t necessarily see.

We are often asked by our clients to find out whether their customers would use or need a Smartphone or tablet app to access their functionality or content. Of course the answer depends on the business and the target user group but it often raises the question of whether a native app, web app, or mobile optimized website is the most appropriate approach where the business wants to facilitate use of mobile devices.

Mobile websites are the simplest of the three as they are simply web pages that are designed to be accessed on devices with smaller screens. Native apps are device specific and are downloaded and installed via services like Apple’s App Store. Web apps are somewhere in-between as they are accessed via a device’s browser, are cross platform and offer improved functionality over mobile websites but do not leverage the full power of the device in the way that native apps do.

The pros and cons of each approach are too numerous to list here, however, in depth understand the context in which their users need to interact with them on mobile devices is often an overlooked consideration. Native apps are great for providing a slick, rich and integrated experience. However, if your customers access your content from mobile devices rarely or are more likely to use web search to find you, developing a native app may not represent the most cost effective solution and choosing instead to develop a mobile-optimised website would be more appropriate. Simply having a native app will not enhance the overall experience if users are not likely to download it in the first place. Companies like Amazon take the approach of catering for all eventualities but most online businesses do not have Amazon’s user base or deep pockets and must choose what to implement.

We believe that establishing context of use and the needs of users with respect to mobile device access is an essential when planning how to facilitate mobile device user interaction. This will make sure that the business understand when, where and what users access on their mobile devices and ensure that the most appropriate, and cost effective, implementation is used.

Accessibility is often one of those things  placed in the ‘too hard’ basket, or worse deemed unimportant as it thought to be only relevant to a small portion of the population.  The fact of the matter however, is that accessibility benefits all internet users.  Accessible websites and the information they contain are generally easier to comprehend, more user friendly and often more compatible across a range of web browsers, including mobile browsers.

While undertaking a full accessibility review can be a daunting process that may require the input from a professional, there are a few simple things everyone can do, to ensure that their websites are more accessible.

1. Do not make your website dependent on colours.
   Colour alone should never be relied upon to convey meaning to users. Links should always be underlined, and important information and forms should always be labelled correctly.It is easy, when designing a website, to think your website is immune from colour blindness problems because it doesn’t use red or green. In reality, there are many different types of colour blindness and the only way to ensure that your design is truly accessible is to check your foreground and background colour combinations to determine if they provide good visibility. 

   The W3C official statement on colour visibility is: “two colours are considered to provide good colour visibility if the brightness difference and the colour difference between the two colours are greater than a set range.” The range suggested by the W3C is > 125 for colour brightness and > 500 for colour difference.”.

   An easy way to check the contrast levels of your website’s colour scheme is to download the Vision Australia Colour Contrast Analyser for webpages: (http://www.visionaustralia.org.au/info.aspx?page=628). This tool analyses all colour schemes according to the W3C guidelines for contrast and provides a pass or fail mark. It can be changed to particularly target different types of colour blindness so all types of visually impaired users can be tested.

2. Place alt text on all images and media.
   Text equivalents should always be provided for all images on your website, as screen readers cannot ‘read’ images, they read the information provided in the alt tags. If the image used contains text, all text should also be included. Having alt text in the image tag ensures users relying on screen readers can hear the description of all images, rather than just hearing the file name. It can also be useful when pictures cannot be downloaded from the server, which often occurs when users are on slow connections. Alt text is particularly essential when an image is used as a main navigational link.Alt tags can be easily placed within the <img> tag of your website’s HTML body code. For those who are unsure, look for the tags that look like this: <img src=”/images/styles/usabilityone.gif” alt=”UsabilityOne”/> The alt text for this image exists after the ‘alt=’ tag, and reads as “UsabilityOne” 

   If you’re not sure about whether to provide alt text for your graphic; the safest solution is to always include it.
   It is also good accessibility practise to ensure your page is not dependent on images for navigation, or that the whole page is an image (e.g. one huge JPG created in Photoshop).

3. Use meaningful and distinctive page titles.
   Another easy way to improve the accessibility of your website is to ensure each of your website’s pages has a different and meaningful title. The title is the text placed between the <title> tags in your website’s source code, and is displayed in the tab of each browser, so you can see the description of each page you’re on (see image below). 

   It is also the first thing a screen reader will come across after a web page fully loads, so it is vital that it gives your visually impaired users a meaningful description of what page they are on, and to differentiate between other web pages.

   Have a look at the titles on each of your web pages that come up in the tab of your browser. Is it succinct and descriptive enough to give a reader an understanding of the page they are on? If someone was just relying on this, could they tell it apart from the other pages within your site? If it doesn’t do these two things, it’s worthwhile manually changing the text in-between the <title> tags in your source code, or asking your web developer to change it to something more appropriate.

   A good habit when creating a window title is to ensure it always follows the format “Page Title | Company/Organisation Name”. This format lists the page identifying information first.

While businesses strive hard to increase their online visibility, at the same time they also make it really difficult for customers to contact them. Some classical examples are :

(a) use of long contact forms which force users to follow a strict template that doesn’t address their specific needs with respect to contacting the organisation, and

(b) email ids like info@companyname.com where emails are seldom read.  Still worse is to provide a phone number which never gets answered.

Does this reflect on the callous attitude of businesses or can it be passed off as a norm? In my humble opinion, the attitude reflects indifference towards their customers.

Contact channels, response rates and turnaround times should be governed by stringent KPIs. Without these in place, many of the queries go unanswered and users/customers lose faith in the brand. This could have a severe impact on the user experience.

Photo credit – ihasahotdog.com

If you have a product/services/corporate website, there are a few key things to watch out for:

1. Contact options listed should be responsive – Under the pretext of encouraging users to use the website, some organizations do not list contact numbers upfront or through direct means. They use a contact form or email option. We have been witnessing this trend especially with a few ecommerce websites. Understandable that maintaining a 24X7 call centre might be out of the budget for small to midsized organizations. In those cases, the contact forms or email option should be extremely responsive. Any lapse could mean loss of credibility and therefore loss of a business opportunity.

2. Keep the contact form short and simple – Long forms are discouraging. So keep it short, simple and to the point. Extract minimal (mandatory) information from the users. Templates are great to divert or route queries to the appropriate departments. But ensure all query types are covered and also provide an ‘others’ option to widen the range.

3. Promote self help options but not at the cost of user’s time – FAQs are great information resources. When provided in conjunction with contact us option, users tend to use this more effectively. But there are few times, when users do not have the time to go through the FAQs in detail. In such situations, users should have access to contact details quickly and not have to go through the hassle of looking through the website to find this information.

Irrespective of the nature of contact channel, the key performance indicators (KPI) should be defined and adhered to at all times.  Different organizations favor different communication channels. Depending upon the channel of choice, guidelines should be defined. For instance: if email is the preferred choice, have an auto generated email acknowledging the receipt of the query and also clearly outlining the timeline within which the user can expect to hear back from the organization. Besides the above mentioned points, provide an alternative option if the user has an urgent query to be processed. Also, be conscious of the timeline provided to the user and provide a response within the time frame. In case of any delays, communicate the message to the user. This will help in addressing user anxiety and avoid scenarios where they send repeated requests.

Eye-tracking can be an invaluable tool and I thought I would share our top 5 tips for using one as part of a usability project.

1 – Over-recruit for your desired sample size – Some participants will not provide sufficient eye tracking data for analysis. This means that you will need to recruit about a quarter more participants than is required for statistically sound analysis of heat maps or gaze plots. It is imperative that this is set as an expectation with stakeholders or clients at the beginning of the project.
2 – Allow plenty of time – In comparison with moderated user testing, more time is generally required for the set-up of the project, the running of sessions and subsequent analysis.
3 – Pilot your study -This will ensure that prior to seeing actual users you are confident the eye-tracker is set-up correctly and working to ensure data is being logged and measuring your stimulus. Without this important step all of the data collected may be useless.
4 – Use a dedicated eye-tracking set-up – This should include a chair on legs (opposed to an office swivel chair) and allowing the moderator to control the eye-tracking equipment (depedning on the eye-tracking hardware this could include the use of a second computer with data logging capabilities). Also, ensure the moderator sits well behind the participant and out of their line of sight.
5 – Is eye-tracking the right tool? – Lastly question whether eye tracking is going to add value to the project. Will it add more than just moderated think out loud user testing alone?

Is there anything you would add to the list for getting the most out of eye-tracking?

For more on eye tracking see Ciaran’s article from the newsletter last year.

PDF’s in general should be avoided as they cause many usability problems. However there are times when PDF’s have their place on the web; for instance if a document is meant to the printed then PDF is the correct medium. If your site contains PDF’s it is vital that users are aware of when a link will open a PDF.

Indicating the presence of PDF links helps to avoid PDF shock; that is giving users a nasty surprise of being dumped into a PDF file. There are a number of different ways of indicating PDF links. One method is to include a PDF gateway page; a page which summarises the PDF content, warns users that they are getting a PDF file, as well as presenting the file size. Gateway pages are supposed to prevent PDF shock as well as let users determine if the PDF is worth opening. However in our labs we often see users experience difficulty with gateway pages. Users assume the gateway page is the ‘result’ and don’t continue to click the PDF file. It is in-fact breaking the link to the real file. Many government websites use this technique and I’m starting to wonder if it really is the best way to display PDF’s.

My preference would be to include the PDF symbol next to the link along with the file size. If this is included in the link anchor text then screen readers such as JAWS can easily determine the presence of PDF’s. Surely this is enough to determine the presence of PDF’s without the need for a gateway page.

What do you think is the best way of presenting PDF links?

We love when our clients give us exciting and innovative designs to test and often we agree that an interface that is not immediately intuitive is learnable and so can be considered to be usable for the target audience. Several factors affect whether an interface that requires learning time is usable.

1. Does the effort outweigh the benefits? The effort required to learn the interface sometimes outweighs the benefits of presenting that content in a complex interface. We feel that innovation is essential, however, sometimes the user is required to do a little too much to access content and they quickly lose interest in the content and the interface as a whole.
2. Will the initial effort required to come to grips with an interface put the user off? It is essential that the interface provides very simple and intuitive core functionality to ensure that users are not discouraged during initial use. This will allow users to use core functionality and learn more advanced nuances of the interface over time.
3. Does the interface hide the purpose of the website? When the interface is too complex or excessively visually based the purpose of the content it provides can get lost.
4. How often will the user visit the interface? Some interfaces will be heavily used and re-visited regularly. In this instance the user has the opportunity to learn the interface and become familiar with its features and nuances, however, where a user visits the interface irregularly or perhaps only once, the opportunity to learn a complex interface does not exist.
5. Who will use the interface? Different user groups are more willing to learn and explore than others. While it is true that younger and more technically savvy users will get used to an interface more quickly, these are often the ones that give up fastest. In comparison to older users who are often more cautious and systematic in their approach, more proficient users assume knowledge and are typically less forgiving of an interface that requires learning.

As web technologies advance we hope that this will enable designers to create increasingly interesting and innovative interfaces, however, we hope that the users don’t get lost in the process.

Back in the early 1990s I began exploring how task models could be used to support usability evaluation.  Twenty years on, and I’ve found a potential contender in the business world. But first, let’s explore what I mean by task model.

A task model is anything that enables you to graphically represent a task, its components, and the logical and temporal relationships between those components.

In the mid 90s the software engineering community adopted UML (User Modelling Language), along with tools such as Rational Rose transforming UML models into source code. But, what’s available in the User Experience community?

Many task models have been developed by Human-Computer Interaction researchers to support the representation of user interaction with systems. GOMS (Goals, Operators, Methods and Selections rules) and its extensions (Keystroke Level Model or Cognitive Perceptual Model) being the most popular. These models remained mostly in the academic world – complexity being their worst enemy. Other popular models are flow charts or mind maps.

However, you may ask, “What models are there to help us, usability practitioners, represent the interaction between users and systems?”

The potential answer is BPMN (Business Process Modelling Notation – http://www.bpmn.org/). It is a notation gaining adoption through the industry world. Its strength is its simplicity. With little explanation, the notation is readily understandable by all stakeholders. Although BPMN’s aim is to represent business processes, it can easily be adapted to represent user interaction with systems and processes.

The figure above presents an illustration of a recruitment process (from http://www.rickgeneva.com/wp/posts/swimlane-lane-or-pool-learn-to-swim-first/). The circles with envelopes represent events that trigger a task to start (the event is the email being sent or received), while the empty circles represent the start and end of the task.

So, why do I use models? I use them to communicate and validate user interactions or processes, to support usability evaluation, to help define the language to be used and/or to create training material.

Twenty years later, and I am still puzzled why models are not more widely used amongst the various members involved in the design and development of digital solutions.

As a new year begins we often reflect on the changes we have observed over the last 12 months. One of the more interesting changes that we have noted, is how people view the online world and the role it plays in their lives.

We have a set of introductory questions we use on most projects across numerous methodologies (interviews, focus groups, one-on-one user tests and card sorts) that break the ice and provide us with some background for each of our participants. These cover things like, common activities online, amount of time online each week, where they access the web and years using the web.

In 2010 we had to change these questions because the web is now so ingrained in people’s lives that our old questions had become difficult to answer.

In the past, people had a clear model of their online lives and were very conscious of being online. Today, being online takes many more forms and is often more subtle. For example, many people are either unaware or confused about whether they are online when using an app on their phone. Further, if we compare the experience of using an app to check your bank balance to logging into internet banking via your desktop the former is a much less involved process which at week’s ends you may have forgotten.

This shift began to hit home in the last 12 months when asking people about what they do online. Some really struggled with the question and responded by saying “well, everything really” . Often, we now have to prompt people to find out about online behaviours such as doing research, banking, buying tickets and booking holidays. In some ways asking about the web is like asking about how electricity impacts your life, it is there but we tend to take it for granted.

Possibly the most telling feedback is that we often hear people say “I don’t really surf the web, anymore”. I always have a chuckle when I hear this. Firstly, the term ‘surf the web’ takes me back to the 90s and secondly it is a term that the digital industry has long forgotten. The statement does emphasise the fact that (mostly) people go online to get things done.

So if online is just another, not too salient, aspect of people’s lives, how does this impact user research? We need to stop thinking of online as a thing (particularly as a mystical and magical land). And start focussing on the various topic areas such as banking or paying bills.

Do you think this is accurate and what trends have you seen?