MMS contains a wide variety of high quality data of potential relevance to a number of external applications. Exposing this data via database links or web services reduces dupli- cated effort, increases reward for maintaining MMS records, and can improve functionality of external systems.
6.2.1
SITS:Vision
Once final grades are calculated within MMS, they need to be returned to central records. The initial interfaces for performing this task have used CSV (comma separated value) files or using SQL to insert records directly into the SITS:Vision database. The former required significant manual handling, the latter bypassed triggers and validity checks within the SITS:Vision application.
The recent addition of StuTalk web services to SITS:Vision means MMS can now write to the system is a better supported form, and work to integrate with this interface is ongoing.
6.2.2
Mobile App Support
Mobile applications for higher education to date tend to focus either on delivery of fairly general information, or on mobile learning (frequently referred to as m-learning). oMbiel’s campusM product and Straxis’ u360 mobile products are examples of the former, both providing information such as staff directories, campus maps, etc. For examples of m- learning, see Herrington and Herrington[46] and O’Malley[19].
These are unusual areas to focus on, given that mobile devices tend to be relatively limited in terms of display size, input options, processing capability, etc. It would seem that there is more of a need to focus on functionality which mobile devices are uniquely placed to support, namely delivery of time sensitive information, such as coursework marks and announcements
MMS contains a significant amount of such data. It also has tools for which there is demand from students to access them as early as possible, such as the tutorial signup tool. There is significant demand for places on tutorials at convenient times, and as places are assigned on a first-come first-served basis, students already frequently access the tool from browsers on mobile devices. If m-learning was considered a desirable goal, it would also be possible to provide access to course content.
Such data and tools suggest opportunities for mobile applications to provide improved in- terfaces (compared with a web-only interface on a mobile device). A partial mobile appli- cation prototype has been developed for some of this functionality, however unfortunately it has not been completed due to time constraints. However, others have managed to make further progress towards this goal.
MSc Student Projects
Some prototype work was done on the St Andrews mobile application to adapt it to retrieve data from MMS via web services, however development time constraints meant it was not
taken beyond the prototype stage. These web services remained as part of MMS, and were later used for two MSc projects.
Two MSc students independently developed mobile applications which integrate with MMS as part of their dissertations. Sulaiman worked on an application for the iOS platform [125], with Luktuke working on Android[73]. Both students consumed data contained in MMS in some manner, although Sulaiman’s work was more generalised in its intended use cases. Their designs are naturally their own work, and can be considered to reflect a student’s own view of what functionality mobile application integration for MMS should provide. The students were supervised by Colin Allison, with assistance from myself.
Both provided fairly similar functionality in terms of integration with MMS, providing a list of taught modules a student was taking, and allowing them to retrieve their own current grades. For the Android version the original design called for providing push no- tifications (based on a publish/subscribe model[24]), although regrettably technical issues compounded by the replacement of the C2DM middleware2by GCM3meant could not be completed in the time available.
These designs can be considered a good starting point to any later analysis of use cases for mobile applications integrating with MMS. See also 12.5.4 in the future work chapter. In terms of integration with MMS, where the applications required to retrieve data (as opposed to having it pushed to the applications from MMS) this was relatively straightfor- ward. In particular as the web application interfaces implement authentication and autho- risation based on the end-user’s credentials, rather than the API not having any inherent restrictions (as is the case for WebCT’s web service interface), there was no risk to system security from allowing students to work with these interfaces.
6.2.3
Google Search Appliance
Given students are expected to use a number of different systems (MMS, Moodle, poten- tially school-specific systems) for module-related tools and material, inevitably there will be some confusion over which system to use in different contexts. MMS exposes its search
2https://developers.google.com/android/c2dm/- accessed 3rd June 2013
interface via the OneBox4 interface, enabling a Google Search Appliance to pass queries
to MMS for it to address.
Currently this is limited to matching modules by module code for simplicity. A matching integration has also been added to Moodle, meaning that one search identifies matches in both of these systems, as well as any other matches within publicly accessible institutional web pages. With additional resources it would be possible to expose course content such as lecture notes to the search appliance, enabling students to search the content by keywords and similar.
6.2.4
EvaSys (Module Evaluation)
MMS now contains the most consistently accurate data staff involved with teaching of modules, as well as students enrolments. As a result, its data is ideal for use in producing surveys for evaluation of teaching of modules and ensuring those surveys reach the correct audience. These surveys are generated by the EvaSys5software. This data is exposed as an archived set of XML documents which can be retrieved on demand from a web service.
6.2.5
Moodle
Moodle requires data on staff and students associated with each module, and with this data occurring in MMS as well as central records obviously it makes sense to reuse existing data sources. Taking student data from SITS or the data warehouse would mean Moo- dle reflected the students taking a module – a logically obvious solution, but failing cases where students were allowed to “audit” on modules they weren’t officially taking, or similar unusual cases not reflected in official records. MMS already stores detail on student enrol- ments on modules sufficient to differentiate these auditing students from others, making it logical to re-use that data.
MMS also pushes details of running modules into Moodle as part of the module activation process, this is discussed in detail in the chapter 7.
4https://developers.google.com/search-appliance/documentation/614/
oneboxguide- accessed 29th July 2013