Major Cascade 2019
TL;DR:We are working on a major release of low level components like o-typography. In this post we'll discuss what improvements are being made and how they further our aims to help bring design consistency and reduce the time teams spend repeating work.
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.
Typography
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:
- o-typography (updated): Fundamental typographic tooling and user interface styles.
- o-editorial-typography (new): Editorial styles including headlines, tags, and bylines.
- o-editorial-layout (new): Styles to layout editorial typography within an article.
Splitting o-typography into smaller, simpler, higher level components means:
- Faster iteration of editorial styles.
- Faster websites (through smaller CSS bundle sizes).
- Smaller migration paths when major changes are made, impacting fewer teams.
- A reduced learning curve for developers and designers.
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.
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.
Buttons
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.
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.
Colours
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.
Dependants
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.
Release
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. 😊