How Greenpeace implemented Gutenberg in 39 institutional websites
Tips, failures and templates from the Planet 4 transition to the new Wordpress UI
*This post is co-authored by Lilian Reyes and Luca Tiralongo
20 weeks after announcing the transition of Planet 4 to Gutenberg, the new User Interface is being used across Greenpeace to create content that changes the world. Time to reflect on what went well and what could have gone better.
While waiting for the P4 community feedback, the team did a retrospective, and below some of the lessons we learned, hopefully useful to anyone about to embark on a similar tech upgrade. Oh, and here’s the full Jira epic.
Tip #1 — “Steal with pride” from others who went through this before
We started by reading a few posts, asking around and checking what others have done. Luckily, our Swiss colleagues already piloted Gutenberg in their P4 website, so we had a wonderful place to start.
#2 — Evaluate native Gutenberg blocks VS your own
Introducing Gutenberg is not only back end work, a new editor will also affect the front-end design. Evaluating such impact is key, especially if your organisation developed custom blocks to achieve specific functionalities.
As a modular interface, Gutenberg has over 50 native blocks, maintained and developed by the Wordpress community. Following the “release early — release often” approach, we opted for temporary exclusion of some native blocks for the go live, to come back and reassess them in the future.
- Here’s the functionality matrix we used, and below a schematic on the approach:
#3 — Define your approach to customisation and flexibility. For launch and beyond.
When coming to customisation, the P4 team decided to adjust our custom blocks to perform the same way as in the classic editor, focusing on developing Gutenberg native blocks for any new requirements.
The mantra we decided to follow (and will try to stick to in the future) is to allow editors to experiment with tools not available before (e.g. buttons and paragraph background colours) while respecting the design of the platform, rather than restricting usage by default.
#4 — Empower the development team and be ready to adjust
Split the tasks and give responsibilities. At some point, only one team member was working on a big piece of work critical for the launch (the conversion script). Besides putting unnecessary pressure on the person, this involved high risk of missing the deadline. Which happened. Sharing responsibility on such an important piece of the puzzle would have allowed for a faster change of direction and reduction of stress.
Furthermore, the team noticed that having people assigned to areas all along (instead of switching context between sprints), not only increases productivity, but also stimulates collaboration and empowers folks.
Support each other. A large scale UI migration is a long process and unforeseen events will happen. In P4, we had to deal with team members leaving, campaign deadlines and other stakeholders’ priorities, all of which affected the scope. Only by being united, flexible and supportive we managed to reduce the delays and allowed people to step up and lead when key resources dropped.
#5 — Try out multiple conversion scripts
We should have kept in mind a bit more that done is better than perfect. The P4 team initially focused on an approach that would convert 100% of the content created in classic editor exactly the same in the new editor, but did not consider that Gutenberg renders each type of content (text, files, a YouTube video..) through individual blocks of information.
Therefore, we spent a lot of time trying to fix each single area that broke, without realising that another approach would be way faster and effective, even though far from perfect.
- This is the final php conversion script, which supports all the P4 blocks, but still imports some blocks in the classic editor, rendering content perfectly fine. The trade-off is that if such content needs to be edited, editors have to convert the classic block to Gutenberg (see .gif below).
The hiccup of chasing perfection, insisting with the same migration script before switching, could have been avoided following the next tip 👇
#6 — Test, train and train-to-test
We found out that the most effective way to deliver good quality is to test the front-end rendering of each block (including text, headings, quotes and lists) and its features after each iteration of the migration script. And then further iterate.
At all stages, the team mostly relied on manual tests for both front and backend, seeking help from the users’ community after activating a decent version of Gutenberg in all the local staging instances. This provided a set of “playground” instances to train editors, and a lot of additional testing eyes to spot bugs.
During the training sessions, colleagues were asked not only to create content, to get familiar with the new UI and ask questions, but also to submit bugs in the same file the dev team used for the tests!
- Here’s the test matrix followed to visualise coverage across sites, and below a graph on how testing fit in the whole project. You can totally do better.
#7 — Constantly communicate progress (and delays)
The P4 team could have done better, to be honest. After the initial comms and the training sessions setup, we held all status updates for almost a month. While being 100% focused on the conversion script, we didn’t consider that the community kept using P4 and, by consequence, came up with feature requests and bugs the dev team wasn’t able to fix (since all these were on shortcake).
When upgrading the core tech, training and documentation are important, but so is transparent communication and change management.
- Here’s the documentation in the P4 Handbook and below the quick video recording shared before go live
Coming up next
To wrap up the retrospective, the team is seeking feedback from the P4 community. Please join one of the 2 sessions next week or fill in the form we’ll send out right after.
For 2020 and beyond, a Gutenberg-powered P4 opens up to great opportunities for tech innovation, allowing contributors to jump in and develop features and block types in a modern architecture.
Such powerful interface will help Greenpeace win campaigns and engage with millions, while hopefully inspire other members of the non-profit family to innovate and use tech to change the world.
Want to join and innovate with the team? Just shout via email, comment below or tweet at #GPP4. It would be fantastic to inspire one another.
Special thanks to all the people who made this huge milestone possible: The P4 team — Nikos, Pablo, Dylan, Sagar, Pieter, Thanos, Andrada, Mark, Natasja, Julia, Will, Gabor — and the entire P4 community.
