Presented at IWMW 2017, this presentation explains how the Cardiff University moved to a single source of course information - how it was done, why and the pitfalls along the way.
3. Consumer Markets Authority
Advice to higher education:
• give students the clear, accurate and timely
information that they need so they can make an
informed decision about what and where to
study
• ensure that terms and conditions are fair, for
example, so universities cannot make surprising
changes to the course or costs
• ensure that complaint handling processes are
accessible, clear and fair
4. Consumer Markets Authority
Advice to higher education:
• give students the clear, accurate and timely
information that they need so they can make an
informed decision about what and where to
study
• ensure that terms and conditions are fair, for
example, so universities cannot make surprising
changes to the course or costs
• ensure that complaint handling processes are
accessible, clear and fair
5. What this meant for us
• 350+ undergraduate courses
• 40,000+ webpages
• Durable medium required
• October 2015 deadline
• Formal working group formed
• Website checked extensively with
SiteImprove
• Realisation that website and SITS out of step
6. Our starting point
• Course information already centralised on
website (due to Unistats requirements)
• Data flows to legacyAPI platform already
established
• NewWelsh Language Scheme requirements
• New API platform being introduced
• Moving website to new CMS
7. Five content management systems*
Content System
Most of website Percussion Rhythmyx
Study pages Bespoke CMS (developed by agency)
Course pages Bespoke web application (developed by agency)
New parts of website Squiz Matrix
Authoritative course data SITS
* just for undergraduate marketing
8. Five content management systems
• Duplication of cost
• High risk of inaccuracy
• Many points of failure (software and
hardware)
• Three different designs
• Course content unstructured
Welsh language support poor on old systems
• Search rankings split over seven URLs
9. Five content management systems
• Duplication of cost
• High risk of inaccuracy
• Many points of failure (software and
hardware)
• Three different designs
• Course content unstructured
Welsh language support poor on old systems
• Search rankings split over seven URLs
10.
11.
12.
13. Five content management systems
• Duplication of cost
• High risk of inaccuracy
• Many points of failure (software and
hardware)
• Three different designs
• Old pages not mobile-friendly
• Welsh language support poor on old systems
• Seven URLs
14. Five content management systems
• Duplication of cost
• High risk of inaccuracy
• Many points of failure (software and
hardware)
• Three different designs
• Old pages not mobile-friendly
• Welsh language support poor on old systems
• Seven URLs
19. SITS data
Content is held as “descriptions” in SITS against
individual courses
Also for each course:
• Name, qualification and mode
• Fees
• Module listings
• Intakes
• Percentage taught inWelsh
20. SITS integration
• SITS data goes into data hub
• WS02 API Manager connected to data hub
• WS02 endpoint accepts parameters:
– course code
– year
– language
– module year
• JSON response handcrafted
• IfWelsh not available, English returned
23. SITS vs Squiz content
• Authors manage all course information in
SITS
• Minimal information in Squiz data records:
– Course code
– Configuration (eg year of entry)
– Images
– Videos
– Testimonials
24. WS02 API Manager
Squiz Matrix development
Paint Layout
REST JS asset
Mustache
Lodash
JavaScript
functions
EN
template
CY
template
Course
data
record
Holds course
code and year
API request supplies
course code, year and
language
27. Performance
• Course pages cached for two hours
– Increases speed
– Reduces load on API platform
– Covers brief API outages
• Funnelback enterprise search
– Stores API response for every course (takes an
hour to crawl)
– Search and listings respond instantly
– Search and listings are CMA-compliant
29. Managing the content
• Who was involved
• Developing course content
• Pain points
• Lessons learned
30. Who was involved
CMA group made up of:
• Communications and Marketing
– UG/PG recruitment, Digital Comms, Comms
• Registry
• 3 x College Communications
• Finance
• Admissions
31. Developing course content
Task Responsible
Initial review of all course
content
College led with input from CMA group and
Digital Communications
Agree template and required
fields
CMA group
Rewrite all courses Colleges,Academic Schools, Copywriters and
Digital Communications
Ensure style guide followed Colleges and Digital Communications
QA review process before
launch
Academic Schools and Digital
Communications
32. Pain points
• Huge rewrite process – 350+ courses
• Template changed part way through process
• Template also used for course approval
• Consistency was hard to maintain
• How far does QA go?
• Welsh – 33% of courses
33. Lessons learned
• Agree template – and test it
• Set governance up early
• Check the focus of your rewrite – CMA vs
marketing
• Clarify processes and responsibilities
• Get a PM – and set out sensible timeframes
35. Benefits
• One source of course information achieved!
• Reuse of content in durable medium and offer
letter
• Risk of inaccuracy much lower
• No duplication of effort
• Fewer points of failure
• One design
• Mobile-friendly
• Bilingual
• Everything on www.cardiff.ac.uk
36. Next steps
• Two years at the same time
• Increase visibility of the process
• Improve content for marketing purposes
• Allow College Communications to edit (and
keep track of changes)
• Power the prospectus?Who knows?
Mention that we are part of Communications and Marketing.
When did these come out – these changed how we worked, we had to address the potential risks (including financial penalties) from the incoming CMA regulations. Key part that they need clear and accurate information so that they can make a decision without being misled at any point. One of the key areas of risks identified was our course information both internally and on the website.
Durable medium from SITS
CMA: Durable medium needed; Considerable inconsistencies between website and student records system; Major effort within University to ensure compliance and reduce risk
14 if you count https
SITS is student records system.
Descriptions include overview, how will I be taught and distinctive features.
Also several fields like fees and percentage taught in Welsh which are all included in the data we receive.
The data hub is our central data repository. It feeds lots of University systems.
We use the WS02 API Manager which is an open-source API publisher. It provides the endpoints, allocates API keys and controls caching amongst other things. This has access to the data in the data hub and our integration team have built JSON endpoints to retrieve the SITS data.
The endpoint takes several parameters which allow us to retrieve the right data for each course.
It took a lot of massaging to get the JSON output clean and predictable because we have so many course variations (eg placements, sandwich years, preliminary years, NHS funding).
This is an example of a request. You can see here that the module year is different from the year of entry. This is so that we can fetch module data from the previous year if modules are not yet finalised when the courses are first advertised. This is a good example of a requirement that we didn’t discover until late in the project.
Here is an example response. You can see the descriptions I mentioned earlier as well as some of the other properties we get back.
Squiz Matrix is our content management system. As well as the course information in SITS, we hold minimal information about each course in Squiz. The course code and year of entry allow Squiz to request information from the API. Other fields such as videos and testimonials are for additional marketing content. Since these are held in Squiz they can be reused on other parts of the website.
Here you can see how it all comes together in Squiz. Squiz is pretty good at connecting to external services like APIs. One of the ways of doing this is using a “REST Resource (JavaScript)”. This allows us to use server-side JavaScript to process the response and render the page.
When a user visits a course, they are really visiting a Squiz data record. The presentation of the data record is controlled by what Squiz call a Paint Layout. You can think of this as a template.
The Paint Layout calls the REST Resource and provides the course code and other parameters to it. This calls the API and retrieves the response. We also load several JavaScript utilities like Lodash and Mustache to make it easier to work with and maintain.
This is what the REST Resource looks like in Squiz. You can see Underscore, Mustache and other files being loaded. All of the course data from the API is inside the _REST.response object. We do quite a lot of processing to build up a data object that is then handed to Mustache to render the finished HTML. What is quite nice about this is that you can use Squiz keywords to fetch content from the data record or other parts of the system and make it all available to the JavaScript code.
Every course is cached for two hours. This makes the pages load faster but also covers brief outages of the API and reduces load on the platform.
We also have Funnelback which is an enterprise search platform. As well as the course search, we also use it for other course listings. Initially we planned to use Squiz for course listings but we realised that pages such as our A to Z would need to hit the API many times to get the right data back. This would be very slow and it would hammer the API platform.
Funnelback crawls the full set of courses and stores enough information about each course to render any course listings we need. It is very fast and doesn’t need a connection to the API after the crawl is completed.
It’s also worth mentioning that we throttle the crawl so that this doesn’t hit the API too hard either.
This is what it looks like now. It’s a lot simpler than before and it is working well for us. For example, since launch we’ve made several improvements to the design based on user feedback and it was straightforward to roll these out across all courses.
Hand back to Jenni who will talk about the content process.
This is an example of a request. You can see here that the module year is different from the year of entry. This is so that we can fetch module data from the previous year if modules are not yet finalised. This is a good example of a requirement that we didn’t discover until late in the project.
Agree template – and test it in the real world – we had to change our template half way through which caused lots of confusion.
Governance – having governance like tone of voice and style guidelines in place earlier would have saved us lots of pain. We had a general style guide but coursefinder required more indepth guidance. Copy writers were writing off tone for some time.
Our rewrite had a focus on CMA not marketing meant that course content still wasn't 100% fit for purpose. We also found there were still issues with house style and errors crept in after changes were made to courses.
The move to course information being held only in SITS meant that marketing content was being added by admin staff in Registry – they weren't trained to spot the mistakes a content editor would – and they weren't aware of the wider implications of how they managed the content.
We have spent a lot of time since launch explaining the course update process and redirecting enquiries to relevant teams. We should have set out these on our intranet by the end of the project but there was no time and appetite for this until problems started showing up.
With a PM perhaps lots of this would have been accommodated. We were rushed through the process and were at many times at the mercy of Colleges and Schools to provide us with the content we needed to move to the next stage of the process.