VLE administration and maintenance

I came into the technology enhanced learning field after completing my studies in web development. This background has allowed me to work on tasks associated with the administration and development of core college bespoke Virtual Learning Environments. In particular I have taken the lead on completing rollover procedures on these systems, before the start of their forthcoming academic years.

Without the awareness of the frameworks and technologies used, I would not have been given these responsibilities and system access, as most administration can be completed via a front end interface, reducing the opportunity for system errors occuring. Whilst the work on systems is challenging, finding a suitable date for system downtime is also a task in itself. Liaising with a number of stakeholders, who all required system access for different reasons, I was able to arrange a suitable time that would have minimal impact between academic sessions.

Using a combination of technologies, including and not limited to .ASP, SQL, PHP and HTML, I have successfully archived academic sessions and created new work spaces for forthcoming sessions, ensuring user and page content has successfully been recreated, within the parameters set by the school programme teams. The most recent rollover procedure was with the bespoke VLE for the delivery of the Undergraduate Medicine programme, at University of Edinburgh.

Coming at a time where functionality is being migrated to centrally supported services, certain areas of the system required to be setup with read-only access for past students, so as not to break access for them whilst ensuring any new students were directed the new tools being used. Other areas of the environment were signed off to be completely removed from teaching, which was a somewhat simpler task. The VLE is built using a combination of ASP and PHP frameworks, and two separate databases, so the job I undertook involved migrating data from one to the other. My evidence below shows screenshots from our team’s Wiki pages that I have edited, showing the procedures carried out (and what is no longer required due to removal of functionality). On the back of the rollover procedures changing per year, I created further wiki pages, to ensure any changes were recorded, whilst providing documentation that can be revisited at future rollover dates.

Impact

The impact of this maintenance task allows the staff community to access the VLE and begin to setup workflows for the forthcoming session; creating groups; uploading timetables, setting adaptive release mechanisms on content etc. Having the opportunity to complete these tasks before the start of an academic session allows for any changes to processes and/or content before students begin their next teaching block.

What went well

One of the key aspects of this and previous rollovers is the documenting of any anomalies outwith the usual task list. With this example and future rollovers, it is likely there will be specific tasks related to each rollover. Documenting these within the team wiki spaces allows the team to be aware of what was changed and when. This is information is invaluable when answering user queries throughout the session. Adding key contact information regarding these changes is also useful – allowing me to contact the key contact if something needs discussed or confirmed.

Future improvements

Whilst I was happy with the level of documentation provided for development and programme teams, more information could have been made available to students and other users of the VLE. Whilst a standard rollover process shouldn’t inconvenience users, during a period where different workflows and processes are changing, it would have been useful to provide students with information on what has changed as a result of the rollover. One possible solution would have been to post a short news item on the VLE which listed which tools are being are used for the different tasks within the programme. Being proactive would reduce the number of user queries trying to access certain tools and services at the beginning of the following academic year.

In previous years (and this one) I had set the at risk period to either a morning or afternoon. With the additional changes required, tasks could have taken longer. In future rollovers, I intend to set clear expectations for staff, and extend the ‘at risk’ period to the full day, allowing for any functionality removals or adjustments to be made within a more manageable time frame.

Evidence