Description:
CoC/CNS uses a home-grown software package for managing user requests called "hm". The package was originally written for a senior design project using ksh scripts and was flung in place in desperation over the volume of unanswered mail that CNS was receiving. Over the past six years, hm has been re-implemented several times. In its current incarnation, it is implemented mostly in Perl using a database of text files with a simple text-based GUI for CNS-users and a ksh script that manages email from end-users. Hm is currently essential for the functioning of CNS and although it has shortcomings, it solves far more problems than it causes.The interface for CNS users is a display screen that lists requests (along with their assigned numbers, date, and a few other details) and a menu of options (such as Close, Assign, Reply). All of the commands are entered as a single letter possibly followed by a request number. The UI prompts for all other information, such as number of hours spent on a request. This UI functions on any text-based device or window, so it can be accessed from any system that can telnet to a Unix host. In addition, the database is on a network-mounted file system, so that the hm UI can run on any SunOS, Solaris, or IRIX host in the College. Shortcomings are numerous, since the UI was designed with ease of implementation in mind. Even so, since we are dealing with skilled computer support people, we have very few issues with learning to use the UI. Our concerns here is to allow quick and efficient use by experienced users.
The user interface for the end users is simply an email message directed to "help@cc.gatech.edu". On receipt of a end user's message, a response is sent acknowledging the request, the request is put in the database, and is then emailed to all CNS users(!). This scheme provides good cross-platform availability as well as internet-wide access, but does not address a number of issues. For instance, there is no opportunity to remind users to tell us the specific location where they're having a problem (e.g. we have 100 NT systems -- it helps to know which one has a full disk) and to query them for a subjective priority (e.g. whether it's "My girlfriend won't get email from me tonight" to "I won't get my dissertation to the graduate office on time"). In adddition, there is no opportunity for hm to recognize very common requests (e.g. "I'm out of bananas" or "The printer is out of toner") so that the request could be routed only to a specific group of CNS staffers who handle that particular type of request.
Other random points:
Cross-platform use is essential for the CNS UI. Current desktops are IRIX, Solaris, SunOS, MacOS, and Win/NT. This probably implies a text, X, or browser implementation. We'd currently favor an X implementation because of the performance and security implications of a web browser. Tk and TkPerl should probably be considered.The latest reimplementation of the CNS UI was done with the idea of separating the database code from the UI so that the UI could be augmented or replaced without rewriting the database.
The end-user mail gateway must continue to be supported, but it need not be the only method of access. Two thoughts we've had were to send back an automated questionnaire (perhaps with questions selected based on the presence of certain keywords in the original message) that could be "replied" to or to provide a browser interface that then generated a stylized email message to help@cc. Our end-users span nearly every dimension from clueless to awesome, from bored to fantastically busy, and from patient to not even understanding the meaning of the word. For some, a one-sentence mail messages saying "My printer is broken" is a huge effort/inconvenience; others would happily crank up a special UI and answer 25 detailed questions.