Christine Cahoon <christine@jupiter.qub.ac.uk>
George Dunn
Majella McCarron
George Munroe
Queen's University of Belfast
United Kingdom
Keywords: information services, user support, distributed.
Today, with computer or network related applications pervading more and more of our lives at work and at home, "good" user support presents a greater challenge than ever. We firmly believe that existing technology can be utilized to provide an effective online support system which: a large number of people can benefit from; can deliver all the facility of a Helpdesk efficiently; and can pool expertise which can then be shared widely.
We believe that conventional user support as offered by many organizations today is "just not good enough" to fully address user requirements.
In evaluating the user support which exists today, the first point to make is that there may be many contact points with a "user support service." For example, the following are contact points which exist at Queen's University Belfast.
| 1 | Help Desk, the main contact point for users. Very often this is a face to face meeting, with queries also being raised by phone and email. |
| 2 | Reception Desk, where registrations, bookings, sales are handled |
| 3 | Main Office, where general administrative queries are dealt with |
| 4 | Network Faults telephone number, serviced by the networking group |
| 5 | Machine Faults, processed by the engineering section |
| 6 | Computer Lab Operators, for direct queries about central servers |
| 7 | Individual Members of the Computing Service who are known to users and are approached directly when problems arise. |
Table 1
User contact points with the Computing Service
There are also "public" channels of communication for updating users with news, important announcements and so on. The problem is that again there are many of them and not all are necessarily given equal attention by support staff. We could have a "message of the day" on Unix systems, log-in messages on other central servers, extensions to mainframe help systems, newsgroups, or the World Wide Web (WWW).
At Queen's, and many other universities or organizations, user problems reported at a Helpdesk are handled by a chain of support staff--a chain with several links. Helpdesk staff record the problem and may pass it to and fro between several perceived experts, before formulating a response for the user. This process is not trouble free especially when Helpdesk staff change frequently or may be absent without sufficient notice. Often front-line Helpdesk personnel simply can't appreciate all that a problem involves and who can help further. Usually there is no easy way to recall solutions to past queries.
Support staff could be Helpdesk personnel or others behind the scenes. From their perspective, there is a vast range of applications and systems to be familiar with and more users than ever before. Their expertise is being "diluted" because there isn't time to specialize. There are lots of trivial questions and requests which waste so much time and cause demotivation. There is a perception of constant "firefighting" and always being in reactive mode. Constant phone calls, e-mail messages and interviews with users are not conducive to stress-free work for those on the front line, and for those behind the scenes, and expected to provide "expert" help, queries are often regarded as an intrusion.
Many of us have had that nightmare vision of a support desk with 20 telephones all ringing and staff running around chasing their tails not knowing what way to turn. We know the conventional approach just does not scale.
Lots of time is required to address queries using phone and face to face dialogue. Lots of paper may be involved in recording queries, and the information on this paper may not be readily reusable. Support is often fragmented with different staff providing varying amounts of help independently. There is duplication of effort--the right hand may not know what the left is doing--and also similar queries may be resolved over and over by different staff. Scaling the standard practices to handle more and more users does not seem like a realistic proposition. In many cases it's difficult to see how the customer can be satisfied.
Times are changing. In computing over recent years, we have seen a move towards:
| 1 | desktop applications and 'easy interfaces' |
| 2 | powerful processors |
| 3 | inexpensive storage devices |
| 4 | wide range of hardware and software configurations |
| 5 | multimedia becoming standard |
| 6 | high user expectations |
| 7 | lots of novice users |
Table 2
Technology and user trends
An appropriate strategy should appreciate that we must build a service which is scalable and which will not collapse as we are faced with the need to sustain more and more users with ever diversifying computing requirements. It is also important to realize that users now expect services on their desktop with a single easy-to-use interface. We would also suggest that a service must be arranged in such a way that staff remain committed and motivated.
On the user side, help must be at hand for users as soon as they need it. Users should be able to help themselves by using resources at their disposal. Software updates should be provided in an organized way. Registrations for e-mail, access to servers, or whatever, should be hassle free. And appropriate electronic forums for communication and the exchange of ideas should be established. It is important to teach concepts rather than provide quick fixes, which all too often are only temporary and encourage users to be over-dependent on support staff. All support work should count--every answer should be available for sharing, nothing should be wasted because it is done in isolation and others are not aware of it.
In a nutshell then, the aim should be: "To provide as many user support functions as possible online, enabling users to easily obtain, and supply, timely and appropriate information on their desktop."
We have given this "vision" a name: "Environment To Inspire Network Users" or ETINU.
We strongly believe that the technology, which we all currently use, can be "leveraged" to provide more effective user support. E-mail and World Wide Web, in particular, can provide the basis of a new kind of electronic networked Helpdesk which makes it possible:
At Queen's we have built a "pilot" system that embraces some of these ideas. This system was set up on a development Web server for testing and evaluation during 1996. During this period feedback from both users and Computing Service management was sought.
The central component of the system is a World Wide Web server, using the Apache software. The Web server stores sets of pages relating to different support areas. Each support area has a corresponding e-mail discussion list, implemented using standard mailing list server software, in this case Majordomo. Every message that is sent to one of these lists is automatically added to a corresponding Web page using a package called Hypermail. The pages for a particular support area center around the e-mail messages sent to that support list and also contain pointers to other resources on the local Web server or elsewhere. A modest library of simple scripts on the server (written in PERL) automatically maintains the system, and provides keyword searching of e-mail messages.
The Hypermail program is used to automatically "markup" every message when it is sent and store it in the appropriate place on the Web server. We envisage that different e-mail lists could be used for both direct support, straightforward reporting of faults, ordering stationery and other functions for which various human contact points exist. When a user loads the Web page of the support list, they are provided with links to a keyword search facility, frequently asked questions and messages which have been sent to the support list, organized by month. Clicking on any month provides the list of messages sent during that month. Messages can be easily sorted by date, subject or author. Clicking on a line in the message list displays that message, with links to previous and next messages. If a uniform resource locator (URL) was included anywhere in the body of a message, then a link to that resource will be active. A simple search of the full text of all messages in any support area is included. An online form is provided for submission of messages for those who prefer to use a Web browser rather than an e-mail program.
Every support list has what we call a "godparent." That godparent acts as a moderator and should be a person who already has some responsibility for the area of service covered by their support list. This introduces what could be one of the most radical implications of ETINU...that those who work at and are responsible for a particular aspect of the overall service, should also be responsible for supporting that aspect of the service.
Another feature of the system is the option of open membership on the support lists. This allows interested or expert users to join the list and receive all messages which are posted (explicitly or via the online form). Therefore a user could provide support and advice to the same extent as support staff--and, on occasions, teach support staff.
Using this system means that a desktop computer running a WWW browser can provide a fairly complete interface to a help system. Such machines could be left in public areas for semi-automatic user support. Traditional Helpdesk staff could also make use of the system to enter queries that they could not deal with immediately--and from that point on, the responsibility would be delegated appropriately to a support godparent. Such staff could also be responsible for a "miscellaneous" list for messages from users who aren't sure what their problem actually is. A record of every query is made without resorting to filling in paper forms, again relieving Helpdesk staff from tedium and pressure.
In the pilot system, support list pages may point to other resources which together make up the whole support environment. These include: online documentation, which can be updated quickly, distributed widely and inexpensively, and referenced very explicitly with a link from other support material; pointers to other useful information elsewhere on the network; frequently asked questions; software archives, including local copies of recommended software tools and utilities and even site-licensed products; and online training material.
Our pilot service identified several issues for consideration in refining the system further.
We believe that committed godparents, who can of course choose to moderate every message if they so desire, are the key to success, and that they can address all the above concerns.
We believe our approach represents an effective way of offering user support. It is important that such ideas be formulated clearly so that many can benefit. Refinements to the very basic prototype could lead to proposals for new standard methods or tools. We are keen that such developments should be open to the widest consultation. We are working with two international organizations which act in a coordinating role for network-related developments: In Europe, the Trans European Research and Education Network Association, TERENA, where user support-related work is covered by the Information Services and User Support working group, ISUS. On a global scale, the Internet Engineering Task Force, IETF, and its User Services working group, USWG.
In June 1996 it was agreed in principle between the respective chairpersons of these groups to form a joint task force to develop ETINU. The new group replaces the former UNITE task force which, in the run-up to full World Wide Web deployment on the desktop, did much to engender interest and useful discussion on the concept of a User Network Interface To Everything. ETINU addresses similar issues but from the service provider standpoint, rather than end user. The aim of the task force is ultimately to establish standards for online user support using the IETF RFC procedures. A schedule of work has been compiled and a discussion list set up. Web pages are available on the main TERENA server. These include the work schedule with a list of deliverables and completion dates. There is also a section containing pointers to existing online support systems, one of which is the Queen's pilot already described. And there is a useful reference section containing pointers to discussion papers and similar resources.
The discussion on the ETINU task force e-mail list has identified four main elements of an online support system for consideration. These are:
| 1 | query processing |
| 2 | frequently asked questions--FAQs |
| 3 | software archives |
| 4 | pointers to useful network resources |
Table 3
Main elements of an online support system
Query processing is a priority. There is a need to address how users can submit questions, requests, comments, and get responses; and how a group of networked people can satisfy these quickly. The Queen's pilot and a Canadian system are being used to help identify an initial list of desirable features. In the Canadian system, all queries are submitted using a Web form. On this submission form a query type and query area are specified and a summary of a problem provided. All queries appear in a common log where each is given an ID number. A small graphic indicates when a query has been resolved--a red dot changes to a green dot. Issues being discussed include: the user being able to select a relevant support "area" for their query; ease of submitting a query and receiving confirmation that it has been logged; identifying other types of support-related messages in addition to direct questions; confirming when a query has been resolved; searching past problems and answers so that users can help themselves.
Some of the issues for frequently asked questions include: how to present them in HTML; how to link them to related information somewhere else on the Net; how different sets of FAQs can be virtually integrated or merged.
For software archives: how to present items in HTML; what meta-information should be included for searching purposes; how items can be downloaded; how to keep the archive up to date.
With pointers to other resources on the network, the task force will address how links to different information areas can be presented most usefully. This is likely to build on any recent work on indexing and meta-information and we expect to overlap with projects such as the TERENA CHIC project.
We believe everyone has something to contribute. Individuals are welcome to join the task force (see References) to participate in the discussion by sharing their experiences and ideas; help to evaluate some of the current systems; take a lead by collating discussions to compile specifications in one of the four user support areas; and even be part of a team building an ideal system in the second half of 1997.
In the above we have:
To join the TERENA list tf-etinu, send a message to mailserver@terena.nl containing only the text:
subscribe tf-etinu 'your_real_name'
replacing 'your_real_name' as appropriate.
Information
Services Group
February 1997