[APPLAUSE] Hello, everyone.

I hope you're all having fun.

I'm Harry.

My talk today is called "Normalizing Designs for Better Quality CSS."

It's a real mouthful I'm afraid-- not a very catchy title.

It's also got a second title of "Rationalizing Designs for Better Quality CSS."

What the talk is going to deal with is how we as front-end devs and often CSS developers, specifically, we spend most of our time building people's PSDs.

We implement designs that we may have not come up with ourselves.

And this is seen as quite a big deal and often too big of a deal for my liking.

As for end developers, we have got far more to do than just build PSDs.

You need to think about the quality of a code base, the health of a code base, how maintainable it is, how scalable it is, how fast it might be.

Those actually building and implementing designs is a tiny, tiny part of a much bigger job.

And in my desire to look after code bases, I see it as not being more important than design, but certainly, I spend a lot of time pushing back on design.

So the last few years of my career I've basically told designers, no.

And I've told them that a lot.

So with that in mind, just kind of a potential third title to his talk, which is why designers hate me.

I think after working with designers so closely for so many years, they don't hate me quite as much anymore.

But it's a really interesting position to be in when you join a new team as a front-end developer.

It's interesting when you try and push back on features for the sake of a code base or your tell a designer that you're not going to build something because it would impact the code base.

It's not necessarily a rude or nasty thing to do.

But it can often not sit very well with design teams.

We've had for the longest time this idea that someone gives you a PSD, and you have to build it exactly like it looks.

And I'm not sure when that happened.

I don't like that that happened.

I don't like the assumption that because someone designs something a certain way, a front-end developer has to build that.

It's almost as if we don't get enough of a sale a lot of the time.

So yeah, my last few years of telling designers no has led to interesting scenarios.

Another next 40 minutes, I'm going to go through some of the process and how I deal with those scenarios-- how I educate designers.

And so I always let them know that we can change things for the quality of the code base rather than the design.

What we've got to remember is we don't put designs in front of customers.

We put websites in front of them.

The website is designed.

But it's still code.

The users and care about the PSD.

They care about how well the website works.

It's an important distinction to make.

Websites have to look nice.

But they have to be propped up by quality and fast code.

I gave this talk in Berlin last month at the CSS conference.

And I used this hashtag because it is such an interesting and potentially controversial subject.

I want to open up for as much conversation as I can.

And if you disagree with me, for example, or have different insights or different opinions, I'd really, really like to see them.

And the easiest, quickest way to start that is probably on Twitter.

Some really interesting stuff came out of last month's talk.

A lot of front-end developers really agreed and really wanted to do the kind of stuff that I spoke about in their teams.

But they were worried about it coming across as being a bit negative.

A lot of designers said that you can go too far.

And you can squeeze the creativity of designs by treating it as more of a code base than a designed piece.

But one really interesting thing that came out of it was a lot of designers feel like they're just not getting educated by their front-end developers.

A lot of the time-- and I see this myself-- I'll design a PSD.

And I'll give it to a front-end developer.

And the front-end developer will complain to other front-end developers about how bad the PSD is.

Very rarely do developers go and try and explain nicely to designers.

So there's a little bitching and moaning, but going in the wrong direction.

And I think you can talk back in this direction and discuss with the designers more.

So these are interesting things came off the back of this talk last month.

So I'd be interested to try and keep going with you guys and see if there is anything else you could potentially have.

So anyone who's heard of anything out there will probably be because of CSS wizardry.

In the last three years, I've shifted my focus away from doing crazy CSS3 stuff more towards pragmatism, and architecture, and scalability.

And a really interesting point at the moment, I've just quit my job to try and do CSS3 stuff full time-- so more speaking, workshops, taking the kind of ethos that I've embedded in my day job to other companies.

I feel like I've almost made myself redundant at my current place of work, because I have done everything for them.

So I want to move on do this for the people.

The day job I'm leaving is Sky.

I presume most of you have heard of Sky.

Quick show of hands.

Of course, for those who haven't, Sky is a really big media organization in the UK.

It's a fantastic and a gigantic place to work.

I work specifically in the betting and gaming so that entertainment and online entertainment sector.

And these sites are huge.

These are sites built on code bases that last for years-- heavily trafficked sites-- sites with tons of engineers.

So our engineering team is enormous.

I don't know an exact number.

But it's certainly pushing 200.

That includes DevOps and test engineers, software engineers, working on these gigantic sites that keep on being built.

These sites are only getting bigger.

For example, the first site I worked on when I move to Sky two and a half, three years ago, there will be someone in the office today-- there's be a team of people in the office right now working on that exact same code base.

These aren't the biggest sites in the world.

But they are certainly big enough to require a shift in the way we think.

And it's been really interesting.

It's a massive engineering team.

I'm the only front-end developer there.

We've got a team of really, really awesome designers who are very, very clever-- very, very good at problem solving.

We've got a team of software engineers who are just stupidly clever.

And I sit in the middle.

So a lot of my job is spent managing people indirectly.

I'm not a manager.

I manage relationships.

And rationalizing designs is part of that.

I need to make sure the designers are kept happy and that we're honoring their solutions to the customer facing problems.

I also need to make sure the code I write stays performing or stays manageable.

The software engineers don't want to work with massive code.

So my job has largely been keeping front ends as small as possible, as manageable as possible-- as maintainable as possible.

Anyone who worked product will know that if you go and work on the same code base day in and day out, you really can't afford for that code base to be messy.

You just stop enjoying your job.

You don't want to resent the code base that you work with every day.

So it's really important to look after it.

One of the simplest things I learned is the best way of keeping a code base maintainable is just to write less of it-- keep it small as possible.

And it's obvious when you think about it.

The less code there is, the less there is to look after and the less there is to potentially go wrong with it.

So keeping code bases small is the easiest way of keeping track of them.

The easiest way to write less is to build less.

And this is where I come in with my saying, no, to design features.

I'll spend my time discussing actual functionality and product requirements.

But most of my job is building less front-end stuff.

The less I can get away with building the smaller code base stays.

It's really important I fire a disclaimer in here at this point though.

I'm not anti-design.

Throughout the talk, I will talk like it's me versus them.

And I also might sound a little patronizing when I refer to a designer, I'm not looking down on designers at all.

It's just an easy way to word things.

But I really want to make sure that you guys know that I'm not anti-design.

I don't feel like they're a separate entity.

I don't feel like I need to educate them.

And these techniques I'm going to discuss won't work on every site.

The kinds of sites I'm talking about I refer to as UI-led websites-- product sites that need to keep hold of a user for hours at a time.

Things like Facebook, where you can easily lose hours at the time-- UI-led websites that are more like products.

These techniques probably work on smaller websites like a photographer's portfolio-- so UI-led things-- Facebook, Google+, those kind of sites.

And you also might disagree with everything I'm about to say.

And that's totally fine.

Like I said, we've got the hash tag.

I'd really love to see some discussion.

Some people did out and out disagree with me the last time I gave this talk.

But the whole point of what I try and do is open up discussion and discuss ways of improving our workflows.

And disagreement is part of that process.

Another massive part of the process is making compromises.

Now, whenever anyone hears the word compromise, they instantly think about things.

Compromise sounds like a nasty word.

But when you actually give it some thought, compromise is a really good thing.

Compromise is the opposite of selfishness.

Compromise is about keeping as many people happy by sacrificing things that you might hold dear, but to allow someone else to get something that they might need.

So it's important to have a good relationship with your designers.

At Sky I've got fantastic-- well, personal and professional relationship with the design team.

We have a massive mutual respect for each other's jobs.

And we understand that our jobs are different.

So we can't agree on everything.

Whereas they might find one thing really important, they can't appreciate that I perhaps think that the amount of code I write is that important.

So it's about compromising and understanding what other people want and descriptions and collaboration.

It's important that you discuss everything.

I will say, no, to designers.

But I will let them know that I'm saying no.

I won't just make a decision to not build something.

This is important for two reasons.

Discussing things makes sure that people don't think you're being a dick.

At least people know why you're doing something.

You didn't just do it behind their back and not let them know.

But the second and more important thing is it can allow them to see why you're coming from.

And they start to preempt the kind of things that you would see as a sticking point.

I've got designers now who will avoid situations entirely because we've had a discussion previously.

And they now understand how something might be problematic.

Another really important part of my process is collaboration.

We still do have this very rigid PSD development to engineering.

And it's a problem I think with large organizations.

Large organizations are much slower moving.

It's harder to adopt a full-on design in the browser strategy.

So what we do is we'll get something.

A designer will have an idea.

And they'll come to me.

And we'll hack on it together in the browser.

Dan Mull refers to this as deciding in the browser.

And I think it's a really nice term.

A PSD can't tell you how fast something might be.

It can't tell you how something might feel on a touch device.

So collaborating to reach ideals to keep both teams is a important part of the process as well.

And also, no means no.

If I explain why I don't want to build something-- if a designers was to say, look, Harry, we want to keep this in the code base.

You're not allowed to cut this out.

This is an important requirement for x, y, z.

If they really tell me, no, then I will concede.

I will build something.

I will put forward my arguments.

I have no more right to a decision than they do.

So if they say, no, I will respect that.

A lot of the discussions I have with designers, or in my work as a whole, seems to really center around cheesy one liners.

And this is one of them.

I actually wrote this in an article I think a couple of years ago.

And I can't remember which article it was.

And people still quote this.

"A PSD is a clue, not a contract."

Now, what I mean by this is something I mentioned previously.

At some point when we decided who had what job, it was kind of decided it was OK that because a designer gives you a PSD, that's how the site has to look.

And I'm really not comfortable with that.

So there's no guarantee that what goes into a Photoshop document-- there is no gaurantee that that's why we build.

And I don't think there should be for anyone.

It seems like PSDs are treated as gospel like something that has to happen.

And I think that's really unwise, because it's far too early to agree to anything at that stage.

Like I mentioned, you can't get a feel for performance from a PSD.

It's naive and problematic to decide to underpin your entire project as early as Photoshop.

There are so many more variables-- so many more things that are subject to change.

If you have to work in PSDs, that's fine.

But it's important to understand that it's not a contract.

You can't be bound to that.

Things will change.

What a PSD will do is give me an idea of the design.

It will tell me the rough feel the page will have.

It will tell me what kind of [INAUDIBLE] treatments we're using-- the general layout.

It will give me an idea of the tone that the design will set.

Andy Clark refers to this as the design atmosphere.

And I think it's a really, really nice phrase.

It's how we design feels.

The PSD maybe really complete.

And it may have lots in it.

But at most, it should just give an idea of how the design should look.

I don't think we should be bound to right.

Another thing I always find myself saying is, it's doable, but we probably shouldn't.

It's doable, but you must understand that it won't work in this browser.

Pretty much anything is buildable.

We're all talented developers, and we can build pretty much anything that gets put in front of us.

I'm fairly certain of that.

But it doesn't mean that we should do.

Just because we could do something, doesn't always mean we should or that's a good idea.

I used to be terrible for this.

You only get a design that's absolutely mental.

You might get a problem with a print designer.

And you look at this design.

And it's crazy.

I used get really proud I could build that.

I used to write tons and tons of CSS.

And I'd have a style sheet this long to build one header.

And I'd sit back and think I'd done a really good job.

I've made this web page look just like a design.

How good am I ? And it wasn't for a long, long time, an embarrassingly long time, I realized that's a really bad idea.

It's naive.

And it doesn't show that you're thinking about the bigger picture.

So it all boils down to just because you can, doesn't mean you should.

And you might be surprised to learn that I got this phrase from Jurassic Park.

If you brought up that Bitly URL from the slides I'm showing, there's a really, really nice scene in Jurassic Park where they are discussing just because we can bring dinosaurs back, does it mean we should? And in that case, it turned out to be quite a bad idea.

But it's a really important way of looking at things.

They got really carried away with the idea that they could bring dinosaurs back.

But no one really stopped to think should we? And it's the same with the work we do.

Just because we can build something, it might result in hacky CSS.

It might result in a fragile layout.

It might result in all sorts of things.

It might result in diminished performance.

We can build something.

But is it right for the code base? A thing I tell designer quite a lot is there's no point having a really nice, beautiful user interface-- nothing like having a beautifully designed site if the user has to wait 20 seconds to look at it.

It is a complete waste of effort.

If you're going design something really beautiful, but users disappear before they can get to see it, there's no point it being there in the first place.

There's no denying that users really love nice design.

They engage more with it.

Studies show that nicely designed things are typically easier to use.

Nice user interfaces are incredibly important.

But studies also tell us that people on the internet, the users, are really, really inpatient.

They don't like waiting for anything.

You've seen the studies yourself.

We know that performance is key.

There's no point having a really nice retina crisp, fancy over-the-top design because users will disappear after a few seconds anyway.

They'll never even get to see it.

One shift I've tried to make in my work and certainly that's starting to detect the fact is moving to performance first.

There are things like mobile first and content first, which are really, really good schools of thought that a performance first will benefit anyone and everyone.

It isn't actually a nice, shiny iMac with a fiber connection, or you're on a tablet on a train.

Everyone benefits from performance first.

And it's really cool.

I'm really proud of the design team at Sky because I have them coming up to me saying things like, Harry, we've designed this.

And I was thinking, if we get rid of this and this, we can save two requests.

And it's really cool for that for a company that still has a very slow-moving process, we can get design teams to think performance first.

I'm really proud of that.

It shows in our products.

There are things worth sacrificing for the greater good if you will.

Dropping two things from a UI to make an entire experience faster is a massive benefit for everyone involved.

Part of the way I go about this is something I completely made up.

There is no metrics in this.

It's something I use as a conversation starter.

(the 80)20 rule-- this loosely states if we can build 80% of the design using just 20% of the code, that's the option we should always take.

If we take some really, really simple numbers, we might have a UI component.

And it might take 100 lines of CSS to build it perfectly.

To make it look exactly like the PSD, it takes 100 lines of CSS.

If we could build something that looked 80% like the PSD, something that looks really similar-- something that's almost there.

If we can achieve 80% of that design with 20 lines of CSS, we should obviously take that option.

That's obviously the better route to take.

We can trim the code base down massively just by getting a few-- getting rid of a few potentially superfluous design treatments.

And this is the whole thing about me saying no to designers.

And it's often a hard pill for them to swallow-- to say to someone who's done a lot of fantastic work for potentially weeks that, yeah, we're going to get rid of this, this, and this because I want to write less code.

It does sound quite selfish from my point of view.

And this why you need to open up those discussions, and collaborate them, and compromise them.

This is something that I often get told to me.

And I get told this by one guy in particular.

My boss is a fantastic designer-- a real nice guy called Robert Farnell.

He's a very clever guy.

I've known him for years.

So he feels like he's allowed to take the piss out of me a bit.

And he does.

He takes advantage of that fact.

So he'll say to me, well, I thought you were good to this? Are you not up to the challenge? I've designed this.

I could probably code this up.

I thought you were supposed to be a CSS guy.

Why can't you build this? And it is just to poke the hornet's nest and try and get something out of me.

But it's a really interesting thing to be told.

He's trying to us reverse psychology to make me to show off and, well, fine, I build it then just to prove I can.

But it's really interesting to hear because it does often make me look like a bad developer.

If you've got a guy who's just a traditional creative designer, and they can code something that you're refusing to build, it makes you look potentially not very good at your job.

But this is the problem I think we've got as an industry as a whole.

We're not here to replicate PSD.

We're not here to just to tap keys.

Our jobs as front-end developers are far more than building things.

The fact that we call ourselves developers at all is probably just a formality.

We're actually problem solvers who happen to use development to solve them.

There's so much more to building a front-end and replicating a PSD.

You'd never judge a builder's worth on his ability to lay bricks next to each other.

That's a daft metric.

That doesn't show you how good a builder is.

You would measure a builders abilities on whether he can create a big structure that might be around for decades or hundreds of years.

You'd never measure his abilities on placing bricks next to each other.

So why are we judged on our ability to put pixels next to each other? There's a much bigger picture we need to look at like I mentioned before-- performance, the health of the code base-- how well the team can work together on it-- how well it will scale.

There's so much of our job in replicating PSDs.

And a lot of people don't see that.

And I worry that could be a problem on our side.

Perhaps we don't get across to the right people what we actually need to do.

It goes back to these discussions.

A lot of designers have told me that I don't feel like my developer is educating me enough.

So it's not necessarily the designer's fault. Perhaps they don't

know what they're doing wrong.

And maybe that's because we're not telling them in a polite or constructive manner.

One thing I've learned particularly in the last three years when I've started flirting more in architecture and bigger sites-- the better you get as a developer, the last development but you actually want to do.

I found this massively.

I've kind of learned this from my engineering friends-- people far cleverer than I am.

The resentment of writing new code when you think about the code bit, you want to keep that small.

You might enjoy typing or writing code.

But that's not your job anymore.

Your job is to look after a code base.

So the better you get at writing code-- and I've certainly found this myself-- I resent having to write more of it.

I particularly resent certain things that I could have potentially avoided.

Whenever I build something that's similar to something else, I really resent the fact that I couldn't recycle that.

I hate building anything bespoke.

I hate adding anything to a code base I know won't get reused again.

This is bound to happen.

This is inevitable.

You can't avoid this.

You'll only have one page header on your site.

You'll only have one page footer, for example.

So there will be bespoke code in your code base.

But I always resent having to add anything to that.

I know that will happen.

But I never enjoy it.

I try and recycle everything.

I even get accused of premature obstruction, which is something I'll cover in a few slides.

But it's borne of this.

I hate refactoring code.

So I build everything to be recyclable from the beginning.

Two easy ways to go about doing this-- normalization and abstraction.

These are borrowed from some sort of computer science and computer theory.

Normalization would typically deal with potentially databases-- cutting down repetition in a data set.

And abstraction is a way of grabbing these normalizations or certainly in front ends I'm about to cover, abstraction is about tying these things up to be reusable.

Normalization is about spotting repetition or certainly how I apply it to front-end dev.

So normalization is about spotting repetition.

But more importantly, it's about spotting the potential for repetition.

It's all right seeing something repeated.

But the more things you can make repeatable, the more you can reuse and recycle-- so if we take a really timid example.

Here we've got three content blocks on a page-- a header, footer, and content area.

These have all got really similar padding values.

I'm not sure why the designer picked these values.

But they're also close that I wonder would a user ever spot the difference? Would a user ever know that one is too pixels bigger or smaller than the other? I guess the answer to that would be, no.

So we need to normalize that.

We've spotted potential for repetition.

So let's make it repeated.

And this is a start.

This is a really good start.

And this is a very timid example.

There could be 10 different types of button that are really similar.

Can we distill that down to three types of button? And this is kind of thing we'd probably do every day anyway.

We're probability already doing this.

But it's a really important way and a really good way of keeping code bases tiny.

This is all well and good.

The next step we have to do is abstract these things out-- write these things up, make them reusable.

It's all well and good spotting the repetition.

But if you can't make that work for you time and time again, it's kind of a bit lost.

It's kind of a wasted exercise.

We have to go a step further.

Abstracting things can decouple them as well.

So the fact that I have 20 pixels applied to three content areas-- how can we make that have nothing to do with content areas? How can we abstract that right out to be dropped anywhere? Well, the first thing we could do is something like this.

This is shared.

We've spotted the normalization.

We've shared it.

But it's still not abstracted.

If we want to use 20 pixels again, we could add another selected to the list and keep growing them up.

But this is our code base growing.

And it's a potential for stopping repeating and writing things.

So the first thing we could do is grab a preprocessor.

And my examples is use SAS stored in a variable.

Preprocessors-- their entire point is to help us spot and use abstractions.

And the simplest first step would be dropping this into a variable.

We can go on then to use abstracted classes.

We can store these obstructions there.

So the class Box doesn't lend itself to any type of content whatsoever.

So we can drop this in our markup wherever we want.

We're not adding anything more to our code base from a CSS point of view.

So that code base is staying tiny.

If you don't want to use marketing or classes in your markup, we could use the silent class that we made and use Extend, again, this is in SAS.

So these are ways of sort of spotting repetition, and wrapping it up into an abstraction, and using this stuff over and over again for free.

So we looked at the PSD.

And we changed it.

We normalized that design.

And this is a really timid example.

There are tons more things-- tons more potential areas that you can apply this.

This is just taking a design and making some sort of code-like decisions to change it and wrapping it up and making the code base better.

So yeah, premature abstraction-- there is a rule of thumb.

And I think it goes something like you shouldn't abstract anything until you've used it three times-- something like that.

It's a good rule of thumb.

And I can totally understand why people say it.

There's no point investing time in inventing an abstraction up front if something potentially never get reused at all.

But at Sky we often have half a sprint dedicated to refactoring.

As I mentioned before, I hate refactoring CSS.

Refactoring CSS is probably the worst job that a developer could have.

So to avoid doing that, while everyone is refactoring their node, or their Python, or whatever they're working on, I twiddle my thumbs and get on with something cool because I've been prepared.

As a matter fact, it was prepared abstraction.

I already built everything to be reused anyway.

So I don't tend to have this awful, awkward refactoring job.

So more discussion stuff I'll have with designers then.

Again, this is something I made up.

This is more of a metaphor than a rule or a fact.

When we talk about CSS, we talk about rule sets.

We're going to implement a design using CSS.

We're going to implement a design using rule sets.

So CSS is a rule-based language.

It's a rule-based syntax.

So I thought it fair to designers-- look, I can build this.

But it has to adhere to rules because the code that will implement it has to adhere to rules itself.

It's a difficult thing to try and tell a designer that they have to distill their creative thought into rules and numbers.

And again, it's all about the collaboration.

It's about the discussion.

But convincing a designer to start thinking in rules can really benefit a code base.

And it can benefit the quality of the code base.

Another thing I say after this is that,well, if we're going to have a good, consistent user interface-- a user interface that someone needs to be comfortable enough to spend hours of their lives on, it should be consistent anyway.

And consistent things are based around rules.

If you imagine Facebook, they must have tons and tons of different brand and UI rules that they stick to, because if you are going to spend an hour a day on that website, you don't want inconsistency.

You don't want anything to look wrong.

You want that user to feel comfortable and be able to trust that interface.

And this is all about basing things on rules.

And ideally, you shouldn't break any of these rules.

Never say never.

Rules will get broken.

But avoid it as much as you can.

Someone asked me in a workshop that I gave on Wednesday-- what if a client wants to change the look of a button just because? And the client has every right to ask that.

There's no reason they can't ask that.

But it's just changing one button.

So it doesn't seem like such a big deal.

But it's not about that one button.

It's about the precedent that that change sets.

If you allow someone to break a rule, they'll brick another one.

And all of a sudden, there is no rule left whatsoever.

I drew this diagram, again, for Rob, my boss.

We were discussing the concept of sticking to rules and design.

He's the lead designer at Sky.

So he's a very creative guy.

I was trying to explain why I don't like breaking rules and why I think it's bad.

We were discussing any given component.

It wasn't one in particular.

And you'll notice the horizontal line that flies straight out.

I actually took this photo after the meeting because I thought I could use it for this talk.

That's why id doesn't look very nice.

But that horizontal line that flies straight out-- that is the lifespan of a component if we never change it.

It's a happy little life span.

Even if nothing changes and nothing goes wrong, it starts, it continues to exist, and nothing changes.

But then we start to add these forks.

So we might have a component that needs to have a different background color on a different page.

That's a fork in the code.

That's a different variation that we have to maintain.

We might have an error state where this component could be a form element, which has an error state, which means it has to be red.

This is a fork in the code.

This is a breaking of the rule.

Now, we have naming conventions like BEM that allow us to deal with this.

But rule changes aren't good.

And they will happen.

But every single fork in that code means that if we change one of them, how it will it affect the other.

These forks are more like commitments.

We've put something into the code base that deviate from a rule.

We have to remember to check every other instance that branches from it.

We have to go right back at the tree and see how a change to this button hasn't inadvertently affected this button down here.

So it's no longer about the button.

It's about the button, and the change and affect on the code base, and the precedent it sets.

One of my favorite rules that I stick to is something that you can decide right at the beginning of any project.

I call this the basing unit.

This is a thing I came up with quite a while ago, I wrote an article about this.

But whenever you start a new project, you'll typically make these two decisions right near the beginning.

You'll decide your base font size and your base line height.

It won't be true of every project.

But you have to have some base font size.

And you have to have some baseline height.

Hopefully, you'd write a little more like this.

But for the sake of the demonstration, I'm going to use pixels.

They're easier to understand.

I wrote an article about sizing UIs quite a while ago, which deals with why we might write it like this.

So, yeah, we've picked these two numbers.

We've said a base font size of 16 pixels and a base line height of 24.

We can steal this number.

This number suddenly becomes very significant.

We can underpin our entire user interface from knowing this number.

It becomes our base spacing unit.

So our line height is 24 pixels.

Every paragraph will have 24 pixels between each line.

So we're used to code like this.

We'd usually see something like this, which doesn't initially look too bad.

But this type of CSS terrifies me.

Why 38 pixels? That number is so specific that I don't change it.

That is such a specific, intentional number that I need to know why that exists.

Because I don't know why it exists, and I would trust it, I won't change it.

So I need modifications I want to make.

I will add a new class under this, which breaks that rule.

And these are the forks in the code.

This is not very thin CSS.

It looks fairly innocuous.

It looks fairly harmless.

But it's about setting precedence.

As soon as you start using unusual numbers, you have explain where they are coming from so the next person knows why or why they shouldn't touch them.

So what I do this-- I just start right at the beginning of the project.

I blitz all the margins from every block-level element and replace it with a margin bottom of our base spacing unit.

This means every gap in our UI is explainable.

And we can undo this.

We can take that margin off if we need to.

This is a really good starting point that we can-- it's hardly any code whatsoever.

It's a real slim way of sorting out your entire site's spacing strategy.

And we can recycle these 24 pixels.

Again, this is a rule that I put in to rationalize a design to give me a better quality code base.

So we spotted problems.

We've rationalized.

We've normalized.

And now the code base is getting better.

And we can use that 24 pixels wherever we want.

And, again, we could hide this in a variable in SAS.

The island object isn't something I made up just to box things off.

And we want a small island.

So we use an islet.

This is just an abstract class.

So we halve that 24 pixels.

We can see where 12 came from.

This is all very watered down examples.

But let's lead on to the next thing-- UI sizing scales.

So the thing that I've started to implement.

I haven't had a chance to write anything upon this either.

I've been wanting to write an article on this for quite some time.

So we could do things like this-- we've got a component called Foo.

And that's just 1 times itself.

If we want to spin off variations, we can have this naming convention which does that.

Any tiny version of any component will quarter it's size.

Any large variation will double its size.

So it doesn't matter what the component is.

We should know that if we peg on these modifiers, we will get a different sized version of it.

For example, our margin bottom-- we can change that.

So if our margin was 24 pixels, but we need to nudge something much tighter, we can spin off of variation based on a rule that we chose way back at the beginning.

And these are all things that due reduced designs is numbers and rules.

And like I said, it's a hard discussions I have with designers.

It doesn't always go right.

It doesn't always work.

And they don't always allow it, if you like, which is totally understandable.

But if you can stick to things like this, you're rationalizing your designs and making everything really explicit and obvious, which applies to buttons.

Buttons is probably the best example.

If you want to spin off size variations, they're all based around this number that you've chose way back at the beginning.

Another really good area of rationalizing CSS is typography.

So you often see things like this.

Again, why are these numbers so similar yet different.

They don't really need to be.

We can rationalize these.

We can make them all 16.

There's no reasons why we should have one pixel difference in font sizes because the user probably won't notice it.

And it'll just confuse developers.

So typography is a really interesting part of CSS.

We've got eight different font sizes out of the box already.

We've got headings 1 to 6.

So we've got six sizes of heading.

We've got body copy, which is whatever put on the HTML element.

And then we've got the small print.

You've got the small element.

We've already eight different font sizes.

Do we really up to add to that? Do we need to spin off slightly different font sizes? Usually not.

Most UI elements will fall into any of the above categories.

And if they don't, then it's a rule that you have to break and a modification, a fork in the code that you might have to live with.

For example, you might have a call to action.

And that may need a much bigger font size.

But if that rule breaks, if that variant is justifiable, and if you can discuss that, then that's something you go and do.

But it's all about cutting back the unnecessary bits.

So yeah, HTML elements should catch everything, and you should just spin variations off-- h1 to 6, already free of charge.

Your small element-- it's kind of already in there.

Nicole Sullivan came up with this, which is a really good way of combining font sizes across headings.

Probably most of you will have seen this by now.

You've got to a h6 that looks like a h1.

We've trimmed code the code base down massively.

But we still give ourselves this flexibility to cross things over.

So I'm going to have to blitz through some real-life examples now.

Some of the things I've done at Sky-- I have screenshots.

And I'm going to discuss.

So this was a thing we built for m.skybet.com

I'm really worried you won't be able to see it quite right here, but I've isolated it in the next slide.

We've got this grid of nine icons.

And between each row and column we've got this border.

And the designers wanted it to be like this.

You can see how they go from gray or go from dark to fade out to nothing.

And that's a very trivial, simple-looking UI treatment.

But how would you build that? You can't just use normal CSS borders because you only get solid, dotted dashed.

So you could use some pseudo-elements.

You could use border image perhaps.

But all these seem unnecessarily over the top.

They all seem a bit much to create such a trivial UI treatment.

So what I did was this-- I cheated.

I applied a fade to the background container.

That's one block of CSS gradient syntax.

And now I can you solid borders on the list items that contain the icons.

So now we've kind of change the design.

And we're using an illusion to create something that looks pretty much the same, but it's far nicer on the code base.

So instead of having to think about CSS gradients on the borders or using pseudo elements, I can use border solid and fade that solid out to the edge of the background container.

So if you take another look, these lines don't fade out at all.

It's actually the dark, blue background that's fading.

So its a simple bit of trickery to alter and use illusion that can cut down on your code base.

So like I said, we can tweak the design and use illusion-- spot clever little tricks that you can make tweaks to the code base and still get almost the exact same design.

(it's the 80)20 rule.

Another example which I've to isolate-- we have this now.

And again, it's this in the same thing.

We had this graded border between them, and again, a trivial, simple looking UI treatment.

There's no reason we couldn't build that.

But when you ask how are you going to build it? Could we use masks and CSS gradients again? Skip forward another one.

You could use a background image-- an actual request.

That's no good.

We could Base64 that image.

But why would you want to use kilobytes of Base64 code for a tiny, tiny image like that.

Gradients and pseudo elements feels a bit nasty.

It feels way too much.

So why don't we just change their design? So instead of using illusion this time, I just changed completely and I said, well, why don't we just have different dividers between the nav items? So now we're using effective two solid borders that join and give the idea of a bevel effect.

So we've completely changed it-- well, not completely.

It's kind of the point.

We've changed one aspect of the design.

It's 80% like the original.

But we only need to use two lines of CSS to achieve it.

We don't have to worry about images, or CSS gradients, or pseudo-elements.

We've kind of cheated and taken the easy road.

One thing I've advised other devs on my team is if it seems too difficult to build something that looks simple, perhaps don't bother building it at all.

I had a developer come up to me.

And he'd been given a PSD that looked on the face of it relatively simple.

When it actually came to building it, there were loads of questions around-- I won't go into too much detail.

But it looked like a really tricky thing to build.

Visually, the designer and the client didn't think much of it.

But when it comes to implementation, you realize that this is far too much effort to build something that looks so simple.

So if you ever find yourself in that situation, I'd advise just perhaps not building it at all.

Look for alternative solutions.

Work with your designers to explain why you think it's bad to implement.

And see if you can bounce ideas to come up with something far better-- far better for the code base.

Like I said, we're not putting PSDs in front of users.

Developers don't sit down and work with PSDs all day.

Designers largely don't work with PSDs all day.

They get in front of users.

And they solve problems.

PSDs are just one tiny part of the tool kit that the entire team of engineers and developers and designers use.

So there's no reason we can't push back on that.

There's no reason why we can't have discussions to modify designs to make the code base better-- the product better.

Usually, we're all aiming towards building a good product.

We don't aim to build or come up with good designs.

We aim to come up with well-designed products.

Let's all think about the bigger picture.

Like I said, take the easy road.

I did.

I've decided that I'm not going to spend two days building some weird hacky stuff to make a nav.

Why don't I spend 20 seconds on it and build something similar? Keep everything really, really stupid.

I've got no problems at all saying I'm a very stupid and lazy developer.

And I think developers should be.

Complexity and showing off is a bad thing.

Complexity in code makes it a pig.

It makes it hard to understand.

It makes people who inherit your code think that you're a bad developer.

Keep everything as simple as possible.

So to wrap up now then-- so the example I just showed you-- this m.skybet.com-- it's

the most pared-back design.

It's the most rationalized and brutally deconstructed design that we ever worked on.

Me and a guy called Stewart Powell, he's one of our senior designers, we were the front-end duo on this build.

And we did some really great work together.

He allowed me to solve say, no, to things.

He allowed me to push back on decisions.

He started thinking with a developer's mind.

And we did some fantastic work on this product.

The company's really proud of it.

So we've done the business proud.

We're proud of the bit that we've done.

But users love it.

That's the best thing.

We've put a product in front of users that looks fantastic.

But it's so fast.

It's so fast.

We've got a team of performance engineers at Sky.

And they work mainly on the tech stack-- on really, really confusing stuff that I don't even dare try and get involved with.

So it's my job-- it falls largely on me in the design team to take the front-end performance route.

And we did such good work on this.

And a lot of it is from just getting rid of unnecessary, superfluous treatments-- design decisions that you could live without.

And users can't wait to tell us how fast this product is.

And I really like that I'm really proud of that.

And I know that the rest of the team are.

So to try and wrap up-- we don't deliver designs.

That's just one tiny part of our process.

We delivered designed products.

We deliver websites.

We work with code bases.

We put code bases in front of users.

If we were to put print designs in front of them, that's fine.

The PSD does need to be perfect.

But because we don't put print designs in front of them-- because we don't work with static visuals-- we need to stop thinking like that.

And we'd think about bettering the quality of the product.

Make compromises and have discussions.

This isn't something you can do on your own.

This isn't something that you should do alone.

You need to get the team to buy in.

You need to get the team to understand why you think differently to them.

It's all about managing relationships.

Stick to as many rules as you can.

If you can manage to distill something down into a rule, but the movement towards component systems like the bootstrap style component libraries-- this move towards those is setting rules anyway.

And that's a really good shift for the web as a whole.

But we need to make sure we're sticking to them.

And finally, just be clever and cheat.

I'll show you two really, really simple, timid examples of where I just completely cheated and changed the design to make the code base a little nicer.

And there's nothing wrong with that.

It's about being crafty.

It's about using illusion.

And it's about cutting the fat, trimming the fat to keep your code base manageable, and lean, and maintainable.

And that's me wrapping up.

Thank you very much.

[APPLAUSE] That was great, Harry.

Thank you very much.

Thank you.

To ask few questions-- a lot of great conversation.

And some of the threads that people were inquiring about is what are your tips for convincing stakeholders to accept differences between what the website looks like and what the PSD was? I got asked this quite a lot.

I got asked it in the workshop on Wednesday.

One thing I think is really important to speak to each stakeholder in a way that they will understand.

If you're speaking to the business, talk about money.

We want the design to like this.

And I would say, well, you can have that.

There's no reason you can't have that.

But just understand that it might take us twice as long to maintain, which means you're spending twice as much money on this.

Is this feature really worth double the budget? So that's that how we deal with clients and business.

An analogy I used actually in the workshop was when you go to a restaurant, and you ask for a steak, an d you ask for it well done.

And the waiter says, well, we don't think you should do that.

And then a good waiter would say, well, don't spend 50 euro on a filet.

Maybe spend 20 on the rump.

And that's advising the customer.

If that waiter told me to get out.

I'm not have that.

That is a bad decision.

I'm paying their bills.

I still have to-- they have to keep me happy.

And it's the same with clients.

I'd advise them as much as you can.

But if they really, really do say, no, and they want to stick to something, you have to just deal with that.

And is the situation where-- I think a lot of people are concerned that they would get into a situation where they deliver something and at the end of it, and the client is like, whoa, this is different.

Is the way to avoid that just setting the expectations up front that they should expect something that is not the same? Yeah, that's a good question.

So what we do at Sky, which is easy, because when you work product, you have the clients to sit next to you so you can discuss that in a far more iterative way.

When I used to work agency side, I'd get involved.

I'd go to client meetings.

I think a lot of the problem is end developers perhaps never even get to meet the client.

So I'd make sure that I was in there and saying to them, look, we're designing this in Photoshop.

But I just want you to know that we'll try and do the best we can.

But things may change.

And if they ask me, why might it change? We'll say, look, we've not done this before.

We've not built this design before.

Anything could happen is what managing people.

It's not easy.

But this is what I go back to as well.

Our job is far much more than tapping keys.

Absolutely.

I guess along with managing people, a client is probably-- us as developers, we have concerns about-- we want to feel good about what we're developing.

And that's what a lot of this is.

And building something that is scalable and the code feels solid and healthy gives us a great feeling of satisfaction.

The client usually doesn't care that much about those feelings.

They want it to look good and feel good.

So how do you balance the two of those, which is like I the developer want to build this in a perfect way.

They just want something that meets their needs, looks good, feels good, and to be honest, they could be happy if the code was spaghetti and terrible.

One thing say I lot of the time is the client shouldn't care about code anyway unless they come with specific requirements like it has to be [INAUDIBLE] stuck.

I don't think the client should ever be told about code, because they don't care whether you've used too many IDs and classes.

They shouldn't care.

I think you should do the best work you can.

And if you need to change the design to make your work better, that's when I would say, look, I wouldn't tell the client about the code.

I'd talk about the financial impact of that code.

If I'm going to build this, it's going to be a ropy mess.

And it's going to cost you twice as much to maintain.

Let us do a better job for you.

You don't need to know how and why.

I always link things back to-- I talk to designers about how the user would feel using a fast site.

I talk to the business and clients about how much money will cost them to maintain a bad site.

So it means that developer's can go on in developing.

But it all links back to talking to people in the language they understand.

Lastly, you showed a lot of techniques and rules.

I'm basically wondering for a lot of people who don't have this exact same experience, but want to basically gain from what you've gone through, what sort of processes or tools could they use at the start of a project to basically solve some of the projects that you showed? Also, are there tools to help identify, at least in the case of CSS, that you could do refactor to pull out common colors-- to basically do an audit where you could make something a bit more maintainable that way? This is a question I get quite a lot.

Unfortunately, I never used any tools to get there myself.

It's just taken time.

I think the simplest thing you can do is have a slight shift in mindset.

So stop seeing yourself as a developer and see yourself as somebody who has to solve problems using development.

So don't think about using tools to spot things.

Use a real common sense approach The thing I mention a lot is the way in which you build a house is very similar to how you build a website.

You need two things in a certain order.

You need to get your foundations laid and build on top of stronger foundations.

So right at the beginning, you need to be looking for any potential got-yas.

And you're looking at the far bigger picture.

I'd rather look at a PSD and think, how can I build that? It's all about the thought process for me-- tools aren't something I particularly use.

I think Nicholas Gallagher tweeted something-- I don't remember when he tweeted it.

But I only saw the tweet recently.

And it said something along the lines of, instead of asking, can I build this? Ask can I maintain this for two years without going insane? And those are the questions you need to ask.

Don't look at something with today in mind.

Look at it with next year in mind.

For me, it's all about shifting in thought processes, and managing people, and expectations.

OK, well, thanks very much, Harry.

This is awesome.

No, thank you.

[APPLAUSE]