Introducing Audrey

Reflective tiles on external wall of Elliot College extension

Last week Angela Watson and I gave a presentation to the Academic Division on the Kent XCRI project. We explained the overall aims of the national XCRI-CAP initiative and how that would bring benefits for propsective students and others but most of our presentation concentrated on introducing the fortyor so people present to the prototype Programmes Plant – the course administration system we are developing. The Programmes Plant – affectionately known as Audrey for reasons which I will leave you to work out – aggregates the data we need for the XCRI feed but it also does much more. It is a multi-user PHP application which next year we will roll out to administration staff in schools and departments – many of those in our audience will be directly affected by the work we are doing. Faculty staff will enter information on programmes, learning outcomes, entry requirements etc directly into the application. After moderation by the Publishing Office to make sure entries conform to our Style guide and other rules, the data can be published direct to the course pages on the web. We are confident that the benefits of the Programme Plant will rapidly become apparent to all users – though of course we can’t deny there will be some disruption whilst we retire old systems and get users up to speed.

Although not a stranger to speaking to groups small and large this particular presentation was making me nervous – I know Angela was having similar thoughts. We decided on a live demonstration of the prototype despite the misgivings of some of our developers. They didn’t want to be left with egg on their faces if the prototype threw up an error. Angela and I perhaps had more confidence in them than they had in themselves. Or maybe we were just foolhardy? Anyway, as we had expected Audrey behaved impeccably. I think a successful live demo in real time can really boost the audience’s faith in a team’s ability to deliver. Much more effective than a few screen shots of ‘how we think it is going to look’. It makes the transition from some ethereal future vision to something – well, ‘concrete’ is probably not the right term, but I think you get my meaning. But it wasn’t that that was making us nervous anyway.

I think it is always difficult to ‘announce’ to a group of staff that ‘this is what you are going to be working with’. No matter how much consultation you carry out beforehand, there will always be those who think you have got it wrong or didn’t take their advice or that the old method was better. And sometimes they are right. But not this time we hope! Audrey Version 1.0 will not be perfect – like any other software it will be tweaked as the users start to use it for real work. Users will feed suggestions back to the developers so we can continue to improve it and fix any bugs. Even so, we have worked very closely with the product owner throughout the whole project and so we are confident that users will see benefits immediately.

I think what really made us nervous was that in preparing for the unveiling of Audrey we came face-to-face with the realisation of just how important the work of this project is. Not just to the project team, not just to the Publishing Office, not just to Schools and Departments – but actually to the whole future of the University and to all our staff and students – prospective and current. Does that sound over dramatic? I don’t actually think it is. Now I am not saying that we weren’t somehow aware of this anyway but when you have to explain what you are working on to someone not directly involved you do have to step back and put things into the context of the bigger picture. Within the project team it is easy to concentrate on whatever particular facet of the project is current and lose sight temporarily of the whole.

To put things in simple terms, we are building an application that gathers data which will form the bulk of our public-facing output. The Programme Plant will aggregate data for the XCRI-CAP feed but will also manage all the data for Kent’s on-line prospectus pages. It will also be the basis for much of the data that we will provide to Unistats (KIS), HEFCE,UCAS, third party websites such as prospects.ac.uk and other websites which may not even exist yet. All these things are important but without on-line course pages we would struggle to attract students. This is a project we have to get right.

I am pleased to say our presentation went very well and the work of the project was received with (almost) universal enthusiasm and approval. As I have already said it is not as if we didn’t know this work was important but it is worth sometimes taking a few moments to remind ourselves.

Preparing for the next technical sprint

Autumn has arrived

With the KIS Widget now configured, tested and implemented on the University of Kent course pages we are now doing some preparatory work for the next technical sprint at the beginning of November. One of the areas we will turn our attention to is a proposed re-design of the way we present data to prospective students on-line. Staff in Enrolment Management Services have drafted enhanced and improved course pages and held discussions with other members of staff to fine tune these suggestions. Some of the changes are aesthetic or aimed at making the pages more readable and accessible. Other changes present additional data or links to related data – such as student profiles and information about Open Days. The KIS Widget, of course, features too, under a Further Info tab. Angela Watson will bring these proposals to the next XCRI-CAP Implementation Group meeting on Monday so we can continue the discussion and make plans to implement the changes.

Although at times the amount of work needed to reach all our milestones has seemed daunting I think the project team has managed to remain positive and enthusiastic throughout. For me it seems like we are reaching a point of synergy between different strands of the project. All these strands are obviously concerned with getting essential information to prospective and existing students, whether through printed materials or through internal and external websites. We still have a way to go but I think it is fair to say that we have unravelled a rather confusing and convoluted ball of information flows and now we are pulling them together in neat ordered lines towards our goal of an efficient and easy to use and re-use course data collection and publication suite.

However I do not want to sound complacent and previous experience has shown that until systems are released into the wild and used in earnest by experienced practicioners we will not be able to judge how succesful we have been. There may still be one or two knots left from that ball of confusion.

On November 1st our team of developers will begin the next technical sprint. We have had a largish gap since the last chunk of development but will catch up with six 2 week sprints back to back. We have planned how we will use each of these sprints and aim to start with UI tweaks for the Programmes Plant and Load testing. Load testing is vital as we need to be confident that the application will retain good response times at those times of the year when the number of users which be much higher than normal. It is of course during these high pressure periods that the advantages the Programme Plant will bring will really prove their worth.

We will also use one of the upcoming sprints to create an inital XCRI feed and to test it against the validator. Now the Programmes Plant has reached its current stage we are reasonably confident that we can produce the XCRI feed without too much additional work but we don’t want to risk leaving this until the end of the project. Just in case.

A quick project update

A pile of carved wooden books and a bench at an outside meeting place on the University of Kent campus

Outside meeting space, Canterbury Campus, University of Kent

The first technical sprint is now over and the project developers have produced their recommendations for a development platform. The current Programmes Factory software is a Drupal application and I think it is fair to say it has its problems. Users find it slow – particularly if there is more than one user – and the developers had some issues with the data model. In summary, neither side, developers or users were keen to redevelop on this platform. However time had been invested in acquiring expertise in Drupal and there are other Drupal applications in use and supported by IS so the decision to drop it as a development platform should not be taken lightly. Ultimately the Project Steering Group will decide whether to approve the team’s decision. I won’t pre-empt that by rehearsing all the arguments here but the platforms we were originally considering were:

Drupal
Microsoft .NET framework
PHP
Sharepoint

The best laid plans of mice and programmers being what they are however a latecomer has popped up in the form of Python on a Django framework. The EMS team are considering a third party application to produce customised Prospectus pdfs and there may be good reasons for settling on a platform that best fits with that system – which uses Django. Trouble is we need a technical spike to make that decision. We can do this but it may push back work already scheduled. Next week sees the first meeting of the project Steering Group – that is where the decision whether to spike or not will be taken.
The development platform is important but not more so than the system architecture. The course data system will be web service oriented with a service bus at its core. The data management tool we build will produce a web service which will be used by the central core aggregator. By aggregating data from disparate web services the central service bus will provide other web services – including the open XCRI feed. The central bus should be platform agnostic towards its web service suppliers. It will also need to have good performance and be fully extensible.

——————————————————————————————————-

An interesting article in the Chronicle of Higher Education reveals how far ahead the UK are – though we are not alone in this – with open course data in comparison to the United States. One of the lessons to be learned from the article is that if institutions do not provide the data students, alumni and prospective students feel they need to make their decisions they will find other ways of getting it. Of course statistics are not the only measure of value in Higher Education but we can surely trust our customers to work that out for themselves?

K.I.S. and tell

Distant view of Canterbury Cathedral on bright but misty day

Morning mist over Kent campus

We have added an item to the work packages for Kent’s XCRI-CAP project – namely configuration and implementation of the KIS widget. Key Information Sets are comparable sets of standardised information about undergraduate courses. In an increasingly competitive market, and in an online world where customers are used to being able to make comparisons, HEIs need to make relevant information easily accessible to prospective students. People browsing the prospectus want to know about the experience of previous students and what their prospects might be after graduation as well as details of the courses on offer. The information provided by KIS differs from the XCRI-CAP feeds in that it includes data from, amongst other sources, the annual student survey. Crucially it is also presented in context on the same page as the course information

Final details of the appearance and contents of the widget are not released until the end of this month (March 2012) but the widget will include data such as:

Student satisfaction
Percentage of graduates of the course in work after six months
Average salary of graduates of the course

The data will be aggregated in part from national data sets, such as the National Student Survey (NSS) and the Higher Education Statistics Agency (HESA) and the Destination of Leavers from Higher Education (DLHE) survey. But data on learning and teaching, assessment methods, accommodation etc will need to be submitted by HEIs initially to HEFCE. In the future HESA will collect this data.

The KIS widget which will be embedded on each page of the online prospectus – much like one might embed a YouTube video – and will display data pulled direct from the aggregating HEFCE website which will be launched in the autumn of 2012.

Much of the data displayed in the KIS widget is currently available from the Unistats website but the widget will display the data with the programme to which it refers. The user will also be able to click through to the Unistats website (or more accurately its replacement) to see further information on the course, the institution and information about the local facilities, rental prices and etc

(Further information on KIS from HEFCE).

Beginning at the beginning

Having talked with the project’s stakeholders we decided that our investigation of the circuituous journey of a new programme or module towards its inclusion in a printed or on-line prospectus should begin at the beginning. This may seem obvious but perhaps not when you consider that the project scope does not include the delivery of a system to streamline, automate and disseminate the creation of programmes and modules. There is no doubt there is a need to improve current methods of working but we do not have sufficient resources within the XCRI project to achieve this. The processes we are looking at in this project begin after a new programme or module has been entered (currently manually) onto the Student Data System.

However in order to ‘future proof’ our developments as far as possible we need to understand the whole process – so this is where we have started. David Sweet & Leo Lyons spent time talking to Ann Tull in the Faculty Office and as a result David, the Information Services Systems Architecture Analyst has produced a first draft of a schematic illustrating the programme/module creation process. After comments and clarification from Ann we should have the first visualisation of at least the begining of the course data journey.

As well as starting to appreciate just how convoluted and complex the processes can be one can’t help but be impressed by the knowledge and dedication of the individuals involved – transporting the germ of an idea through to its appearance on-line or in print. I thank them for their patience in explaining to me what is second nature to them!

Mapping what we have to ensure we get what we need

Modern glass building in Paddington against a clear blue winter sky

Paddington skyline in winter

Matt Bull and I braved the ice and snow to go up to London for the XCRI Programme Meeting last week. Only they didn’t really have any ice or snow in London. It was a well-attended event and for much of the day we split into small groups to explore possibilities for collaboration and mutual support. There was less overlap than might have been expected in terms of systems currently used for storing course data but overall participants seemed to be pretty relaxed and confident about producing the desired XCRI feeds.

As at Kent, most institutions involved – a mixture of FEIs and HEIs – were also intending to review current workflows for production of both web and paper based course information. It was more or less universally agreed that it was these work packages that might prove more problematical so it was good to hear people’s ideas and at least feel we were not alone. The aims of the project make a lot of sense to all our stakeholders – we all have the same goals – but the path we take to implement changes and the way we schedule the work will need careful planning and buy in from all those likely to be affected. We will end up with a more efficient, less fractured way of working and less disconnected data stores and duplication. But the day-to-day work of those involved in compiling, editing and publishing the data has to continue during the development process. The work of the project inevitably will have an impact on this – though we will strive to keep this to a minimum. It is vital that the communications channels stay open and that we design the work packages well. We are going to use an Agile methodology with a time-boxed iterative approach, regular reviews and a commitment to rapid and flexible response to change. It is early days in the XCRI project but I know from previous experience that work put into agreeing the way forward with stakeholders and the adoption of a robust working framework will pay dividends later.

With this in mind our first major task will be to create a detailed map of current data stores and data outputs and to analyse the processes that get the data from one to the other. Then we should know who we need to talk to as well as what we need to do.

XCRI-CAP project launched

A Crane against the evening sky above Kent's new music centre site

XCRI-CAP? Not perhaps the most elegant of acronyms but it stands for the following:

eXchanging Course Related Information – Course Advertising Profile

In a nutshell this project aims to consolidate all the data the University holds on its courses, programmes and modules into a nationally agreed format.

This data is used for many purposes both internally and externally – for online and printed prospectuses, for Key Information Sets and for the Higher Education Achievement Report. The project will ensure our data is compliant with the UK standard for describing course related material, will reduce the need for re-keying information and look at improving workflows and rationalising current disparate datastores.

The Kent XCRI-CAP is a JISC funded project and is a joint effort between the Enrolment Management Service and the IS Web Development Team. JISC is funding similar projects at sixty three HEIs.

Initial meetings have already taken place involving staff who will be working on the project. Further details will appear here very shortly.

Kent XCRI

The University of Kent XCRI-CAP blog

Tag Archives: JISC