atomic design, mono-repo vs
single repo, how we’re using
Sass mixins, dependency
management, progressive
enhancement, design
language…
@alicebartlett
Slide 58
Slide 58 text
All you need to know for this talk is that
these components exist, and the next
question is: how are our developers going to
get them into their projects?
@alicebartlett
// Input
= ui_component("forms/search", {
label: “Search"
})
http://engineering.lonelyplanet.com/2014/05/18/a-maintainable-styleguide.html
This is SO TIDY
Step 2:
Slide 85
Slide 85 text
This is also how GOV.UK’s
component’s system works. (Inspired
by Rizzo!)
@alicebartlett
@alicebartlett
Components Websites!
Application code
Tools
.css
.css
.css
.rb
.css
.css
.css
.rb
.css
.css
.css
.rb
THIS IS ONLY USEFUL IF
YOUR APPLICATION IS
WRITTEN IN RUBY
• Get really good at understanding
and resolving dependency
problems
• Pick and stick to a CSS naming
convention (we use BEM)
@alicebartlett
Slide 105
Slide 105 text
Web Components might
help us a bit here
Alice Bartlett
http://somewebsite.com
Slide 106
Slide 106 text
Adam Onishi has looked at how we
could use bits of the Web
Components spec
https://speakerdeck.com/onishiweb/
planes-trains-and-css-components
@alicebartlett
Slide 107
Slide 107 text
@alicebartlett
Javascript
CSS
HTML
Slide 108
Slide 108 text
Assets are the easy part
@alicebartlett
Slide 109
Slide 109 text
http://origami-build.ft.com/
Slide 110
Slide 110 text
The Build Service takes any
combination of modules and returns
their CSS and JavaScript
@alicebartlett
Slide 111
Slide 111 text
@alicebartlett
Slide 112
Slide 112 text
We can push minor version changes to components
directly to the page
@alicebartlett
Slide 113
Slide 113 text
239,318,470
Build Service requests for April 12 - May 12
via Akamai
Slide 114
Slide 114 text
This is a bit clunky for some of our
developers
@alicebartlett
Slide 115
Slide 115 text
- no critical path rendering
- have to download more than they really need
(especially for sass)
- have to use our classnames
@alicebartlett
Slide 116
Slide 116 text
We took the code behind the Build
Service, and made it an npm package
called Origami Build Tools
@alicebartlett
Slide 117
Slide 117 text
Both of these approaches are
application language agnostic
@alicebartlett
Slide 118
Slide 118 text
FT.com has a release cycle of 3 months,
they use the Build Service
@alicebartlett
Slide 119
Slide 119 text
next.ft.com want a lot more control
over their build process, they use
Origami Build Tools
@alicebartlett
Slide 120
Slide 120 text
The CDN and Build Tools give us
enough flexibility that anyone making
a site at the FT can use Origami
@alicebartlett
Slide 121
Slide 121 text
But that’s not enough.
@alicebartlett
Slide 122
Slide 122 text
@alicebartlett
DOCS… MARKETING …
SUPPORT
TOOLS
COMPONENTS
Slide 123
Slide 123 text
FREE MARKET
SOFTWARE TEAMS
Slide 124
Slide 124 text
… teams are allowed and encouraged to pick
the best value tools for the job at hand, be
they things developed and supported by
internal teams or external to the company.
Matt Chadburn,
Principal Developer
http://matt.chadburn.co.uk/notes/teams-as-services.html
Slide 125
Slide 125 text
So Origami is competing with any
other tool, or the option to not use
Origami at all.
@alicebartlett
Slide 126
Slide 126 text
This keeps us pretty focussed
@alicebartlett
Slide 127
Slide 127 text
When I joined the FT in October, I did
some user research on Origami
@alicebartlett
Slide 128
Slide 128 text
I interviewed people around the
business, developers, designers and
journalists, product managers
@alicebartlett
Slide 129
Slide 129 text
What people told me was mostly
positive
@alicebartlett
Slide 130
Slide 130 text
But I did discover one problem. Our
documentation was confusing people
or boring them
@alicebartlett
Slide 131
Slide 131 text
http://origami.ft.com
Slide 132
Slide 132 text
http://registry.origami.ft.com
Slide 133
Slide 133 text
http://github.com/financial-times/o-gallery
Slide 134
Slide 134 text
HOW THE [HECK] AM I
SUPPOSED TO FIND TIME
TO READ ALL OF THIS
STUFF?
an anonymous Origami user
Slide 135
Slide 135 text
I wish this was just more
like bootstrap’s
documentation
an anonymous Origami user
Slide 136
Slide 136 text
http://getbootstrap.com/getting-started/
Slide 137
Slide 137 text
Using Origami is as easy as pasting a
tag into your
@alicebartlett
Slide 138
Slide 138 text
It’s as easy as Bootstrap
@alicebartlett
Slide 139
Slide 139 text
We re-wrote our documentation using
the principles used to write Django’s
docs
@alicebartlett
Slide 140
Slide 140 text
https://jacobian.org/writing/great-documentation/
Slide 141
Slide 141 text
We have a documentation style guide,
just like we have guides for JavaScript
and Sass
@alicebartlett
Slide 142
Slide 142 text
https://github.com/financial-times/ft-origami
Slide 143
Slide 143 text
Documentation isn’t
complicated. It’s just
hard.
Slide 144
Slide 144 text
Marketing is also extremely important
@alicebartlett
Slide 145
Slide 145 text
Marketing is how you convince people
to use your stuff without them having
to think too hard about it
@alicebartlett
Slide 146
Slide 146 text
The amount of marketing you have to
do should scale with the number of
users you have (or want)
@alicebartlett
Slide 147
Slide 147 text
http://getbootstrap.com/
Slide 148
Slide 148 text
https://www.lightningdesignsystem.com/
Slide 149
Slide 149 text
https://www.futurelearn.com/pattern-library
Slide 150
Slide 150 text
Marketing isn’t just pretty websites
@alicebartlett
Slide 151
Slide 151 text
And at a certain scale, you’ll need a
communications plan for new releases
to your components system
@alicebartlett
Slide 152
Slide 152 text
You should publish your incident
reports
@alicebartlett
Slide 153
Slide 153 text
You should have a support channel
@alicebartlett
Slide 154
Slide 154 text
With free market software teams, this
matters
@alicebartlett
Slide 155
Slide 155 text
With free market software teams, this
is as important to the success of your
project as the code you’re writing
@alicebartlett
Slide 156
Slide 156 text
“People won’t fight you,
they’ll just ignore you”
Slide 157
Slide 157 text
Conclusion:
1. Components at the centre
2. Make the simplest tool for the job (maybe no
tools at all!)
3. Don’t forget the other stuff
@alicebartlett
Slide 158
Slide 158 text
Conclusion:
1. Components at the centre
2. Make the simplest tool for the job (maybe
no tools at all!)
3. Don’t forget the other stuff
@alicebartlett
Slide 159
Slide 159 text
Conclusion:
1. Components at the centre
2. Make the simplest tool for the job (maybe no
tools at all!)
3. Don’t forget the other stuff
@alicebartlett
Slide 160
Slide 160 text
Alice Bartlett
Origami Lead, Financial Times
@alicebartlett
Thanks
@alicebartlett