Realising the vision of a single source of course information

Editor's Notes

• #3: Mention that we are part of Communications and Marketing.
• #4: 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. 
• #6: Durable medium from SITS
• #7: CMA: Durable medium needed; Considerable inconsistencies between website and student records system; Major effort within University to ensure compliance and reduce risk
• #16: 14 if you count https
• #20: 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.
• #21: 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).
• #22: 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.
• #23: Here is an example response. You can see the descriptions I mentioned earlier as well as some of the other properties we get back.
• #24: 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.
• #25: 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.
• #26: 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.
• #28: 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.
• #29: 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.
• #32: 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.
• #34: 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.