How a very small web team can support many clients

Maria Moore, Web Development Coordinator, Web and eLearning Systems Team, Centre for the Advancement of Learning and Teaching (CALT) [HREF1], University of Tasmania [HREF2] , Private Bag 133, Hobart 7001. Maria.Moore@utas.edu.au

Abstract

The University of Tasmania (UTAS) evaluates its web sites using a 'Health Check' framework based on criteria designed to provide an optimal user experience. This framework combines three approaches: an evaluation of web sites (Health Check), training sessions given to web developers on selected topics taken from the Health Check, and the UTAS Web Publishing Guidelines. Conventional web site improvement services available commercially tend to concentrate on search engine optimisation and market effectiveness. The UTAS Health Check process incorporates both of these areas but also evaluates site maintenance procedures, content quality and the experience of the user. The Health Check framework is an efficient, practical and effective method for a very small team to provide support to a large client base and to promote its services.

Introduction

The Web and eLearning Systems (WELS) Team provides support and training and maintains policies and guidelines for UTAS web developers. UTAS has a distributed model of web site responsibility, with web sites considered an official publication of the section that maintains them. UTAS web resources consist of approximately 360 web sites and 600 units with an online component. Web site size varies from a few pages to several thousand. There are nominally three full-time WELS staff available to provide support to web developers. Only two of these provide advice on web site effectiveness. To manage support and prioritise resource allocation, all sites are ranked according to their strategic significance to the University. Any site will receive support if requested, but the custodians of the highest ranking sites may be targeted to contribute to specific projects.

Pre-Health Check Support Process

Previously WELS staff were asked for a 'bit of help' by the person maintaining the site, whom we call the Site Editor. The Site Editor would point out new features or aspects of the site, and WELS staff would make a few suggestions. The Editor may agree with the suggestion, or would justify their decision to do whatever they had done, and move on to the next feature. The main outcomes of this sort of session were:

• The Editor showcased their work to a sympathetic audience. Maintaining web sites is usually only one part of their job which goes unnoticed unless there is a problem with the site.
• At the end of the session the Editor feels they have justified the time spent working on the site.
• The site might be improved.
• WELS staff may feel satisfied by their contribution, depending on the number of suggestions that seemed to 'stick'.
• WELS staff may get the Editor to attend a training session or two in the future.

This sort of approach certainly consumes time and keeps WELS staff busy. However, this is not necessarily time well spent. While WELS staff are more than competent to offer ad-hoc advice, and Site Editors more than capable of making improvements with or without help, the main outcomes of this type of support process are:

• No record of what was discussed.
• Nothing to demonstrate how WELS staff added value or to justify the time spent - important to document in a very small team.
• Nothing specifically identified in the site that was either good or bad.
• The workload, justification for the time spent on the site and identification or recognition of skills needed is not directed towards the appropriate audience, such as the supervisor of the Editor, the Site Administrator or the Head of Section.
• No other way forward except to wait until the Editor asks for another session and repeat the process, or suggest another visit from WELS.

Basis of the Health Check Process

Jakob Nielsen, in his book 'Designing Web Usability', proposed 7 basic requirements of a web site that can guarantee an optimal user experience. I derived the HEALTHY criteria from his approach [HREF3], including Basic Health for all sites (conformance to the legislation relevant to web sites) and:

• High quality content
• Easy to use
• Always kept up to date
• Lowest possible download time
• Totally relevant to users needs
• Highly specific to the internet
• Your Organisational Unit supports the site

The Health Check

Using the HEALTHY criteria above, I devised a process that could be used to interrogate a site and identify problem areas. The Health Check is essentially a series of questions with Yes/No answers. Most questions relate either to site management, content presentation and quality or to the user experience. The mode of delivery of the content is not relevant. Both static web sites and database-driven systems can be Health-Checked.

All questions are based on characteristics for which very clear good or bad examples can be recorded. This makes any 'No' answers difficult to contradict by reluctant participants. Content quality questions can be answered by WELS staff inspecting the site. Site management questions are answered by the Site Editor. User experience questions are answered by the Site Editor from site feedback or queries to the section, or investigated with usability testing [HREF4]. Where the answer to a question is 'No', an example or description of the issue is recorded, and a solution proposed to address this issue.

Once all questions are answered, questions with answer 'Yes' are removed, leaving all questions that the site could not satisfy, and the solutions. Some issues may be addressed by the same solution. All solutions are then sorted, ranked and prioritised to create the Action Plan. The Health Check and Action Plan are given to the Primary Site Editor and Head of Section or Site Administrator. The process is then overseen by a member of the WELS team.

Where a solution needs to be provided by the WELS team, this is may be managed in a face-to-face session or a tailored workshop session available to all web development staff regardless of whether their site is being Health-Checked. For example, content issues are addressed in a 'Writing for the Web' seminar.

Typically, a Health Check and its Action Plan take approximately 2 days for one person to complete for a large site. Health Checks are recommended every 2 years, when a site is redeveloped or when there is a change of site management. Although only two WELS staff conduct Health Checks, this has proved more than enough to create a certain amount of momentum that has resulted in improvements to UTAS web sites and also service provision by WELS.

The Health Check Criteria - examples of questions

Basic Health for all Web Sites - 12 questions including:

• Does the web site content and purpose apply to research, teaching, marketing or administrative activities of the University (AARNET Policy on Allowed Access - [HREF5])?
• Is the nature of sponsorship clear and specified for a finite time?
• Is the site free of offensive content?
• Is the site free of material that vilifies, defames (on the basis of race, sexual preference or disability), or violates the privacy of any person or people?
• Is the site free of content that misleads people or misrepresents the University?
• Is content promoting non-University or third party commercial activities absent?
• Are Copyright and third party material used with permission from the owner?
• Does the web site satisfy the Disability Discrimination Act 1992 and UTAS Equity Plan? - only one W3C Priority 1 issue [HREF6] needs to be demonstrated to require rectification.
• Are UTAS approved templates (standard or custom) used without modification?

Solutions may require the removal or rectification of unsuitable content, or the removal of the whole site.

High quality content - 20 questions including:

• Is all content relevant to site purpose?
• Is content related to links?
• Is the language appropriate for intended audience (not too formal or informal)?
• Does the content use the Active Voice and Standard Register?
• Is appropriate emphasis is given to content based on its relevance/importance (most important content placed near the top of the page)?
• Is content formatted for ease of reading (uses lists, does not contain large blocks of text)?
• Are menus used correctly (for navigation only, do not contain content, no dynamic menus used)?

Solutions may include attendance at Writing for the Web seminar. Navigation issues may require creation of new menus or a site restructure.

Easy to use - 15 questions including:

• Can representative users complete representative tasks? May be determined from queries about the site from the target audience eg. 'cannot find' queries (emails or phone calls to contact points).
• Is appropriate content found in major search engines using common search terms used by the target audience?
• Is the site in the University search engine collection?
• Does the site have appropriate Metadata?

Solutions include upgrading metadata, most importantly page titles. The site (if sufficiently large) may be evaluated with task-based usability testing [HREF4].

Always kept up to date - 7 questions including:

• Is content that applies for an identifiable timeframe current?
• Are Site Editor(s) able to maintain amount of content requiring regular review?
• Are old versions of files removed from local and remote site (may not be linked to in site, but should be removed)?
• Is site content reviewed according to a regular schedule?

Solutions may include removing old content, updating content, or developing a web content review program.

Lowest possible download time - 1 question:

• Have page size limits and download speed recommendations been followed?

Totally relevant to users needs - 3 questions:

• Do pages contain content appropriate to the intended audience?
• Have new sites been through planning process?
• Have existing sites has been redeveloped using planning process?

Solution may involve re-planning the site [HREF7].

Highly specific to the internet - 7 questions including:

• Does the site follow functional rather than organisational unit structure (unless site is about an organisational unit)?
• Is the client informed that their feedback has been received?
• Have one or more restricted directories used if necessary?
• Are search engines prevented from indexing sensitive information?
• Is the Site Editor a member of the Web Developers Mailing List?

Your Organisational Unit supports the site - 9 questions including:

• Does the Site Editor have a computer capable of running centrally supported web software?
• Is a Site Editor currently appointed to maintain the site?
• Has appropriate web-related training been included in Performance Management Planning for the Administrator and all Site Editors?
• Have web-related tasks been specified in the Position Descriptions of the Administrator and all Site Editors?
• Is the authorising entity identified in the footer?

The Action Plan Management

The Action Plan derived from the Health Check is not an open-ended document, but typically takes about a year to complete all items, with priority items addressed as soon as is practical. WELS staff check with the section regularly to see how things are going. At the end of a year, a review of the Health Check is done and a report prepared describing how each Action item was progressed, and recommendations are made for future work on the site. Recommendations for further work may include any uncompleted Action items. The site may have been changed substantially in that time, but the core recommendations from the Action Plan do not tend to lose relevance since Site Editors usually repeat the same practices and duplicate the same issues. In the case of a major site revision, a number of other documents may be prepared, such as a proposal for a new site structure, or an evaluation of accessibility for people with disabilities [HREF8].

Health Check Benefits for our Team and the University

After a trial period in 2004, we have so far Health-Checked 12 sites. These sites varied in size from 100 to 4,000 files. The largest site Health-Checked so far had the following issues:

• Approximately 2,000 HTML and links to 2,000 non-HTML documents, including duplicated, redundant and out of date content. Many pages were very large, and therefore took longer than 8-15 seconds to download on a 56K modem.
• Many pages were corrupted, and did not use standard UTAS Templates. This meant that considerable technical knowledge was required to make simple changes to the site.
• There was no dedicated Site Editor.
• Although the site was nominally about one business area of the University, the site followed the organisational structure of each section in this business area. Each of these sections created their own versions of some content, leading to duplication. Up to three conflicting sources of information were revealed in task-based usability testing on one client group for a single task. Each person was convinced that they had found the correct piece of information.
• There was a general lack of metadata.

All Health Check Actions were completed:

• Staff from the whole business area attended a seminar on Writing for the Web.
• The site was restructured to reflect the requirements of clients, with some new content areas identified. All staff from this business area had input, including the Head of Section. The amount of content on many pages was reduced, and the total number of HTML files was reduced from about 2,000 to 983.
• The Higher Education Officer (HEO, or worker, HEW) level and duration of a short-term appointment to restructure the site and to rectify corrupted Templates was determined. This work was successfully completed in the recommended time.
• After restructuring, site maintenance was allocated to a permanent staff member.

Interest in the process has now developed to the extent that in 2006 we intend to Health-Check at least 20 more sites.

Benefits for the WELS Team

Although we have so far only 'Checked' a small proportion of available UTAS sites, promotion of Health Checks and our other services has had a number of additional benefits for WELS, including:

• Allowing WELS to prepare focused staff information sessions, such as 'Writing for the Web', 'Speed up your Web Site' and 'Web Site Health', which can be delivered in any section on request.
• Identification of which WELS web resources best support Action Plan items.
• Involvement by WELS in UTAS web development projects at a much earlier stage.
• Review of the UTAS Web Publishing Guidelines. The previous Guidelines were heavily focused on a specific visual standard and therefore needed updating when the visual standard was changed. To create a more generic but also practical document, Health Check questions were reframed as statements which then formed the basis for the new Web Publishing Guidelines, a very rapid solution.

There were even benefits for WELS when dealing with unwilling participants. In at least one case, the site custodians were not prepared to complete their actions. Although there was not much WELS could do to encourage them to perform their part of the Action Plan, it was easy to demonstrate from the Health Check documents that WELS had dedicated a significant amount of time and effort to improving this site. Consequently this site could be given a lower priority for allocation of WELS resources in a subsequent project.

Benefits for the University

Once a Site Editor has been through the Health Check process, it gives them the means to investigate their sites themselves, and knowledge of the characteristics of an effective site. UTAS is considering adopting a Content Management System for admin web sites. Because the Health Check questions address content quality and content maintenance, the criteria still apply to a database-driven system.

Most Common Site Health Problems Identified

Some sites have more specific issues, but generally the most common site health problems were (with few surprises):

• Overweight sites - bloated with far too much content.
• Antisocial behaviour - sites that did not deliver what they promised, particularly through inconsistent navigation and uninformative link text.
• Socially awkward sites - these cannot indicate to which part of the University they belong, or that they belong to the University at all.
• Prematurely aged sites - content is out of date or irrelevant.
• Sites with multiple personalities - divided along organisational lines rather than the needs of the user.
• Effectively dead sites - which were not part of the University search engine collection.

Conclusion

Web Site Health Checks have proved to be an efficient, practical and effective method for a small team to evaluate sites and produce a plan of attack to rectify any issues found. The notion of a having a Site Health Check has generally engaged web developers and Heads of Sections and provided a palatable method of ensuring compliance with internal and external standards. In addition to identifying what needs to be rectified in a site, training, support, software and hardware needs can also be identified by WELS. It has also informed the development of support resources providing maximum value and applicability for UTAS web developers.

References

Nielsen, J. (2000). Designing Web Usability: The Practice of Simplicity. New Riders Publishing, Indianapolis, Indiana USA

Hypertext References

HREF1

http://www.utas.edu.au/calt/

HREF2

http://www.utas.edu.au/

HREF3

http://www.utas.edu.au/webservices/health_check/index.html

HREF4

http://www.utas.edu.au/web_testing/usability.html

HREF5

http://www.aarnet.edu.au/publications/access_policy_2005.html

HREF6

http://www.w3.org/TR/WCAG10/full-checklist.html

HREF7

http://www.utas.edu.au/site_planning/index.html

HREF8

http://www.utas.edu.au/accessibility/guidelines/evaluation.html

Copyright