Tag Archives: xcri

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

When projects collide

I am sure many institutions working on the XCRI project will sympathise with how tricky it can be juggling work on both XCRI and KIS (and trying to maintain service as usual!).

Last week my colleagues and I found ourselves spinning our KIS plates (providing a list of 400+ URLs for the data submission; gathering up KISCOURSEIDs and working out just what to do with that widget…) with our XCRI plates (trying to suss out the data definitions, testing the new CMS and providing feedback to the developers).

We’re also working on the postgraduate online prospectus and then there’s that small matter of Clearing…

But if there is one thing that’s cheered me through the last week, it has been reading the JISC progress report summary and reading about the experiences of other universities working on the project.

I am amazed at how similar everyone’s experiences are to each other, and to our own. The recurring themes were the undocumented and haphazard ways in which course information is generated, used, passed on and dispensed with. Not to mention the sheer complexity of the whole operation and the potential difficulties with trying to systematise such vast and sprawling processes.

Reading the report, I felt reassured that we were not alone and a little inspired by the common recognition of how important this project is for our institutions. Working on these multiple projects  is a bit of a juggling act for all involved but it helps us to see how things connect and feed into each other which I hope will benefit our work on the project as a whole.

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

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.

Standard