Origami Frontend Components & Services

Major Cascade 2019

Posted on by Lee Moody.

The Origami team maintain around 52 front end components. A component is a shared piece of user-interface which, along with other components, is used to build a webpage.

We are working on a major release of low level components including o-typography, o-buttons, and o-colors which will require a major release of dependent components which use them, and components which use those components, and so on. This is a process we call a major cascade.

In this blog post we’ll discuss what a major cascade looks like; what high-level improvements have been made; and how they further our aims to help bring design consistency and reduce the time teams spend repeating work.

The Major Cascade

Some components are low level — fundamental building blocks used to build many other components and end products. o-typography is an example of a low level component.

Other components are high level — complex components which are used in end products and rarely used to build other components. o-table is an example of a high level component.

As low level components are used to build other components there are more projects between them and the end product. To make major changes to a low level component means upgrading each project in-between step by step.

An example graph of product dependencies. Low level components o-colors and o-typography branch out; they are included in final products directly and indirectly via other components including o-table. In reality the graph is much more complex because many projects comprise "ft.com".
Dependencies on o-typography, a low level dependency, are a large portion of the overall graph. Components in-between including o-buttons and o-table must be upgraded before the end products can be upgraded.
Dependencies on o-table, a high level dependency, are a small portion of the overall graph. If a major version of o-table is released the end products may be updated immediately.


As a low level component o-typography is used by every group in Product & Tech in some way. It includes fundamental typographical styles including fonts, font scales, and tools to customise them for more unique projects. But it also includes more specific styles to present Financial Times articles. This creates a huge dependency graph and makes releasing major changes tricky — it requires coordination between many groups and impacts over 167 projects across the Financial Times Group.

If we want to make major changes to our article typography across “master brand” projects such as those which power ft.com, amp pages, interactive graphic pages, the app, and our content management systems, that should not impact other teams — like Operations and Reliability, Internal Products, Specialist Titles (or this blog).

So we’re splitting specific styles used by ft.com and other “master brand” products from o-typography into two new components:

Splitting o-typography into smaller, simpler, higher level components means:

Along with the Product Design team we also audited existing users of editorial styles. Where we discovered design divergence between projects we merged an updated version back into o-editorial-typography to improve design consistency and quality when moving between Financial Times experiences.

Unique blockquote-like style one.
Unique blockquote-like style two.
Unique blockquote-like style three.

This process of design rationalisation fed into Origami components and our new Sketch UI Kit, to help the design team prototype new experiences more efficiently without recreating existing elements.

With editorial styles moved, we also made a host of other changes to simplify o-typography for developers. See more details in the o-typography v6 proposal.


o-buttons is another low level component, with broad use across Financial Times Groups. We’re making changes to simplify the developer interface, encourage style reuse for faster websites, and make custom buttons created by projects consistent with default buttons.

o-buttons currently. In the right column "primary" buttons of different themes. In the left column "secondary" buttons. The rows show the different states of each button, for example when hovered, focused with the keyboard, or pressed. Each button has its own quirks, especially the final two rows.
o-buttons after. There is consistency between "primary" and "secondary" buttons, improved accessibility checks, and better contrast between each button state.

We worked with the design team to generate custom buttons in the same way as default Origami buttons. This simplifies maintenance, improves design consistency, and was added to the Sketch UI Kit to support future design work.

The colours for each state are automatically chosen based on design rules and WCAG 2.1 recommendations for colour contrast, to maintain our commitments to accessibility and DAC accreditation.

We also simplified the developer interface for new button themes, which may be created by specifying a single colour. Developers can find out more about upcoming changes in the pre-release migration guide.


o-colors (yep, we use British English for documentation and American English in our code), one of our lowest level components, also has some updates.

These are mostly developer focused updates but also remove technical debt from our introduction of component brands (master, internal, and whitelabel); reduce the CSS bundle size for some users (for faster websites); and make changes to reduce the chance that visual errors make it to production. See more details in the o-colors v5 proposal.


Because of the major cascade, we’ve taken the opportunity to implement more recent Origami proposals across all our components. These include consistent ways to customise components, so Origami can better support products with a unique look; removing CSS class name modification, to encourage style reuse and faster sites; primary Sass mixins, so developers can work with Origami more efficiently; and moving from CommonJS JavaScript modules to browser native ECMAScript modules, to support modern methods and tools of bundling up and delivering our websites and apps to customers.


We will start to release betas for these changes next week, with an announcement and full releases following soon after. We’ve discussed our plans with groups across the Financial Times and are planning a time to support Customer Products directly with their more complex upgrade path. If you have any questions, concerns, or feedback please reach out to the team — we’re here to help. 😊