[MUSIC]

>> Everyone hear me okay?

It's a quite cozy, intimate room so that

you don't have too much difficulty hearing me.

Okay.

So, so yeah.

As we, as you just heard, my name is Phil Hawksworth and

indeed I work at an agency called IGA based in, in London.

It's actually an American company.

Working for exactly those kinds you, you heard of.

I'm not quite sure how we're gonna run on time.

We've, we, we, a tiny bit late starting.

Should be absolutely fine, but it might be a squeeze for questions.

I'm gonna be around all day anyway.

So, if you have questions, come and grab me.

You can also just shed, shout at me on Twitter.

If you disagree with what I'm saying, if you got questions.

Feel free, you know, bundle into it on Twitter that's absolutely fine.

So the subjects that I have come to talk about is a bit delicate, you know and

you've, you've heard it already but the subject

is I can smell your CMS it reeks frankly.

And they do say that you shouldn't really start

a talk like this by admitting you are nervous.

And, so that makes this slide a little bit silly, but

there are reasons to be anxious about the subject and this presentation.

I've been to FOWA many times in the, in the, in the past.

And looking at the schedule for the next few days, you

know, there's reasons for me to be nervous because there's some great

speakers I really appreciate the fact that you've left Patrick in

the other room to do what I'm sure is a great talk.

But the doors are locked, so you can't get out now.

actually, you know, for fire reasons the doors aren't locked.

Before they bundle me off the stage.

secondly, this is the, the stage two.

This is kind of off in the business track.

Which is something I'm not really used to doing so there's a bit of in this,

in this which is about technical stuff, a bit for you know business reasons as well.

Slightly new ground for me.

But the third reason I'm anxious about this

is, you know, I'm talking about content management systems.

Which is not, necessarily, the most exciting

and exotic subject in the, in the world.

So I'm impressed that you've actually come here at all to hear about that.

Let's have a bit of context for what, exactly, we're gonna talk about.

As, as you heard already, I work at an agency in London.

And so that means working with clients, building things for clients.

And agencies have.

Something of a dilemma and anyone who builds web

products for clients have a bit of a dilemma.

And, you know, you could sometimes describe it as a bit of a problem.

And that problem can be the clients.

Now I should be careful about saying that, as well, because, you know, my

bosses will see that and then, you know, my career will be cut short.

But there's a reason I, I say that.

I was thinking about this a year or so ago.

And I was talking about it on Twitter.

And a friend of mine tweeted this, he said, Phil isn't the root

of the problem with agency work, the fact that it is happening in agencies?

Well, that stings a little bit, but I know what he's talking about.

You know, perhaps there's this This ambition to

build something quickly and then you move on quickly.

Which is obviously not the kind of thing we want to do.

We want to do something that fits really well.

So, you know, you could argue that there's a bit of an agency gap,

a bit of a tension, between what clients expect and what they end up getting.

My job at RGA is very much about trying to find a way to satisfy what a client wants.

But a client will figure out that they've got a

problem that they need solving and they'll come to you.

Often bringing a solution with them and say, we want one of these please.

And actually what you need to do is deliver them what they need, which

is not always the same thing as what they come for in the first place.

And so there's this kind of tension, sometimes, between

people building things for clients and, and the clients themselves.

Something that also, kind of, crops up is there are

a lot of trends that we're seeing at the moment.

There are a lot of, this is all fashion in web design.

And so we're seeing a lot of, a lot of

things kind of emerging, and kind of repeating over time.

It's nice to be able to work as I do, an agency that has a bit of a big platform.

You know, I, I'm lucky that I get to work for big brands.

Often it's kind of stuff that's launched on a big stage and a big audience, as a.

As result.

So I think that anyone working in an agency or

indeed anyone working with the clients that are putting things out

onto the web there's a certain responsibility to do, obviously to

do good work but to do it in a responsible way.

And so this is a tiny diversion but you

know it's,it's something that I care very much about, I'm

a little bit opinionated on some of the styles

and some of the trends that we see popping up.

Does anyone remember [UNKNOWN] site that came out a little while ago?

Couple of heads nodding.

So I tweeted this.

You know again, it was about a year ago now.

Dear web developers of the world, can

we stop this silliness before somebody gets hurt?

And it, I was, and it was a very flippant thing to say.

Especially about someone else's hard work.

But, you know, I was kind of referring to these kind of sites that.

Well, you can see, I, I know we've got fourteen minutes, but

maybe I will skip along to the end of the loading screen.

And it's one of these, you know, single pages, and

it's very typical of campaign work that you see at

the moment This, I think, I kind of refer to

it as scroll jacking, where the, the scrolling doesn't always do.

What you'd expect you know it's doing all kinds of bits and pieces.

I,I love the fact that on this, on this page,

you can see there's this like whites kind of blur

in the middle the kind of starburst there, that, that

white image itself um,that kind of gradient, half a megabyte.

So you know there's, there's lots of [COUGH] kind of inefficiencies and

things in here and I care very deeply about the way I've been

doing things that work well and there's a very good reason for that,

so this is typical of a particular kind of trend at the moment.

We won't spend too long on this.

But there's, there's another example from, you know, a few months ago.

Sadly, not around anymore.

Happily, not around anymore.

And it's never one of these, you scroll the page up and down.

And a tortilla flies around the page, and a

chicken wrap is kind of born before your eyes.

Now, a single page about a chicken wrap.

And, you know, 38 and a quarter megabytes.

405 HTTP requests.

So, for any developers who are in the room.

You know that there's a massive overhead

in performance with that number of HTTP requests.

1.1 minute for the onload event to fire.

So.

I mean, the, the onload isn't necessarily a

good indication of when it's ready to use.

But nonetheless, you know, it took a long time for that page to, to render.

And so this slight diversion ultimately is

my way of saying, you know, performance matters.

We know that performance really matters on the web at the moment.

You probably be familiar with this, this little quote so Greg

Lindon from Amazon, they did a, a bunch of tests, bunch of

experiments on the Amazon homepage adding different bits of latency to the

loading time and, and just kind of did some testing on that.

And they discovered that 100 milliseconds of extra load time.

Impacted their sales, sale, 1% drop in sales on Amazon.com.

That's huge for a tenth of a second.

So these things are really important.

You know, time is money, performance is money.

And so, this is all my kind of way of describing

the fact that front end development has become a serious business.

If we didn't realize that before.

Certainly, I think we all appreciate that now.

And I, I kind of like to think of it as front end engineering.

It's not that long ago that people didn't really about engineering on the front end.

But I'd, I'd suggest that the, the tide has turned.

You know, we, this is a big deal now.

my, my history is, as we heard earlier on, is, as a JavaScript developer.

And, you know back in the, you know late 90's I

used to have this kind of conversation with people in pubs.

I, I don't, that was my opening gambit but people ask what you do.

And you say, I'd say I'm a software engineer.

And they'd say oh yeah, me too.

What language do you, do you work in?

And I'd say JavaScript.

And that had a particular [LAUGH] kind of response from them.

And for me that's just incredibly frustrating.

But I think now we accept that this is important.

JavaScript development, front end development, is

somewhere where a lot of craftsmanship occurs.

And it's, you know, super important.

So, you know, I'm kind of flippant coming out with these kind of things.

But.

There's a, there's a serious point behind this,

somebody might get hurt, it sounds very grandiose

for, you know, a sites about a chicken

sandwich but it's the trends that are,are strange.

I mean, everyone seen this, right?

People seen this.

Again a few people nodding.

So this is the Milwaukee police news which won a Webby last year

beating Gov Uk in that category which drives me a little bit insane.

But it's another one of the, the same thing, you know.

People are, are following this pattern.

Following this trend.

Um,and sorry if it's making you a little bit seasick.

Cuz I was scrolling up and down there.

It sort of helps you to, to scroll to a particular place.

I, I love this carousel.

I mean I can't, I couldn't help to keep on, you know,

getting the police academy stuff to march across the, across the room.

I haven't read any of the details that are in there.

I was just fascinated by it.

I was also really entertained, and again, I'm trying to

get it, get the view pulled in the right place.

I could hear this distant dog barking, you know,

just over the sound of my fan wearing away.

And that, there he is, he's down there somewhere, I think.

Where is he?

He's at, there he is, just behind his leg.

Anyway, doesn't matter.

All kinds of nonsense.

There we get down to the most wanted

section after, you know, if you've stalked it out.

So anyway, it's, it's.

It's a strange trend, and, and, I can see that, that what we're

trying to do there, the designers were trying to make it very kind of

elite and exciting, and, you know, trying to big up the, I'm sure the

very good work that the men and women of the police force there do.

But I think it misses the mark.

I don't think it quite conveys what they want to do.

So, slight diversion.

Let's try and get back on topic, talks a little bit about the

importance of front end development and that the trends are there and performance

but getting more to the nub of it, you know something that's very

important as developers and as customers and

clients is this desire to avoid lock-in.

And we spend a lot of time trying to architect systems that don't lock us

into a particular technology that we'll never be

able to move away from in the future.

A thing that clients often care about is being you

know, trying to avoid being locked into a provider, an agency.

Now I, I don't really want our clients at IGA to be locked into

us because we're the only people who can operate something that we built for them.

I want them to stay with us cuz we've done something great, but.

Clients do care about having the freedom to move on

you know having,having the freedom to be able to manage their

own site in the future, and not being dependent on what

could potentially be an expensive agency who's done that design work.

So obviously you mean can see where I am going with

this, a tactic that they have for trying to dodge that.

Is that they've employed the, the power of you

know one of these fellows the content management system.

And then thankfully all of their problems are solved or not always as it turns out.

So we should perhaps ask ourselves why, why have a CMS?

Well I think it's probably fairly self evident

but it's worth tacking on a tiny bit.

You know, a CMS is there to help reduce the cost of change

and make it easier for us to change the content obviously on the site.

We're trying to minimize dependencies on perhaps a, a

particular body of people or perhaps a particular expensive

or rare skill set to try and enable us

to, to move past needing a developer to do everything.

And more critically, we're trying to empower content authors.

You know, we want to be able to let

people create content and get it published as rapidly

as possible and that's the whole purpose, you know

or this, the common purpose of having a CMS.

So, in my experience there's actually some problems

with that and you know, I kind of, you

can kind of tell I work at an ad agency coming up with terms like the CMS paradox.

But nonetheless, I do find that there is a bit of a paradox there.

That's particularly prevalent in systems that

describe themselves as enterprise level systems.

You know and you hear the term enterprise level a lot and often

it's referring to something that's very large

and expensive and very, very feature rich.

You know,a huge long list of features and no enterprise ready.

There's this kind of notion of them being really, reassuringly expensive.

You know big companies use it, it must be good,

we'll be able to do it but it costs a lot.

I find that reassuringly expensive usually just translates to.

Expensive, but that's, that's by the by.

And so what I've observed is that there's this kind of this

desire for flexibility, and flexibility in the, the, the software that you've got.

But that doesn't actually translate to flexibility in the solution very often.

And it's for a number of reasons chief amongst

them, you know, is this, this kind of choice paralysis.

You, you buy something off the shelf that is

able to cater for every possible outcome in the future.

And the, the UI that then you, you get, and

you put in front of your content authors that you're

trying to empower, is actually so overwhelming that people, people

kind of freeze and don't know how to use it.

And when you've got the ability to change everything

on your website, where on earth do you possibly start.

So, I've observed, in fact I've tried to use many

systems that, you know, just go stale because it's actually a.

You know so overwhelming to try and do it.

And as a result, you know, you kind of get this,this strange situation.

Where the cost of the system is

somehow proportional to the cost of making changes.

Because you have to send people on training courses to use these things.

It's, it's not commons skills that everyone has to, to work on

this very expensive, very difficult to

acquire enterprise level piece of software.

So you have to train them up and they're a bit

overwhelmed by it and so they use it very often and

so they forget and then you need to train them up

again or you need a team of people to do that.

And so it's surprising that something that costs

so much and the desire of it, the aim

of it was to reduce the cost of making

changes actually becomes something that's quite expensive to use.

I'm moving on another real strength to this big enterprise level systems.

This is powerful workflow.

Everyone wants a workflow for managing their content.

But sadly, you know, that is often just completely odds with getting shit done.

Because it, it just gets in the way that the number of times that

people buy something with a huge powerful workflow that they can put in place.

But then don't use it because it's too complex, it's just it's, it's staggering.

And one of the reasons for this is you

know the people who're choosing to put a CMS in

place and involved sometimes in the shopping around are the

people, not people who directly are gonna be using it.

You know they want to empower the, the staff

to be able to,to easily manage the content, and

so they, they look for something that's very powerful

and can have the kind of control that they want.

You know, you'll have different levels of, of authors, you know,

people who can create the content, then people who can review

it, and then finally someone who's got the, you know, the

rubber stamp to be able to say, right, we can publish this.

But you know, the people who end up using

these things often aren't the people who've been specifying it.

You'll, you'll.

You'd be amazed at how often a CMS is operated by

a, you know, a marketing intern, you know, someone on work experience.

Well, just look after the website, cuz that's, you know, that's the easy stuff.

Developers often end up operating these things, because they're so complex

that people go, oh, I don't know how to use it.

Let's go get someone who works in computers to do it.

And so it's kind of strange that the system that's been put in place to.

Avoid the need to use a developer ends up use, having a developer to operate in.

And so in this, in this way, you know, the

first thing that happens when you get a complex system like

this is that, you know, you end up trying to

find ways to subvert the workflow that's been put in place.

You know, everyone gets made to be a super admin because

the one person who's got publishing rights is always off traveling, so.

You know.

Everyone can then do everything so, so why

have the, those features in the first place.

So you know, this is turning into a slight rant from me.

A slight bit of therapy you can say that maybe

I've been scarred by some of this in the past but,

you know, I want to try to get back the

point at hand which this notion of you know, smelly CMSs.

People who maybe work with codes in the room will be

familiar with this, this kind of notion, the notion of code

smell which refers to, like, a symptom in the source code

that perhaps suggests a deeper problem, a darker problem in the code.

Often it'll be something that indicates the very

tight coupling with something further, further in the up

the chain in the software or something that you

want to try and refactor out and, and optimize.

It's inefficient code, the.

That really is, in there is a hack that you want to get rid of.

And what I'm suggesting is that content management

systems, as you may have guessed from the title.

Content management systems emit a smell as well.

And in many cases, you know this, this smell is quite severe.

In fact, I'd describe it as a stink.

so, we should look at some examples of

stink and see exactly what I'm talking about.

Okay.

So [COUGH], everyone's, everyone's familiar with these guys.

You know, these file extensions that you've seen around on the web for years.

Certainly my first, my first homepage Although it was

just, lots of NBA basketball and a hit counter.

You know, it was a, it was a static file, so it had a .html extension.

But you know, over time, it's learned to use

different technologies, perhaps using php for some simple templating.

So the file would end up, you know, the URL would end up with a php extension.

What happens then when you want to start

using a different implementation in the back end.

Maybe you've moved it up to .asp or .jsp or, or take

your pick, you know, of the file extension you will then change.

And this is an example of, you know, the content

being coupled to the technology, which is something that we want

to avoid, and it's something that we've learned to avoid

by careful URL routing and that kind of thing these days.

Tim Burners Lee talks about how cool URLs don't change, and that's really important.

I mean, we could go off on a tangent and talk a little bit about the

importance of stability of URLs, but, but we'll

leave that for now just, just to take

it as read that, that it's a valuable thing to have reliable URLs so you don't

have link rot and kind of, you know, a weakening of the links of the web.

You know, the URL is what makes the web the web.

And so, if you have a system that.

Prescribes a URL structure that you can't control.

That dictates what your URL is gonna be without you being able to control it.

And that's a form of lock in I'm arguing.

Because if you ever want to change the technology in the future, then you're

locked in to that URL structure so, so you're going to have to re-imagine that.

But that's not the only problem with something

that will detect, dictate a URL structure to you.

Sometimes you get very ugly URLs that aren't very efficient.

So, I'm gonna pick on a site and, and show you an example of that.

Now, so burton.com is a, Burton is a, a brand that I, I care for a great deal.

My company didn't work on this project.

We didn't work on this site.

However, I did notice from looking at their URL structure that they

used the same technology that I used on a project at RGA.

It was one that was kind of imposed by the client as is often the way.

And so I was able to see from the URL structure that it was the same thing.

And I'll teach you how to do that yourselves.

so.

So this is the homepage.

and, and the URL for that is global.burton.com.

Before I go on I should, I should mention that this,

this bit of software, it's, a, a CMS as a service.

It's hosted up in the clouds.

And it enables lots of eCommerce features.

It's a very powerful bit of software.

And the Burton.

,the Burton site, you know this this site is a really nice

example of like some responsive design,

it's really, it's really nicely put together.

But it's the URLs that I've kind of got a little bit of a bee in my bonnet about.

So, yeah.

The homepage, global.burton.com.

Now, global is there because, [INAUDIBLE], they have different localized versions.

And each one receives a different sub domain.

Not wild about that, if I'm honest [COUGH].

But, you know, that's more of a taste thing.

But that's, that's not my beef here.

So, the homepage.

Ben.com, it's global ben.com/on/demandware.store/sites-burton_Global-Site/default/Home-Show.

That's, that's the home page URL.

Now, I think we can all agree that this is mental.

This, this is not, no one's going to design a URL structure like this.

To be fair, if you go to burton.com, it will.

Do a a redirect, and this is where you, where you'll end up.

The reason for that is that this bit of software provides

something called vanity URLs, or what I like to call URLs.

And a vanity URL in this world

is something that is, is essentially a redirect.

But they do mention that you're only [COUGH]

really able to implement so many of them before.

The system starts to perform badly, which is just frankly to my mind, absurd.

This is a solved problem.

But this kind of thing is prevalent in

what I describe as enterprise level bits of software.

And it just goes to show that enterprise level doesn't necessarily mean something

which is gonna be powerful and awesome out of the, out of the gate.

So you know I said I'd teach you the

very fine art of choosing, of, of noticing what the

software is here, you'll have to use your eyes

it's on demandware is how it is nicely described here.

So Demandware is, is the bit of software And, you know,

now you know the trick, and you know the structure of these.

I'm sure you'd be able to hack the URLs yourself, no need to use the navigation.

Just edit your, your address bar and easily find

the menswear, the womenswear, and of course, the snowboarding experience.

You know the URL structure now.

Again to be fair.

Demandware has an API as well.

So the way that I would prefer to go.

Is to use that API to enable all the e-Commerce features.

And then build it on something that, you know, I have control over.

I don't have to live with the kind of templating that they enforce.

The kind of euros that they enforce on you.

Or that kind of vanity URL.

So there is a method to do that.

But, but this I would describe as Stink.

This is an example of Stink.

It's something that bleeds through into the experience at the front.

Also, you know, an example of lock in.

But frankly, I just think it's fugly.

It's just not nice to have those kind of URLs.

It's not a nice experience.

URL hygiene is incredibly important you know.

It, it has an impact on the user experience.

It has an impact.

On the information architecture.

I, I talk a lot, you know when we're working on projects at IGA

about URL design being a craft and we try to make URL design a priority.

You know, when you're doing the information architecture of your site.

Understanding how the hierarchy works and mapping that to URLs is, is key.

It kind of helps clarify the thinking and

apart from anything else, designing the URLs gives you

a uniform way of describing all of the

assets as you're going through your, your design process.

So it's really important.

Not everyone cares about URL kind of clarity.

And so I tend to talk about URL stability a little bit.

Which again some people are like, well yeah I don't really care if it changes.

So my kind of top tip for that kind of conversation is

to kind of call on the siren of social media because not everyone

cares if a URL changes, but people do care if there is

a URL to their product page and you change the URL for that.

And then your Facebook likes all vanish, you

know, because its, they're mapped to your URL.

So, so that's, that's a way that I've

sometimes, sometimes got people to care about that.

Moving along.

Performance is another issue and we spoke at the

very beginning about the importance of performance on the web.

And Steve Souders again developers in the room may be familiar with Steve Souders.

Who he's not the guy in the, in the muscle suit, he's the other one.

So he's a, a performance engineer at Google.

He's spent, you know, his career working out ways to make things go fast.

He talks about the, the value of things performing

quickly and going quickly, being fast on the web.

Initially he Spent his time focusing on the back end.

Looking at making sure the server requests were responded to quickly.

Optimizing database structures and that kind of thing.

Getting the content back to the browser as fast as possible.

More recently he's focused on the, on the front end.

He does a lot of talk

about front-end development, front-end engineering cuz there's

a lot of, you know, opportunity there to really make a massive difference.

And so,you know what,my, my background's a front-end developer so I care about the

opportunity to kind of tuning and optimizations

and different tricks in the front end.

To make sure that, you know, you, you're

serving the widest possible audience as fast as possible.

And that's a place where there's just a great deal of craft.

So the foundation that, that sits on, of course is really important.

Which is why I care so much about CMSs, you

know, it's not a sexy subject it's a front end developer.

This is why I care about it.

And so we should look at another real example,

so there may be people who'vee experienced EPiSERVER which

again is a ,a, a product that I've used

on projects in the past is a .net-based CMS solution.

You can tell it's built for the web because

it inexplicably has a lowercase i in its name.

but, the nice thing is, that, you know,

the EPiSERVER site, which you can take a quick

look at here as you'd expect, is built

with EPiSERVER, you know, they built it that way.

So, have a little look at the code and see, see what's.

See what's to see.

And there are a few little bits and pieces in there that

maybe we'd, we'd change, you know, there's, there's not a huge deal.

But, you know, the JavaScript is split into

a few different JavaScripts, so they're in the head.

I'd typically want to concatenate those, push them to the bottom, you know.

Little things like that, performance.

That's not what I'm worried about here.

What I'm worried about is this little

chap that's just creeping into screen down here.

This This form, I don't.

I don't remember writing this in my template, this as I

was building this, ASP net form um,with some hidden, hidden values.

And the thing I don't like is this

view state attribute which, I don't remember writing that.

And what you'll find is that, on this system,

every page has injected into it by the system

that was still going has this, this hash injected

into it, to keep track of the view state.

And the reason for, I mean, no one wants that.

No one's gonna spend time, you know, crafting a beautiful, you know

front end code and then be happy with this getting forced into it.

The reason it's there is for, for various UI hooks.

You know.

This is a classic example of a CMS that allows you

to manage the content in place, in the the front end.

You know, you go to an admin URL.

And then you're managing the same code.

And so, these bits of, of code in the html are there to provide these, these hooks.

This is a classic example, in my mind, of Stink.

You know?

This is something that I didn't put there.

It's sticky fingerprints left in the code, and you don't want it there.

So moving along modularity and flexibility.

You, you're buying a system that's going to be able

to control your site for the, for the foreseeable future.

You want it to be flexible and modularity seems like a good thing.

Naturally, that's goinnna be something that's positive.

Well again, there's.

Space for some caution here.

So let's look at the, the kind of makeup of

a, of a module typical in, in kinda CMS systems.

Very typically you'll have some HTML naturally.

And then, you'll have some kind of

target variable, where your content gets injected.

There'll be CSS along with that to, to style the content.

Sometimes that will be very obtrusive CSS which

is right on the, on the elements themselves.

Sometimes it will be in line, sometimes it

will be linked in from a, from another resource.

Either way, it's kind of bundled in together with that bit of content.

Likewise for JavaScript.

If, if this module has some behavior then the JavaScript may

be kind of, again, obtrusively imposed on the elements or inlined or.

Or, or put there as a file resource.

And then, this whole kind of packages

encapsulated in some own way, major repeatable, so

that you can, you can plunk these things as a module on different, different pages.

And so you get this module, and then you, you

start building your page with, with a load of these modules.

This is, you know, typical of things like

SharePoint And a whole host of other systems.

And I think any, any front end developer in

the room will al-, be ahead of me already.

And just suggest that this kills rendering performance.

You know?

When you're switching backwards and forwards between.

The HTML and then having to go and get JavaScripts and get CSS.

It just really kills the rendering.

It all, it all just blocks up.

Also, it's a main, a maintenance nightmare.

It can be really problem, problematic.

So, even this kind of form of modularity.

Can be an example of stink.

But, more importantly to my mind, you know, with the performance that

it kills, this is the kind of thing that makes Steve Souders cry.

And the, the first rule of front end

development is though shalt not make Souders cry.

You've gotta get that into your head.

Things have to go fast.

Okay.

So that's a bit of performance.

But, you know, there's other aspects as well.

You know, I'm very fortunate in that where

I work, I work with some amazingly talented designers.

They, they don't necessarily love the fact that I include

them in my slides, but, you know, that's their own fault.

People come to a design agency or a web development

agency, I should say, for, for design expertise as well.

You know, the.

The client always has an opinion on design, but, you

know, they are coming to you for, for that design expertise.

And so something which is kind of baffling in, in the CMSs is the fact that Rachel

Andrews put this beautifully, and I think she's doing

a talk later today, she did a workshop yesterday.

So um,she talks often about how a CMS can

give the user the power to ruin their site.

Which is absolutely right, you know.

You give them something and then they say that's great

but I think I will put the sidebar over here today.

Just undoing all that good work.

And a, and a place where that hap, happens

very frequently is in a core feature of many CMSs.

Ones that we all know and love.

It's the WYSIWYG.

So everyone's encountered this.

I'd suggest that WYSIWYG is dangerous.

You know, over time when you're using a WYSIWYG,

you get this kind of attrition of the styles,

until eventually the thing that you're left with bares

no relation to the thing that was designed and crafted.

And built in the first place.

Personally, I feel that WYSIWYG is the enemy, or WYSIWYGITE, if you prefer.

It's easier to remember.

And it's not just that WYSIWYG kind of can produce a slightly unexpected result.

But it's also that it's not necessarily fit for purpose now.

I mean, you think about how.

you're, you're letting someone design how their content will

look in, in a, you know, in a WYSIWYG editor.

How it will look where?

You know, it'll look in the context of what they're looking

at or how about on all of the devices that exist now.

Mark Boulton a couple of days ago.

Published a great post on this, and he suggests, well Wysiwig doesn't

look the same anywhere, everywhere anyway

because different browsers render things differently.

We've got a huge range of devices now.

You know?

How is it gonna look on, on the devices in the future and the

things that you're gonna find under the Christmas tree at the end of the year?

But more importantly to me, I think that WISYWIG

just makes it impossible to protect the design experience.

You know, if someone's come to you to craft something

and to design something, then you, you want to preserve that.

And it also makes it impossible to protect the

mark up, they may protect the code that you've engineered.

This next slide is, is a difficult one for me.

I don't have the guts to do live coding.

I just haven't, haven't got that skill or that courage.

I've just about got enough courage to show you some old code that I wrote.

The caveat is that this was code that I wrote and has now has been WYSIWYGed.

It's from a, a.

A restaurant here in London which I'm not going to name.

again, for fear of getting in trouble.

But it's some codes that I wrote for that site.

And then has, I came to look at some two or three years later.

And so this is that code.

So this is my HTML expertise for you.

Now.

I don't know what the make up of, of developers and, and, and real people.

And [COUGH] I'm a developer myself so I can be allowed to say that.

But if you look at this code there's some,

there's some beauties in here there's some great things.

First of all if we just read the language that's in the link.

You know there's a link here to allow you

to you know add your name to a waiting list.

And the language reads.

Please click here to add join our waiting list.

Which you, already is, okay, I don't know if that completely scans.

But then if we look at the, the text that's in the anchor itself.

It's just a thing of beauty.

You know, we've got two words, click here.

And each one is individually lovingly wrapped in it's own strong element.

And then, again, lovingly wrapped in its own font tag.

Nice to see that old friend.

Showing up again u, and you can see that, right there in the font element.

We've, we've forced it to be black.

You know we've imposed the color on each word individually.

You know, because we mean it, and that, you know overwrites.

The style that we meant, know, emphatically on the anchor itself.

Which, you know, is, is there on the a tag.

It's just, it's just bat shit insane.

Don't get me started on the footnote class on the top,

with a font size of 4 with a space in it.

it's, there's also, and then, there's also like a

Unicode character down here, in the, in the cancellation policy.

Goodness knows how it got, that got in there.

But either way, you know, you can see there's some copy and paste funk going on.

I'll move away from the code but I can't move along without showing you this.

I don't know how everyone else does it, but this is how I

like to add a bit of a margin to the bottom of some content.

You've all been doing it wrong.

I think we can agree that this is stink.

I think this is, this is a classic example of stink and

this is an output of this kind of round tripping that happens.

It happens over here in the WYSIWIG controls, so

this is, this is a very popular JavaScript WYSIWIG control.

With all of the elements turned on, and there's a

couple of buttons in here that I want to call out.

This one, you probably can't see it but does anyone recognize that?

Look up.

Paste from Words yeah.

But the thing that every front end developer loves

to see and thankfully it has got a companion.

It's this button source.

So what happens here is that people go off and

they create their content where their happy with it in

Microsoft Word and they will format it their because they've

got an opinion of exactly how that's going to be structured.

And then they paste it in here, and then it, come

gets a bit buggered up as they, as they do that.

And then they'll like tweak it and nudge it.

And then someone's got to figure out how to fix it.

So they go into the source, and then the tweak it in the source.

And they go, how's this been implemented?

No idea, and they clean it up.

And it kinda goes backwards and forwards in

this kind of, kind of Clash of the Titans.

And this, this kind of loop, this kind of trend ,translation is imperfect.

So you end up with this degradation over time through this kind of circular aspect.

So I kind of like to refer to that as circular stink.

Everything's gotta have a name.

And so the way that I would try and get around that, and avoid that,

is, I'd, you know, I'd much prefer

to be authoring things in something like markdown.

You know?

Markdown's a really nice way of allowing.

Just enough control to put, give meaning to

the content, and put semantic structure into the content,

but without giving full control to the content

author over exactly how something should be laid out.

And so I'm a big proponent of this kind of approach

of structured content and that's the kind of thing you should manage.

A content management system is intended I

think to manage the content, not the design.

When you allow it to manage the design, I

think you get into a little bit of trouble.

So, I'm a big advocate for simplicity and using something like Markdown.

Now you might say, well, that's all well and good, but I've got a complex site.

I've got lots of content.

It's a rich, it's a rich bit of of

content, and I've got lots of people authoring it.

This won't work for us.

So what I'd, my response to that is I'd point you at gov.uk.

I think most people would be familiar with the work of gov.uk, which.

I just think is staggering work, really valuable and they use, they use Markdown.

You know just some credentials for for this,

you know last month they served 23 million uniques.

115 million page views last month.

You know, they, they've been winning awards.

They will, won AD and D Black Pencil.

This is a yellow pencil I, I know that.

They won the Black Pencil.

really, you know, just really doing amazing work.

And the thing that I love is that as I mentioned it's built in Markdown.

Or rather the content is authored in Markdown.

And, and it's big.

You know, as of a few days ago.

Was that 67,000 documents published, written in Markdown,

and this is, this is a valuable one.

You know, more than 1000 authors globally are creating that content.

Those content authors, many of them are civil servants, not developers.

They're not comfortable, you know, with, with development environment.

And so, they, they love using Markdown.

You know, I'm told that.

They, they take a very short amount of time to learn it

and then they love it cuz it does exactly what they ex, expect.

The design principles behind gov.uk by the way are also really worth checking out.

They're on the links to the slides and I'll give you a link later on.

So here I'm kind of describing how constraints can be huge enablers.

You know they get rid of that choice paralysis

and they can really valuable and empowering to the users.

Now not all constraints are enablers, obviously.

This is a constraint I've encountered.

A,a vender of a CMS said this to me and I said this to them.

And then it kind of became clear later we can purchase it as an add on.

The fact that the, the back end, the CMS is so kind of crippled, it won't allow you

to offer something that work well in mobile, I

think, gets us back into this kind of territory.

So again, I'd say that we should be managing

the content and not the design in these systems.

And that's the only way that we can build something.

That's truly future friendly.

That, that works everywhere that we want it to go.

And, as I say, on all of the devices that we know about now.

And all of the devices that are under the

Christmas tree as, as Brad Foster likes to say.

So, you know, simplicity.

Simplicity is the key I'm banging on about simplicity all the time.

And you'll be getting bored of it.

But.

I've had a lot of success with this kind of

conversation where a client has come along and, they said,we'd

like you to build a site and this be on

CMS, this is the first question I always always ask.

This is the second question I always ask because the

answer to the first is, well, everything needs to be dynamic.

We want to be able to control everything.

So really you have to tease into it, what really needs to be done like.

And then they say, Oh, okay this much.

And they say, what really needs to be dynamic?

You'd be amazed at how many sites I've

discovered could be static site with a blog.

Which is not the same thing as a fully content managed site.

Often people say, well why, one day, we might

want to,and you know they fill that sentence in.

With, with all kinds of things.

But you know there's this term from software

engineering YAGNI - you ain't gonna need it.

You know just worry about what we're going to need a bit later on.

Rather assuming, rather than assuming we're gonna need

everything because the complexity goes through the roof.

So again, I'm suggesting that we should ruthlessly pursue simplicity.

It's difficult to do but it, it's really important.

And then if we do that then it means that we can focus on the available skills.

You know, who, who's going to be managing this stuff in the end anyway?

You know, it's, it's not gonna be, you know,

the, the people at the top of the, the list.

Very often it's this guy.

You know, they're, they're going to be using the

CMS to, to manage it anyway so why not.

Capitalize on the fact that HTML skills and kind of good engineering skills

are much more available than the skills in you know, ACME and complex enterprise CMS.

And so, in that way [COUGH] you can actually avoid

lock in, just by using the skills that are available.

More readily anyway.

You know, I like to even push people to consider using no

CMS at all and just make it easy to update the site.

You know, there are so many tools around now that,

you know, give you kind of conventions and patterns, guidance.

I mentioned the, the the gov.uk design principles

and they kind of give you templating as well.

So that you can rapidly generate a new version of the site and easily deploy it.

People may be familiar with Jekyll.

Which is a very nice, very simple lightweight templating engine.

This is actually a bit focused for blogs,

but there's a whole load of static site generators

that give you some conventions and some templating to

generate a static site that you can host anywhere.

Just.

Reduces that, that barrier.

I also really like Perch.

I mentioned Rachel Andrew earlier on, with her quote about the ability to ruin.

Users have the power to ruin their site.

This is, this is the product that she and and Drew [UNKNOWN] have built.

I really like Perch.

Because it gives you a chance to optimize in the front end.

You know?

It's my front end roots coming out again.

You build a static site.

And then you say, okay, these are the pieces.

That I want to be content manageable.

So you wrap those in some PHP tags.

And then that generates for you

a completely decoupled stand-alone admin page

which only just has those bits of content available for you to manage.

So it's incredibly lightweight and flexible.

Not overwhelming for the user.

And there are, of course, there are a host of other things along those lines.

So, you know, moving on.

I'm close to wrapping up.

I'm just about out of time.

You know, this standard waterfall picture of a waterfall process.

But you know, this is a common agency

and you know, development pattern that you'll see.

you know, especially if you're working with a third party or if

you're working with a content management system that comes in at the end.

You know, you go through all of this user experience,

the design, the front end development, then you do this kind

of integration piece at the end on the CMS where

everything just kind of falls away and you get into trouble.

So, I'm out of time, so.

My kind of summary to finish.

I'm kind of calling on everyone to challenge

the introduction of CMS stink and to really care

about what the CMS will do to the

engineering and to the work in the front end.

Know, that's how you can protect the craft that's been put into developing things.

And protect the performance, the performance.

And, you know, keep sites working well.

And this is a way that we can fight for a chance to do really good work on the web.

I've used a bunch of creative commons images in my, in my slide.

So, my thanks there.

There are a few links to things I've referenced.

And a few, like, things to read.

They're all available in the slides.

The slides're up now on Speaker Deck.

And you can get them from //bit.ly/what-a-stinker.

I mentioned earlier on that I'll be around all day.

You can ask me questions right after the session in the break, on Twitter.

Just come and grab me.

Sadly I'm not around tomorrow.

But, please feel free to come and grab me.

Thank for, you know, walking away from the session in there.

I know that Patrick Lowe could.

We've done a great session on touch events so I appreciate you coming here.

Thank you for your time.

>> [SOUND]