Course proofing: how to build a content management system within a content management system
DC Team Leader Steve Evans describes an innovative solution to help us manage a course proofing process with numerous stakeholders, varying workflows, and evolving content.
Managing course content is often a multifaceted challenge. Ensuring the information is accurate and up to date is often fraught with problems. With numerous stakeholders, varying workflows, and evolving content, a streamlined approach is essential. This post explores an innovative solution we implemented: a course proofing system built within an existing content management system (CMS). Here’s how we tackled this complex process and the lessons we learned along the way.
Courses at the University of St Andrews
The University publishes about 370 courses for undergraduate and postgraduate students. The courses are managed by the T4 content management system using three different content templates. These templates ensure that the standard text, such as policy information, can be easily duplicated across all the courses.
Most courses include information, such as entry requirements, contact details, fees, and start and end date, from central data sources. The remaining information, such as course description and teaching information, is manually entered into the content template.
With about 50 individual elements per course, the content template is complex and difficult to maintain. Each year, the course information needs to be reviewed and updated. Academic Schools are responsible for providing the course description and teaching details, but due to the complexity of the content type, it is impractical to train users to edit the content in T4, particularly when the Schools would only need to modify a few of those 50 fields. Also, it would be difficult to manage permissions in T4 so users in Academic Schools could get access to just their courses.
The challenge: time-consuming proofing process
Instead of giving academic Schools access to T4, the alternative approach has been to individually copy the course content from a webpage into a Word document. The document was further annoted to indicate the content that needed to be edited and the acceptance criteria for edits. These documents were termed ‘Word pulls’.
Once a Word pull had been created, it was emailed to the relevant parties in the Academic Schools so they could use track changes to indicate the edits before being passed back to the Digital Communications team and Admissions for quality assurance checks.
This approach had several inefficiencies:
- Fragmented communication across academic Schools, publications and admissions teams.
- A lack of a centralised data repository, leading to duplicated efforts and potential data discrepancies.
- Time-consuming manual edits and reviews.
Clearly, we needed a system that allowed for seamless collaboration, robust version control, and clear accountability.
Enter the Digipulls™ proofing system
To address these challenges, we developed Digipulls™.
Users can edit content directly within the course pages using TinyMCE as the editor in combination with two plugins from Loopindex for TinyMCE:
- FLITE for track changes
- LANCE for adding comments.
The edits could be stored as revisions with a MySQL database. We used T4 to publish the TinyMCE code within the course pages: a content management system within a content management system!
Once edits were complete, the final submission of the course page was sent by email that was then processed using Power Automate.
The workflow
- Proofing phase:
- Courses were duplicated from existing courses in T4 and placed in a proofing folder. Power Automate was used to notify Schools of links to the proofing pages.
- School contacts reviewed content, tracked changes and added comments inline on the proofing pages. Revisions could be saved with comments before final submission.
- On final submission, no further edits could be made on the proofing page.
- Review phase:
- Emails were sent to a single email address. Power Automate detected when an email had been received, checked for the presence of any erroneous HTML (for example, content pasted from Word) and updated a change log with the changes and a master spreadsheet that had a list of all the courses.
- The Digital Communications team validated the updates, flagged discrepancies, and recorded changes in the master spreadsheet.
- Edits were made to the proofing pages in T4.
- Final checks:
- The proofing pages were moved to a different folder for checking by the School contacts. This allowed a further check before making the course page live.
Key features
- Centralised proofing pages:
- Schools were given dedicated proofing pages tailored to their courses.
- Inline editing capabilities allowed for real-time updates.
- Version control and tracking:
- All changes were logged in a database with details like the editor’s ID, timestamp, and final comments.
- A centralised change log simplified the auditing process.
- Automated communication:
- Standardised emails with links to proofing pages streamlined communication.
- Tracking features ensured clarity on the progress of each course.
- Streamlined editing:
- TinyMCE and custom plugins enabled intuitive editing.
- Developers added specialised functionalities for enhanced usability.
Pros and cons of the system
Pros:
- Efficiency gains: centralised data reduced redundant tasks.
- Accountability: change logs ensured clarity on who edited what.
- Transparency: stakeholders were aligned throughout the proofing cycle.
- Scalability: the system handled around 370 courses, proving its robustness.
Cons:
- Learning curve: some users resisted adopting the new system.
- Setup complexity: creating and managing proofing folders required technical expertise.
- No post-submission edits: this rigidity occasionally posed challenges.
The future of DigiPulls
This novel approach to course proofing was time consuming to implement due to the development and testing time. However, it is anticipated that efficiencies will be gained as we use it for subsequent proofing cycles.
We intend to use module data from central sources, which will simplfify the proofing process as Schools will no longer need to check this content: module content often triggered the most changes and comments.