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.
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
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.
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.
In case you arrived here through the back door ...