Origami
4 person team who develop front end tools for services at FT
- reduce time spent repeated work
- unify design across FT
How?
Building components.
... not a talk about design systems - this is about what you build once you have your design system.
FT Solar System
further out the solar system less 'like' FT
- FT.com
- nested brands
- tools & services
- sub brands
- branded business
several products - all using different products and tools by different teams
Teams all over the world built in house built by agencies actively maintained not maintained
FT has about 250 sites
Maanging this complexity and keeping all of these sites aligned is what we use Origami for
What's in a component system?
- components
- tools
- documentation
- Components HTML + CSS + JS === a component, although sometimes a component doesn't require all three. Over ~5 years, Origami has grown to 50 patterns
Each component have their own repo and their own version number.
Most components systems look kind of the same.
Where they differ is tooling
- Tools
Components + Appication Code == Websites
the + is quite difficult.
The best tooling, is no tooling.
When you have to ship to more than one thing you will need some sort of tooling
How do we get HTML, CSS, JS out to all these applications?
templating - but in what? What language dependencies are required?
no templating - people could leave off or remove things they don't understand. You've created something that couldn't be easily changed in the future. You can't update easily.
There's no good option if you're wanting to make something super flexible.
Origami uses copy/paste
pick and stick to a css naming convention get really good at understanding and resolving dependent problems
Getting CSS and JS to people is a lot easier. as <script> and <link> are language agnostic.
ship the whole thing - redundant CSS and JS could be ok, depending on the overall 'size' and 'complexity' of your site.
The FT.com is a little more strict. 50 patterns, using Bower.
using bower packages == critical path rendering can use only the Sass mixin you need rather than be forced to download all the classes for things gives uses option to manage their own build process and assets
some teams don't want to have the hassle of a build process or asset management. Built a build service for each pattern so that people can 'request' the patterns as needed - 4.3 million requests per day.
Both approaches are application language agnostic (apart from the need for Bower).
- Documentation, marketing and support
Origami - is competing with any other tool, or not tool at all. It's important to focus on this as the team for Origami is funded by it being used.
Research teams in FT about Origami ...
found out the documentation was 'boring'. "I just wish this was more like Bootstrap's documentation" re-write docs built on Django's documentation principles
now have documentation styleguide on how to author the documentation. Active voice.
The amount of marketing you had to do should scale with the numbers of users you have (or want).
Marketing isn't just about making pretty websites - you will need a comms plan for releases, publish incident reports, you should have a support channel.
"People won't fight you, they'll just ignore you"
Dulle, Quorre, Christoph, Stilgyde, Jenn, The Head Wizard, The league of Wizards, Spells, The league of Dragons, Spellbooks, Strass, Stella, Ben, Firebolt, The Book of Strap, Villagers, The Baron, The Duchess
Focus on the magic and the spells, but Firebolt still needs the attention.
Watch the video.