Each week Radio NZ publishes highlights of upcoming programmes for print media, and these items are also used on the website. On the website these highlights are augmented by content from programmes with production cycles that make it impossible to meet print deadlines.
Highlights appear on the Radio NZ Home page, National home page, and Concert home page. Highlights are also display on programmes pages – for example at the bottom of the Insight page. Their use on programme pages meant this section had to be migrated before I could start on programmes.
Highlights and Schedules were based off the same model (schedule_events), with a few fields being for the exclusive use of one or the other. Schedules had been running for a few months, but when I came to actually use highlights a some extra features were needed. Because the needs of the two were diverging, I decided to split them into separate models.
This made the code simpler to read and avoided having to hide different fields in the edit screens. The other major refactor was the removal of a base model – content – as an association. The content table held common fields such as body, broadcast time, and status.
It is my view that this approach – of using a single table to hold data that is shared between other assets – is almost always wrong. It makes the code more complex and harder to follow. There is an extra join for every database query, and this make indexing and optimisation more complex. Yes, there is duplication between models – many have a body field – but the benefit is clarity and ease of maintenance. In our case we wanted to keep things simple and avoid overhead.
To avoid code duplication, the functionality built on these fields is extracted into Modules. I’ll cover that in a future post.
There was no need to migrate historical content; only the content for the next few weeks is available on the site. This was extracted via the same XML technique mentioned previously, and imported into ELF. For a short period we generated XML content feeds in ELF for use on some Matrix-generated pages.
In Matrix, adding highlights was a multistep process.
- Go to the correct folder
- Create a News Item
- Enter a summary and body on the details screen
- Change the created date and time to match the broadcast time of the asset
- Update the metadata to provide a link for the RNZ email newsletter
- Make the item live
In step 4 we are faking the broadcast time in the created field. Everywhere that highlights appear, they are sorted by created date and time, and only those after ‘today’ are displayed.
Individual programmes could enter their own highlights by adding News Items to a folder in their part of the asset tree (as in this example from Saturday Morning).
In ELF there are two contexts for adding highlights. The administrator context allow highlights to be entered for any programme, while the programme context allows individual producers to add highlights for just their programme. This is the edit screen:
Everything is on one page, and images can be uploaded directly without having to go to another screen. There is also a widget to move between days (it is not a tree), and I will reveal this in a future post.
The speed of adding highlights is much faster in ELF. I taught a producer to add their own highlights last Friday; it took less than 30 seconds to create and add a highlight.
These are the benefits of a well designed bespoke system – simpler maintenance of content, faster updating, and less confusion for users.
Next time I’ll cover going tree-less, and extrating functionality to Modules.
One thought on “Rebuilding Radio NZ – Part 9: Highlights”
Very nice Richard, I have enjoyed reading about the transition to Elf.