Tag Archives: interface design

Usability for the enterprise

In many enterprises, usability, if it exists at all, remains an isolated and inconsistent experience. The amount of importance attached to user interface design or the wider user experience often varies according to the level of epiphany within individual project managers or developers. Indeed in some large development projects I’ve seen usability commitment (and commensurate quality of the output ) vary between developers on the same project.

The challenge for the enterprise therefore is establishing some consistent approach to usability across the organisation that

  • Recognises the varying usability needs of the project (the steps appropriate for a command-line interface used by 3 senior administrators must be different to those for a GUI used in front of customers across 2,000 bank branches)
  • Recognises the varying skill and exposure levels of the involved parties
  • Works with the above two constraints to maximise the cost-benefit of usability activity.

In brief, this post explains an approach that we implemented for one organisation that works very well in engendering usability with minimal up-front upheaval.  In essence only three steps:

  1. Make usability assessment a mandatory step within the project planning process
  2. Simplify and distribute the fundamental usability activities
  3. Standardise and centralise the advanced usability activities

Make usability assessment mandatory

The trick in this step is to make the assessment of usability needs mandatory, but not the conducting of any activity. The purpose of the assessment is solely to determine what activities are appropriate for the project.

This assessment can be easily quantified via some form of checklist or score sheet, tailored to the particular needs of your organisation. Have your project managers review their project against your checklist and output a score and/or recommended level of usability activity.

In developing your score sheet, here are some attributes to consider:

  • Audience: internal or external users? Education/experience levels? Prior exposure to tool/concepts? Number?
  • Platform: web-based vs. native app?  GUI vs. mainframe/terminal?  Availability of support resources (online help, tooltips,..)?
  • Timeliness:  How time pressured are users?  Is it critical to complete fast?  Are customers watching?
  • Location: for use in a quiet office or on a noisy factory floor? To be used outdoors? Underwater?
  • Risk: what are the implications if the customer gets it wrong? To them? To us? What’s an acceptable error rate?
  • Alternatives: availability of training developers? or classrooms?

In its simplest form, have your project manager score their project on a 1-5 scale for each chosen attribute. Then get them to compare their total with your own guidelines (a la most personality quizzes in the Women’s glossies):

  • If you scored < 5, your project has low usability requirements. We recommend (a).., (b)…
  • If you scored between 6 and 10, your project has medium usability requirements. You must complete (a..). We recommend (b)…, (c)…,  etc

The checklist provides the project manager with a list of required activities, and a list of recommended activities.   Give some flexibility since human nature (and most project managers are human) welcomes a semblance of control and personal decision-making. It also accommodates differing levels of commitment to usability within your organisation and encourages those who are ahead of the curve and recognise the value of completing more, rather than less.

In outlining the required and recommended activities, also provide some estimates of the work effort, scheduling and resourcing needs. This gives the project manager all the information needed to produce a project plan that correctly integrates the new activities in the tasks to follow.

Note: These implementation guidelines need to reflect your organisation’s own development methodology: waterfall, agile, etc.  The aim is to make it easier for the project manager to add these activities (and mitigate risk/fallback to them once project is implemented) than to ignore them.

Simplify and distribute the fundamental usability activities

Within your list of required or recommended usability activities there will several that are so fundamental you’d be recommending them on most projects. They’d also be activities that most project managers would say they do already (to some extent). These are activities like:

  • Contextual inquiry
  • Paper prototyping
  • Design walkthroughs
  • Usability walkthroughs, etc

Such activities can be defined to such a level that project teams can take responsibility directly for their completion. The role of the central usability team is to support them in that regard by:

  • Providing clear instructions on how to most effectively conduct the activity
  • Developing and issuing related resources or tools (for example, interview checklists, prototyping templates, etc)
  • Offering in-house training or support

Where the line is drawn between the fundamental and the advanced activities will vary from organisation to organisation. And will vary with time. However initially focus on those activities project managers would expect (or believe) their project team is already completing themselves. Even getting to a standard definition and implementation of a usability walkthrough would be a great improvement for some organisations we’ve worked with.

Standardise and centralise the advanced usability activities

When the usability needs for your development become significant it is time to call in the big guns:

  • Interactive prototyping
  • Heuristic evaluation
  • Formal evaluation
  • User survey, etc

These are the skills your project managers/teams are not yet skilled enough to conduct themselves (heuristic evaluation), or that it is easier to always manage from a centralised location (user survey).

These may also be skills that you would want to always retain central control over. This is particularly the case if working with external developers/vendor companies. As part of the contract you’d be happy/expect them to conduct the fundamental activities but would manage the advanced activities in-house to (a) ensure they are completed satisfactorily, and (b) to make the outcomes a guaranteed part of the development obligations.

Note: Longer term the organisational goal should be to inculcate usability so deeply into standard project management practice that you are able to push activities “down” from this centralised/managed position to the fundamental. There is no reason why your usability lab cannot become another resource (like an OHP) to be booked for project meetings.

Alternatively, investigate replacing some of the complexity with technology. For example a tool like allows anyone with a Mac to conduct an in-depth usability evaluation complete with recordings of on-screen behaviour and user reactions/responses. No need to buy that two-way mirror!

Conclusion

Usability is far too important to leave to personal preference. Make identification of the need (and risk) standard for all projects and you’ll be in a position to use that identified need to drive adoption and the subsequent performance benefits.

CSS 101: Changing link appearance

[Had a few people ask me about this. Easier to write it down....]

By default, links in HTML:

  • are underlined
  • are in the same font as the rest of the document
  • change colour depending on whether the link target has been visited or is yet to be visited in the current browser session.

Note this the last rule “link has been visited” is slightly different to the expected “link has been clicked”. Your links can therefore change their appearance to indicate a visit without ever being clicked. For example if you have two links to the same page, both will change colour when you click one of them and visit the target page.

To change any of these defaults you simply need to define an alternate style for the links.

A word of warning before we start

Be careful when updating the default styles for your links. Users are used to the defaults given above.

If you change them too dramatically some users may not be able to identify your links and not access your content. If changing the styles, ensure you provide some other method to identify the links as links. For example, position in an obvious-looking menu, use different colours/fonts, add an icon or image, use standard wording, etc.

Styling links based on their status

A link is added using the <A> tag. However adding a style for this tag is slightly complicated because the link has four different statuses, called pseudo-classes, and styles can be set for each:

  • A:link – link that has not been used, and the mouse is not pointing at it
  • A:visited – link that has been used, and the mouse is not pointing at it
  • A:hover – link that has the mouse pointing at it (but not clicking it)
  • A:active – link (visited or not) that has the mouse clicking on it

There are some rules about the order to define the pseudo-classes:

  • a:hover MUST come after a:link and a:visited
  • a:active MUST come after a:hover

An example

For example, assume you want to remove the underline style for the link, but show the underline when the mouse hovers over it. Additionally you do not want visited links to show a different colour to unvisited links. A sample style definition would be:

A:link, A:visited {
        color: #0066ff;
        text-decoration: none;
}

A:hover, A:active {
        color: #0066ff;
        text-decoration: underline;
}

Note how the different pseudo-classes for the link tag are identified by “:name”. Eg A:hover defines the style for the hover status of the link, etc. Also note how the same definition can be used for multiple statuses simply by separating the names by commas.

Obviously you can do anything you want on those styles. For CSS text-decoration is the attribute that determines underlined or not.

using these styles in your page

To make use of these styles on your page you need to include your new style definition:

  • in the <HEAD> section (add a <STYLE> section within the head), or
  • as a separate, linked CSS file

To add the above definitions in the document, add a <STYLE> section in the document head. For example:

<head>
        <style>
        A:link, A:visited {
                color: #0066ff;
                text-decoration: none;
        }
        A:hover, A:active {
                color: #0066ff;
                text-decoration: underline;
        }
        </style>
</head>

To link as a separate stylesheet, save the style settings in a text file (don’t include the <style></style> tags) and then add the link to that file in the document head. For example:

<head>
        <link href="styles/main.css" type="text/css" rel="stylesheet" />
</head>

If you want to add comments/descriptions in your stylesheet file (you know you ought to!) use /* … */ to indicate those comments.

Styling based on location on the page

Only other point of interest is that you can also set styles for your links depending on where they appear in your HTML. For example we often use links in table headings to allow sorting (click on heading to set order, etc). Since headings have a different default style, we need different link styles just for headings:

TH A:link, TH A:visited {
         color: #ffffff;
         text-decoration: none;
}

TH A:hover, TH A:active {
         color: #ffffff;
         text-decoration: underline;
}

Notice how this CSS just refers to links within the tag to allow me to finetune their appearance.

more information

Once you know the pseudo-classes for manipulating link appearance, you are obviously free to make any changes supported by CSS. All these pseudo-classes are part of CSS1 – the full CSS1 specification is on the W3C website.

A useful primer on using CSS and styles is provided by W3Schoools.

Accessibility in a nutshell

The term accessibility has quite specific connotations in the internet world.  It describes the capability of your site to support users with disabilities:

  • colour blindness
  • sight loss (up to and including complete blindness)
  • hearing loss (up to and including deafness)
  • reduced motor skills, etc.

Additionally the disability to be considered may not need to be one that is ‘part’ of the user but could be one imposed on the user by circumstances.  For example accessing your site via a mobile device, or in a bright environment.

Published guidelines

As is the way of the web, a series of guidelines have been developed (see http://www.w3.org/WAI/ for details) that provide tangible steps a site designer can take to address accessibility issues.  These are prioritised as 1,2,3 depending on to what extent your site is to meet accessibility needs.  From the guidelines:

  1. A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
  2. A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
  3. A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

A site that meets all priority 1 requirements is given a conformance level of A, priority 2 = AA, priority 3 = AAA.  You’ll see some sites reporting this conformance level.

What guidelines do you need to meet?

Only government sites, or government sanctioned/supported sites may have mandated conformance requirements.  This is particularly the case in the US where federal laws determine the levels of accessibility to be supported.

For the rest of us the choice is private.  Grade A (meeting all level 1 items) can be considered the de-facto standard for any site, irrespective of audience or content.  It includes such straightforward requirements as providing ALT descriptions for all images (so text readers can describe them) and generally using HTML (and particularly CSS) correctly so different presentations can be created easily.

There is considerable work involved in conforming with the higher accessibility grades, particularly if reworking an existing site or content.   We may therefore choose only to go those levels if our particular audience requires it, or if particular elements in our site require it (eg online policies for disabled access would attract more users with accessibility issues and thus warrant higher conformance levels).

Testing compliance

The first step in considering accessibility is reviewing the guidelines and conducting a code review (and/or developing a coding standard depending on project status) which encompasses the core elements.

There are several online tools or services available to allow published sites to be tested easily (and regularly – important if content is changing).  The UK’s Royal Institute for the Blind maintains a comprehensive list of such testing services.  One of the most famous/useful testing sites was Bobby.  Unfortunately this appears unavailable at present.

Accessibility and SharePoint

SharePoint can be configured/developed to provide compliance with several accessibility guidelines.  And for sites requiring a higher level of conformance there is a downloadable Accessibility Kit for Microsoft Office SharePoint Server 2007.  This Sharepoint team post on accessibility explains approaches using both standard SharePoint and the accessibility kit.

Conclusion

As any other core business system, an intranet needs to comply with the firm’s directives for supporting staff with disabilities.  The W3C guidelines provide a clear and comprehensive method for assessing, ensuring and displaying that support.

iPonder

My iPod (and other items?) automatically adjusts for an initial “The” when sorting artist names. Rather than grouping all such bands under “T” it ignores “The” and puts in the appropriate place in the list. Eg “The White Stripes” appear with “Wolf Parade” not “TISM”.

Point to ponder is what happens to the songs by the olde British band The The? Where to go to look for them?