M+

Headless Wagtail powers the digital home of Hong Kong’s museum of culture

,
Author information: Ben Heasman , Product Director , Post information: , 6 min read ,
Related post categories: Digital products , Wagtail ,

Worldwide, Tate or Guggenheim are household names when it comes to art & visual culture. But now there’s a new kid on the block in Hong Kong: M+.

Testing of LED lights on the M+ Facade.
Testing of LED lights on the M+ Facade. Credit ©WKCDA, Hong Kong. Photo: Kitmin Lee

On the 12th November 2021, M+ opened its doors to the public for the first time - and we’ve been massively privileged to be involved in the process by building the backend to their brand new website.

The home of the M+ museum is among some of the most stunning architecture I’ve come across (this fly-through is well worth checking out). Our challenge - to build a site to match the scale and prestige of the museum it represented.

For those familiar with the museum and arts sector - you’ll know the kind of complexity involved in these types of projects - integrations with third-party systems, including collections management, ticketing systems, and CRMs abound.

Couple this exciting opportunity with an M+ team who are big Wagtail fans and who were working to a fixed opening day deadline - this was our kind of project!

Here’s the journey we went on and some of the challenges we faced along the way...

M+ website homepage

Going headless (& multilingual)...

We knew from the outset we were going to be working with the team at Anton & Irene who’d be serving up a frontend using Nuxt.js. Which meant a headless (or browser-rendered) approach was the way forward.

Headless in short: splitting up website content (on a server) from where it’s presented (in a browser). Which (amongst other things) allows flexibility in choosing different technology stacks on the frontend and backend and the ability to integrate the content with multiple external systems using the same API.

The first question to address in any headless build - what technology to use to expose the BE data to the FE? We discussed the merits of both REST (using the existing Wagtail API) or GraphQL. We landed on using the Wagtail API as the least risky approach - it’s easier to cache and more widely used meaning we were likely to face fewer surprises. This felt particularly important given we were about to embark on a journey which would see us create around 45 content types and their corresponding APIs.

Going headless is certainly not an unfamiliar approach to us. But this time round there was an additional layer of complexity: internationalisation. Initially, the site would be available in English, Simplified Chinese and Traditional Chinese. Which meant 3 of everything that you’d expect in a single-language build. 3 of each page. 3 of every taxonomy. 3 of every snippet. 3 of every API. We couldn’t wait to get started!

On paper - no issues. We’d recently launched the internationalisation feature in Wagtail enabling editors to create translated pages in the CMS. However, Chinese doesn’t always ‘behave’ in the same way as languages using the Roman alphabet. To deal with some of the inherent difficulties that the Chinese characters threw up, we used tools like Algolia with inbuilt capabilities to deal with searching in Chinese language. We also built on the existing Wagtail Localize package to enable editors to translate pages using a machine translator (in this case, Google Translate was needed as one of the few tools that enabled Simplified to Traditional Chinese translations).

M+_multilanguage(7)

Integration, Integration, Integration

On top of the complexity multiple languages and multiple APIs would bring, we knew the build was no standalone site with a handful of managed content types. M+ had laid out a complex technical vision to bring together a whole host of platforms to create a seamless user experience.

The M+ team was confident that Wagtail was the CMS to help solve some of these problems and tie everything together to provide an unsurpassed editor experience. So at the start of the project, we kicked off with a period of technical discovery, the big aim of which was to investigate the integrations so we had a good handle on when each of the major pieces of work could be slotted into our delivery plan.

The tech discovery also fueled integration documentation which served as a guide to the wider dev team who had joined with us. This was pretty important as it allowed our tech lead to transfer his learnings from discovery to the wider team who’d be picking up the majority of the work.

We spent time looking into the CRM (Salesforce), ticketing (SISTIC), video player (Brightcove), payment gateway (AMEX; FirstData), the museum’s collection database (TMS) and event management (VEMS) integrations as well as how best to handle event data syncing between the M+ site and the wider, West Kowloon Cultural District site (which was being developed in parallel).

M+Collectionimage (7)

Even within those individual systems, we were dependent on APIs & documentation being ready (some of which didn’t exist when we started) so we could progress with our build when we needed to. Because of the nature of the payment and personal data we’d be handling, we knew PCI and the Hong Kong SRAA assessments lay ahead.

To de-risk the situation, the team gradually set up over 350 automated tests. These became a key component in dealing with the challenging tech landscape and ensuring the integrations remained intact throughout the build. On top of that, our CI/CD pipeline allowed us to push changes to staging on a regular basis (>10 per day was a pretty regular occurrence) to make sure we were testing the work on a regular basis across Torchbox and M+.

By integrating directly with each of these external systems, the M+ team were able to have the flexibility to choose tools that really served the goals they were trying to achieve. It meant Wagtail could become the one-stop-shop for editors to manage content, media, translations, and collection items on the website.

The alternative was less appealing: adapt off-the-shelf solutions offered by a CMS - which, while in reality would have made for a simpler build, would not have necessarily given them the unique and world-class experience they were after.

Thank you so much for helping to adapt the project and prioritise our needs. We continue to receive great feedback on the site design and technical architecture from our visitors, museum teams, and the wider West Kowloon district.

Diane Wang - Manager, Digital Products

All Around the World

As a team we covered 12 hours of timezones - all the way from Manila and Hong Kong through to Europe (Russia, Spain, and the UK) before journeying beyond to the East Coast US - with limited opportunities to speak in person and a whole host of first languages to boot.

Given our brief only covered the backend work, we would need to be working closely with the frontend team. However, the way things were set up, both teams were working largely independently and using different methodologies (us, Agile, with the frontend team opting for a more waterfall approach).

Impact Mapping

This was certainly one of the biggest challenges and one we certainly didn’t nail completely - even by the time we launched. However, harnessing tech was key to making sure we made the partnerships a success. The M+ team carved out a fortnightly slot in everyone’s calendars to ensure we were talking big picture together on MS Teams. This meant some late nights for them (9am NY time was 9pm in Hong Kong) - but these were a key time to get together and ensure alignment. Outside of that, the M+ team was fully integrated into our sprint ceremonies and processes which ensured we were working on the right things, at the right time.

Given we were limited on how much time we’d have to speak with the frontend team in particular, tools like Slack and Jira were key for asynchronous comms on tickets and overall strategy. We held sprint demos with M+ that we recorded and shared with the FE team so that they had visibility on what we were working on. Towards the end of the project, we implemented regular tech demos with the FE team to walk them through work we’d merged to their staging branch - which helped give them a leg up into the individual APIs they’d need to hook up with.

I feel as though my words aren’t enough and I just want to emphasise how lucky we feel to be working with you and your teams. Not only have you helped us build such a solid product for us to build upon, you have all been incredibly patient and understanding with us as the museum’s operations have changed with new requirements and operations.

Diane Wang - Manager, Digital Products

It’s only the beginning...

It’s fair to say that we’ve learned a huge amount ourselves from the past 6 months working with the M+ team and their frontend partners at Anton & Irene. The best news is that M+ now has a beautiful site up & running - with editors finding Wagtail ‘robust and easy to work with’ as a CMS.

Would we do things differently if we were to start again? Of course. That’s what Agile is all about, right? Recently, at the end of the main phase of work, we ran a cross-team retrospective to capture learnings to take into the next phase of work. We talked through what we’d do again, what we’d start doing, and what we’d not do if we were to start from day one again.

We can’t wait to continue our partnership with M+ over the coming months and are excited to apply what we’ve learned to our work with partners such as Tate and The National Archives too!

M+ Final Retro

,
Author information: Ben Heasman , Product Director , Post information: , 6 min read ,
Related post categories: Digital products , Wagtail ,