Coda

I must apologize to my keen readers who I have no doubt have been wondering what had transpired since my last correspondence. It might come as a great disappointment to some of you that the rumour of me spending four weeks writing a social apocalyptical novel where humanity is forced by an exploding star to relocate is a complete fabrication. On the contrary, my untimely hiatus has been the consequence of a separation and formation of attachment of an affectionate nature, which is to me a source of both melancholy and contentment.

The sharp-witted ones among you would certainly recall the swap of roles between Geofrey and I about one month ago. To be sure, letting go of Web-CAT is heart-breaking, given the weeks I spent with it. On the other hand, working with Java/SWT in Eclipse and doodling UI designs is a welcome change.

I’ve spent the last month building on top of Geofrey’s unfinished prototype, and the progress has been absolutely gratifying, with a small but key exception. The WebAPI component of Web-CAT server which is the prerequisite for the plugin to converse with the server, has yet to be updated in 4 weeks. The current implementation of the API, allowing logging in and loading of assignment info, is incomplete. With most of the GUI already in place, little work has being done on the API and some of the related backend model. We had hoped that Stephen would be able to complete more of the WebAPI component for our using, however clearly he was not expecting to work so closely by our schedule. In our initial correspondence regarding the plugin project he did mention that presently they do not have the manpower or time to implement such a component.

The plugin is far from fully functional in its current form, so it’s my best interest that some enterprising individual (from Virginia Tech probably, as we just decided not to use Web-CAT at UofT) would be willing to finish it. In two weeks the project will come to a coda, my intention is to clean up the existing code and prepare documentation so that the person who inherits it would be able to set it up with the effortlessness that is much in wanting of with Web-CAT itself.

Group Think

Now that the warm-up is finally over, it’s time to roll up my sleeve and start tearing Web-CAT apart down to its database core. Next on the agenda is to integrate partner and group associations into assignment submissions. The plan is to add the ability for users to setup groups and use it to collectively organize individual student submissions.

Currently, partner associations in Web-CAT is – excuse my language – practically unusable. For one thing, partners are done on a per-submission basis and only has a one-way relationship, which means that student A’s submission might be partnered up with student B, but student B’s submissions aren’t. This can both be tedious and can create duplicates, where it’s possible to have two groups with the same members. Also, the fact that the grader is responsible for specifying partners manually (without any automation tools) would certainly make a grown man (or woman) cry if done on a course with 300 students on a span of typically four assignments.

Overhauling the entire workflow on group submissions is a daunting task, which is what I’ve been doing for the past week. Since Karen is away, I’ve been working closely with Jennifer Campbell and Paul Gries to solicit very useful feedback on what they think would be useful for courses that involve group assignments. With the design we have so far, students take charge of creating their groups instead of the instructors, based on an invite model similar to Facebook. However, groups would be decentralized, meaning that an actual Group entity doesn’t exist, and is only formed according to students requesting and accepting invites. Implementing it this way allows us to impose restrictions such as no student can create and be in more than one group.

One of the major difficulties right now is handling group merging and taking into account all the different cases of how invites and joins should be handled. Putting control of group assignments in student’s hands involves some serious restrictions on what they’re allowed and not allowed to do. Privacy and sharing issues also presents problems that we’re looking into as well. The good news is that we should be able to reuse some of the underlying database for submissions to merge user submissions into group submissions. However this would still take a lot of non-trivial work to fully implement, while considering how our changes would affect existing Web-CAT installations. There’s a lot more to figure out along the way but with what we have so far, I think Web-CAT has a promising and bright future to look forward to.