 Good afternoon folks. We're gonna talk today or I'm gonna talk today, and then you're gonna talk back to me. Hopefully about static mock-ups about the absurdity of using images to design websites. So my name is Mark Conroy. I'm a lead front-end developer with a company called AnarTech where the largest Drupal agency in Ireland, and at the moment we have the accolade of WebAgency of the Year. At Drupal Conalash we won WebAgency of the Year and the best website in Ireland and most beautiful website in Ireland and lots of lots of nice awards. So we think we're kind of good at what we do. I'm also the chairperson of Drupal Ireland. So if you came to Drupal Conalash year and had a good time you might come along to Drupal camp next month. I'm an admin on the Drupal twig.slack.com. The Drupal twig Slack is the kind of the front end Drupal, the front end Drupal Slack. If you're looking for front-end knowledge, it's a great great great resource. It's a, you know, you ask a question and usually within five minutes somebody will at least tease out the question a bit with you if you can't get an answer. One problem we do have with being Slack is it's the free plan and we lose lots of knowledge as well. So if you do join it and you ask a question and you get an answer, please write a blog post so we can kind of archive the knowledge somewhere. I'm also working on the out of the box initiative. So I'm part of the team implementing the team for the new team for Drupal core as part of out of the box and I'm Mark Conroy on Twitter. So today here's what we're going to look at. A quick kind of overview of you know the problem, what goes wrong when we use static mock-ups and why should we not use Photoshop and why should we not use InVision and why should we not use Sketch and things like that? Then we look at what is the solution. So, you know, I'm happy to rant and complain a lot about Photoshop, but we might have some sort of a solution or some sort of thoughts about how we can solve the problem. And after that then we will look kind of a bit more detail at Atomic Design and specifically at Pattern Lab and how Pattern Lab integrates with Drupal. So this is me. This is the day we won a nice contract and I'm fairly happy. My dog is, dogs are dogs I guess, but I do the developer thing then. We win the contract, we're going to build a new website and I become a code monkey and I start writing my code. So this is a me writing the code and being productive and thinking that yeah, we're doing it right. But the contracts often come with the kind of contracts we work on on fairly big contracts in two stages. Sort of could be a tender for some company to design a website and a tender for some company to build a website. So often we win the contract to build a website. We don't have a large design team. So we often don't win the design aspect of it. So this happens. We meet the client and they tell us they've got designers and it's a great design agency and often it is and they've won lots of awards and they tell us yeah, we'll deliver the PSDs, the Photoshop documents. Oh god, PDFs or you know, this kind of crap. And I get frustrated, but eventually after some thinking about that I realized hang on, hang on, hang on, we can fix this. So I had a Eureka moment. So we're going to try to solve it. Here's a quick little exercise. I'm going to guess this sounds familiar to certainly the front-end developers here. The back-enders might not realize the pain we go through. So this sounds familiar, let me guess. You get some designs. Is this showing up here? And the client signs off designs and says yep, this is exactly what we want. The spacing is right. The line height is right. Imagery is correct. Everything is on brand. And then you build a website based on these designs. And the website that you build, it looks quite like the designs. It's not exactly like the designs, but it's quite like them. I mean from the developer point of view, it's exactly like the designs except the designer used five words in every single blog post title. And yours doesn't look exactly like the designs because you have one blog post that has six words in the title and one that has four. And the client can't understand why different words look different. And these are real problems. We can laugh, but these things happen. So that's not the client's fault. That this isn't exactly as it should be. And it's not your fault that it's not exactly as it should be. You've built what you were asked to build in the manner that you're asked to build it. But you know, it's I suppose in terms of diversity and inclusion, I shouldn't say it's someone's fault. It's something's fault. I'm gonna say it's someone's fault. So someone's someone has made a cock up here and I think that is the person who used Photoshop. So here's the problem we have. So websites in the real world use real content. An example of this becoming an actual real issue for a client of ours recently, we're working with, the designers used five words in the title of every single news view. Lorm, Ibsen, Dollar, Sit, Amit. Okay, every news post, every press release, every person's name was these five words. And I said what happens if there's more than five words in a news post? We will look at their present content. See this news post here. This has 26 words in the title. This one here has 17. So, you know, they're long kind of government things where you have to mention all the ministers and the counselors and that in the titles. So the designer said we're gonna train the client how to write shorter titles. And I said okay, here's the client's name. Vienna, city and county council. Okay, the client's name alone has five words. Now, the data website goes live. You're gonna tell me, you're gonna train them through right titles that are less than five words when the first news post they're going to write is Vienna, city and county council launches new website. So we've got a problem when we start working with real content, we've got a problem and Photoshop can't really solve that unless the designers are willing to copy and paste in all the different titles and lens and things like that. The next problem we've got then is that these are these are static images. They can't be tested on proper devices. They can't be like you send them mobile design to your client. You can be sure to open up that in a desktop and have a look. Oh, this is going to look great on the phone on my desktop. You send them desktop designs and they're traveling at the time. So they open it up on an iPad and say oh, yeah, my desktop design is going to look great on an iPad. On top of that then, if they design them for 1200 pixels wide, they're only seeing just one representation. They're seeing exactly what the website will look like when it's 1200 pixels wide, not when you're on a 22 inch monitor, not when you're on a 50 inch monitor, not when you're on your watch. You know, not when you're opening your fridge and whatever incident of things kind of are connected. So it's basically, you know, to make it short, what you're doing in effect is you're showing your client that this is the most effective way that I can make sure that you will never have the website that you think you're having. I actually don't know who Steven Hay is. I found a file with some notes for this presentation and I don't know where I got that quote from. So thank you, Steven, if you're here or wherever you got it from. So here's two examples of Photoshop layers. This was from a blog post we wrote called Design Wars. If you see the one on the bottom left, it's called Dock One. It's a Microsoft Outputs.DOC for Dock files with lowercase letters. So somebody actually had to go to that and edit that and decided I would prefer to call this Dock One with capital letters. We've got subheading two and we've got layer 29. Now how I'm supposed to find the correct things I want to find in a timely manner, I don't know. So we end up going over time and we end up going over budget. This one here is from one of the best design agencies in Ireland. We do a lot of work with them and they are absolutely fantastic and we really like working with them. But their layers are called or their groups are called group and inside group we've got group. And below that we have group and below that we have group and below that we have group. You can see where this is going. So this doesn't lead to a nice workflow. Now we've had some meetings with them and we're talking about how do we make handover better and how can we make things more enjoyable. And that's great. So you can massage your designers somewhat. So basically when we're talking Photoshop, we're saying the function of Photoshop is in the name, photo. It's an image manipulation tool. You know it's not a design tool. It's for adding lens flare to buttons when you click them that you can't implement when you're a front-end developer. It's for cropping out the sunshine or cropping out electrical poles on a nice view. It's not for designing websites. It just happens to be used for designing websites. So we need to move away from that. One very commenting that happens with me is I'm working on a Mac and my Mac system renders fonts in a certain way. Photoshop renders fonts in a certain way. Chrome renders fonts in a certain way. Safari renders fonts in a certain way. They all look fairly similar but there are slight differences. Photoshop renders fonts in, I don't know, some other mental way that I can't work out. So again, you get the designs and they look great because you're looking at a photograph. Then you implement it and your client says, hang on, this is supposed to be open sands, size 72, font weight, bold, line height, 34 pixels. And I opened my inspector and I showed him this is exactly what is in the designs and this is exactly what I've implemented. I'm not a very good developer so I have to make sure I implement what I'm given so you can't complain about it. And this is what happens. So the fonts get rendered differently. Again, you're not handing over to the client what they think they're getting. Your pixel-perfect design can't be pixel-perfect for these kind of reasons. So here's three reasons that we don't use Photoshop or we don't like Photoshop. Number one is that it's not responsive. So what you're going to end up getting is lots of designs for desktop. Again, with the client we had the recent, as mentioned earlier on, we got 46 desktop designs. 52% of their traffic comes on mobile. We got six mobile designs. We got zero tablet designs. So as a front-end developer, your job then is to, okay, I can implement a mobile. I can implement a desktop version. And I don't know what happens on tablet. Do we just stretch the images more and more and more? And that doesn't break layout, but it doesn't look great. So you get the exact same on tablet as you get on mobile. Or do we do something else? Do we design ourselves and say, okay, well, if there's three items in a grid on desktop and one on mobile, how about we put in two on tablet? And that's great, but there's three, because they want to show nine results in their view. So then when we put in two on a row on tablets, we get to end up with one extra one at the bottom. So we're not getting tablet designs. They're designed then for a specific browser size. As I mentioned a minute ago, if they're designed at 1200 pixels, you'll only see them at 1200 pixels. And often not see the big bleed of what happens to the hero image when the monitor is larger. So designers are kind of designing these great experiences. They're about user experience and user interaction and being creative, I guess. The user is just one functionality. You know, the design of a drop-down, and it looks great, and it's got subtle hover effects. But most of our work is with government. We've got to make sure we pass WCAG 2.0. So the government signs off a design, but the drop-downs aren't accessible anymore. So we've got those innovations. So you don't see them popping up in Photoshop. They're not a problem. Number two, I think, is that designs are zoomed out. So you send your design to a client, and it's maybe, we'll say, 4000 pixels high. What the client ends up doing is zooming out, because they want to get a look at the whole overall web page. Now, the point of this, I don't know, because this is one of our own designs in Photoshop. And they zoom out completely. Their font is rendering at about one pixel. They can't read it. No one's going to actually look at a website like this. But for whatever reason, they want to zoom out. And the same with the mobile designs. You can see this tiny, tiny little mobile screen, and it's going way down the page. So what you should be able to see here is only the header and that hero image, because that's about what you're going to be able to see on a desktop or on a laptop. And my favorite reason for not using something like Photoshop is that it's too easy to create crazy ideas. So this is three examples. The client is anonymized because we like winning contracts. But these are three actual requests we got from clients, not necessarily when I was working with Anarchek, when I was working self-employed. So the first one was that we don't want to maintain an about us page. Instead, we want that when you click on the about us page, it will open up Wikipedia page in a color box. But Wikipedia has to be styled like our website, our color scheme, because we can't have Wikipedia breaking our brand guidelines. So if that was Drupal, when you click on the Drupal about us page, this is the Wikipedia Drupal article, and we played around with it yesterday. That's very easy to do in Photoshop. You can do that no problem, and you can hand it to a designer, to the developers. But no matter how much you do that in Photoshop, I still cannot change the CSS of Wikipedia on the fly. Another reason, another example, a client came to me and said, there's a website in Ireland called Dundeele. It's basically like eBay. It's an Irish version of that. And he said, I don't like the look of my website. He came to me first time. He has an e-commerce website. And I said, no, you don't. I built your website. There's no e-commerce. Yesterday, I have an e-commerce website, and he showed me basically eBay, where he sells his products. That's kind of clever. Okay, you've got an e-commerce website. Yes, Mark, I do, but I don't like the look of my products on it. All of the things on Dundeele, their branding is red and brown, but my color scheme is blue and yellow. So can you change the look of Dundeele for me? So if we're selling Drupals again, yeah, no problem at all. Give me Photoshop, and we can do that. But since we're, we can't, again, same as Wikipedia, we can't edit the HTML to see as that's the JavaScript. And no amount of explaining to this client could get them to understand that I cannot change Dundeele. I cannot change eBay just because your designer gave you a Photoshop document. We get the lens flare issue. When you click on this button, it gets lens flare. And that's fine if you want to put in, say, a transparent PNG, you can say that, okay, on clicker, on hover, on focus, that there's an after pseudo element. But we did have a client who says we have this hero image, and here's what the hero image has to look like. And all hero images have to look like this as well. And they have to have alpha transparency layer on top. It must have a gradient on top. It must have a desaturation filter. It then must recolorize the image with a kind of a blue hue to fit our brand guidelines. And we said, why can't you just upload the image? That's in the Photoshop document. And they thought, we might want to change it sometime. So we said, okay, well, for the first instance, until you do want to change it, can we upload that? No, no, we've got to get this done properly. We've got to get this done with CSS. So we went back to the designers and said, do you have any idea how this might be done in CSS or how we might be able to implement this? This is looking a bit tricky. And they said, no, that's not possible with CSS. Okay. Where do we go from here? So it got to the stage that the client had no choice but to upload the image. So again, if you want to add some lens there when you click on Try Drupal, this is what you might get. And again, this is simple in Photoshop, but this is very difficult in code. So what's better? Well, SketchApp is better. I'm not going to go through SketchApp because it's a fantastic tool. It's great for quick mock-ups. It's great for UI, creating interfaces and things like that. We use this internally for our designs, but then they get transferred to me to pattern lab and we can send the URL to our clients. But ultimately, it fails for the same reasons. You're still sending static mock-ups. You're still just really sending an image to your client. There's a man called Clark. Clark Valberg, I think his name is. Does anyone happen to know who he is? Okay, I'm kind of... Is he here? He's going to turn up some of my presentations sometime. Clark doesn't like InVision. Anyone not like InVision? Brilliant. Thank you. Thank you. Thank you. Welcome to my party. So Clark is the CEO of InVision. And I had a tweet a while back to say, yes, InVision, and I'm sure it's going to be a shit experience that you're loading. And Clark replied to me, unfortunately, you're correct, sir. I'm all over it. Expect significant improvements soon. So fair play. At least the CEO of InVision knows that InVision is not a good tool. And then they contacted me for a couple of weeks to see if they could schedule an interview or a chat to discuss my pain points with InVision, which I declined because I've seen no reason to speak to them unless they have a big fat delete button and feel like doing that to the master repo of InVision. So then a couple of weeks ago, they launched some new tool that does some inspect thing in InVision which is basically sketch on line or something like that. I don't really see the point of it, but I had to sign up for it because another design agency asked us, will you try this tool with us? See what it's like. So I signed up and I got an email from InVision. I thought, okay, you're developing what you say is the best design tool in the world. You can't make a mobile email. So what's the solution? That's enough of the complaints. What's the solution? Well, basically, the web was founded on HTML, CSS, and JavaScript. And at some stage, we're going to have to write HTML and CSS and JavaScript. Whether that's in Drupal and the renderer pops it out for us or we write it using something like pattern lab or similar cases, no of whatever style generator we're going to use. But at some stage, you have to write CSS, JavaScript, and HTML. So why not just do that at the beginning? Take the pain out of it. Instead of sending a PSD to our clients, send them a URL. Every time you want to change and you want something different color or whatever, they can just refresh the URL and they have it straight away. And they have that there then as a living document for themselves. So Brad Frost, I'm sure you've heard of Brad Frost. He's the founder of the kind of idea of atomic design. He had a great blog post a while back about building a website for some politician in America. And he got the whole thing done in one week. And I thought this was a very good point from it, that designing in the browser allows you to get closer to the final product which faster. So we're not sending our clients this kind of approximation of what the website will look like. We think it will be something along these lines. We're actually saying to them, this is what the website will look like. Here it is with long titles and short titles. Here it is when you're logged in, here it is when you're not logged in. Here's the different views we have for different content types. And they can see these then in real time and on real devices. So if you send a link to the designs and your client happens to open it on a phone, well, he's going to see what the website's going to look like on a phone. And if he happens to open it in a laptop, he's going to see what it looks like on a desktop. So we've got five stages really to go through. Number one, discovery. This is finding out what the client wants. This is great for the client that's all the different types of unicorns that exist and what they want. And then we go to number two, research, which is where the real magic happens. When we actually talk to some users and see what you actually need, what problems are we trying to solve? And there's quite a difference between what the client wants and what you need. So again, a lot of our work with the government, we need a big picture of the minister on the front page of the website. Nobody needs to see a picture of the minister on the front page of the website, but the minister wants to get elected next election. And that's why he has to go on the front page, not because he's adding any value to the front page. What the users need on the front page is a big search box. Then we can do some rapid prototyping. It depends. The papers posted notes, pencils, whatever you need, and gets your information architecture and things worked out. And then there's more rapid prototyping and something like maybe Balsamic or Sketch or Photoshop if you must. And that can get the design going. And I don't mind designers using these tools. My problem is when we send that on to the client. So you get the design going and you get a component finished. So you know what the header is going to look like. But when you know that, tell me and I'll write the HTML, CSS and JavaScript and we'll have a header designed and the client can sign off the header from a browser, not from an image that we're going to send to them. So we agree on the different components then and we can team them up. And we use an atomic design approach. I'm going to guess that at this stage people have a fair idea so I'll kind of skip through this but it's basically that we go through what we call atoms, molecules, organisms, templates and pages. So an atom is something that's the smallest unit of HTML like an input field or a button. And a molecule is when you get more than one atom and put those together. So you get the input field and you get the button you put those together and that becomes a search block. An organism then is when you get a couple of molecules and put those together. So you get the search block and you get the branding block and you get a menu and you put those together that makes a header. Then you get a template. So you get a header and you get a footer and you get a main section and you get a sidebar and that makes a template. And then the page is the actual colors and the fonts and the real content going into it. So here's what we do then. We have pattern lab. The version we use is the version created by phase two. Simply because that was the first version. I think that was released. I'm going to start looking at emulsify and some of the other versions as well to see what we can learn from them. So we create all the components in pattern lab. We then map these one to one from the Drupal team so we could say that the node hyphen hyphen teaser.html.twig maps to the teaser.twig inside pattern lab. And then the client will see these designs eventually and when they see them and they sign off them and say these look great, they're actually signing off then on the front end. We've got the front end built. So the design process is actually the Drupal teaming process. So rather than going through discovery, back end, site building, design, then front end, we get the QA for the front end done up front. And when we're finished, they've got two things. Number one, the team is signed off. So we're working quicker than we would be working with Photoshop. And number two, they've got themselves a style guide. So we don't even ask them, do you want a style guide? How much would a style guide cost? Well, maybe 10,000 euros for three weeks of work or something like that. We don't even bother asking your clients, do you want style guide? Because when you use pattern lab, we can't not give them a style guide. That's just, that's what pattern lab does. It automatically builds it for us. Okay, so here's an example then. Each of these examples I'll go through the things on the top. This pattern lab, the things on the bottom is Drupal. So this is just a very simple one of a menu and I put in five menu items, home, about us, our work, blog, and contact, and gave one of the menu items a class of, is active or something like that. And then the bottom one is the Drupal implementation. And you can see that we have six menu items instead of five and the design doesn't break and we can add in more in short client list what it would be like with seven items. But the design is still the exact same. Pixel for pixel, color for color, padding, margin, everything is 100% identical. So if the client was to sign off on the menu in the top one, we know that we can't not give them the exact same design in the bottom one. And if you were to make something like a header, again, you can see on the left-hand side of the top image it says ENGA, that's for English and Guelga. Again, a lot of our websites in Ireland for the government would have to be multilingual in Irish and English. So we got that language which are there, we got the logo then in the middle and we've got the menu on the right-hand side. And on the Drupal implementation, the client decided that we don't want EN and GA, we want the words English and Guelga for accessibility reasons. So they can change that, no problem and the design doesn't break. You don't get that kind of flexibility when you're working with something like Drupal. So we go a bit further then towards looking at a node. Again, this is a node page from this winter-ready website. So on the left-hand side, we've got our default data that we pull in via JSON and we got an image, which doesn't matter what the image is, all we were worried about here is that we have the image dimensions and the client can see any image will be going there. And you can see the Drupal version of them, it's the exact same. The style is the same, the size is the same. So we can't, again, we can't not give the client the design that they're signing off on. So to do this, as I said earlier, I'm not a very good developer and I'm a lazy developer and I don't know enough clever things to be able to do things cleverly and I don't know how I would write the Drupal menu system in PatternLab. So what I did instead was I took menu.html.twig and copy and pasted it into PatternLab. So I thought, I can't go around. I have the exact same markup now that Drupal has. And when I did that then in my Drupal templates, so I've got two directories, one called components or called PatternLab and one called templates and the templates is the Drupal templates. I then go to my templates folder and I get menu.html.twig and you can see there on the top right and I say that you will find the HTML for this inside the directory called atoms slash menus slash horizontal menu slash horizontal menu.twig. And that's as simple as that. You're really just swapping one set of templates for another. So if you look at then at the branding block, again, what we've done here is actually this is the default code that comes with the Phase 2 PatternLab team. So what Phase 2 did here was just wrote the HTML that they're going to get back from Drupal into their branding block.twig file. And then for that I go to my branding block.twig file in my templates folder and I've said what you're going to do here is extend rather than include the block.html.twig file. And inside that file you'll see a block called content as in a twig block. And there where we have a variable called URL which links back to the home page of the PatternLab installation. You use that for that variable where you use angle brackets front. So it'll link to the front page of the website instead of the front page of the style guide. So again, we're extending from one template to another and then swap a variable. Okay, if we've got slightly more complex then we can look at the header. So the header is an organism. So again, what we're doing here is we put in the header HTML that we're going to expect to get back from Drupal and then we just include three different blocks that we need for the header. So in this case we've included the molecule called branding, that's the branding block. The molecule called language switcher and the molecule called superfishing menu. And when we have those three in there and we've seen just a moment ago from here what the HTML is going to be like. So that means then inside our block PL block we get the exact same HTML that Drupal was going to give us. What I've done then is on the left hand side I've got a block called block PL. This is where I say I'm not very clever and that's what you see in PatternLab. And then under that I've got a block called block Drupal and this is what you're going to see in Drupal. So the block Drupal in PatternLab is empty and on the right hand side in the Drupal header.twig file I make the block PatternLab empty and I print the content. So whatever blocks get placed in the header in Drupal will get rendered in the header in the team. Then we had some issues with attributes and in terms of accessibility and things like that to get all the area attributes and to know if things are open or closed and know what it is in classes. So to make sure that would work I just added the attributes item into my PatternLab so that when I extend from Drupal to PatternLab and it reads that HTML attribute is already there. So if you're looking for attributes at class or attributes then know what title and things like that. In my JSON I've just created a default item in that. This one here is slightly more complex. This is looking at a paragraph bundle. Specifically a paragraph bundle that would create a card. So the card has an image field, a title field, a small text field and a link field. On the left hand side in PatternLab we put our if statements data. If there's a title, print a title. If there's an image, print the image. So this will allow the editors to not have an image if they want or to not have a title if they so choose. Then in Drupal where it gets a little bit more complex is that what I've said is the four code blocks at the top. I'm checking for a value first one. So I'm saying that check if the image field has a value and if it does have a value create a new variable and the variable will be called a card title or card image. And then the second block there then I've said is that you will find the HTML for this paragraph hyphen hyphen card.html.twig. You will find that in the organisms folder, building blocks slash cards as card.twig. And then swap the variable that we call title in card for card title which is the variable we created just a second ago in the top block and swap image for card image and tease it out. So that then allows the editors to not use an image if they wish to not use an image or not use title if they wish to not use the title but we don't end up getting empty divs rendered on the page. And then if we were to do this with a node it's pretty much the same again we pop out. Pretty much the HTML we're going to be expecting to get back from Drupal. And then we tell the node template so node hyphen hyphen teaser.html.twig that you'll find the code for this up in the organisms content type guide guide that twig file and then swap what we call the body in that field for content that body swap image for content that field image. And again that renders back then the HTML that we've already been expecting from pattern lab. So why is this good? I mean it's easy to do. It does take a bit of conceptualizing how you're doing it and you're kind of if you're used to Drupal and the modular approach you should get the theoretical framework fairly quickly but it does take a bit of work time to work out what your general pattern is. But why is this still good? First thing I think it's sustainable. What we have on the left here is the Photoshop way of doing things. So a client doesn't like the background colors. The designer needs to open up every single Photoshop file and go and change the background color of all the different buttons. Now I know you can do some clever ish things that might make that a bit less painful but that's the general thing. And the designer charges by the hour so he can retire young. Here's what we do in component-based style guide driven development. The client doesn't like the background color on buttons. The developer changes the button class to be red instead of blue. And the URL then automatically gets updated and the client can see the new work. That takes 10 seconds, 15 seconds. So there's a minimal cost and the developer needs to get a second job to pay the mortgage. Why is this so good? Part two, it's so good because we get QA done quickly. I'm going to guess like us, we talk to our clients and we say we want things tested continuously throughout the project and we're working in an agile manner and as we finish each component and you test that and you sign that off and they always say yes and then no testing gets done until the project's finished. And they tell us we don't want to test individual components. We want to test whole pages or we want to test whole site sections. So the designer designs the website. The developers build a website. It's not exactly what the client wants or they realize there are some issues that they didn't factor in because of the designs. They do some QA, they report some bugs. The bugs get fixed. The client tests again. More bugs reported. We eventually get it fixed and everyone's happy and we get a sign off and that process takes time. If we take a style guide approach to this the designer will design the website in the browser. The client will look at this on real devices and as many clients as they want can look at them as many devices as they want to look at them and then the QA becomes part of the design process. So as they sign off the design and say yeah, this is what we want you to develop they're signing off the front end QA. So you can still do all your QA in terms of the back end has to be done. The Drupal website needs to be built and things like that but we're signing off basically the front end QA. So the finished design then is the finished front end. And then we get to the idea of a living style guide. So like I said we don't ask clients do you want a living style guide? We just give them a living style guide. There's probably going to be a question in a minute when we open up the questions along the lines of how do you sell this to your clients? How do you sell pattern lab to your clients? How do you convince your boss that you want to use pattern lab? And the basic answer is you don't care what's your boss. Thinks about your desire to use pattern lab or not because your boss doesn't know you're using pattern lab. They're not the front end developers. No client will ever come to you and say yeah we want a website developed and you must use Bartik as your base team. The client doesn't care what base team we're using and they're trusting us to use the correct one. So again I don't tell my boss I'm going to start using pattern lab and it's going to be great and I'm going to spend 16 weeks convincing you because to be honest I do talk to her. She's still not convinced that we should use pattern lab. That can be hard so I would say don't. But what you're doing then is just use what you want to use and if pattern lab is the correct choice for you use that or KSS node is or if Fractal is or whichever you want to use and then you're going to give a living style guide to your clients. So if they want to design a new page they can look at your components and you can say these are the components you have there's no more. What do you want the page to look like based on these components and you can drop four or five bits of HTML into a pattern lab file and show them instantly this is what your new page is going to look like. So this happened to us a while ago. We got like I say 46 PSDs one of them was called style guide dot PSD then we got some final design dot PSD hyphen updated dot final dot PSD which had some changes to colors and we are implemented the style guide version because we presume the style guide is a canonical document and then the client told us now we need to change these to these colors and we said hang on the style guide says this this says this and what you're asking for now is actually something different which is the canonical source and the client didn't know. So you're under pressure when the client doesn't know what they actually do want and you don't have that problem with with something like pattern lab because there can only be one source and every time the code gets updated gets updated the style guide automatically gets updated so again I'll skip three days what you're doing down really is that when it's just a URL any updates are instantaneous so it's good for regression testing it means we can use what we call real content I'm going to get some questions about this in a minute so I'll have a few answers what we call real content in terms of say 10 blog posts and we can put in a body field of different lengths in each of those and different length in titles and different images but we don't use live content so we don't put in a JSON feed from the actual website we could do that but we don't and the reason we don't is for regression testing so if we want to test the views, listing page for news and we're using live content every time we try to do a regression test it's going to fail because there's new news posts on the page so when we use real but dummy content let's say actual content from the website that won't be changing so that our regression tests will pass because we're testing against the exact same news page all the time or if there's an events page and the dates are changing well if we use static content this doesn't happen oh yeah I had a joke during after skipping it oh well so the COS had a heart attack because he's designed a new component and the new component breaks something else he realizes after three weeks when we use regression testing and we use something like pattern lab and pattern lab is a great I can't think of what is called inheritance or something like that that when you look at any component it tells you that this component here is made up of these other components and this is automatically generated for you so if you want to change a component you know what other components need to go back and regression test and then it tells you every component you have it then tells you that this component is used in a higher up one so it tells you that the branding block is used in the header and it tells you that the header is made up of the branding block plus the search block so when a new component gets added we can test against this we can make sure that the website doesn't break and then three weeks later the CEO is in good health probably retiring early with the designers so that's the basic discussion around what we're trying to and what I'm trying to promote in terms of not using static generators not using static design tools and instead using things like pattern lab using things like fractal Drupalcamp Dublin is on next month the 21st of October it would be great if some of you could come along it's only 20 euros for a ticket we're only charging this year for the first time because we find if we don't charge money lots of people sign up and don't come if you can't afford 20 euros talk to me and I'm sure we can get you a ticket there's contributions, sprints on we're obliged to put this up so please have a read of it and go to sprints if you can and help out whatever you can and if you'd like to review this session click like or heart or faith or stature or whatever this you do you'll find a comment form on the link for this page so is everybody happy? Do you have any questions? No, I explained it too well or not well enough great presentation thank you agree with everything but I'm still having trouble understanding like how do we convince designers to use these tools because it seems to me that you became the designer but how do you know what to design what to make? I'm a front-end developer so I get Photoshop designs all the crap with that but the problem I'm having is that I can't convince designers to like switch tools like learn new tools to make it for websites is this the solution for that problem what I used to say was fire your designers that designers are clever people you know if they can work out how to use something like Photoshop they can work out how to write HTML and CSS and at least rudimentary JavaScript in terms of show hide type stuff or slide toggle I stopped saying that one of our friends company is another Drupal company I had a quite discussion with him about his wife telling him that his wife is not a web designer his wife is a graphic designer that happens to be designing websites so I don't go that far anymore I don't want to insult people and I don't think you can convince designers to not use what they want to use so instead now what we say is if you want to use Photoshop to design that's fine just don't send those to the client don't send the client to PST don't send the PDF so use Photoshop if you want to design or use Sketch whatever gets you designing the best website as quickly as possible at some stage I have to write the HTML and CSS and JavaScript so before you send out the client give it to me I'll do that part of it and then we'll send a link to the client so we let the designer design with the tools that they want to use and we get the front-end written as quickly as possible good thank you what did you do when the client want to completely change the front page after the first design it says oh no I don't want that maybe you can do some something different do you redo all the stuff that's what you do yeah it's no different if you use Photoshop you've got to get your big juicy delete button and start using it if the client doesn't like it you design again one thing that we do hope will work out in our favour in the coming years we'll have different design patterns from different websites and a client might say that we like the header style of your Oxfam website and we like the slider that you have on the Irish Cancer Society website and we have those components from the pattern that have been dropped into their new site and changed the colours then to match their branding and that would mean that we could design very very quickly and it's already regression tested and things like that but yeah if the client doesn't like it you've got to go back to designing again I don't see a solution for that I arrived to the solution just a few minutes later forgive me if I asking you something that you already replied but I think besides the problem of the mock-up itself it raises potential problems on the sales process if you know what I mean that you show your work to the client for example you can have clients that say what's all those for the website that's actually finished why do you need three more weeks to finish that understand the gap between the mock-up and the finished website for example or signing a deal because if you do that sophisticated mock-up you're essentially working for free unless you have a deal signed in advance and to get that deal signed in advance you need something to sell and I don't know how do you deal with those problems in the sales process it's been in our contracts when we write a tender and the section on design we have a browser and we'll be using a a website generator and that you'll be at the URL so we tell them specifically you will not be getting any Photoshop documents you will not be getting sketch files you'll get a URL you can try some kind of education process on the client to understand the we have the onboarding session so we go through to the client this is an example of pattern lab here's some design components for a listing page here's some design components I'll get you through the process with that different example it does take a bit of they're not used to this kind of approach so it takes some not necessarily selling their approach to them because they've already won the contract and they've agreed that this is what we want to do but just some education to let them know how it actually works in the real world thank you how do you deal with typography beyond headings like if you had a field label and a tag that looked just the same would you create a component for that maybe mixing just not reusing sorry can you repeat the question how do you deal with typography like different textiles not just for headings but maybe if you had a field label and a tag that looked just the same yeah you have to just create classes we have base files which would allow us to do things like spacings and margins and text float left text float right and things like that you can pop those classes into whatever components you're using so they wouldn't get styled at the individual component level if you're going to need to reuse them so they get styled in a utilities directory at the root level another quick question what do you use as your base team the pattern lab the pattern lab phase 2 version we use as far as I know doesn't have a base team it's all runs on itself let's say when I'm working myself for a base team we're progressing towards let's say a pattern lab so we have another base team that we use we call the weather team because in Ireland the weather changes a lot and that uses as a base team hi I'm a developer so you were talking about testing what do you use for testing designs backstop backstop it runs on phantom it's a headless I don't know a huge amount about that part okay thank you