It is relatively easy to translate the current UMich gateway tests
into eGrade testbanks, given the latex2webtest utility
provided with eGrade. eGrade also supports the functionality needed
for the test questions in the current gateway (that is, function and
numeric answers as well as multiple choice). The only exception to
this that I've noted is in the integral gateway, where it is
impossible to require the addition of a "+C" to students' solutions to
indefinite integrals. eGrade does support a "formula mod C" problem
mode, but while this allows students to enter answers that differ by
arbitrary constants it provides them with the "+C" in the solution as
well. eGrade does include an answer previewer that allows students to
check that what they have typed in displays as they would expect it.
Each gateway test (assignment) exists in the context of a class. There are two ways in which this could be implemented: a single class could be defined including all students in, say, math 116, and the gateway tests (assignments) for the class defined for that, or a class could be defined for each section of the class and the gateway tests copied into each, presumably by some script that edits the eGrade system files.
The obvious and potentially crippling disadvantage of the first implementation is that there is no easy way for individual instructors to extract the results for only those students in their class(es). To do this it would be necessary to either analyze the student files for the class, selecting those with the correct names or student ID numbers for a given section, or to export the data and do the analysis on that file. Both of these are possible. If the objective is to be able to return (1) which students have taken the gateway, and which have passed (or not), and (2) which students have taken the gateway as a practice test at least once, the data analysis would not be terribly difficult. If more precise data (see the data analysis section of the eGrade use page) is required, this becomes slightly more bothersome.
There are two disadvantages of the second implementation. First, that there will then be a potentially large number of classes to select from whenever there is a drop down class menu (though this may be mitigated by use of shortcuts---especially if augmented with a javascript function to generate the correct shortcut URL). And second, that it becomes difficult to generate aggregate statistics for all sections of the class. This would require the creation of a script to read through the data for all students in all class-sections to compile the statistics desired. This would be a "slightly more bothersome" caliber of problem.
It is, of course, not clear that these problems are necessarily specific to eGrade.
eGrade requires a proctor login at the end of any proctored test event before the grade will be registered. It can, optionally, require a proctor login to start the exam at all. I surmise that the preauthorization proctor login is to discourage students from starting a proctored session from somewhere other than the math lab before realizing or being reminded that they probably won't be able to guess the proctors username and password. To deal with a potential flood of students coming in to take the test at the same time, the preauthorization should be omitted. It is not clear if this would be problematic from the point of view of incorrectly started tests (but see below for an alternate model that might address this).
An alternate model would be to have a separate, hidden, class (or classes) for the proctored test---it would then not appear on (nor clutter) the drop-down list of classes. It would, however, be accessible by using a shortcut (either to get class data or to actually take the test). There is one difficulty with this, namely, that of providing an easy way for students coming into the testing center to find the shortcut. If the lab in which the gateways were being administered was dedicated to that purpose, the home page of the browser could be set to point at a page with links to all of the available proctored exams, so that students coming in to the lab would only have to click 'home', select the test, and then log in and take the test.
eGrade is a sophisticated package. In general its interfaces are intuitive and easy to navigate, but there are cases where this is less true---for example, the location of the 'next problem' button in the exams at the top of each page (rather than below or to the side of the problem), at least when problems are displayed one to a page. The biggest (and perhaps most significant) complaints I have with its interface and system lie in the many levels of prompts that have to be clicked through to do things through the GUI, and the issues indicated above.
Potential additional uses for the gateway testing software include, among other things, (1) on-line placement testing or calculus readiness testing, (2) calculus or precalculus tutorials providing self-paced or supporting materials for students with weakness in either of these subjects, and (3) integrated readiness tests and tutorials, which would route students from a test to tutorials on missed material.
Subject to restrictions imposed by the on-line medium and requirements for proctoring and so forth, eGrade could be adapted relatively easily to accomplish (1). Depending on the nature of additional materials desired for (2) or (3), it is less suitable for those. In particular, it seems on the face of things that the only way to make a transition from an eGrade administered test or quiz to supporting materials is to have a link to that page appear as part of the results that are given to the student. This could be done in two ways: a link could be placed in the 'comment' field for a question, or on the results page itself. In that comments are shown in lieu of the solution when a problem is missed, they could provide links to additional information on a specific topic. However, it is not clear that the additional material could be provided on the basis of the passage or failing of a given test---any message appearing on the results page appears whether or no the student has passed.
In short, eGrade is good for testing. Its tutorial feature may allow its use for more formative assessment, but more sophisticated interplay between this and specific quizzes would require some thought or manipulation.
It would be relatively easy to have the technical side of using eGrade for all of the gateway exams up and running on very short notice. It would do a very solid job of running the gateway exams, and has the possibility of being extensible to support additional uses of the system as indicated above. Additionally, as it has already been used by the University of Nebraska for their gateway testing system, there is some empirical evidence that the system can support the volume of students that will need to be processed by whatever gateway test we implement at Michigan.