Designing for improved usability: the my.monash portal

Dey Alexander [HREF1], Web Designer, Information Technology Services [HREF2] , PO Box 28C, Monash University [HREF3], Victoria, 3800. Dey.Alexander@its.monash.edu.au

Abstract

my.monash is a Web portal providing members of the Monash University community with a personalised gateway to Web-based resources and information. The poster presentation, and associated paper, document the results of a usability evaluation of the portal's customisation interface and show how the application of usability design principles to the redesign of the interface achieves significant usability improvements.

1. Introduction

my.monash is a Web portal providing members of the Monash University community with a personalised gateway to Web-based resources and information. As well as 'pushing' information relevant to various groups of users, the system facilitates user customisation, enabling the addition, removal and ordering of content to suit individual work or study requirements.

The portal was developed in-house by the Flexible Learning and Teaching Program (FLT), an educational technology project team within the Information Technology Services Division (ITS) at Monash University. A prototype was released for user evaluation in mid-1999 and the official release of the system was in July 2000.

The focal point of the development was on back-end elements of the system: programming for the required functionality and personalised content delivery. By late 2000, the FLT team realised that there were significant usability problems with the user interface. A request was made for Web and Internet Facilities (a group within the ITS Infrastructure Services department) to assist with making improvements to the interface, with an initial focus on the customisation functions.

A heuristic inspection, and subsequent pluralistic walkthroughs, indicated that the severity of the usability problems was such that a complete redesign of the interface was needed.

The poster presentation demonstrates the use of usability principles to re-engineer the interaction elements of the interface. 'Before' and 'after' images of a series of the customisation interfaces are shown, and together with this paper provide an overview of the project, a summary of the usability problems identified and the way in which usability principles were employed in the redesign.

At the time of writing, the redeveloped interfaces are being prototyped and the intention is for user testing to then be undertaken. It is anticipated that some further changes to the interface may be required once test results have been analysed.

2. Overview of the customisation functions of my.monash

The ability for users to customise their portal is provided through eight main customisation functions, each with several sub-functions. The main functions are:

  1. add content
  2. delete content
  3. change layout
  4. reset defaults
  5. delete channel
  6. rename channel
  7. create new channel
  8. change colour scheme

A ninth function, 'add channel' (from a list of ready-made channels), is planned for introduction in 2001.

The customisation functions apply to a series of themed or subject-oriented pages known as 'channels'.

Most, but not all, functions are accessed by way of the 'change content/layout' hyperlink located at the top of the user's screen. The functions operate on a channel-by-channel basis, with one exception - the change colour scheme function which operates on all channels. Not all functions can be applied to all channels: some channels cannot be deleted or renamed.

3. Summary of main usability problems identified

1. Unnecessary complexity and lack of clarity in the operation of the channel-by-channel customisation

In order to customise a particular channel, the user must first navigate to that channel, and then choose the 'change content/layout' hyperlink.

Severity of problem: HIGH

2. Lack of clarity in the options available for adding content to a channel

There are three ways in which content can be added to a channel: by performing a keyword search in a 'resource catalogue'; by selecting resources organised into 'component groups'; and by typing in a URL of the user's choice.

Severity of problem: HIGH

3. Inappropriate screen location and ambiguity about the availability of customisation functions

Not all of the customisation functions are available on the 'change content/layout' page. The 'create new channel' function is available from the left-hand navigation bar. The 'delete' and 'rename' channel functions are only available when navigating to the customisation screen from a channel that can be renamed or deleted.

Severity of problem: MEDIUM

4. The scope of some functions is not obvious

The scope of 'reset to defaults' function operates is not clear.

The scope of 'change colour scheme' is not clear.

Severity of problem: MEDIUM

5. The use of ambiguous or system-related terminology

The term 'component groups' is ambiguous, as mentioned in point two above, however this is compounded by the labelled of some component groups (eg. 'specific interest', 'unclassified').

Contents included on a channel are referred to by the system file name and location (eg. '/monash/sports/dummy.comp')

Reference is made to the 'right bar' in the change layout function.

Severity of problem: LOW

6. Inconsistency in the naming of navigation links and page titles

Several inconsistencies appear in the naming of navigation links and page titles. For example: 'change content/layout' leads to a page titled 'customisation'.

Several different pages have the same title.

Severity of problem: LOW

7. Insufficient error prevention

Functions that are not available to users are not always clearly labelled (eg. there is no list of channels that cannot be deleted or renamed and content items that cannot be deleted are not adequately identified).

Severity of problem: LOW

8. Inadequate feedback

Feedback messages confirming customisation changes are inadequate or not provided at all.

Severity of problem: LOW

4. Principles used in redesigning the interfaces

The redesign of the interface was based on a series of recognised usability principles.

Flexibility and efficiency of use

All customisation functions have been unified on one screen, and users can access channels to edit from within the customisation screen, rather than having to navigation through two screens to do this.

Consistency and standards

All customisation functions were located on one page Interfaces were standardised (in terms of layout and the use of GUI widgets) across all screens comprising the customisation functions of the portal. Page titles are consistent with hyperlink and function names.

Visibility of system status

Rather than reloading channel pages after customisation changes had been made, feedback screens have been introduced providing details of the changes made.

Match between system and the real world

Terminology was reviewed and use of ambiguous and system-related terms eliminated.

User control and freedom

User is given the choice of opting out of a change after taking the initial steps in the customisation process.

Error prevention

The complexity of the customisation functions was reduced by making all channels editable and all functions available from one page. Restrictions on the use of some functions (delete and rename channel, for instance) is now explicitly stated.

Recognition rather than recall

Users do not have to remember how the system works as the interface and interaction have been redesigned to match the way users work, rather than the way the system works.

Aesthetic and minimalist design

Page layout has been revised to make use of visual hierarchies and to minimise screen clutter.

5. Conclusions

The development of usable and functional Web applications requires a multi-disciplinary approach to design and development. Programmers are not interface or interaction designers and tend to create interfaces that model system functionality rather than users' goals.

The application of usability engineering principles to interface design can increase the usability of Web applications. Interfaces must, however, be subjected to user testing in order to ensure that usability problems are identified and rectified.

There are cost-benefits in introducing usability in the earliest stages of Web development: getting it right at the start saves time and money by reducing the likelihood of the need for major redesign further down the track.

References

Nielsen, J. and Molich, R. (1990). 'Heuristic evaluation of user interfaces', Proceedings of ACM CHI'90 Conference, pp. 249-256.

Nielsen, J. (1993). Usability Engineering, Academic Press, San Diego, CA.

Nielsen, J. 'Heuristic Evaluation'. Available online [HREF 4]

Pearrow, M (2000). Web Site Usability Handbook, Charles River Media, Rockland, MA.

Bias, R. G., 'The pluralistic usability walkthrough: coordinated empathies' in Nielsen, J. and Mack, R.L. (eds.) (1994). Usability Inspection Methods, John Wiley & Sons, New York, NY, pp. 63-76.

Hypertext References

HREF1
http://deyalexander.com/
HREF2
http://www.its.monash.edu.au/
HREF3
http://www.monash.edu.au/
HREF4
http://www.useit.com/papers/heuristic/

Copyright

Dey Alexander, © 2000. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.