[MUSIC]

[SOUND] Okay.

Is this gonna work?

Great.

[SOUND] Hi, so my name is Andrew Betts this

talk is about the FT's journey to web components.

It turns that basing your whole architecture on

components means changing not just a lot of

your development practice, but also the way that

we do design and product development as well.

I realized actually there's a chance that this talk will make me look like the

kind of guy who kind of hangs out in parks shouting crazily at birds.

And that always reminds me of this guy.

so, I'm hoping not to come across like Bill O'Reilly on Fox News.

But I have to admit I am the guy who made a

comment to our internal development standards

that banned our developers from using jQuery.

[LAUGH] So, I'm gonna look in more

detail later on about why jQuery and other general purpose toolkits and frameworks.

Because it's not about jQuery specifically.

May not make sense necessarily in a component-sized world.

And I also had a lot of chocolate at lunchtime.

And I'm feeling really sugar high right now.

[NOISE] So excuse all the shaking.

So let's start at the beginning.

Where do we start today, and why are components the way forward?

Each web project we do at the FT, is

becoming more complex, more complicated than the last one.

Our brand is increasingly digital.

And people are interacting with us on a

broader range of devices and browsers than ever before.

So that means that the cost of achieving a good user experience for

every user is increasing and the cost of testing is increasing all the time.

And this is a big problem.

It's a problem we need to solve because for 124 years we were a

newspaper, and for the last ten years of that we've had a website as well.

But for the last two years, we're a website that also prints a newspaper.

So that really is completely changing the way we look at digital.

So if you look at what we have today, you could quite easily just say well

you don't have a responsive site the Guardian

has a responsive site you should do that.

And many media companies already have responsive websites the BBC does

as well the Boston Globe well said on a very good job.

And the Guardian is a great example of responsive done

really well, but being responsive is not our biggest challenge.

There are far more important things to establish

what we think of a healthy web development ecosystem.

Something that we can use as the foundation

to build not just one responsive product, but hundreds.

So, what we have today is a collection of bits.

You know, you have some advertising, some

navigation membership bits, content bits, various sharing tools.

And all of these things come together on a

page in a way that is not very well coordinated.

A lot of them are built by different people, working

in different teams, that don't really talk to one another.

They're not really, even very well encapsulated.

They can be coded very defensively to prevent

interference from other things that might be on

the page, even though all those things are also built by people at the same company.

You get things, the resistance integration,

and also, too limited in scope.

So, the range of of stuff that you can do with them, the amount of

value you can get from all that work you put in is actually fairly limited.

Now this is exemplified by some of the, the kind of work

that we've had to do to create the same product more than once.

so, on the right here, you've

got marketslifeseat.com, which is a Desktop website

and on the left you have Markets Data in the FT web app.

So that seems a bit mad obviously there are companies that build the

same products in iOS and Android and Blackberry and Windows and on the Web.

We've built it twice using the same technologies

in both cases which seems a little strange.

Bt when you look at the FT web app and the way that was

built and the way it was designed,

it's resistant to integrating with other things easily.

So,

we see responsive as a feature.

But anyone can do that.

It's about how you approach building things

with Web technologies that we're trying to change.

There's a senior product executive at the FT who said to

me recently, you guys have been talking about components for years.

I remember people talking to me about components in 2005.

What's so special about components now?

And I think she's right.

Components are evolving and have been evolving for quiet sometime.

We've now reached a point where we can do really powerful things with them.

If you look back at the history of components,

you can trace it back to things like identity guidelines.

Big chunky documents like this one from Apple

which appears only appropriate for Apple certified individuals.

Which is a very big, thick flat document that just tells you what things

should look like, and doesn't give you any indication of how that should happen.

So, you can evolve from here to something like a living style

guide, which not just, doesn't just tell you what something should look like.

It gives you a reference implementation of how to do it.

So you then have the the origins of a standard component sized UI.

Because you have a piece of UI and you have lots

of websites to implement that UI in exactly the same way.

This actually is a really good living style guide

for Code for America made by Clearleft in Brighton.

So, this is a great start but what you don't realize

you need is a way of putting logic around those components.

A way of instantiating them, tearing them down, templating them.

Rendering them into the dorm and all of those things need

to be done in the same way for all those components.

And you really want a way of encapsulating those things, so

they can't interfere with other components that might be on the page.

So that's where you evolve again, and produce things like component frameworks.

Facebook produced a component framework very

popular one at the moment called Reacts.

We actually made something very similar called Fruit Machine, and our

Fruit Machine and Facebook's React actually came out roughly the same time.

And when you take a fairly simple example and you produce it using

Fruit Machine and using React, it's

astonishingly similar what you end up with.

So, that's a really positive indication for us.

It tells us well, Facebook and the F2 are very different companies.

But we had a very similar technology problem,

and we solved it in almost an identical way.

And that tells me well, we probably have our eyes on the same goal.

And that is the next step in the evolution

of components, which is to take it to web clients.

When we reach the point where we can use Web components.

We no longer have to opinionated about how we

wrap those components and put them in the browser.

So, you no longer have to be running React or running Fruit Machine.

You'll just make use of the components in the browser.

And components is something I've become completely

obsessed about because I think with the

number of websites that we have, the number of things that we're trying to do.

You can't always think about the tiny details every time

and you want to build something really good every time.

So, to try and build something really good

really quickly, you need to build with bigger bricks.

And so the analogy I always make to people internally is well, I want

to build a house, but I don't want to build a house using bricks.

I want to build a house using rooms because they I can put

a house together in a day and that's a really powerful thing to do.

So our objectives are these sort of things.

We want components standards more collaboration better

encapsulation and everything needs to be composable.

We wanted to go a little bit further than this.

Because we, we identified things that we

didn't think other people were doing so well.

And we wanted to try and come up with a solution that would take us there too.

So first of all, I asked a

domain administrator, how many websites do we have?

I thought, I'll go through them all, I'll

figure out what the commonalities are between them.

So it turns out we have 600 domain names.

And I took one of those ft.com and it turns out we have 800 sub-domains of that.

So I didn't look at how many sub-domains we have at the other 599 domains.

I didn't order all those work sites.

But, a lot of people still use them, you know,

millions of readers actually find a lot of these websites.

Very useful and they read them everyday, and we don't want to have to

rebuild them all, we don't have time, we don't have money to rebuild them all.

So, when we build components, we really need to

get value from those components on these existing websites.

And there are two big problems with this.

First of all these sites don't have bill, a bill process.

There's build process that I can insert dependencies

into, and build them into a front-end build.

In fact, a lot of these sites were

built before the idea of a front-end build existed.

And secondly, there's no foundation.

There's no common library or framework for running components on

the page, or if there is one, it's, it's obsolete.

So we need to be able to work around those

things without having to make major changes to existing sites.

Second thing is, I don't like monoliths.

I don't things that become a dependency of every single other thing that you build.

Because when you do that, at some point you will hate that thing.

And, you'll want to get rid of it.

And it will be a liability.

But the more things depend on it.

The more difficult it would to get rid of.

So the easiest thing to, the easiest way to avoid having to get rid of

something that's really difficult to remove is

not to build it in the first place.

The third thing is, we want to raise the bar.

This is a beautiful graphic that Google came up with years ago to

show the progression of web technologies and

basically it's all happening at this end.

These browsers on the other hand, continue to exist.

And I think there's a sort of

unasked question always, in, in progressive enhancement.

Which is where are you progressively enhancing from?

You know, the idea being that you, you serve a good basic experience that

works everywhere and then you enhance as

new technologies are detected in the browser.

But you're bound to have, have set a cutoff like we don't

care about browsers older than this because, you know, no one's using those.

And actually there is a native, there is

native support for doing that in the browser.

The problem is it was fixed to a

particular cutoff point which is the existence of JavaScript.

So the no script tag offered us an ability to

serve alternative content to browsers that didn't meet a quality threshold.

The problem is we couldn't move that quality threshold.

So, and that quality threshold is now in a position that's completely useless to us.

So I'd really like to have that kind of no script

capability but to be able to put it wherever I want.

So that we can decide what browsers meet

our quality bar and what don't, and which don't.

And finally, we want to make something that is so easy, that we

can hand it to an agency to build a website for the FT.

They've never worked with us before, and then they

can use it within an hour without talking to us.

Which is quite an ambitious target for ease of use.

So we took all these things and we made something that we call Origami.

So Origami isn't a framework because that would be to create something monolithic.

So it's a specification.

It's a document that describes the best practices that we've agreed to to share.

And, it's a suite of tools, that help us to stick to those best practices.

And, it's a whole load of components that

we've built using that, that, those best practice guides.

So, I'm going to dive into the spec, first of all, and talk

about a few of the the, the highlights from the decisions that we've taken.

And then give you a demo of some of the tools that we've built.

So first of all we have rules to deal with the weight of ease language and syntax.

So in JavaScript for example, we have

rules around Not using globals, not modifying the

DOM on parse and outside of areas that you expect that model to be responsible for.

So if I use a component that's built by a colleague and I

haven't spoke to them about, you know, to make sure they did it well.

I can be confident, that putting that code into my bundle, won't slow down my pace

load and the it won't interfere with anything on, on the page unexpectedly.

We also name space for our events so that we can be

sure that two developers building components

won't name their events the same thing.

And of course we have standards for things

like static code and analysis tools like jsHint.

CSS is actually a little more interesting.

Because CSS doesn't really have scope in the same way

that JavaScript does, we have to do a lot more namespacing.

So we care about adding namespace prefixes who are like classes.

And we have rules about not styling out of namespace.

So, for example, if you have a

gallery component that requires a basic box component.

The gallery is not allowed to re-style the box.

It can take the boxes styles, mix them into its own classes, and re-style those.

But it is not allowed to, to re-define the definition of box.

Because the box might be used by another component.

Specificity is another thing that we need to be very careful about.

And if you look at some of the legacy products that we have to support you find

you know the usual problems with specificity wars, where

things are fixed simply by making them more specific.

So, in starting this project we try to set up

rules that will try to ensure that that doesn't happen.

So using them, lock in a modifier syntax to

reduce our CSS selectors to one single token where possible.

And where we're using raw HTML tag selectors, we'll generally use them with

a descender operator to make sure that we don't target more than we intend to.

We have a list of states that we we consider when we are designing.

So this has been really helpful for

collaboration between the developers and the design team.

Because we now have agreed exactly what we mean by active, and

selected and focused and busy and disabled and invalid and so on.

And these are the interaction states that we care about.

And when we, when we implement those interaction states,

we use the correct ARIA roles to describe them.

And finally another thing I thought I'd

mention about CSS is how to do responsiveness.

Because components and component authors can't tell.

Where that component is gonna be used in the page.

There's no point in, in putting media queries into a component.

Because I could have a component that might be

on the, the, the full width of the page.

But equally, the developer of the page that's using my component might put

it in a box that only occupies a small part of the page.

So the media query if it's inside the component isn't necessarily gonna work.

So instead, components export mix ins that allow you to restyle the

component in a number of different visual styles that are generally different sizes.

And then, the developer of the product that is

embedding the component can write their own media queries.

And can select the different visual styles of

all the components on the page that they want.

And that's a little bit of work for the product developer,

but it means they get same breakpoints that exist at consistent

locations, and that they can control exactly what the behavior of

the components on the page is when they hit those breakpoints.

We also have a standard build pattern.

And this is really important because it means that we can consume,

large dependency trees of components and build them all in one build step.

It means that we don't, ever have, repeated

code within our, our built JavaScript little CSS bundles.

Everything is, is guaranteed to only be included once.

And this pattern consists on the JavaScript side

of using common JS for our module format.

Browserify to convert those modules for use in the

browser and Closure Compiler too produce minified concatenated bundles.

And on the CSS side we use SASS which does all of the above, and we're using Bower to

require all of those modules into a a flat

components directory which we can easily deal with to produce those bundles.

And the final point on the spec that I want

to talk about is the cut, the cuts the mustard technique.

This is a term that the BBC responsive news team came up with to describe the

idea of running a very simple test in

JavaScript to determine how good the browser is.

And this is where we bring in this new quality threshold.

Rather than just does this browser support JavaScript?

We now care about whether the browser supports enough

JavaScript to make sense for us to run it.

So if it doesn't we actually run no JavaScript at all.

And that leaves us with a website that we describe as core experience.

Something which works.

It provides basic you know, pipe link based navigations through everything.

And its a great fall back for all the browsers, for search engine crawlers

for users who use JavaScript doesn't work for some reason.

Maybe they've had a firewall or

Misbehaving network operator interfere with it.

So, there's a lot of cases that are covered

by having a decent core experience that works without JavaScript.

And then, for those browsers that do pass

our test, we can progressively enhance within what

we call the primary experience to provide different

levels of experience for, for different qualities of browser.

But fundamentally we acknowledge that we are progressively

enhancing from a point, and that we can

move that point as browsers become less popular,

and we can drop them in to core experience.

So an example of how cutting the mustard works,

is oh, okay, this doesn't navigate with onJSDown, sorry.

[INAUDIBLE] Okay, so an example of how cuts TheMustard works is simp, as simple

as this, you literally write something incredibly

simple that will return a true or false.

And you want it to be incredibly simple because you want it

to not crash or become a problem in very, very old user agents.

This is something that you want to work absolutely everywhere.

So, those are the harlots of the spec.

There's a ton more content to it, and

you're very welcome to read the whole thing.

It's origami.ft.com.

So I thought I would also show you some of the tools

that we've made to help us implement components that are spec compliant.

And this is that these tools are really critical to the whole thing.

Because if you produce a big document of rules and

you say, you know, thou shalt stick to these rules.

That actually is quite difficult to enforce.

So, the easiest thing to do is to make some tools

that make it easiest to do that than to do anything else.

Because if you make it easier for someone to do what you want them to

do, what you don't want then I like you to do what you want anyway.

So the first tool is the registry, this is a,

a website that lists all components that we have it is.

A self-discovery mechanism so you don't have

to register your component with the registry.

It will go and scan all of our GIT

locations and it will find things that look like components.

And then when it finds them it will test them, and

if they are valid components it will list them in the directory.

Which provides a huge incentive for component developers

to stick to the letter of the spec.

Because if they don't there's a good chance the registry

will kick out your component and say this is not valid.

The best way actually of showing the registry is just to, to demo it.

It is a public website so you can look at this as well.

[BLANK_AUDIO]

Hopefully the WiFi will work.

Okay, so this is the Origami registry.

You can see we've got a fair number of components in here already.

And I can show you some examples that we've made.

So let's have a look at gallery for examples.

okay.

That didn't work.

Maybe it hasn't loaded yet.

[BLANK_AUDIO]

Should chose a simpler one really.

These will also expand when they finish loading to exactly

the right size but, let's load it in a new tab.

Okay ,so we have a gallery component fairly straight

forward most media companies will have a gallery component.

In fact they'll be lucky if they have less then five.

And we've got a nice time line down here and it's also touch friendly, as well.

So, this is a great example of where, if you hadn't built as

a component, and you needed slide show functionality as part of a product.

You probably wouldn't have bothered to put the touch support in, if tablets and

phones weren't your, your sort of key

audience for that, for that particular product.

So, by using a component where we thought about all of

these best practices, and encapsulated them all in something that's reusable.

We can provide a great experience a great gallery experience everywhere.

This is of course seeing you believe galleries

are a good idea in the first place.

So slow [SOUND] let me show you a slightly simpler component.

[SOUND] Let's have a look at buttons.

So as well as giving us rich UI components that we would use for very specific

purposes, but we also have much lower level

components and even more lower level than this.

But this is an example of a component

which gives us our, our standard FT-buttons styles.

So let's say I wanted to generate the CSS and markup that, that does this right now.

I would need to go find the buttons component, check it out.

Well, I'd have, first I have to install NPN

in Bower, and then I have to Bower install.

The buttons component, then that would go and

fetch all the dependencies of the buttons component.

Then I'd have to run a browser file.

I'd probably have to set up the Grunts or Gulp

first to make sure I can do all of those steps.

And then that would produce me a bundle, which I would then

have to cash and serve through a web server of some kind.

And that sounds like a lot of work!

alternatively, we could use our other tool that we've word got at [INAUDIBLE].

So, I'm gonna take this code which is the mark up

that produces these buttons and pop it into a JS bin.

If I can make JS bin work.

Huh, that's interesting, don't know what that's there.

Probably not the worst things that could have come up in JS bin.

[LAUGH]

>> okay, so, by default, this is gonna give me some standard browser buttons.

So this is not very exciting so far.

But if I go down a little bit further on this page, the next

section I see is a quick start section, and it gives me a link tag.

And let's copy the link tag.

[BLANK_AUDIO]

And we get our solid buttons, magic.

So, what happened there?

Let's go out to the notation and I'll talk about it.

[BLANK_AUDIO]

So, what you just saw was something called the Build Service.

And it is a node application that will take on

the query strain, a list of modules that you would like.

And it will go away and do all of that, all of that process that I just described.

It will use bower to install the module,

it will install all the dependencies, it will run

it through browser fight, it will do all of

the best practices that we've put into the spec.

And then it will serve it either on HTTP or ACPS

as you like and it will push it through a CDN.

So everything that you could want from something

that would build your front end dependencies for you.

And another great thing about this is you can

specify the version of the module that you want.

So in this case I'm saying I want version

one three seven of Header, but I prefixed the version

version number with a carrot which means that I'm

prepared to accept any version up to 3.9 including two.

So you can be very flexible about exactly how risk averse you are.

If you're building a product that's, let's say a stand alone

interactive graphic site and you want to freeze it in time.

And, you want to make sure that it never changes, never breaks.

You can specify the exact version.

And, even when later versions of this component are released, the build Service

will always be able to build

that particular version or that particular module.

Alternatively, you can leave the suffix completely blank.

Like, I've done in our Tweet.

And that's saying well, I don't care.

I'll take major version updates, that's fine.

So that's fairly risky.

It could be break the API completely but you,

it might be something you wanna do safe analytics.

Where you're are intending to interact with the modules API at all.

You're just gonna let it do it's thing.

So in that case maybe a major version update is gonna be fine.

So you can choose and it, it gets

you started with new projects very, very easily.

This instantly is also a great way

to retrofit components to existing websites that don't

have a build process because you can very quickly just slot in a, a built code.

I'm gonna use the last section.

Of my talk to talk about some of

the tricks we've developed as part of this project.

So we actually found, we have to resolve some problems that we already thought

we had solutions for, because in a

component world those solutions no longer make sense.

And the first example of this is Polyfills.

We go.

Back to full screen cuz I moved [UNKNOWN] okay.

So components are developed independently.

We can't make assumptions about what else might be

on the page that that component will ultimately be on.

So if the component requires a Polyfill.

Let's say the J sub t polyfill or the query select polyfill.

Should it shit with that polyfill?

Well if it does that than presumably other components might

also include the same one, and then we've got co duplication.

Or we could create a module that contains

that polyfill and express a dependency on it.

But if we do that, than we won't get the

co duplication, but we will get the polyfill come or may.

And actually, we'd really rather only serve

that polyfill to browsers that need it.

Don't really want to serve it to browsers that already have that feature.

So we decided to create a metadata file for each component.

And one of the things in that mass

data file is a list of required browser features.

So, this particular component is saying, I need post message and local storage.

Otherwise, I won't work.

I'll just break.

So it's then up to the website, that

integrates, that integrates that component to provide those features.

Either by not running the JavaScript in

browsers that don't have them, or polyfilling.

We express those requirements instantly as Modernizr test names so they're

not just random strings, they actually link to something that mean something.

And that means also that we can use

Modernizr when we write our cuts the Mustard test.

So here's an example of a cuts the Mustard Test that includes polyfill fallback.

So first when we run our basic cuts the Mustard

expression and we conclude that this browser, yes, is good enough.

So then we can test for other things that the browser

may not have despite having passed the cuts the Mustard Test.

And if those things fail, we can load some

polyfills before we then load the main application JavaScript.

I did say that I, I thought that there might be a few things in here that seemed

a bit crazy, one of the other ways that

you can do this is with service-side feature detection.

That's a very neat, I think a service called polyfill.io.

Which will, which has a very big index of user

agent strings, and it will deliver to you exactly the

polyfills that are required in that browser, which is quite

neat and it means that your front-end code is very small.

So, yeah, you could do that.

So, that's polyfill fallback.

Like, you know, we, we don't have a feature so

one of the things we could do is polyfill it.

Another thing you could do is fallback.

And that's split into two.

You could feature gate something so if, if you can't do it

then just make it appear that that feature doesn't exist at all.

Or you can do feature alternation i.e.

you can't do something, so you do something else instead.

So, the last approach is what you want to use a lot of the time.

So, for example, if you have an article with comments at the end, it might

be that we don't want to be able to accept new comments in core experience.

Because it's a fairly complicated piece of functionality.

We don't really want to support that for all the browsers.

So how do we display something else to browsers that don't cut the mustard?

You can't use NOSCRIPT because it's hard coded to

a different quality threshold to the one we want.

So instead we use a div with a class and we will

add or remove a JS class on our document element the HTML tag.

To hide or show you that content.

This actually a pretty reliable method that

works even in very, very old browsers.

What am I going to do next?

Oh, yes, so another thing we see sort of related to this is feature flagging.

So we want to.

Be able to turn various on or off depending on conditions in the browser.

One of those things is hover state.

Hover state only makes sense if you have a hoverable pointer.

Actually it was one of Paul Lewis' HTML5 rocks articles that put that sort of, got

me thinking about this and that was to

do with disabling hover effects while scrolling for performance.

But actually we're sort of slightly more interested in using it

to disable hover effects on devices that don't have a hoverable pointer.

Because if you don't have a hoverable pointer then you can actually

activate the hover effects by touch and you generally don't want that.

So, iOS, for example, has emulated touch.

Sorry, yeah, emulated hover, sorry.

Which exists because some websites require you

to hover in order to use the navigation.

You can't actually navigate the website unless you can hover over a menu.

Now we don't have any menus that are like that.

So, it makes sense that we disable hover on touch screens.

Or at least we disable hover on touch screens

that don't have a mouse, and there's massive crossover and

confusion here because f course there are lots of devices

that have both mouse and track pad and touch screen.

Or they don't have a mouse but maybe you

plug one in while you've got the page open.

All these kinds of scenarios we need to take count of so that

we don't just annoy the user by assuming something that's not actually true.

So, yes this requires detecting touch or,

more accurately, it requires detecting a mouse.

But we find that provided that you do that in

a sensible way, it can actually be a great user experience.

And finally how do we do asset loading?

So this is one of those things where is

just a no brainer if you not using components.

Let's say you have a share widget and the share widget has a swisser logo on it.

So where are you going to get that Twitter logo from?

Well you'll load it from your web server obviously.

But if that share widget is a component

and, that Twitter logo exists in the component compository.

What URL will that image exist at when it comes to be loaded from your website.

And, that's something that might vary from

one website to another, that contains this component.

So, when we write the component, we don't actually

know where we're going to get that asset from.

So, we have an assets module that helps us to resolve these URLs.

First we pass in the the path within the repository.

And, the name of the repository we'd want to get the file from.

And, we just assume that there is the the return value from that is a value URL.

And, you use it like you would any other.

And then when the component is integrated into a site, we can set

various configuration that allow us to

control exactly what happens to those URLs.

So we can say for example, well I put all my components in

the results directory, and I put this particular one in the web sub directory.

And that will then allow the assets module to resolve what the full URL is.

And that means that as component developers we are not penated

about how you as a, a product developer craft your URLs.

You can create whatever URL scheme you

like, and the components are, are fine with

that.

So, in summary, I'm actually ahead of time, which is amazing.

We have some pretty cool stuff at the FT.

In fact, the web app won best news app in the Newspaper Awards

in the paper a few weeks ago, so we were very proud about that.

Some of it isn't very consistent and isn't very well integrated.

We see web components as very much the future of the way that we build

websites, and also part of the solution to the sort of problems that we have.

So we set out to build a spec and some tools to try and

fix those problems and to get us ready for web components when they arrive.

We have lots of interesting challenges, and

working in public has been really interesting,

because it's enabled us to get a lot of feedback from developers outside of EFT.

It's also meant, interestingly, that other media

companies that also have these same problems are

very much more willing to talk to us

and explain how they're solving the same thing.

So I think ultimately

that means

that we will end up with a, a much better product.

So that is all I have to say.

Thank you very much.

[SOUND]