You are not alone….

Last week I attended my first XCRI programme meeting with Leo (PM) and Matt (dev). As a new recruit to the team I’ve heard a lot about the project and the institutional value it promised, so I was looking forward to seeing the bigger picture.

After frantically swatting up on the JISC project aims during the journey we arrived at the conference centre, where I was surprised by the quantity and variety of HE providers represented.

While grabbing a coffee we had the opportunity to mull over the project posters, which gave me a great insight into the plethora of deliverables and the extent of technology and resources invested. One resounding theme from the posters was that it had been one hell of a journey! This message resurfaced throughout the day, as people spoke of institutional challenges and limitations, with many confessing if they had been visible at the beginning of the project they would have questioned their participation.

The day consisted of seminars where participants demoed their projects utilising the XCRI-CAP feed, or talked about the approach they had taken.

One thing that became apparent was the strong sense of community that filled the room. Individuals felt united by their struggles and limitations, yet empowered by their ability to improve course data workflow, for the greater good of their institution and the HE sector.

I left Birmingham feeling elated and hoping that the institutional collaboration nurtured by the XCRI-CAP project was just the beginning of a great transformation in the HE sector.

Preparing the online prospectus

Since December things have moved on incredibly fast with the Kent Xcri Project. Thanks to the dedication of the web development team (who are literally working all hours on the project even when off-sprint), we now have a fully-fledged ‘superuser’ version of our new content management system and have started entering all the course data for our new undergraduate prospectus. The system is a pleasure to use and flexible enough to deal with forgotten fields and last-minute changes. In the next sprint we are continuing to look at the front-end, final backend issues and the xcri cap feed.

Within Enrolment Management Services, we are continuing to review the best way to present our course pages (editorially-speaking) which is challenging given the timeframe and the sheer amount of programme data to enter.

However, a great benefit of the system is that we can eventually allow editors within academic schools to contribute to these pages directly within the CMS. This will be a great step forward – after all, Schools know the most about their subject and their students. It’s definitely a very busy time for all involved but it feels like we are making excellent progress.

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.

Load Testing the Programmes Plant

Staff in the Enrolment Management Services department continue to give feedback on the new course data administration system – most of it positive I am pleased to report. In the next few weeks we will carry out load testing on the system. We are currently working with staff who will use the system to create realistic scenarios to test against. This is never an easy task as many factors can influence how many people will be using the system at any one time – one of them being the design and usability of the application. Often there will be very few people logged into the system and even less actively using it but at certain peak times that number will be much higher. Working out how much higher is the problem. The best estimate we can make is that between twenty five and thirty would be a reasonable maximum to expect to be using the application during ‘normal’ periods. Not all of them will be processing data constantly – some may be using the system to check and locate data – which will cause less strain on the servers. At peak times – say shortly before publication of a new prospectus – there may be as many as fifty or sixty users on the system.

We are hoping for a positive result from the load testing – it certainly cracks along with only a couple of users on it. But if it does not perform as well as we would like there are things we can do and at this stage of the project there will still be time to do them. We could beef up the hardware and we can isolate processes or even lines of code that are causing bottlenecks. If these measures do not increase performance to an acceptable level we might have to look at staggered workflows.

Our next technical sprint – aside from load testing – does not begin until November. We are using the time until then to look at how we might be able to re-use data which is managed and stored in other university systems such as the Student Data System and the Module Handbook Database. The ideal is one authoritative source of data but this is not so easy to achieve as one might first think. If data only flows in one direction – feeding the new Programmes Plant – then we will potentially have a disconnect with the source if data is edited in the new system. But we do not have the remit nor the resources to develop the originating application to keep it in synch.

Our current methods for storing, editing and publishing course data are circuitous and less than efficient with much potential for disconnects and differing versions of data. We have to face the fact that within this project we are unlikely to solve all the problems but if we design these first steps well we can build on this work and continue the good work in future projects.

On the KIS data front we are ready to go though I think it is fair to say that the size and design of the KIS widget has not won it many fans around here. It would have been nice to have had something that we could customize to tone with our online prospectus a little better. Early days I guess…

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.

Spotlight on the Programmes Factory – or is it Plant?

Just a quick update in this blog. After a fairly intense period of development and prototyping we are just about up against clearing. So developers are going to be somewhat occupied. We have one more feedback session with the product owner this week. Time to take stock and look at some of the less technical – but equally important work packages.

We have been beavering away as a fairly small group for the last couple of months and I think it is fair to say we are pleased with progress on the new Programmes Plant software. (Is it the Programmes Plant or just Programmes Factory II? Not sure really but we can worry about that later.) The development of the Programmes Plant up to this point has mainly been about how it will be used by the EMS team. We have worked directly with those who will use the system in that department. This has required a great deal of commitment from the Enrolment Mangement Services team as well as from IS but the result is that we are delivering what is needed. It is a really important consideration for any HEI or FEI considering going down this route – the mebers of staff who will be the users of the system must be given the time to provide a high level of involvement – which of course means many hours – if there is to be a succesful outcome.

Now we are ready to start spreading the word and looking at how others in the Faculties and Schools will feed data into the system.

So one of the tasks for the next few weeks will be to introduce the work done so far to our colleagues in other parts of the university. Although we have complete faith in our developers ability to build the application, it will not exist in a vacuum. The Programmes Plant is just one part of a whole range of systems – some software based, some manual and some a mixture of the two – that are needed to get out course data out to those are, and those we hope will be, studying at Kent. And of course to produce the XCRI feed. The long term plan is that these systems are automated and will talk nicely to one another but we cannot achieve all that within the life of this project. Neither can we continue with disparate systems that have the potential to get out of synchronisation and necessitate duplication of effort. To bridge the gaps and maintain communication between our current systems we need to be confident that we have appropriate, efficient and comprehensive workflows in place.

We need to map out how our colleagues in the Schools and Faculties will interact with the Programmes Plant and, where data flows are not yet automated, what manual triggers we need to put in place to capture the creation, modification and termination of programmes and associated marketing information. Some of this information we may be able to get via web services from the Admissions system and the Student Records systems but for the time being some will rely on email notifications and on-line forms.

There is a positive mood in the team at the moment and we are looking forward to demonstrating how far we have come and talking to our colleagues about next steps.

User testing our UG online prospectus

Recently my colleague Fritha Hassell and I conducted a user testing study on our undergraduate online prospectus pages.

We wanted to know how effective the current layout of our course pages are and whether there are any areas of the online prospectus causing setbacks for our users.

This is to help inform the improvements we make to our online prospectus and in particular to the 2014 UG online prospectus, which we hope will be the first prospectus outputted using the new CMS.

The study was conducted with year 12 students in a number of schools – with six participants in total. Users were asked to conduct a series of tasks such as researching information about a programme of study; finding out how to apply for it and looking up information about fees and funding.

We couldn’t have asked for better participants and the insights they gave us were invaluable. We learned a lot – such as that a colour we were using for callouts made users think they were ‘greyed out’ and unimportant (we swiftly changed that colour!)

We also discovered a few blindspots on our course pages and that some information isn’t as clear as it could be. However, we were pleased to find that the layout of our programme pages generally works well – so they’ll just need a few tweaks and of course we’ll need to figure out how to house a KIS widget on each of them.

For those interested in user testing, I can thoroughly recommend the training given by the Neilsen Norman Group and the book Rocket Science Made Easy by Steve Krug which gives sample scripts and helps you plan a study from start to finish.

We have also purchased the user testing software Morae which we trialled on this study. We’ve had a few glitches so far with the observer software but have managed to record the user testing with the screen recorder, which is great for capturing the usability issues in action.

All in all a successful study and it was really interesting to hear what the school pupils thought about going to university and how they went about researching and choosing a course for them.

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.

Improving the Modules Catalogue

Follow up demos of the Programmes Plant prototype application (see previous blog) went well and we have another technical sprint booked to begin on June 14^th. This is a double sprint giving developers four weeks to work on the next version of the prototype. In preparation for this Mark Fendley, Scrum master and I met with customer representatives on Monday to refine user stories. Following a final sprint planning session on the first day of the sprint we will hand over to the developers to do their stuff.

Meantime the project team have begun the work of looking at Kent’s module catalogue. It is beyond the scope of our XCRI-CAP project to deliver a new application to deal with modules. The current module catalogue software works well but we have identified a few possible improvements which are within the project’s remit. Our project plan states that we will do some work to

improve data quality,
add or enhance searching, grouping and collections functionality and ;
clarify the purpose and remit of the Modules Catalogue.

Nick Thurston kicked off the practical work on this by running validation reports to identify ‘orphaned’ modules – the Student Data system appears to confirm they exist and are active but detail is missing from the Modules catalogue. (Details of these modules are available on the School or Faculty websites). The missing data is not evenly spread across the schools – but I shall not name names. Now these anomalies have been identified the Faculties have been asked to rectify things but that is just the beginning. To have a lasting legacy the project will put in place workflows to try and ensure data stays in synch in the future.

It is interesting to observe that as a result of getting stakeholders from departments who deal with the different parts of the module and programmes lifecycle many of the problems identified at the beginning of the project can be solved almost immediately. For example: Person A says I need to know when X happens. Person B says well when X happens we send out an email to Y & Z. Shall I add you that list? One of the greatest values of projects like the Kent XCRI project is that it gets people together and gives them the space to talk about things. In our busy day-to- day working lives we often just don’t find time for that.