Wagtail: Cape Town Sprint

07 March 2016

Wagtail Sprint. Cape Town, South Africa

In 2015, Springload made the move to Wagtail as our preferred content management system. One thing we've loved about Wagtail from the start is the community. The product attracts the kinds of people who are working to make the world a better place, and has gained popularity among developers building seriously high-profile websites. There's Nasa, the US GovernmentBurton, and the Royal College of Arts, to name a few. You can see more at Made with Wagtail.

Among these organisations is the Praekelt Foundation, who are using wagtail to help achieve social outcomes at a national scale in South Africa. Praekelt are building their next generation mobile platform, Molo with Wagtail, and organised a three day sprint with the core team from Torchbox to share ideas and build new features.

Springload and our friends Takeflight in Hobart have been actively involved in the Wagtail open source community, so Tim Heap from Takeflight and I were able to come along for the ride.

We spent the first part of the sprint doing introductions – learning about how everyone is using Wagtail, and defining a roadmap for our time together. Tom from Torchbox shared the roadmap for the 1.4 release of Wagtail, Milton from Praekelt told us about Molo and the Free Basics intiative, and I gave everyone a demonstration on the Springload approach setting up the admin interface for different editorial staff and business units.

Molo, which means Hello in Xhosa, is a platform as a service (PaaS) for non-profits to share their content on mobile networks throughout Africa. Praekelt are doing some awesome things with Service Workers and satellite-enabled ruggedised portable wifi hotspots to ensure that critical content reaches even the most remote communities. They're also big on progressive enhancement, given that a number of their audience are on 2G networks and feature phones.

Molo uses Wagtail for its content management system, and sites can be lauched through Mission Control, an infrastructure orchestration layer built on docker.

With 11 official languages, any digital solution targeting South Africa needs a good translations workflow.

The traditional way to handle translations in a web project is to create a copy of the site tree for each language. so you end up with EN > Home > About and FR > Home > About. However, this requires you to have 100% translations coverage for each page, or the page won't show up. It also means that moving pages around in the hierarchy involves changing the page in every language version, which is a time intensive task.

Milton and Saeed from Praekelt came up with an alternate approach, creating translations as ‘alternates’ for each page. This lets a content editor scaffold out the page in their default language, and add translated content as it becomes available. It also cuts down on the amount of double-handling an editor has to do – always a good thing.

I helped out with the UI, creating a new dropdown component to handle a large number of languages. Look out for the new translations feature to drop in Wagtail 1.5 (April).

Opening up Wagtail's front-end contributions

Wagtail is popular with python developers because it's got great DX – that's developer experience, and it's a real thing™. It's very easy to customise the admin interface and create new content types, ultimately making it cheaper to ship great websites.

For front-end developers, a lot has changed since Wagtail has launched two years ago. In front-end land, we rely more on npm modules, view-layer libraries like React, and build tools like Webpack and Browserify. My mission for the sprint was to ready Wagtail for a transition to a React-based front-end, to leverage the new admin API that Karl (Torchbox) has been working on.

React makes it easy to create things like this new admin explorer component:

Working with Justin from Praekelt, we imagined a better DX for front-end developers who want to get involved in Wagtail. We thought about wagtail's guiding principle of being easy to extend, and came up with a way for front-end devs to easily extend core Wagtail components.

In short, now you can do this:

$ npm install wagtail

Why does this matter?

Having an npm-installable wagtail package will let developers override core components in their own implementation really easily. It's a principle of wagtail to make everything super simple to extend. If you'll excuse the detour into code for a moment, this is pretty signficant:


import ReactDOM from 'react-dom';
import { Explorer } from 'wagtail';

class MyExplorer extends Explorer {
    onPageSelected(page) {
        // Do something custom here
    }
}

ReactDOM.render(, document.querySelector('.explorer'));

We're really excited to start developing more of Wagtail's user interface in this componentised, easily extensible way.

Generator for React components

Best practices are easier to follow if you don't have to think too much about them. We wrote a small generator for automatically scaffolding out new interface components in React.

# Assuming you installed wagtail globally `npm install -g wagtail`
$ wagtail component MarkdownEditor

# Will generate
$ [ created ] ~/myproject/client/components/MarkdownEditor/index.js
$ [ created ] ~/myproject/client/components/MarkdownEditor/style.scss
$ [ created ] ~/myproject/client/components/MarkdownEditor/README.md

A better content authoring experience

After one of Praekelt's excellent team lunches, I caught up with Lisa and Tamsen from the content department to talk about the editor experience. Gareth (our esteemed creative director) has worked on a series of improvements to the admin UI, which we looked at together.

Ensuring helper text is more prominent in the UI

Minimising distractions when editing content

Editing pages and managing the site structure are two distinct activities. What if the editor view covered the whole screen?

Making streamfield a more seamless part of the page editor

Wagalytics

Tom (founder and Techncial Director of Torchbox) worked on a feature we've been wanting for a while: a Google Analytics dashboard in the CMS. By setting up a Google Service Account, developers can configure an Analytics tab inside Wagtail, giving content authors access to key website metrics. The next release of this feature will allow for per-page analytics and custom, pretty charts.

Project governance

Before the Torchbox team jumped on a flight back to the UK, we spent some time discussing how Wagtail is managed, who's accountable for which parts of the project, how to plan out new features, and how we can grow the community in a sustainable and responsible way. Takeflight and Springload have also gained committer status – we're now able to merge code directly into the Wagtail core.

Wrapping up

Cape Town was an awesome experience, and extremely beneficial for all of the core team working on Wagtail. It was great to meet face-to-face, to make Wagtail better, and to solve problems that will ultimately mean better health outcomes for South Africa.

Praekelt are a super-talented organisation, doing excellent things in the non-profit space. They were also amazing hosts for Torchbox, Takeflight and Springload, taking us out for dinner, providing outstanding breakfasts and lunches for the whole sprint, and taking us hiking up Lion's Head at 6am.

I look forward to the next sprint, and we'll see you all at Wagcon ’16…