VIX were invited to join the NHS Digital Tech Away Day in 2018 and given the opportunity to run a workshop along with a lightning talk. Here's what we did.
NHS Digital Tech Away Day
We knew straight away that we wanted to use Wagtail as the base for both our workshop and talk. We wanted to showcase some of the research and work we have been conducting around content editors as users. Our goal was to highlight the problems that content editors have when using Wagtail CMS and demonstrate how we can ease these frustrations and make the process much more efficient.
The Great Wagtail Bake Off Workshop
The workshop allowed us to have a little bit of fun and spark competition amongst the attendees, so "The Great Wagtail Bake Off" was born. Using the workshop we wanted to demonstrate the difficulties content editors face on a daily basis, not just in the NHS but across all of the Wagtail community. To do this we wanted to take some of the things we had seen in page models which had caused content editors friction (when adding content to a page) and compile them all in one model.
This Included Things Like:
- Poorly named fields.
- All features enabled on a rich text block.
- Streamfields used for entire page creation without proper guidance.
- No use of help text or prompts.
- The use of wrong field types for content such as urls.
We obviously added a few red herrings into the content models to highlight the case further.
We rendered the content on a simple page with a few different elements.
We took our model and template and presented the challenge to groups of around 5-15 people that work within NHS digital.
The Challenge Included:
- One example page - what they should aim to achieve (see image below).
- 1 content model.
- 1 template.
- 10 minutes.
Some of the attendees had already used Wagtail and others hadn't but overall people got stuck straight in, adding images and links (we allowed the use of the preview button). You could soon seen the frustration set in. Why won’t my link appear as a link, why won't my image and text sit side by side?
This was all part of the plan. But fair play, the attendees persevered and created a page as close as they could to the example in the 10 minutes.
We ran through the pages created. Some were very close, others not so much, but we explained what had happened and why they might have struggled, emphasising the struggles content editors face on a daily basis. Their efforts were rewarded with cakes and everyone seemed to have had a good time, becoming more familiar with Wagtail if nothing else.
Now to our lightning talk. Some of you might have seen our Wagtail Wednesdays videos over the last few weeks. These have been focussing on how we can avoid what happened in the workshop and make content editors lives much more simple and efficient. This included things like:
- Adding help text to fields to explain what the field will do.
- Limiting the amount of features on a rich text block - right tools for the job.
- Using the right types of fields and name them correctly.
- Using tabs to organise fields.
These simple things make the world of difference to the content editor experience and make that experience much more efficient, saving mass amounts of money in the long run.
Wagtail Lightning Talk by Damon and Kieran
We wanted to demonstrate these in the lightning talk, showing how they can be used and the impact they can have. Damon talked us through the frustrations as a Wagtail developer, both at VIX and the NHS, while Kieran showed use how we can implement these simple changes and make a difference to the content editor experience. The three simple implementations that were discussed, as a way to improve editor experience were:
- Naming of fields - This touched on naming fields in a way in which in leaves editors with no doubt as to what that particular field corresponds to on the page. A good example of a poorly name field would be ‘title_one’. Compare that to ‘popout_modal_title’ and you can instantly see that the ambiguity has been taken away from this field name.
- Adding help text - A simple change yet it can make such a big difference. The example used was for an image chooser panel. It is easy to add the image however there is no information as to what size or style the image should be. A good example would be ‘Size of Hero Image should be 1200px x 300px. Used for the blog card background and the hero image on the blog post.’
- Customising rich text features - A great analogy came from Damon on this one. “Imagine having all the tools you own on your tool belt. It would be rather heavy and cumbersome! Just have the tools to get the job done.” This is basically limiting the rich text features such as the amount of headings, embed links and ability to add images and only having the ones the editor needs. It saves time and eliminates the chance of the page rendering incorrectly due to the wrong elements being added to the page.
We hope that both the workshop and lightning talk together highlighted problems content editors face and showed how simple it is to fix some of them.
If you are interested in learning more or working with us, please get in touch.