E-mail Based UI

While the main interface for MMS is via web pages, it also uses e-mail for many forms of interaction with the users:

• Confirmation that an action (such as submitting coursework) has been completed successfully.

• Notification of events such as coursework deadlines, particularly in cases where ded- lines have been missed.

• Reminders of tasks to be completed, such as marking of coursework.

• Alerting users and support to potential problems, for example data inconsistencies.

Independent Verification

Early implementations of the coursework tool suffered from a lack of confidence and sup- port overhead caused by frequent student claims that they had uploaded work to the system, and it had since been “lost”. Despite a lack of verified cases where this happening, this re- mained a persistent rumour amongst users. Staff time spent investigating such claims was also a noticeable part of support workload.

E-mail receipts were introduced to fulfil three functions:

• Provide proof to staff of work being uploaded.

• Provide diagnostic information for system administrators in cases where problems were reported.

Email receipts proved extremely effective in reducing the number of claims of lost files, which can be attributed both to reduction in user uncertainty with regards to whether a file was successfully received, and less mis-attributed blame for late submission of course- work. In a very small number of cases students have attempted to present fake receipts for coursework, however these can be readily verified by checking the signature on the email. There has been only one recorded case of a receipt being issued for a file that was not stored within MMS, since the introduction of e-mail receipts in late 2002. In this instance the student uploaded two copies of the same file in quick succession (likely a double-click of the “Upload” button). MMS correctly detected that two files were being submitted for the same coursework assignment, and accepted one copy, however in deleting the duplicate copy it also deleted the original file as well. As MMS had accepted one file before this point, it had issued a receipt for the file, which was no longer present on disk.

Notification of Events

In a scenario where staff must “poll” MMS for changes and work to be completed, there is an inevitable inefficiency in terms of time spent searching for such changes and tasks, due to time spent checking unnecessarily. Using e-mail to notify staff of events, such as students uploading work, can minimise time expended checking for such activity. This is particularly important in cases where work arises to be done, outside the normal timeline, for example a student submitting work after the deadline.

In one extreme example a student was given an exception to a coursework deadline, and submitted after the end of teaching. The school noted that it required staff to actively check for this work, which is both time consuming and error-prone.

Other requests have included for automatic monitoring of student performance (attendance, average grade, timeliness) and notifying staff where these metrics are outside of a defined set of criteria. Early prototypes were developed, however they suffered from accuracy issues due to underlying data quality, and were eventually abandoned. The later expansion

in use of data in MMS has led to improved data quality, and this feature could be re- evaluated as part of future work.

Alerting Users to Problems

Timely notification of users and support staff in case of problems is key to reducing the impact of those problems. Consider a scenario where a contradiction arises in the stu- dent enrolment lists for a module, and a student is left off a module as a result. If this problem can be resolved within hours of it arising, the student may never be aware of the issue at all. As time goes on, however, the student is likely to raise a help-desk query (with consequences in terms of support time). If the problem is allowed to persist, it can have consequences in terms of access to course materials, group signup, etc. which are significantly harder to undo.

Input via E-mail

There are scenarios in which user input via e-mail may be a natural interface in comparison to a web application. This is particularly true where material is already in e-mail form, for example conversations between users, to which MMS could then be CCed in order for it to be able to track the discussion. Students have also suggested that it would be convenient to be able to email coursework to MMS, for example so that in case of network connectivity issues, retries are automatically handled by the mail infrastructure rather than requiring manual intervention.

Input over an asynchronous communication system introduces substantial complexity how- ever, such as how to handle lost e-mails, risk of e-mails being delayed (especially where time sensitive, such as coursework submission), security implications (given that encrypted e-mail is by no means ubiquitous), etc., and remains an item for future work.