Improving curriculum data quality with better tools

Every student in the University of Edinburgh is enrolled on a degree programme and has some sort of “degree programme table” (DPT): a set of rules which guide the individual courses they’ll take during their studies.

For some programmes, the DPT is just a selection of the courses you must take each year. Others add choices for students (“select French 1A or Arabic 1A”) or let them select from a wide range of courses (“select any level 10 courses in the Moray House School of Education”). These rules are joined together with simple and/or logic.

On Wednesday we released a new version of our DPT editor. Those familiar with the old editor will be pleased to see a big UI update, plus features to natively support core courses and unstructured degrees. More exciting to us though are changes to improve the quality of future DPTs.

A screenshot of the DPT editor for the Russian Studies and Business programme
The DPT editor for the Russian Studies and Business programme

DPT creation and editing was a combination of multiple tools, which were difficult to follow without guidance and made it difficult for users to complete the task without clear validation steps across these tools.

These issues were surfaced through a mixture of user feedback, Path development, and identification by students both in person at the Academic Fair and through online feedback.

As part of the development of the new editor, we wanted to target the core issues and either help users overcome them or to just fix them without user intervention.

Limiting assumed knowledge

A common rule in DPTs asks students to select from a custom collection of courses. For example, in Law LLB programmes, you must select two courses to determine which topics you want to specialise in.

In the previous system, creation and maintenance of these custom collections was done outside of the main editor, meaning users had to leave the editing task, go to change the collection, and then come back to the editor. They also had to remember (or write down) the automatically generated codes for these collections (such as “ROU_A-A_PTMSCHISTD2F1_11-11”).

Users now don’t need to even know what a collection is. They can now create, use and edit which courses are attached to a rule in the editor itself, without needing to know that a collection was created or what code it was assigned. This removes a critical barrier to entry for new users, and allows experienced DPT designers to focus on more important things.

We’ve also removed some fields which required users to update the underlying data structures. Where previously a user had to decide whether each rule needed opening or closing brackets to allow more complicated logic, we now just ask them to nest rules where suitable and calculate the brackets behind-the-scenes.

In the old application, each rule had a “sequence number” which determined its order and couldn’t be changed. If you had labelled two rules “104” and “105” and wanted to insert something between them, you’d have to delete something first. Sequence numbers are hidden now, and calculated automatically when the programme is saved.

Abstracting the data structure

Due to third party applications and integration with other pieces of software, we are quite limited in the ways we can change a DPT structure in the database. This means that many of the improvements we’ve made have only been changes to the way we display the data and let the user interact with it; the database is still identical.

The sequence number mentioned above is a good example of this. Each rule in a DPT still has a unique sequence number, but it is never displayed to the user and they are not limited by it when inserting or moving rules. This means that, when saving, the application sometimes has to delete the database record for a rule to free up the sequence number, and then insert the deleted rule elsewhere. This is all hidden from the user.

The idea of blocks goes further down the abstraction route. Blocks allow a DPT designer to group rules together so they can ask students to take courses following a certain set of rules or take courses following this other set of rules. This may allow students to select a specialisation or choose to avoid recommended but non-compulsory courses.

Screenshot demonstrating the use of blocks
Using blocks to allow students to select a specialisation

However, the concept of “blocks” doesn’t exist in the database. Behind-the-scenes there is only a flat list of rules, some of which have opening and closing brackets. At startup, the editor converts those brackets into blocks (e.g. one opening bracket will represent the start of a new block). When saving, they’re converted back into brackets.

Inspiration for this (hard to build) level of abstraction comes from one of the Government Digital Service’s design principles: “Do the hard work to make it simple.” The application handles a lot of complexity and almost completely abstracts the user from what’s in the database, but that complicated development is worthwhile because it will improve the quality of data.

Validation messages

One of the most common problems we’ve found with DPTs is unclear logic. For example, a DPT might say “follow rules A and B or C”. In this case, it isn’t clear to the student whether they should either follow both rules “A and B” or rule C, or whether they have to follow rule A, and the choice is just between “B or C”.

In our new editor, this logical ambiguity is recognised and the user is immediately warned about it. The validation error then stays until fixed and, whilst it doesn’t prevent saving, the user must confirm that they want to ignore the warning.

The validation error says "Unclear AND/OR logic: From the operators provided, it is unclear which courses need to be taken. Show me where"
A validation error warning the user about unclear logic

So far, we have added 11 validation errors covering common problems in DPTs. These cover various cases of missing, unclear or contradictory information.

As new anti-patterns are identified and reported, we will continue to add validation errors to help guide DPT designers.

New user interface

As mentioned at the top of this piece, the most noticeable change to DPT designers will be the new interface. This is clearer and more consistent not just within the editor but with other administrative systems in the University.

But the new interface isn’t just about looking pretty or keeping up with trends: it brings more clarity to the structure of the DPT. With fewer interactive elements and a clear hierarchy, it will help readers understand their DPT. This will ultimately be helpful to students but, during the editing process, designers too.

Conclusion

The Degree Programme Tables are a key part of the University’s business and this development will help users continue to build them with less opportunity for error and more guidance when things don’t look quite right.

We will continue to take the burden of complication from our users and provide them with straightforward applications which handle difficult manipulation without the user’s involvement bringing benefit to both staff and students alike.