Free help and advice to the UK Further and Higher Education community

Helpdesk

Graphical User Interface Design: Developing Usable and Accessible Collections

Last updated: 19 November 2008
Published in: Managing your digital resources
Tags: accessibility | delivery | digital collections | finding images | usability

Summary

This paper looks at the development of a graphical user interface (GUI) for a digital collection. It takes a general view of facilitating effective access to a digital resource and then examines more closely the issues of usability and then accessibility. It is intended to be of use to collection managers wishing to grant access to a digital resource.

Contents

  1. Introduction
  2. Common GUI elements
  3. Planning your GUI
  4. Building your GUI
  5. Ensuring usability
  6. Ensuring accessibility

1. Introduction

This document presents some advice on developing an effective graphical user interface (GUI) for a digital collection. While much of this advice relates to larger digitisation projects, there are principles here of use to collections of any size. The key points in developing effective GUIs are to:

  • Involve your users at all stages
  • Look at what others are doing
  • Know and work within your limitations
  • Ensure your GUI is both usable and accessible

When talking or reading about GUI design, two issues often crop up:  usability and accessibility. These are closely related, but are not quite the same thing. Usability is about ensuring that your design is user-friendly,  intuitive or easy to grasp. Accessibility is about making sure that your GUI doesn’t create barriers for those who have disabilities or need to access your resource in alternative ways. If your design is not usable it will frustrate your users; if it is inaccessible, it may actually exclude potential users altogether.

2. Common GUI elements

The list below outlines the elements that are typically found within public interfaces to digital collections, although some collections are simpler and others are much more complex.

Introductory and supporting information

  • Welcome. Often a colourful ‘splash’ page reflecting something of the collection’s content
  • Information about the collection. Who produced it, its scope, and, sometimes, how it was made
  • Help information. How to use the resource
  • Contact information. How to get in touch with those responsible for the resource
  • Rights information or Terms of use. Information about ownership, copyright and the user’s obligations

Facilities for finding content

  • Way(s) of browsing the collection. Where the user can navigate through the collection by clicking on hyperlinks
  • Way(s) of searching the collection. Where the user can enter a search query and view the results

Main collection content

  • Summary pages. Provide an overview of browse or search results, typically with thumbnails
  • Detailed pages. With screen-sized images, video or audio players, and full metadata

Extended features

  • Ability to view digital images at larger sizes. Often through zooming
  • Option to watch video streams at different sizes. Depending on network bandwidth
  • Option to download files.To local hard drive for later use
  • Option to embed a file. User embeds a digital video clip into another online context
  • Ability to ‘bookmark’ the files for later reference. Often called ‘albums’ or ‘favourites’
  • Ability to annotate or comment on an image, video or audio file. Tagging for personal use or for public display

3. Planning your GUI

3.1 Your user GUI is one of the first things to think about - not the last!

A primary goal of any digitisation project is to enable its users to have efficient and rewarding access to a collection. The collection may be superbly digitised and catalogued, but if the GUI is poor, it is unlikely to be much used.

All too often, those planning digitisation projects concentrate more on their collection and its characteristics than on their users and their users’  needs. In extreme cases, this leads to a hastily bolted on GUI and a scramble to find some users and convince them that they can benefit from the resource!

A much better approach is to identify your users’ needs at the beginning of the project, allowing these to dictate which collections or selections you digitise and the functionality you require from your delivery GUI. Instead of being an afterthought, the GUI should be sketched out at the very beginning and should inform the way you digitise and catalogue your collection.

For example, you may have a collection of historic tapestries. While the art history students might be satisfied with images that depict the general design of the works, if the intended user base includes conservators, they may wish to examine the detail of the stitching (front and back). To facilitate this, you may need to produce very large digital images and serve them up using some sort of zooming technology. If you decide you need to serve a number of difference audiences you may decide to offer completely different GUIs to each group.

As a second example, you may hold a collection of analogue oral history recordings which you plan to digitise. These recordings may originate from many different parts of the UK and participants might speak in a rich array of regional accents on a wide range of social history topics. If the intended audience for your digital resource consists of dialectology students, your recordings may have to be searchable by region, perhaps by linking each recording to postcode data. However, sociolinguistic researchers may prefer to search by sociological factors such as family size or interviewees’ job type.  Collecting postcode data information is not a trivial task. It is important to plan for this from the beginning. It can be very time consuming (and hence costly) to go back and add such data. There may be further cost implications if you need to purchase additional software or license other data.

There will always be a balance to be struck. Standards and practices in GUI design develop over time, so your current GUI should not entirely dictate your data capture and cataloguing practices. Ideally, your digital media objects (images, video, audio) and metadata should offer you some flexibility in the longer term.

Your digital master files should be large enough and your descriptive metadata broad and deep enough to support enhanced functionality or display.  While you cannot guarantee your data will meet every future need, you must, at the very least, ensure that your data files and metadata do not compromise your current GUI. Your collection is unlikely to if it fails to support and excite its current users.

3.2 Get your users involved in the design of their GUI

Even if you’ve identified your users carefully, it’s all too easy to make assumptions about what they need or expect from your collection. There is no substitute for asking them directly: at the beginning of your project and throughout its development.

It will probably be useful to make a distinction between your core users -  those for whom the collection has been funded and is primarily intended - and your extended users - those who may also derive some benefit from it. Where there are contradictory suggestions or resource limitations, it is likely you will favour the needs and suggestions of your core users over your extended user base. However in some cases you might decide that you need to provide more than one GUI to your collection.

Don’t forget your cataloguers - they’re also users and it’s vital you pay attention to their needs. Entering metadata is a very time consuming activity and over the course of a large project, a minute or two saved per record will really add up (for 5,000 records each minute saved is worth about 2 weeks!).  Where possible, make use of templates, default settings, drop down lists, bulk editing tools, automated metadata extraction tools or the ability to clone/duplicate records. A simple thing like enabling your cataloguers to tab through the fields rather than have to mouse-click, will save a lot of time.

3.3 Find out what others have done or are doing

It is vital to look at what others have done. Take the time to locate and assess other digital media collections. Look closely at those that are similar to your own, but also look broadly at what is happening within other sectors and in other countries.

Be very critical. Imagine you are a typical user of the collection you’re looking at: what works well and what doesn’t work so well? What could have been done differently or better? We’ve compiled some questions to help you think critically about online collections.

  • Why was this collection made? Who made it? Who is it for? How does it relate to other collections or resources?
  • What are its limits? What is its size and scope? Is it clear how and why the items were selected?
  • What is the quality of the assets like? Have appropriate file formats been used? Are the files of sufficient quality to represent and communicate the original?
  • What is the quality of metadata like? Have appropriate standards been used? Is the metadata meaningful? Has it been fully exploited in the search and browse? Is it displayed in an innovative way?
  • Is it well designed? Is the navigation clear and consistent? Do you always know where you are within the resource? Does the choice of font, colour and graphics support or enhance (rather than distract from) the content?
  • Is there appropriate support? Are clear instructions provided? Is there a separate online help section? Can you get help offline (email, phone)?
  • Can you browse or search the collection effectively? Are the categories for browsing meaningful for users of this collection? Does it offer advanced searching options? Do the results match your expectations? Are they well presented?
  • Can you personalise the collection? Can you customise the GUI? Can you bookmark or store content? Can you annotate or tag content? Can you contribute your own content to the collection?
  • Does the collection offer a good level of accessibility and usability? (see below)

If possible, contact collection holders directly ask them how they did it,  what they would have liked to do with more resources, and what they would do differently if they were starting out again now. There is a lot to be learned from the experience of others.

Also, make an attempt to find out about innovative work in progress. Send messages to email lists. Read digital library literature and relevant conference reports. Contact commercial asset management system vendors.

The time you spend doing this research is time well spent, and you are likely to develop a good sense of what you need to do. But don’t rely on your own judgements. As we said in the previous section: show examples to your users and canvas their opinion.

If you’re looking for collections that are already online, here are some starting points:

Projects in development are much more difficult to find. You might try:

4. Building your GUI

4.1 Using an ‘off the shelf’ solution

Having thoroughly researched your users’ needs and explored a range of possible approaches, you need to assess what is going to be realistic given your current resources. A decision has to be made; will the GUI be build in-house, be off the shelf or will the solution a combination of the two?

For many projects a significant limitation is that they are working with an off the shelf digital asset management system that offers limited functionality and minimal ‘tweaking’ of the GUI.

It is important that you identify the limitations of the GUIs (delivery and cataloguing interfaces) when you are sourcing an asset management system. It’s also worth checking whether there is a proactive user group. Some asset management software companies have a good record of responding to requests from individual users or from user groups.

JISC Digital Media’s report on Choosing a System for Managing your Image Collection offers a good general checklist of things to consider. In terms of the GUI, you’ll need to look particularly at:

  • Data entry interface. Can you customise the data entry interface to improve your cataloguing workflow (e.g. rename or re-order fields, set up templates or drop-down lists, remove from view fields that you don’t use)? Are there other features to aid productivity or accuracy (e.g. keyboard short-cuts, tabbing, automatic word completion, spell-checking, data validation)? Can you enlarge the font or change the colour combinations?
  • Customisable visual design. Can you add your own graphics and text to make it look and feel like the rest of your Web site? Does it work well and look good across different Web browsers and operating systems?
  • Search and retrieval interface. Can you customise the search or browse interface to better suit your users and your collection? Are there advanced search options? Are search results displayed well?
  • Additional user functionality. Some systems offer extra features, such as enabling users to collect and annotate their own selections, the ability to group items etc.
  • Control over user access. Can you limit parts of the collection to specific users or groups of users? Can you deliver different features or levels of functionality or detail depending on user? Are there any digital rights management (DRM) features such as automatic watermarking?
  • Interoperability with other collections. Is the linking content and metadata supported?  Can a user search across collections?

4.2 Do-it-yourself GUI

If you are building or commissioning your own delivery system, you will probably have more control over the look and functionality of your interface.  However, this can prove an expensive and time-consuming process. Unless you already have the expertise within your staff team, you will need to find and hire someone with the relevant skills or train someone to do the work. The development is likely to take considerable time.

If you do take the route of developing your own system you need to be very clear about your requirements, ensure that there is strong and effective project management in place, and document everything fully. You must also make sure you have a plan for maintaining the delivery system once the project is finished.

4.3 Combined solutions

There are some other options that may offer the best of both worlds - i.e.  delivering the desired functionality without starting from scratch, spending a fortune or risking the reinvention of the wheel. Some off-the-shelf systems are sufficiently flexible that experienced programmers can significantly customise the GUI - or develop their own interfaces. Some producers will also supply highly customised systems for their clients, using a mix of existing modules and new components to create something that is a good fit for your users’ needs.

5. Ensuring usability

Usability draws on the field of Human Computer Interaction (HCI), which investigates the way people use computers. Usability is best thought of as a set of tools or techniques, rather than a rigid set of rules, although there are some relevant international standards, including:

  • ISO 9241: Ergonomic requirements for office work with visual display terminals (VDTs) , especially Part 11: Guidance on usability (1998)
  • ISO 13407: Human-centred design processes for interactive systems (1999)

Effectiveness, efficiency and satisfaction are important factors to consider when evaluating your GUI and usability experts have developed several approaches to measuring these, including:

  • Usability testing with real users. Giving typical users some tasks to perform and recording what they do and what they think of the resource. This might involve observing a user in action and noting down how they navigate.
  • Usability evaluations by you or experts. They might make use of formal guidelines, checklists or questions (e.g. ‘usability inspections’ or ‘heuristic evaluation’) or might involve role-playing particular users types (‘cognitive walkthroughs’).
  • Gathering user feedback. These approaches involve seeking feedback from users after they’ve used the resource. A common and easy approach is to survey users, but interviews and focus groups are likely to deliver much richer information.
  • Usage logging. A lot of useful information is recorded automatically by the server or software used to deliver your resource. By analysing which pages users have visited and how successful their searches have been, it is possible to build up a picture of the usability of a resource.

5.1 Designing for usability

The techniques above can and should be used to test your GUI at various stages throughout the design process, but there are other techniques that can be used to inform the design itself. These include:

  • Looking at competitors’ designs. Getting some typical end users to evaluate resources that are similar to the one you’re developing; and tell you what they like or dislike about them.
  • Card sorting and labelling. Asking your users to organise and label your content and interface in the way that makes most sense to them. Different users will come up with different solutions, but it is likely that this approach will provide some useful and surprising ideas.
  • Prototypes. Asking users to evaluate models and mock-ups of your resource. These could be created on paper or on screen, and might include real content or dummy content.

ISO 13407 focuses on the processes involved in developing a high-quality and usable interface. It advocates four main steps:

  1. Specify the context of use. Understand who will be using the resource and how they will be using it (e.g. which browser will they be using to access the resource?).
  2. Specify user and organisational requirements. Set out the tasks that must be supported (e.g. searching for video) along with some measurable targets for how effectively, efficiently and satisfyingly these tasks should be performed (e.g. “find video in 70% of searches, within 2 clicks, with 90% satisfaction”).
  3. Produce design solutions. Design the resource in order to meet the requirements identified in Step 2.
  4. Evaluate designs against user requirements. Check that the development does in fact meet the requirements and targets you have identified in earlier steps.

This process is iterative, cycling through the stages and refining the requirements and design until the resource is completed. For some resources the process will never be complete since users, contexts, and expectations change and new solutions are developed.

There is a lot of information about usability on the Web.  For some good starting points, visit these Web sites:

6. Ensuring accessibility

In addition to JISC Digital Media, JISC funds TechDis, an advisory service specialising in accessibility issues. For this reason we only provide brief information here and refer the reader to the JISC TechDis Web site and helpdesk for more detailed information or for answers to specific queries.

6.1 The legal obligation to consider accessibility

Accessibility is something to take seriously. Not only will a responsible resource creator want to produce something that is as accessible to as many users as possible, but there is also a legal requirement for those providing educational resources to consider accessibility.

The Disability Discrimination Act (DDA, 1995) gave certain rights to people with disabilities in the areas of employment, housing, and access to goods or services, but it excluded education. This was amended by the Special Educational Needs and Disability Act (SENDA, 2001), which made it unlawful for an educational institution to discriminate in the services it provides for students. Institutions are expected to make ‘reasonable adjustments’ to ensure that their students with disabilities are not disadvantaged.

6.2 Accessibility is not just an issue for those with disabilities

Although accessibility issues are often discussed in relation to those with physical or learning disabilities, it is useful to think about accessibility much more broadly.

In addition to disability, some people can face technological barriers to access, either through a lack of resources or their choice of technology.  For example, your users are likely to be connecting to your resource at a wide range of different speeds (dial-up modems to broadband or fast educational networks). If your resource requires large downloads, it will not be very accessible for those with slow connections. Similarly, users will want to use a wide variety of devices to view your resource (from large screen monitors to digital televisions and mobile devices). If your collection is designed with the largest screens in mind, it may not prove very accessible on the smallest.

6.3 Try to be flexible

While it can be difficult to anticipate every need, it is not usually hard to offer some alternatives and build a bit of flexibility into the design of your resource.

If you’re developing your own GUI, accessibility is best addressed as part of the design process, rather than dealt with as an afterthought or an add-on.  Instead of hastily changing your interface in response to a request or a complaint, you should be proactive in providing a resource that offers the best possible experience to the widest possible audience. This means considering the issues from the beginning, making use of some of the resources listed below,  and consulting your users who are drawn from a wide ranging and above all representative user group. It is also sensible to test your GUI on as many different browsers, devices, and connections as you can.

Accessibility (and usability) can sometimes be harder to achieve where you have bought an off-the-shelf digital asset management system to deliver your collection. Some systems offer little flexibility, forcing you to adopt colour combinations, font sizes or layouts that hinder accessibility. Others offer good accessibility already or can be customised to achieve a suitable design.  When purchasing a digital asset management system, you should make sure that accessibility and usability are on your checklist. It is well worth talking to systems vendors about the issues. If the current version of their software has problems, it may be possible for them to incorporate improvements into future designs. It is in their interest to develop a product that meets user needs and satisfies accessibility guidelines.

6.4 Some things to think about when developing online collections

We will highlight a few questions here that relate specifically to digital collections:

  • Interface. Is the interface accessible across a range of devices and browsers? Is it possible for the user to alter the colours and font sizes? Does it use style-sheets to format the resource (rather than frames, tables or graphics)? Are all instructions clearly written? Is textual information presented as text (rather than just pictures of text)?
  • Navigation. Is it always clear where you are and where you can go to next? Are hyperlinks clearly identified and available as text (rather than just graphics)? Can the user fully control their navigation and use of the resource (e.g. pause any video or sound elements)?
  • Search and retrieval. Can the user access search forms via the keyboard (or does it depend upon the mouse)? Are the search and results presented as HTML or XML (or embedded in another application, such as Flash or Java)?
  • Dimensions and size of files. Are there a range of image/video sizes (dimensions and file sizes) to suit different needs? Is the user made aware when they are about to access a very large file? Is it possible to look at an image in detail (either a large image, enlarged sections of the image, or a zooming feature)?
  • Description of files. Are there textual descriptions for all visual resources? Are there transcriptions for audio and video files? Are there searchable text equivalents where pages of writing have been digitised?

6.5 More information about accessibility

If you require more information about accessibility, here are some good starting points:

Last updated: 19 November 2008
Published in: Managing your digital resources
Tags: accessibility | delivery | digital collections | finding images | usability