Tag Archives: course data

Introducing Audrey

Reflective tiles on external wall of Elliot College extension

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.

Standard

Preparing for the next technical sprint

Autumn leaves on campus

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.

Standard

IWMW: Xcri-cap files workshop

At this year’s IWMW (Institutional Web Management Workshop) I attended a workshop session on xcri-cap facilitated by Rob Englebright, from JISC and Claire Gibbons, Web and Marketing Manager at the University of Bradford.

A few attendees at the workshop came from one of the 63 institutions involved in the JISC course data programme (the xcri-cap project). Others were not involved but keen to find out how xcri-cap might benefit their institutions.

It was really interesting to hear Claire Gibbons talk about how Bradford are using the project to refine their course information handling processes, with the full backing of senior management. Having worked on Kent’s corporate website for five years, I saw many parallels between their experiences and ours at Kent.

Like Kent, updates to Bradford’s online prospectuses have historically been driven by the annual publication of print prospectuses, with the prospectus text then being cut and pasted online. Of course, this is not ideal because it doesn’t make the most of the online medium.

Print prospectuses tend to group programmes of study into broader subject areas – there just isn’t space to give a detailed description of each and every course.

Online there is the potential to produce course catalogues containing detailed information about each programme. At Kent, our course catalogues contain programme pages but many of them would benefit from more detailed, programme-specific content.

Producing an effective online course catalogue is a chief goal of our work on the xcri-cap project. For us, the steps to achieving this are:

  • Developing a CMS with workflow – to store, manage and output course data online
  • Collating the necessary information about each programme, and
  • Establishing a suitable process for keeping online course information up-to-date throughout the year

These are undoubtedly steps worth taking when you consider that an aim of the xcri-cap project is to allow prospective students to compare courses from a range of institutions. More pressingly, from September 2012 all universities will be required to carry a KIS ‘widget’ (a sidebar) on each of their undergraduate programme web pages.

The widget will display course-specific data aimed at helping students to decide whether the course is right for them and will represent value for money.  Producing more bespoke programme pages will help us contextualise the KIS data and help inform the decision-making of prospective students. The better suited a student is to a course, the more likely they are to graduate with a well-earned degree.

So there’s everything to gain from providing accurate and bespoke course information online.   The question for is: how do we best achieve this? As readers of this blog will know, we are already developing a new course content management system. However, as many of us at the workshop agreed, it’s important  to keep sight of understanding, developing and refining the people-based processes which must lie at the heart of an efficient course information management system.

Standard

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?

Standard