Future Work

As Agar approaches stability and a feature-set robust enough to stop the flow of requests, the places where it falls short are becoming more and more apparent. Some of the problems that are surfacing are subtle effects of the choice of wxPython as the GUI platform for the tool. Most notably, Agar fails to perform in one of our design guidelines: since this represents an entirely new kind of tool there is almost certainly going to be a large discrepancy between the user-model and program-model of behavior. To minimize this effect, the behavior of the system must be as transparent as possible. Unfortunately, within the wxPython widget paradigm, there is little that can be done to mitigate this elegantly. A fundamentally different interface design is necessary. If the interface is to be thrown out, it represents an opportunity for change in terms of separation of interface from functionality, increased testability, and better software engineering practices. Within the next 6 months we hope to begin work on Agar2, which will be a significant departure from the existing paradigm in terms of interface and usage metaphor, and will take advantage of all of the lessons that have been learned in the development and deployment of Agar over the past year. The core ideas in Agar2 will include

• A more concrete program metaphor. Agar meets Bruce ``Tog'' Tognazzini's definition of a Graphical interface rather well [21]. Much better would be meeting Tog's guidelines for a ``Visual'' interface: an interface where the application has a clear metaphor which is clearly and consistently communicated with the user through multiple channels (text, graphics, etc).

• A more robust system for combining tools into rubric tests, even at the expense of the simple tool interface. Users do not want to engage in tool development as a first step in grading. When faced with that, they will (historically) choose to grade manually even if the net time spent on the task is possibly greater.

• A more transparent testing phase. Currently Agar gives no more information than displaying the username of the submission being tested. Showing the exact flow of information and series of tests that are triggered during an execution would decrease the time required to debug a rubric.

• Tool ``mix-ins'': So many tools have demonstrated a need for similar functionality (such as a timeout mechanism) that it seems prudent to allow for functionality mix-ins to reduce code replication.

• A proper separation of GUI and functional elements. One of the properties that was lost in the organic development of Agar is the separation of functionality from interface elements. Without this separation, regression testing is almost impossible. With it, the interface becomes just another modular component, allowing for greater flexibility in interface.

As a proposed system model, a flow chart with labeled and color-coded inputs and outputs would grant both greater flexibility and more intuitive interface. A grossly simplified mock-up of what a rubric could look like with such a system is shown in Figure 7.1.

Figure 7.1: Agar2 Rubric Mock-up