.

Progress Blog

Course Data Show and Tell event

User AvatarPosted by XCRI Project Manager at 04/02/2013 15:20:23
Aston Course Data Project Jisc
Last week we attended Jisc’s Course Data Show and Tell event (we didn’t have far to go – it was hosted at Aston). The day brought together all of the Course Data Stage 2 projects (over 60 in total) to share experiences and findings.

As well as the usual presentation and panel sessions, each project was asked to design an A1 poster summarising their project. I chose to do ours in a hand-drawn, comic strip format in the hope that it might invite people to explore a fairly dry subject. I had some help from the professionals at BlamBot, whose excellent Letter-O-Matic and Palooka fonts did the heavy lettering work, and Jim Campbell, whose brilliant comic book lettering blog taught me some of the finer points of layout and effects.

There was a fantastic range of posters detailing the work of the projects and we we’re really surprised and pleased that our poster was awarded second place. A big thank you to everyone who voted for us and to the other winners.

You can download an A3 version of the poster (700K, that will also print at A4) or view the poster online.


Iteration one: valid XCRI

Posted by XCRI Project Manager at 14/01/2013 15:46:50
The first iteration proper refined the proof-of-concept to incorporate the storage of the HE-BCI survey data and create a valid feed. The full set of requirements was as follows:
  • Create a feed that validates (M)
  • Create the data structure to store taught hours for each non-credit bearing course (M)
  • Create an interface to access and edit the taught hours (M)
  • Create a structure to store income for each non-credit bearing course (S)
  • Create an interface to access and edit the taught hours (S)
A significant amount of work was done to ensure that the feed validates in its current state. Data was imported from Sits into the IPP module and then transformed using the Standard Letter technology to create XML. Bringing the data into IPP allowed us to confirm our initial audit of the data and better identify the gaps.

As expected, data for the following items wasn't present and will be addressed in future iterations:
  • Abstract
  • Mode of attendance
  • Mode of study
  • Location
  • URL
Where data was present there were some unexpected quality issues that will also need addressing
  • Multiple locations corresponding to Aston University that will need to be reconciled.
  • Course titles containing award, mode of study and occurence data
Investigation into the Sits database revealed a pre-built section of the system designed for storing information related to non-credit bearing courses. We have re-used these fields to integrate both the taught hours and income data entry and retrieval into the system.
Time has been scheduled to verify the HE-BCI functionality with the staff previously and currently responsible for the return.

The following requirements weren’t completed in this iteration
  • Store and display the date of the last amendment (C)
  • Automatically identify non-credit bearing courses (S)
Now that we have the basic system working we are switching focus to concentrate on improving the data. The requirements for the second iteration are as follows
  • Populate the course abstracts with live data for a single school (M)
  • Generate a unique URL for each course (M)
  • A means of producing HTML from the course data (S)
  • Automate the hosting of XCRI feed file (C)
In the first instance, the abstract text will be inserted for courses taught in Life and Health Sciences. Piloting the process with a subset of the data will allow for streamlining in future iterations as lessons learned are applied.

Prototype feedback

Posted by XCRI Project Manager at 02/11/2012 14:23:49
The proof-of-concept iteration was shown to the University’s Executive and Professional Development forum in September. This is a group tasked with policy and marketing for the University’s non-traditional courses and includes academic and support staff from across the organisation.

The system was demonstrated live using test data and met the following requirements:
  • Means of entering course data (M)
  • Means of viewing course data (M)
  • Means of amending course data (M)
  • An Xcri-Cap feed automatically created from course data (M)
  • The Xcri-Cap feed published to a publically accessible location (M)
  • The system must be supported and maintained within the current University ICT infrastructure (M)
We were able to show the entry and retrieval of course data and the subsequent Xcri-Cap output (although the feed wasn’t valid). The concept and system were well received by the group who were keen to see executive and professional development courses more widely marketed.

(The following requirements weren’t completed in this iteration. They will be included in later developments as per Atern’s ‘flex features’ philosophy:
  • Means of producing HTML from course data
  • Means of validating course data
  • Individual users are able to enter and access their own data)
As a result of seeing the prototype, several new functions were suggested:
  • Storing the contact details for the person administering the course to facilitate better internal communication
  • Storing income and hours for non-credit bearing courses for the HE-BCI survey
Neither would be published as Xcri data, but would be kept with the relevant course information. The extra data entry would create additional requirements:
  • Automatically identify non-credit bearing courses
  • A means of reporting the HE-BCI data using standard University reporting software
Prototype validation
In the previous post I talked about the purpose of the prototype – to validate the choice of Sits as the technology platform. Developing in Sits has initially proved difficult. It is hard to learn and uses obscure and outdated programming concepts. Despite these shortcomings we have decided to continue with Sits as the technology platform. The difficulties must be offset against the benefits of building within a key University system:
  • The administrative staff who will be maintaining the course information are already trained in its use
  • The course database will slot easily into the maintenance framework of the dedicated Sits IT Support team once the project is completed.
The requirements for the next iteration are as follows:
  • Create a feed that validates (M)
  • Store taught hours for each non-credit bearing course (M)
  • Store income for each non-credit bearing course (M)
  • Automatically identify non-credit bearing courses (S)
  • Store and display date of last amendment (C)
This will create enough of the HE-BCI functionality to allow us to check the implementation with the end users.

Finishing foundations – Xcri-Cap prototype

Posted by XCRI Project Manager at 14/09/2012 15:05:07
The Foundations stage of the project is complete and we’re now entering the development phase. This is an agile project so development is split into a number of stages or iterations. The project is planned so that each iteration delivers a specific set of working functionality. This first iteration is a special case because its goal is to create a proof-of-concept of the whole system to verify that Sits is the right technology platform.

Prototyping is a key part of Atern because it allows you to ‘succeed sooner’.
  • Specific design assumptions/hypotheses and the project’s overall direction can be verified with tangible examples.
  • Staff can use these prototypes to give detailed and valid feedback throughout the project.
  • The process is engaging and collaborative; business users are involved in the development and evolution of the product rather than simply having to use it at the end.
The high-level functional specifications for the prototype system are:
  • Means of entering course data (M)
  • Means of viewing course data (M)
  • Means of amending course data (M)
  • Means of producing HTML from course data (W)
  • Means of validating course data(C)
The high-level non-functional requirements are:
  • An Xcri-Cap feed automatically created from course data (M)
  • The Xcri-Cap feed automatically published to a publicaly accessible location (S)
  • The system to be supported and maintained within the current University ICT infrastructure (M)
  • Individual users are able to enter and access their own data (W)
The letters next to each requirement are a shorthand for priorities determined through Atern’s MoSCoW process (Must, Should, Could and Won’t this time).

Although we’ve chosen to use Sits, we’ve decided against the outline Tribal solution demonstrated at Brunel University’s Sits Assembly in May. Tribal’s module was based upon course approval using programme specifications. Interviews with Marketing staff across the University during Foundations revealed that programme specifications were considered a contractual document and don’t contain the marketing information that Xcri-Cap requires. Using programme specifications would have required a two tier system with additional fields for marketing data maintained separately by marketing (rather than administrative or academic) staff. However, we recognise that the two share data in common and will investigate the possibility of a process for synchronising information between them.
For the proof-of concept we’ll create data entry and management screens using Sits e:Vision Vistas; Sits Standard Report Letters will wrap the course data with Xcri-Cap tags; and a stored procedure will be used to publish the feed publicly.

We’ve arranged for the prototype to be demonstrated at a forthcoming meeting of the Universitys Executive and Professional Development Forum. Staff involved in the administration and marketing of short courses and professional development will be able to see the prototype in use and provide feedback on the design direction. I’ll discuss the feedback and how development’s progressing in the next post.

Employable Graduates; Exploitable Research