Fronteers — vakvereniging voor front-end developers

I can smell your CMS by Phil Hawksworth


[applause] Wow. I really feel like cannon fodder after that particular intro. It's hard to fill those shoes. As Christian said, my name is Phil Hawksworth. I work at an agency in London, a big marketing, branding agency called R/GA. As you'd expect, for someone who works at an agency like that, works on big clients, people like Nike and O2. Big, thundering brands, I'd have some kind of creativity coursing through my veins. I think that's evident in my Twitter handle. A lot of imagination has gone into that. That's just the first example of many, hopefully, of the kind of creativity that I'm going to bring to this section. Congratulations on being here, by the way. Not being at home, hung over in bed, like some of us have been along the way. I'm here to talk about a delicate subject. That's the, "I can smell your content management system. It reeks, frankly."

I'll be honest, I'm a tiny bit anxious talking on this stage. It's very exciting to be here, but I'm anxious because I'm surrounded by some really amazing speakers today. There've been some things that have blown my mind. I'm sure everyone's had lots of moments that they thought being really impressive. So that's hard company to be in. As Christian said, this is the post-lunch dip, so we've all got full bellies. I'm probably not going to doze off. If you couldn't, that would be great. Much appreciated. Also, I'm talking about content management systems. These are not necessarily the most exciting things to bring to a tired group of people to talk about. So if you put all of those things together, it feels a tiny bit like this is the perfect storm of a failure opportunity.

Don't want it to be dull. I don't want it to be the perfect yawn. Yes, that is the kind of pun that you can expect. This is the standard we're operating on here. This is just the second example of the kind of creative juices I have got here. I was talking to a few people in the bar, the last couple of nights, about how to make a talk about content management systems even remotely interesting. They said, "Oh, you're fine. You're in Amsterdam. Just make sure you include lots of cocks." [laughter]

That wasn't the direction I had been going in. I'm going to be completely honest. I looked through my slides. I've got quite a lot of slides. I realized that I haven't got any cocks in there at all, so I went through very quickly and added some. I don't know if that's what everyone was after. Do people recognize the cock on the right? [laughter]

So that is our scary friend. [applause]

I love the fact there's a round of applause for sharing a picture of an awkward teenage boy, but there you go. OK. Let's move on. Fronteers... We're talking a lot about front-end development and things pertaining to the front-end. I'm talking about content management systems. So it's perhaps worth giving you a little bit of context and setting this up a little bit. As you now know I'm working at an agency. How many people here, just a show of hands, work in an agency, large or small, or have clients that they have to service that you're not working on a product? OK. So a smattering. So maybe this is a bit familiar to you. The fact that agencies, I certainly find, have a bit of a dilemma. You could almost say that agencies have a problem that is common to a lot of their projects. That problem is the clients. Now, I should be careful saying that, because it's not the kind of thing that my colleagues and my bosses are particularly keen for me to say.

Working with clients often brings a certain set of challenges. Of course, they come to you and they've got a problem that they want you to solve. They've got an idea in their head of how they want you to do that. They've got this solution in mind. They kind of just want to pay the money and for you to give them what they want. That, sometimes, is at odds with what actually is the best solution to that problem. Sometimes the thing that they want actually isn't exactly what they need. So there's this gap, sometimes, between what they're coming expecting to get and then what you should really be delivering to them. I was musing about this on Twitter recently. An old colleague of mine said this... he said, "The problem with agency work is the fact that it's happening in agencies." That stung a little bit.

I understood what he's talking about. Because it's hard to treat the project you're working on, sometimes, as your baby, in the same way that you would if you were building your own product or your own services. That's something that matters to me a lot. I've come from a background where I was not in the agency world. I like crafting things that are really good citizens of the web and really perform beautifully, and have the finish that you'd expect when you're building your own stuff. So there's that tension there that exists. I personally feel that it is even more the responsibility of people who work at an agency to make sure that they're behaving sensibly when they're building things for the web. Particularly for the developers there, because of a number of reasons. First of all, often very lucky in that we get to work on big brands, things that have got some kind of cachet to them, rightly or wrongly. A big household name. Often, the work you do then is seen by a lot of people. It goes on to a big stage, often accompanied by some kind of big marketing push or TV campaign. It's got a bit of a whiz bang behind it, to drive a lot of people. So there's a large audience there for that. So it really upsets me when I see things that are being done by agencies that are just a little bit irresponsible. Did anyone see this, recently? The new Grolsch

site? I've got to be careful talking about stuff like this. Inevitably, there's going to be someone in the audience who throws things at me, because they worked on it. I was a little bit frustrated... I'll just move along, skip past some of the loading. A bit frustrated to see this. We've all seen this before. I've got to be careful I don't go down a tangent and go into a different talk. This is another one of these single pages, scroll-y, monstrosities that is just...Don't all look at this, by the way, now. This is a 13 megabyte home page. So don't go a hammer the Wi-Fi with this. This is hot on the heels of another site that I've talked about a little in the past. The Beetle site.

Which, again, is a piece of work by a big, heavy weight, expensive agency. You can see how... We're looking at examples of work on the web and then people are taking that and saying, "We could do something similar and then move along." That's the way that things happen very often. That's how we progress forward. We see things, we take some inspiration and we move along. There's definitely not just a technical example, but also creativity. We sometimes learn by example. We see things that give us that kind of inspiration. I'd seen those kinds of examples. They've been talked about a lot. I was being a little bit glib when I was saying, "Can we stop this before somebody gets hurt?" I was really just dismayed to see this.

Did anyone see this? It's the Milwaukee Police News website. Which is another one of these things. There's probably very important content in here, I imagine, squirreled away somewhere behind the police academy line up that we've got there. I'm probably making you feel a little bit queasy with the scrolling up and down. I promise I'm not doing that on purpose. That was me just trying to get the thing to stick in a certain position, but it tries to be helpful, to scroll you to the right place. This carousel is a lot of fun. Obviously looking at stats and seeing this marching thing walk across. If you're using that with audio on, I'm sparing you the audio, you can just about hear the sound of a dog barking, over your fan whirring away. Because there's a dog in that lineup as well, which is barking at you. I just think that this is a really poor example of doing responsible work on the web.

It struck me as a cross between the characters of S.W.A.T. and the characters of Reno 911. I'm sure the men and women of the Milwaukee Police Department do really good work, and I don't think this represents them very well. Apart from the creative direction that these things give, and the way that we see them and learn by example. Of course, we've already mentioned and talked about quite a lot today. The value of viewing source and how that's such an important resource for all of us, as we build things, on the web. So I think that's part of this responsibility that agencies and all of us, indeed, have when we build things on the web is to make sure that we do so in such a way that it moves us forward and imbues good craftsmanship in the code. I'm delighted to hear the word "craft" so many times today and over the last couple of days.

I think that really does describe the kind of work that all of us aspire to in the front-end. Regardless of all of these tensions that there are, working with clients and agencies, one thing that we certainly agree with, with clients, is this desire to avoid lock-in. As I may have said, I'm from an open source background, so I'm keen to avoid all kinds of lock-in. The kind of lock-in that clients are interested in is they don't want to get locked in to a particular agency. They don't want to spend a lot of money with you to then go and build something that they can't operate themselves in the future. That's a reasonable thing. That makes a lot of sense to me. A way that they often try and dodge that, of course, is they ask you to build a site in such a way that they can manage the content themselves, through one of these things. That will solve all of their problems, mostly.

I love that turtle. I think there are some cases where a CMS doesn't solve all of their problems. That often is as a result of something I like to call the CMS paradox. Straight away, another shining example of my branding of terms. The CMS Paradox is really more obvious in large organizations with large, enterprise level software. Big companies like the security of paying a lot money for a platform, because that means it must be good. If you've paid a fortune for it, then there must be a reason that it can be a trusted, expensive piece of kit. I actually think that often that's what that means. Rather than anything else. One of the issues with this CMS Paradox is the flexibility that you have in a content management system. The big, expensive ones allow you to do anything you like. You can control everything. So they've got a great deal of flexibility, but in actual fact, that flexibility that they provide doesn't always translate into having something that is a flexible solution. One of the reasons for that is this choice paralysis that you get when you're given the opportunity to control absolutely anything in the site that you've had delivered. They're very complex things to use.

That leads, often, to this strange kind of relationship between the cost of a system and the cost of making changes to it. If you're having to send your team on training sessions and actually train someone specifically to use this piece of kit, then actually the ability to make changes in there has a cost associated with it. That kind of complexity is in all kinds of places. One of them which are really common is making sure that you've got a very powerful workflow. People who've paid a lot of money for something that's going to manage their dot com site don't want any Tom, Dick or Harry to be making content changes and then pushing those out to real people in the real world. What you find, often, is that there's a very complex layer of authentication and permissions and privileges that people have. Right down from just a content editor, through to somebody who's able to push the big, magic, go-live deploy button, and everything in between.

That's kind of at odds with getting stuff done, because the more layers of control you put in there, the harder it is to manage it all the way through there. Of course, everyone in that process needs to know how to use the system. That kind of thing is very popular, at the point that you're choosing a content management system, choosing a platform for your site to run on. The people at the top like to have the idea of control. Ultimately, these aren't the people who are going to be using it. Often. the content is managed by just someone who has work experience. An intern, and when it gets complicated, we have to bring in a developer after all. As a result, the first thing that happens when you've got all of these layers of authentication is we just end up subverting the system. We've got six different layers of permission but we can't get it done. So make everyone a super-admin and they can do anything they like. So we invest a lot of time, effort and money in these systems that, ultimately, we just walk around.

This is me grumbling a little bit. This is turning into a tiny bit of therapy. This isn't exactly the point of what I wanted to talk about. I was really talking about smell. Later on Rebecca Murphey is going to do a talk about code smell, what that is, and how we can eradicate it. So I don't really need to overlap on that too much. Just suffice to say that, this is gospel because it's from Wikipedia. Code smell is a symptom in the source code that possibly indicates a deeper problem. It's something that's being implemented a little bit chunky that still works, it just works fine, but it's left its dirty footprints there. It's the kind of thing that you want to re-factor out and get it out of your code. So that it performs a little bit better and is a little bit easier to maintain. What I'm suggesting is that content management systems are really big perpetrators of smell. They leave a lot of smell in your code. In fact, I'd go so far as to call it stink. So we should look at some examples of stink, which is an unusual thing to say in front of 500 people. We can all remember the time, in fact, the time is still here, when URLs on the web often would end in a file extension. We've all built things that were just in HTML and that's how they manifested themselves. Of course, we've learned as we've developed and we've become a bit more sophisticated, that this is an example of coupling the content quite closely to the technology that underlines it. If we wanted them to go and change the way that we built our site, so that it's no longer running on ASP and now it's on PHP, should we be changing all of the URLs for this content to do so?

TIMBL tells us that cool URIs don't change.

We should care a bit about URIs and making sure that content has a predictable and stable address. So this automatically is a kind of lock-in. The kind of lock-in that you typically want to avoid. A real world example of something that is a content management system that introduces this kind of smell. This is the website that got launched, not too long ago, for Burton Snowboards. Which is a brand I particularly care for, but it's not something that we did at R/GA. I was able to take a look at this and figure out that they were using the same platform that I'm using with a partner on a project at R/GA. I recognized some of the symptoms here. Now, this is built on an enterprise level content management system that has all kind of e-commerce support. It's a pretty powerful thing and it's one of the first examples I've seen of a nice, responsive web.

It's pretty good as a responsive web approach that has full e-commerce integration as well. The problem with it is that the URL for this... I'm not wild about the fact that it's got global in there for what is, essentially, a web page. It doesn't seem like its good from a localization point of view, but we're not done. The URL for the home page is [laughter and applause]

I'm really glad to hear that I'm not the only person that thinks that is mental. How could that possibly be the address of the home page? Now, in fairness, if you type into your browser, it redirects you to that, because it treats as something it calls a "vanity URL". Or to the rest of us, a URL, because URLs should have some kind of meaning. I've been battling with this platform a little bit myself recently, and discovered that you can have many vanity URLs, but actually only a few, because it starts to impact performance. I just can't quite get my head around that. This is a big, enterprise level platform, but I don't think it's doing the kind of thing that we should want it to do. I mentioned that I was able to figure out, through my super-sleuthery, what platform that was on. Don't know if you were able to spot it, but hidden very subtly in there is the name of the platform. It even actually says, "On Demandware." So it really makes it quite emphatic for you. Of course, this is a lock-in to a platform, when that is part of URLs. Worse than that, it's just fugly.

It's just horrible stuff. You don't want to see it. As we've been talking about, a little bit today already, URL design is a bit of a craft. It's something that's really important. It's something that I, personally, think should be part of the design process. When the information architecture process is going on, pages that are being designed, whether they're wireframes or if they're low fidelity sketches, I think they should be labeled up with the URL, to make it part of something that we design along the way. So really my plea to you, if you're working on anything for a client, where they're not really going to care about it, try and find a way to make this a priority. Care about the URLs. My tip for doing that, in places where, frankly the client doesn't give monkeys about it, is that you can start talking about URL stability and the stability of the address of the page.

You can call on the siren of social media, which is to say that, "If the address of your page changes, you're going to lose you Facebook likes." That's something that people tend to care about, funnily, a little bit more. Moving on to other examples of CMS stink and how it impacts performance. I think most people... Everyone know Steve Sounders, right? Everyone's familiar with Steve Sounders, who's done so much for making tuning and performance of websites a bit of a priority for us. You should probably know, Steve Sounders starting off caring about how he did the tuning at the back end of the systems. [laughter]

Making every... Everyone loves a pantomime horse or cow or thing. He was really working on making sure that the database queries were done in a really fluent way. The request, when it came into the server, was processed as fast as possible. and then return content to the user. Then he discovered that, actually, one of the places that it makes a real difference and you can really optimize where it counts, is the bottleneck at the front end. So he started shifting his attention to the front end a little bit more. That led the way and ignited a better understanding in a lot of us of the kind of tuning and the kind of optimizations that you need to do in the front end to really make it fly and all of the tricks. The kind of things that Marcin was doing with the Google Doodle team. It was just mind-blowing, the things that... They just squeeze every little bit out and push it down the wire, make things work properly in the browser for you. That kind of craftsmanship is really important.

Of course, it sits on top of a foundation because this stuff has to get served from the back end somewhere, and you really want that to be an elegant solution that's going to not get in your way. A little bit of an example of a CMS that I've had a bit of experience with. This is another one of those enterprise level CMS's. This is actually a .NET platform. Just looking at their own site, if we just take a very quick look at the code, they do good work. They eat their own dog food. Nothing particularly horrific to see straight away, but still rocking the transitional doctype, as they might. As we come down the page a little bit and see what's going on... Yeah, maybe they could do some more efficient things with their JavaScript, but hold on a second. What's this form element that we've got here? Line 28. ASP Net form. It's got a load of hidden fields. What Episerver does, as it turns out, is it wraps every page that it serves to the client with a hidden form. Then it sticks in there a hash with a view state in it. This is injected into all of your pages, whether you've asked for it or not. I don't think I want it there. If we've been spending a lot of time with that kind of craftsmanship... [laughter]

That kind of craftsmanship is really important. We've put a lot of care and attention into making sure that our site is going to be as good as it can be in the browser. So we don't want this kind of shite cluttering it up, but his is just a classic example of putting UI hooks into the front end. So that people who are doing the administration of content can then come along and manage things in place. This is classic stink. Now modularity and flexibility are exactly the kind of things you'd expect to see in an enterprise level content management system. They've got to be a good thing. They usually are, but they do sometimes have a little bit of an overhead. So a pattern that I've seen a lot in all kinds of content management systems and platforms of this variety, either from things like the EpiServer platform we looked at or DemandWare, or even places like Drupal you see it as well is... This pattern for a module. The module is logically comprised of the elements you'd expect. There is HTML elements in there. Within there, there is some kind of target, some kind of variable that allows you to inject text into it.

That's often accompanied by some CSS. Often that's inline CSS. Sometimes it's right on the HTML elements themselves. Sometimes it's linked to another CSS resource. Then likewise for JavaScript. Sometimes it's obtrusive JavaScript right there within the HTML elements. Sometimes it's inline. Sometimes it's linked to externally. Then all of these things are encapsulated in some way that makes them repeatable. You can have many instants of them on the page without them crashing. These kinds of things are all wrapped up, and then you have this unit that you can put onto a page. It doesn't take a genius to understand that, when you have a component like this, and then you make up a page with lots and lots of these modules, what you end up with is this soup of HTML and then in-line CSS and then JavaScript. Then more of the same. We go round.

This kills rendering performance. This is the kind of thing that we're all working hard to squeeze out of our development. It's also a maintenance nightmare. Trying to figure out why something's gone awry, when the code is coming from all over the place, often these modules include different versions of the same library. Just to keep things interesting for you. This is another example of stink. It's an example that makes Steve Sounders cry. It's going to upset him, because it's the wrong way to do good performance and we should all be thinking that we don't want to make Steve Sounders cry. Now, a reason that I particularly like working at agencies is working with really amazing designers.

These really are some of the designers I work with, who probably won't be happy that I'm putting it up on stage, but they're incredibly talented. This is an opportunity to work on things that is going to look amazing, because you're working with these talented people is something that's very enticing to me. Indeed, this design expertise is one of the reasons that a client will come to a large agency, or someone who's got that kind of credibility. I think Rachel Andrew put it really nicely at SmashingConf, a few weeks ago, when she was talking along a similar kind of subject. She was saying that CMS's often give users the power to ruin their sites. That's absolutely right.

In this effort to avoid any kind of lock-in, clients often want this control over all of the aspects of the site. So the designs that they've maybe paid hundreds of thousands of dollars for and they've agonized over the position of absolutely everything... "Well, that's fine. But sometimes we want to put the sidebar over there." That kind of thing. A core feature of big enterprise CMS's that help you do that is, of course, this one. The dreaded WYSIWYG. Now, WYSIWYG, I think, is dangerous. Again, it's another example of where it doesn't take a genius to understand that, over time, there's this kind of attrition. Before you know it, your content is being managed out of all recognizability. I really think that, when it comes to looking after the code that we're producing and the quality that we're producing, WYSIWYG is the enemy. Or WYSIWYGITY, if you prefer. [laughter]

It's not just that WYSIWYG gives you an unpredictable outcome very often. It also just means that it's really hard to do good work and then protect it. So once you have some WYSIWYG controls on there, it's so hard to protect the experience that's been designed and crafted really carefully. It's really hard to protect the markup, again, that we've agonized over. I always want to try and eliminate that. I couldn't resist but go and look at an example of a site that I'd worked on, in a former life, at another agency, to see how it's faring, now that it had been sent out, into the wild. I'm not going to name the site, for fear of making myself look silly. It's worth taking a look at this code.

This is code that was in reasonably good shape when we left it. We came back just a few weeks ago to look at this. There is lovely stuff in here. It's great. Just the very first line itself is fantastic. The fact that, somehow, along the way, we've started using the class of "footer" on this paragraph, which doesn't really need to be up there. Then we're forcing it to have a font size of four, so that that space can be sized the right way. That's all we're doing with it. I really like, also, the way that we've got this inline style on the anchor tag, setting the color of it at the top there.

Then every word that's inside that anchor tag, which is just "click here", is individually... Its care and attention to detail. Each word is wrapped in its own strong element and then wrapped in its own font tag. Good to see that old friend. The color forcibly overwritten. To say nothing of the English that's there at the bottom. So that sentence reads, "Please click here to add join our waiting list". There are all kinds of copy and paste shenanigans that have gone on here. I don't think any of us want to see this kind of thing. I'll move along, but I can't help sharing this little gem. [laughter]

What's not to love there? Come on. It's nine lines of just nonsense to make sure that we've got a little bit of padding at the bottom of the section. Why not? I don't think there can be any argument that this is an example of CMS stink. It's found its way into our code that we've crafted. We don't want it there. Now, this kind of stink gets there, often through the kind of round tripping that happens in a WYSIWYG editor. What I mean by that is...

Just looking at this one here, this is having all of the controls of this particular WYSIWYG editor exposed. There are couples there that are really important. There is one which you may just be able to make out at the top there. Which is, "paste from Microsoft Word." Which obviously warms the cockles of every front-end developer. That being the case, when that gets copied and pasted into your site, which introduces all kinds of funk.

You've got to find a way to get that put right. There's another button over here, which is "view source". So you can import stuff from Word and then you can go into the source and fix it, because it's been hosed. The problem is that the piece of code that's doing this translation between the two is going to have to keep going backwards and forwards. It's imperfect and it can't make head or tails of some of the nonsense that's going on in there. That has this iterative process of just making things worse and worse and worse. Something I like to call circular stink. This is probably the last example of my kind of branding expertise. A way that we can get rid of that is by doing away with WYSIWYG as much as possible.

I personally like the use of markdown for this. Markdown has been discussed quite a lot over the last couple of days, as a way of being able to enter structured data, without having to get really into the nitty gritty of the HTML. I think it's the kind of thing that you'd want to be within the grasp of someone that you'd let loose on your content management system. This gives us a way of having a slightly more structured approach to changing the content that's there, and not giving people completely free rein. I'm a big fan of managing the content, rather than the design, because of course that's something that we should be protecting. That's what's been invested in so much.

I know that it gets away from this lock-in idea. This maxim of, "Give a man a fish and he'll eat for a day. Teach a man to fish and he'll eat for a lifetime". That's all well and good, but I think context is really important. Sometimes teaching a man to fish isn't the right solution. If this guy's just hosting a barbecue and you give him research papers on intensive salmon farming, he's not going to end up with 80 fish, he's going to end up with sausages. They're not going to be good sausages. They're going to be the really nasty sausages, made of eyelids and elbows and goodness knows what that is. So I think it's really important to find ways to challenge the introduction of stink into our content management systems and into our front end. In that regard, I find that constraints can actually be real enablers.

Through finding this simplicity, we can avoid the choice paralysis that goes on in the first place. Also, we can just simplify the implementation of this system. And fine tune it and make sure that the users can do just the thing that they need, in a way that's not destructive to us. Not every constraint is a good thing and an enabler. I recently had a conversation with a platform vendor that went like this... I didn't really understand how the back-end could not ever work on a mobile device. Why are the two joined together? It doesn't seem to make any sense to me. It did get followed up with this line as well. The fact that you could buy an add-on for the content management system to make it mobile aware.

We're back into this realm, I think, at this point. I feel that, if we can manage the content separately to managing the design and give content editors ways to manipulate just the content there. in ways that they can understand, it means that we can build things out that are a little bit more future-friendly. In ways that aren't tightly coupled between the content management system and the code in the front-end. So that we can cater for different devices, and use the kind of techniques that we're slowly learning as we go, when new devices are being enabled along the way. It's easier to say than to do.

Not every situation is going to allow you to say, "Well, just simplify the CMS. You don't need something huge". People like "The Guardian", for instance, aren't going to have a super simple CMS. The Guardian has been working on their content management system, their platform, for many years, and it's not done. It's a living bit of software. So the expectation that maybe a client could come to an agency and say, "In six months we'd like you to give us this platform and that will do everything we need", is kind of a mismatch. I've been fortunate in having some success in the past with challenging the customer.

Challenging the client about what really needs to be dynamic, and having that conversation is a really important step to making things simpler. You don't get there straight away. You ask once... They say, "Well, it all needs to be dynamic at some point". "But what really needs to be dynamic?" "This. The contact us needs to change and then this bit." "What really needs to be dynamic?" They break down and say, "Everything's fine, but we just need a new site." It's almost like that moment in Good Will Hunting, where Robin Williams and Matt Damon are having that conversation.

You say, "Son, it's not your fault. It's not your fault." Finally he breaks down, "I just need a blog". So one of the ways that that gets responded to, often is, "Yeah, but one day we might need to do XY and Z". Probably, people are familiar with this term, "YAGNI, You Ain't Gonna Need It". We go to great lengths to try and make sure that things are going to be flexible and going to work for everything that we can imagine in the future. Often, that just gets in the way of getting things done and getting things out there. And getting them into production. So really challenging exactly what is essential, versus what is something that is nice to have, is an important step.

I'm all about ruthlessly pursuing this simplicity. Since things can be a little bit complex, one of the things that I've seen a lot is that the person responsible for managing content ends up being a developer. Developers... I don't think many of us really want to spend our time in a big enterprise content management system, turning buttons on and off, and cleaning up other people's content entry. Given that developers are often involved there, it begs the question for me. Why don't we just use the available skills? If, out of this scenario, this is the person doing the work, then, frankly, their HTML skills are much more available then skills in a given content management system.

Development processes are much more widespread and available and have a bigger pool of people to hire from than knowledge of a particular content management system. I think, actually, that turns out to be a better way of avoiding lock-in, and a way that we should really make the case to clients and state that we should maybe look at something that's a bit simpler than this big, exotic CMS. There are also examples of doing things without any kind of CMS that still give you that kind of flexibility. I'm not talking about just writing everything by hand. There are things out there that provide you templating engines and give you patterns to use and conventions to follow.

This is a particularly good one. I guess a lot of people have seen this. Jekyll is just a bit of Ruby that lets you write your content and use some templating logic. It just spits out static HTML. Actually, a lot of sites that I've worked on could really have just made use of this, and wouldn't have needed to pay any money at all for a content management system. Naturally, that's not suitable for everyone. You'd be surprised how many big brands have built things that need occasional revision of content, but they don't need everyone to be able to tweak things and turn them on and off.

This solution, not only would it be free, in terms of licensing. Frankly, you could host it on GitHub, very simple. Another example of something that I really like is Perch. Perch pitches itself as being a really small CMS. It's really simple. The thing that I love about it most is that it focuses on the front end. So you build out your content the way you want it to behave and the way you want it to exist in the browser. Then you identify the bits of content that you want to allow to be content manageable and you wrap those in a particular tag. That goes off and it creates the admin behind it, in a different view of the site.

It's a really powerful thing that is actually very simple to use. I asked Drew McLellan, who is one of the founders, with Rachel Andrew, in fact, behind that product... I was asking them if it could be used just to spit out static HTML files, because I'm a bit of a fan of going really simple. If you've got sites that get a lot of traffic, then static files perform really nicely. He said, "Well, it doesn't work that way at the moment, but you could just stick Varnish in front of it and it scales up really nicely". I think that is a little bit of a nicer way of doing things, then the approach that is quite common in agencies. Agencies often follow a really waterfall process.

Very often, a project will follow this course of there being user experience design. Then some visual design. Then the front-end development happens. Then there's this dreaded integration with a platform that you have to work with. There are problems all the way down there. As we've been talking about for the last couple of days, waterfall is problematic. It's really hard, in agencies, not to work in a waterfall kind of way, because clients want to know what they're going to get, when they're going to get it and how much it's going to cost. So an agile approach is actually really difficult to do well. We have to find places where we can borrow from agile and do them just in little islands sometimes. This bottom stage, this front-end development integration phase, is just where a lot of the problems come in. That's where all of our good work, where we've really tried to craft something beautifully, gets stunk up by the CMS.

To finish, I'm really just hoping that I can engage you in this battle to challenge the introduction of content management system stink and think a lot about when you're starting a new project that has a CMS involved, or if you're working with a client to choose a platform. Hold some of this stuff up as things that you want to care for, and try to battle the CMS stink because that's the only way that you can fight for the opportunity build things out in the way that you really want them to exist. So you can do good work on the web. With that, that's it for me. Thanks to the people I've stolen work from and also a few links on here. I'll put these slides up on Slide Share shortly after this session. Thank you very much. [applause]

Well done.

Thank you.

The fun of .NET content management systems. I left that world years ago. Actually, it's quite fun, because the view state is just a setting in .NET that has been removed for four years. They just have a really old install on their own website. That's just one of the most stupid things I've ever seen. And every website was like three megs, no matter how much content you had on it. Just incredible.

It's the kind of thing that they always expect we could tune out and there must be some way to turn it off. But that screen grab was from a couple of days ago.

It's a classic that these content management systems don't upgrade their own websites, only the ones that they do for clients. Not realizing that they're shooting themselves in the foot to any developer that wants to start working for them.

But that's true of so many things. Agency websites often are notoriously terrible, because it's the last thing to get real love and attention in an agency, quite often. Because we're working on things for the client and it's the thing that we will fix up. It's like the builder's house is the one that always needs the most building work.

Do you think, also, that we are shooting ourselves in the foot as developers a bit? I think there was an article in 2001, 2002 or something that actually said web developers should not be like car engineers. When you go to get your car repaired, the guy would open the hood, would go in there and swear loudly and very annoyed about the last guy that repaired your last car that was a total idiot. We keep doing the same things. We get hired at a new job and are first job is normally to... Oh, I want to rewrite all of that. I cannot use any of the other stuff. It's no wonder that a client wants to have a What You See Is What You Get editor. Because they don't want to understand HTML. They don't want to rely on a developer that might leave in two months time, and the next guy starts from scratch again.

That's a good point. I think it is in our DNA, as developers, to always... I think we talked about it earlier on... Always expect that you're the people that can do the best job. You know best. We all have different ways of approaching things. So when you arrive on a project that's been around for a while, often the first instinct is to go, "its wrong". But often it's a case of, you just need to learn what's there. I don't know if introducing WYSIWYG is the best way to avoid that. Because WYSIWYG has to live in concert with other things.

But it's the lifeline that customers then want. Like, "I don't want to understand this web stuff. It's all so really hard". Which it isn't. "That's why I want to have a What You See Is What You Get editor, so I'm not dependent". Our job would be to make WYSIWYG editors unnecessary, by giving people proper documentation and these kinds of things.

I totally agree. I think the barrier to entry on the management system that we've got, often, is much higher than just going off and writing code in the first place. So the person that actually would be responsible for making those changes usually isn't the person who's written the content in the first place. It gets handed on for someone else. Often the first thing that they've got to do is they've got to learn the system and learn how it works. WYSIWYG is one thing, but it actually lives within a larger environment that they need to learn first. Often they probably would have been done and finished and onto the next thing if it was just some HTML, and that, often, can be the way. With some good version control, that can be a way to avoid having to use these systems in the first place.

What about the things that good CMS, the three or four that are out there, actually are good at, like localization, internationalization and changing different branding and blueprinting? That's not as easy in these hard-coded versions.

Agreed. I don't know if... That's definitely a good use-case for content management systems. That really is more a question of applying different templates in different cases. Having a need for localization of content isn't quite the same thing as having the need for a system where you can regularly and readily maintain the content and change the content that's in there. Just because it's something that's localized and across lots of languages doesn't mean that it needs to change very often. I think, in many ways, we're employing a system that solves one problem to fix something completely different. They're addressing different issues.

While that is a common use-case for them, it's something that is a bit more difficult to do with just some simple templating. I don't know if those are the most efficient or cost-effective ways of solving those problems. I'd, for instance, much rather use a good MVC framework for fixing some of those things sometimes, and applying different templates for different cases. As opposed to having a content management system that you've got to learn how to use before you can say the right thing in French.

Is it just a case of waiting for the old school product managers and project managers to die out, that really drank the Kool-Aid in the 80's that one system can do everything for them, until the end of the world? I honestly don't know. I have this argument a lot. I think we just need to demonstrate it in a few high profile cases. There's a certain amount of momentum that happens when a big site for a big brand, that's built on a big, expensive platform. That's the way it's accepted that it's done. I think we need to have one or two examples where a really low-fi, much more efficient solution is being used, that really gets some notoriety, to then demonstrate that it can be done.

Isn't the problem that big brands, they don't want to talk about any of the internals? So even if this is a success story, we wouldn't be allowed to talk about that they used templating for this...

Yes. Maybe that's true. I don't know. I think maybe we'll notice a little bit by not seeing any stink. It'll be notable by its absence.

I find it incredibly annoying, as a web developer, to basically never have a portfolio. When you work at an agency, you do something cool, you're really impressed with it and then you leave the company and two years later you see stuff like you see there. So burning DVDs and CDs with my stuff was basically saving me so many times.

Absolutely. I had the same exact thing when I started out. I was building software that went into banks. That doesn't exist anywhere else. I could never really point to it. It's often the way with building things like this that you don't get to point to it later on. Agencies are difficult like that sometimes.

Do you think that the next thing will be like libraries and things that people use? We have CMS putting things in, but we also have people that then like... I've had clients where I made a website, a bit of JavaScript and a year later I found like three Dojo widgets, two jQuery things and a YUI thing in there, because they liked the carousel in each of them.

Yeah, you see that a lot. It's the same example as you were talking about earlier on. A new team comes on and they've got another way of doing it. And don't often clean up behind them. You slowly add more layers to this thing. I think that happens a lot. There are projects that I've worked on, some at previous places, some where I am now, that frankly, I'd love the chance to go and re-factor them. You don't often get a chance, when you're working at an agency, to go and re-factor things. Make them as beautiful as you wanted the first time around. It's that tension between just hitting the deadline and then getting it out there.

Yeah. Fix-it-later is just a myth. I've never seen that happening. As a developer, you sometimes have to push back and... Like, "No, I need another week".

But do you think fix-it-later can happen when you're working on a product, working on your own product? Or do you think it just doesn't happen anywhere? On your own product, without any other product owners? Maybe. Inside Yahoo, where the same product was for five years, it was always like, "Get it out there", and then we fix the next bit rather than the last one.

I guess there's also a difference between, "We'll fix it later", and "We'll add this capability later". If you start from the lowest common denominator and there's only one thing you need to change, then enable that. You'll be working quite happily, until you discover you have another need. Then you can layer that on. I think there's a certain class of sites where that could be really effective, but then, of course, there's another entirely different tier of sites where that just wouldn't work at all. I think it's knowing what the right approach is, and where the context is appropriate.

I think a very important part that you did was just show bad code of somebody who did something after you, and explain what happened. Like that this thing came from a What You See Is What You Get editor, or from a framework. I think we're far too good in pointing out mistakes in other websites by looking just as the source code, without understanding where that mess came from.

Right. Of course, no one wrote that nonsense. The last person, probably, to touch that code might have been me. So, I'm disappointed at how my child has grown.

With that, thank you very much.

Thanks very much. [applause]

Post a comment