Realising the vision of a single source of course information
•
1 like•286 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Realising the vision of a single source of course information
Similar to Realising the vision of a single source of course information (20)
Recently uploaded
Recently uploaded (20)
Realising the vision of a single source of course information
- 1. Realising the vision of a single source of course information Graham Bird, Jenni Taylor and David Hopkins Cardiff University
- 2. Contents • Background • Technical implementation • Managing the content • Lessons learned • Benefits and next steps
- 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
- 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
- 15. Seven URLs* • www.cardiff.ac.uk • www.cf.ac.uk • www.caerdydd.ac.uk • courses.cf.ac.uk • courses.cardiff.ac.uk • coursefinder.cf.ac.uk • coursefinder.cardiff.ac.uk * just for undergraduate marketing
- 17. Student Records System (SITS) LegacyAPI Main website CMS VLE Study pages Course database Course pages CMS Insert solution here New CMS New website pages Before…
- 18. Technical implementation • SITS data and integration • Squiz development • Performance
- 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
- 21. Example request /squiz/v1/courses/UFBSACCA?year=2018&mod uleYear=2017&lang=welsh Parameter Value Course UFBSACCA Year of entry 2018 Module year 2017 Language Welsh
- 22. Example response
- 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
- 25. In Squiz Matrix
- 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
- 28. Student Records System (SITS) New API platform Main website VLE Course pages Search and listings New CMS Durable medium Now… Funnelb ack
- 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
- 34. Wrap up • Benefits • Next steps
- 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?
- 37. Thank you
Editor's Notes
- 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.