The Get Into Teaching website has multiple pages that contain financial values. Some values, such as bursaries, scholarships, and teacher salaries, need updating yearly. Other values, such as fees and student finance, are updated less frequently.

Financial values are referenced on multiple pages across the site. For example, bursary and scholarship values appear on:

  • our main bursaries and scholarships page
  • subject pages
  • landing pages for paid search and social campaigns

Below is an example from the teacher pay page on Get Into Teaching:

get-into-teaching-teacher-pay-page.png

The values needed to be replaced manually, which was time-consuming and left the process open to human error.

To speed up the process and reduce the risk of mistakes, we centralized monetary values into one place in GitHub. This means that instead of manually updating the values across the site, we only need to change them in one centralized config file.

Doing this benefits both the content designers on the Get Into Teaching team, and users, as shown in our user stories:

As a content designer I need an easy way to update salary and bursary information
So that I can be assured that we are providing the right finance-related information to prospective teachers.

As a potential teacher trainee I need to be able to see consistent, correct financial values across the whole Get Into Teaching site
So that I can be reassured about the validity of the figures and apply for teacher training armed with the correct information.

Designing the variables

To replace the values with variables that were held in a central file, we created variables that were:

  • unique and clearly described what the monetary value was for
  • written in markdown
  • inputted as strings to account for non-monetary values, such as dates

For example, salaries_starting_min would represent the monetary value for the minimum starting salary for teachers.

Example of variable strings next to financial value amounts.png

Working with our developers, we went through each type of value on the site and grouped them into categories. Since many values appeared on multiple pages, it made sense to organize them by value type, rather than by web page or category.

example of variable groups in GitHub.png

Now, to update a monetary value, our content designers just update the value in the config file, and this will show the new value wherever it appears across the site.

We have also used this approach for dates. For example, when we need to update the recruitment cycle dates, the information is in this file.

The dev team implemented 2 types of tests to check whether the variables are working. These tests check that:

  1. Any variable referenced on a page exists in a config file
  2. Any variable referenced in a config file is referenced on a page

Next, we plan to test whether this approach can work for blocks of content that are the same on multiple pages, such as subject pages.