Instructional Labs Trouble Reporting System

Instructional Labs consist of over 2000 computers at approximately 90 locations on campus.Several years ago staff developed an ingenious on-line Trouble Reporting System for students and lab managers to use when any particular computer went down. When a user or lab manager filled out an on-line form, (or when an automatic pinging system didn't get an answer from a particular station) the resultant email initiated an automated chain of events which lead a staff member to materialize in the lab very quickly to fix the problem. I got the fortuitous opportunity to model several versons of a new front end for the Instructional Labs' Trouble Reporting System which used PERL version 6 and PERLDOC CGI, was more friendly to the user, and more informative to staff - giving me the opportunity to not only contribute to the design concept of a critical system, but also learn Perl and JavaScript and some Object Oriented Programming in a collaborative environment! Woo Hoo!

The model evolved through several versions as I presented various stake holders with something to react to.

1. Prototype One was basically something to kick around to generate feedback and ideas.

3. Prototype Two considered everyone's feedback and tried to implement it in a user-friendly way, but still had too many different pages, which is what we wanted toaway from.

4. Prototype Three was the ultimate solution. Everything the user needs is on one screen. This script germinated from a number of ideas ICD programmers were batting around and sharing on more than one project. It can identify its point of origin and makes extensive use of JavaScript and Object-Oriented-Programming to dynamically update form fields. Since I got my computer programming technology degree in 1991 before OOP programming was commonly taught, I voluntarily and independently went through a computer-based-training program so that I could use OOP programming concepts.

Our negotiated design idea was not entirely without its challenges. This was relatively new ground for us and there was some quirky browser behavior with the dynamic drop down boxes that needed to be addressed. Also, my supervisor had advocated for just one form for any type of problem whether it was an access-from-home problem or a campus lab problem or file retrieval problem or whatever. His point was that we shouldn't expect inexperienced users to choose and differentiate between multiple technical scenarios but simply let them articulate their problem in their own words. While this is almost always a good idea for various reasons, using the same form (or at least the same page) for users on different bandwidths presented us with a problem. In the case of the campus labs, we still needed users to identify which station "was broken". And while the script could determine its point of origin, the strong likelihood remained that the point of origin wasn't the station or even the lab with the problem. Unfortunately giving the user an assist with the task of identifying the problem machine by providing them with lab names and their corresponding hostnames from a dynamic drop-down box duo required preloading or somehow building all the labs and all the hostnames (2000 of them, remember?), preferably from some sort of a real-time database of all the labs and machines. But including all the labs and hostnames would make the page rather large and slow, especially for people off campus and on slow bandwidth. The Javascript Object Model is not a terse language by any means- and I was just learning how to use it and hadn't yet figured out how to shorthand it (or identified an alternative coding option).

Here is the live implementation of what we worked on, also listed on the instructional lab's top website (see Report a Problem link). While keeping the same look and feel across each page, the implementation uses different forms on separate pages for different types of problems (so the user does have to choose). This allows information to be tailored more specifically to the support area who will be dealing with the problem (also a good thing). However the system does include an option for someone who isn't sure which choice to make, a nice touch, in my opinion. And the form for on campus labs does contain all the instructional labs and hostnames. However requests for this particular form would usually originate from campus which has fast bandwidth. In short, the on campus page could get away with being larger than recommended, because most of the requests for it would be traveling the fast campus bandwidth. And even if a user did decide to report a lab problem from home, DSL is much more common these days than it was in 2001.

However, if we had stuck with the one-form-for-everything concept, I think that rather than including all the labs and hostnames, we could just initially preload the labs. Once a user chooses a lab, then the script should hit the server, and populate the drop-down with all the hostnames for that lab. I know this isn't ideal, but except for the brief refresh, the user perceives that he is still in the same place. In the practical world, I feel the refresh is a small price to pay, or is a good compromise between our ideal and the constraints of the real. However, in the end, I also think having separate forms on separate pages for separate problems may wind up being "less is more." Perhaps trying to make one form or one page do too much can be just as confusing for the user (and technical support staff) as having multiple forms for multiple problems. It becomes a balancing act. We must also remember that one advantage of technology is that it can be used to scaffold users of varying levels of technical expertise. In short we can use technology to provide users with some helpful tools to aid them in expressing their problem.

An interesting follow-up or evaluation study of this application would be to track how users do indeed choose and use these forms - do they use them as expected? Which ones are most frequently used - and why? This would inform any future development or tweaking of this application.

At any rate, and as I've already said, it was a thrill and great learning experience to be able to participate and help shape this project! :D

Instructional Labs Tracking Form

I was asked also to code a very simple On-line variable length form for tracking the rollover to Windows 2000 in the Instructional Labs.People can enter tasks and notes on their progress. It's crude but it works! Well, sorta.

Instructional Labs Trouble Report Search Engine

I located and evaluated several search engine scripts and ultimately installed and collaborated with Sergej Tarasov over distance to customize the RiSearch PERL CGI script for searching thousands of trouble reports in Purdue's Instructional Lab Archives by accessing them via a symbolic link (not implemented in this demo version). Just enter a search phrase such as "disk drive" and the script will search the archives and display all trouble reports related to the search phrase.