Reading University Observatory: A web-based resource for 21st century teaching and learning

Dr Andrew Gabey,

School of Mathematical, Physical and Computation Sciences

a.m.gabey@reading.ac.uk

Year of activity: 2016/17

Overview

The University’s Atmospheric Observatory continuously collects high-quality environmental data, which is used heavily in teaching courses – particularly in Meteorology.  A new web-based system, due to go into service for the Autumn semester, has been developed under this project so that the data is (i) more easily accessed by students, and (ii) pulled automatically into other software applications, such as interactive websites, for either teaching or outreach. Alongside these impacts, the system represents a more manageable way to disseminate data, and is a helpful case study for developing digital offerings using Cloud technologies supported by University IT Services.

Objectives

We aimed to build a modern environmental data service based on data from the University Atmospheric Observatory that:

• Provides an improved user experience for students in the various classes using this data.
• Can be accessed by anybody with permission, on or off-campus.
• Supports development of data-driven applications, including interactive websites, that help explain the environment and climate.

Context

Meteorology departments generally teach with data from their own atmospheric observatories, often using clunky methods. Our school website provides an on-campus-only service for students to access data needed for Meteorology, Sustainability, Biology and Geography classes, but the software for this has grown organically and has reached a point where the user experience is somewhat overwhelming. This technologies used are also unsuitable for modern applications such as interactive data-driven websites that could showcase the university’s facilities.

Implementation

Stakeholder input and co-ordination: Meetings were held with the departmental data manager, laboratory technicians, other research staff interested in sharing data efficiently, and the HoD responsible for funding the on-going computing cost for operating the service. As they were engaged during the proposal writing, these discussions were broadly positive and yielded useful considerations such as the need for legal wording on the website.

Design and implementation of software: The proposal document was used to inform technical requirements passed to the programmers. These focussed on the different journeys taken by service users and administrators, and feedback between the programmers and I helped smooth interpretation.

Standing up the service: University IT Services were happy to explore ways of helping people to deliver services using cloud-based approaches, and even covered the first few months of running costs while we determined how things should work in terms of finance and support.

Documentation and support: The completed code is stored on the GitHub website, along with installation and administration instructions for system maintenance and, hopefully, the addition of more data holdings and users as time goes on.

Impact

Expected outcomes

To ensure successful outcomes, we established technical requirements based on the planned benefits to teaching and learning: Improved user experience through a better user interface; accessibility from anywhere; allowing the data manager to tailor data for classes/individuals, and employing more modern web technologies.

Based on these technical criteria, these have all been solidly realised, and the system is being stood up to be used by Meteorology students as the new academic year begins (subject to ITS support). Initial user feedback has been positive, with test users able to extract data without needing much help. When help was required it was mostly caused by bugs, which have been resolved (see follow-up for more feedback).

Unexpected outcomes

IT Services: We employed Microsoft Cloud technologies to power the service, and this in turn has allowed IT Services to determine how they can support groups within the university keen to innovate in this way.

Technological development within the department: This software has formed the basis of a similar tool to share research data elsewhere in the department, and can in theory be applied to many such datasets.

Reflections

As this was fundamentally a software project, it was essential to have well-developed requirements and criteria for success. These were worked through in detail at the start, and left enough room at the end that small extra tasks could be completed to refine the finished product.

The hardest part was spending the money: Although the University Careers centre were very helpful we were unable to secure any suitable interns, having advertised it as a summer project. An email to the departmental PhD students yielded a pair with the perfect background, and the work was completed within the increasingly tight deadline, and to budget, paid via ad-hoc work forms. Appealing to PhD students first rather than holding out for a summer intern would have been the wiser course.

A more impactful result would have been achieved if we had built some demonstrations of how the new system could be applied. For example, web-based data visualisation would show how accessible the data is; and negotiating with the University to make some of the archive available to the public would have been helpful for outreach. Public datasets are supported in the software, so a decision to make data available is easy to implement.

Follow up

Initial feedback was positive from teaching support staff, and constructive criticism was taken on board. For example, a test user was able to choose invalid dates like 31 April, which resulted in errors. Concerns were also raised about it being hard to go back and change options when a mistake was made. Refinements were made (reflected in images below) to address these.

Links

Atmospheric Observatory