Origami and 177 FT sites

by Alice Bartlett

The FT has a lot of websites. More than just FT.com. These sites can be split into some categories:

1. Things displaying news content to customers. FT.com, things built by the interactive graphics team, Google AMP stories, Facebook Instant Articles
2. Things talking about the FT itself. Marketing micro-sites, FTLive events pages, things that are about the FT but not the FT
3. Separate publications. The FT owns about 15 other publications such as www.thebanker.com, www.money-media.com, and www.ftadviser.com.
4. Internal sites and tools. The sites people use to do their jobs, be that writing articles, managing subscriptions or monitoring uptime.

I don’t know exactly how many sites the FT currently has, I have a spreadsheet with 177 rows in it which is how many I’ve found so far*.

These sites are written in different languages, using different stacks. Some have daily release cycles, some release every 3 months. Some are maintained by teams in London, some by teams working in other countries. Some are being actively developed, many aren’t. Some are built by people who work for the FT, many are built by agencies.

Ideally, sites that share design should share code. This is primarily to lower the chance of designs straying from one another, to provide a consistent experience for users, but it also lowers maintenance costs of those sites too. I think it was Remy Sharp that pointed out that given that bugs appear in lines of code, a way to have fewer bugs is to write fewer lines of code.

In order to achieve this level of cooperation between so many teams, it is not enough that everyone building them agrees to do a good job and share their code. You need a team of people to actively manage that process. That is the team I lead, it’s called Origami.

Origami is 4 developers and a designer. We have two objectives. I tell them to everyone. I bring them up in meetings. They’re good because they’re easy to understand and they’re easy to make decisions against.

1. Origami should provide a way to create a unified style and experience across FT products
2. Origami should make web development faster at the FT

Origami accomplishes this mission by providing:

1. A load of UI components to build with
2. Tools to use those components
3. A set of services for speeding up front end development, such as an image resizing service and a polyfill service.
4. A specification to help people build their own Origami services and components

Each one of those 177 websites is one that the Origami team is building for. Up until this point, it’s been hard to get some sites, those that pre-dated Origami, to adopt it. You can’t simply breeze into a team and tell them they have to rebuild the front end of their site using your tools and processes. The long term benefits of using Origami components — lower net cost of maintenance to the FT as bugs can be fixed in a single place and rolled out, the democratisation of design — do not weigh highly enough against the cost of rebuilding a front end. People don’t want to quietly tidy up their codebase if there’s going to be no big improvement to their customers. They want a big bang moment, which up until now, we haven’t had.

An opportunity for a generational shift

Right now, the FT is putting a huge amount of effort into a rebuild of its core site FT.com.

The new site is a revolution, built from the ground up. You can take a look at it over at next.ft.com, or read more about the data we’re using to build it in Matt and Gadi’s post.

What this means for many of the other FT sites, is they now have a reason to change their design, and an opportunity to use Origami. The core brand is changing, so everything must be updated. Changes of this magnitude, entire redesigns of the whole front end, do not come around often. The Financial Times has had the same design (known internally as ‘Falcon’) for 10 years. The next time this happens will be in another 10 years, so Origami must be ready now to help these sites get up to par with next.ft.com, or risk them re-implementing the Next design in their own ways, as happened in the past with Falcon.

In a future post, I’ll explain how the Origami team is helping sites at the FT hop on the Next train, but until then, if you’re working on something similar, I’m collecting examples of components systems. Please send them to @alicebartlett.

*to be absolutely fair: many of those 177 sites outwardly appear to be the same single site. I just happen to know they’re served by separate codebases.