Why we’re starting from scratch with The Economist’s new website
The first pages are already live. Here’s what we are changing
Economist.com is under construction. Not unlike Britain’s Houses of Parliament, our current website just about does its job but is in danger of collapsing. In September 2018, we launched an internal team to rebuild The Economist’s website. Many of us felt that the site could do a much better job of showcasing the best of our journalism and of encouraging more people to subscribe.
I joined The Economist as a developer just as the team was being formed. It is a rare and exciting opportunity to work on a greenfield project — building without constraints or consideration of what was there before. Here is what we’ve achieved so far, and where we’re going next.
First things first
We began by setting out some priorities and principles that have formed the foundation of the site rebuild:
- Reading experience: a website that matches the quality of our journalism, so that our readers are engaged and want to come back to read more.
- Code quality: a high-quality codebase that is easy to understand, work on and maintain.
- Site performance: a high-performing site that works properly and loads quickly.
- Team culture: a squad with no bias towards “HIPPOs” — the Highest Paid Person’s Opinion. Everyone’s opinion is valued. There are no silly questions. We form part of a truly cross-functional team.
By prioritising these things, we want to deliver a site that will provide the best possible reading experience, built on a codebase that no longer feels like “wading through treacle,” as one developer put it.
AMPing things up
We decided to start with Accelerated Mobile Pages (AMP). A “revAMP” if you will. AMP is an open-source html framework designed to optimise pages on mobile devices. It is lightweight and offers fast page loading (hence the lightning bolt in the corner of an article on a Google search page) and better search engine optimisation.
AMP supports limited JavaScript — making the page load time short — and only article pages (rather than all pages on the site) are able to use AMP syntax. This, combined with the fact that the AMP codebase was already separate from that of the full site, meant our initial time to launch was relatively short and low risk. Given that our website serves primarily to allow people to read our journalism, it made sense to use AMP to launch our new article pages first.
Additionally, building an AMP article page created a template for the real deal on the full site. This means that as we begin development of our new economist.com article pages, we already have an almost complete one ready to go, forming a springboard from which to develop the rest of the site. So what have we done differently? To be candid, our old AMP site made some mistakes. The rest of this post will look at how we’ve learned from them.
“Life is a series of building, testing, changing and iterating” — Lauren Mosenthal, product designer
What has changed?
Product
Previously, the full site and AMP sites were built by separate teams. From the start this presented a challenge to the product team, who had to manage two similar products that were built in very different ways. It was difficult to make consistent changes across both economist.com and AMP due to the requirements of different stakeholders.
Equally challenging was the lack of clear product management strategy across economist.com and AMP. We now have a dedicated product manager and a delivery lead who oversee the development of both sites. Consequently we can effectively generate our product roadmap, communicate with stakeholders and build the best possible product for readers.
Our approach to product development as a whole at The Economist is changing: we’re now increasingly user-focused, and we’re implementing a design system that is aligned across all products, with a coherent user experience and a consistent codebase.
Design
One of the biggest changes to the AMP site is the design. While the previous iteration reflected the full site visually, there was a lack of design process. This led to components on AMP being built as an approximation of the design of the full site using styled components, which goes against styling patterns across the rest of our digital products.
Crucially, the previous AMP site was not designed for mobile first — surprising given the “mobile” in Accelerated Mobile Pages. This time around, we’ve used responsive, mobile-first designs and common components that will go on to form a design system being created in tandem to the building of the website. This will ensure the styling of our digital products is consistent and easy to implement.
By starting with AMP, we have been able to test the new article page designs on smaller screens, as well as taking on board feedback before rolling the designs out across the full site, and other digital products.
We have taken the decision to no longer support old versions of certain browsers, enabling us to use cutting-edge CSS (Cascading Style Sheet) techniques and take a new approach to design on our site. An example of this is our use of CSS custom props—variables that we can declare and then reuse in our style sheets.
Visually, the new AMP site is an iteration of the current site design with a newly designed masthead and footer. We’ll add to these changes as we continue to build the full site. Eventually this will amount to a complete site redesign, removing restrictions around CSS from a technical perspective and promoting things such as larger images and smoother “wayfinding”—the mechanism by which a user navigates the site.
UX
The new design of The Economist’s website is largely informed by the work of our user experience team. We want to create a product that our customers will love by placing them at the centre of the design process. Through user research groups, we are engaging with our customers to find out how they interact with our site, what they love and what they don’t. We can then bear those pain points in mind when creating a product for them. The new paywall experience on AMP is a striking example of this.
Technical
Along with product, design and UX, the final piece of a good website is the code itself.
As mentioned, underpinning the current full site and old AMP site are separate codebases. Both were built in React but this is where the similarities end. This led to high levels of context switching for developers when changes needed to be made across both sites, which is both mentally taxing and inefficient.
From a technical point of view, the old AMP codebase was “not bad”, according to some of our senior engineers. The main issue was a lack of consideration of the scale at which the site would need to run, leading to poorly designed infrastructure and the site being throttled on a regular basis.
In order to avoid this happening again we’ve spent time evaluating our infrastructure in order to deliver a high performance site. As we build the full site, we will continue to regularly question whether the infrastructure we have is meeting our requirements and, if not, we’ll adjust it.
Additionally, we’ve introduced health checks (to monitor) and logging (to record requests made to the site), both of which are essential for us to not only maintain a high performing site, but also to let us know if there’s an issue, so that we can respond to it as quickly and efficiently as possible.
Underpinning the code itself are a set of approaches and behaviours that the developers on the team have decided upon in order to create a codebase that is both easy to understand and maintain. We create Architecture Decision Records (ADRs) to document important technical decisions we make, so that anyone reading our code has some context, and we use git hooks, linters and high test coverage to ensure our code is as robust as possible before it goes live. We’ll continue to do all of these things following the launch of the new AMP site, and as we build the new full site.
It’s inevitable that we’ll make mistakes along the way, but we’ve learned a lot so far, and we’re now in the best position to minimise the effects of any mistakes in the future.
So far I’ve been a part of the creation of a team that places high value on code quality and culture. I’m proud to be part of a team where, despite our varied levels of experience, my opinion is always valued, respected and sought out. I’m excited to see where the rest of the site rebuild takes us, and I’m sure our readers will appreciate it too.
Olivia Frost is a software engineer at The Economist.
