 Well, hello, everybody. Today I'm going to talk about company-driven design and development. I'm Christina Chumillas. You can find me on Twitter as Chumillas or Secrena on Drupal.org or on iReceive. I'm designer and front-end developer at Imbra, a Drupal shop based in Barcelona. I come from the graphic design world. I'm not a developer. I was a developer, but I met Drupal about five years ago when I became freelance and I've been doing Drupal since then. Well, what are we going to talk about on this session? I'm going to talk about components, what they are, and why can they be useful. About design systems, about CSS methodologies and what they are, about the style guides and how can they help, and of course, how can we implement everything on Drupal. But first, let me say a couple of things about web projects. I'm pretty sure all of you know the typical waterfall project that is, that everything is done, everything starts when the previous phase is finished. For example, you don't start the design until the planning is already done. You don't start the development until the design is completely finished. You don't start the theming or the testing until the previous phase is everything finished. And finally, you deploy everything, the full project. On the other hand, there's the agile methodology, the agile workflow, that let you develop a group of features and you release a group of features every spring. So you can be developing at the same time that the designer is working. So you can be doing several things at the same time. Another thing that I would like to remind is that the lifetime of a web project never ends when you deploy your project, when you launch the website. After it, there's the maintenance moment and if you haven't had, if you haven't written a good code, it will be really hard to find it. It will be really hard to maintain everything. And another thing that it will be really good to remember is that for science now, most of us are having using static deliveryables. We deliver Photoshop, PDF, PNG images, but they are not responsive. They don't have interactions. At the end, they are not on the browser. So they are not the real thing that the visitor of the website will see at the end. So we should think if the client really won a Photoshop because they are just used to that because they are used that it's a standard but it's not the best option. But well, how can we improve all that things with components? What is a component? Component is any predefined object available across multiple pages. It can be also known as widget, blog, module. It's an independent entity and it has its own meaning. It has its own part. For example, in that case, it has a title. It has a list. It has a read more button, but it's independent from the other parts that will be in the page. Why components are an improvement for us? Because components can make systems modular and a system to be modular, it must have interchangeable parts. And what makes a component modular? First, we need a standard and shared design to across the project, across the website. It means that you have to take it into account when you are designing. You have to design thinking on components. It's really, really important. It comes from the beginning of the project. It also needs to have a centralized code because you are using, if you have centralized code, you only will use once that code. You don't will write the same code again and again and again, and then you will have to maintain several pieces of content. You just have to use one of them. And another thing is that it should be controlled via a system, via the system, not the user. The user shouldn't control it. And it should have customizable options. The user, for example, should be able to decide if it's a list. I want, for example, two things, two items in the list or three items in the list, for example. It's really, really important that we give some tools to the user, but not a complete control to it. Here we have an example. As I was saying, we can have the same component. In that case, it's a testimonial. It's another real example. Here we have a testimonial with one item, for example, or with three items. Depending on the case or in the place we are putting it. For example, here, as you can see, there's the same component on the sidebar. We only need one item because it's smaller. It will not need more attention. But, for example, if we want to put it in the central part of the page because we want more importance to that component, the user can decide if he uses, for example, one of the items on it. And if you have to remember, one slide of this presentation is that one. We are not designing pages. We are designing systems of components. This is the most important one. Design systems. I'm pretty sure some of you already know what's that because they are all in the range in the design world nowadays. What is a design system? A design system is everything, everything that makes up your product. Everything. It means typography, layout, grids, colors, icons, of course, components, but even coding conventions. That things are also important on a design system because everything makes up your product and everyone needs to know the same thing. Here you have an example of a design system. Here you can see a main navigation bar. You can see some buttons, some pages, a breadcrumb. It all have the same style. Here you can see another example of different components in that case. They all have the same colors, the same typography, same titles, same styles, and if you put any of them in any part of your website, they will have the same style. But why should we use design systems in our projects? Because it's reusable work. We only have to do things once. If you reuse our work, we will be able to have more efficient projects and with efficient projects, we have large scale ready code, so big projects. We will be able to have and manage big projects. But also everybody will know where is everything. If someone gets into your project in the middle of the development, he will know where he has to find anything. And also it integrates multidisciplinary workflow, the tester, the developer, the designer. It will be really, really good for everybody in the project. Well, inside the design system will sometime, some years ago, some time ago appeared the atomic design concept. It's a methodology. It was created or invented by Brad Frost. I don't know if some of you already know who's Brad Frost. Yeah, because he's a really important, he's a really good front-end developer. He has a blog. He also writes usually, and he was going to launch a book about that. What he says is that when you are building a design system, when you are designing your website, you don't have to start with pages. You should start with smaller pieces of your website, with atoms. And then you should put together atoms and build molecules. And putting together molecules, then you build organisms. With different organisms together, you build templates, and finally you build pages. But you don't start with pages. Here we have an example. We have some levels with some inputs. If we put them together, we have a form. It will be the typical form. It will be a molecule. If we put that molecule inside an organism, it will have, for example, the comments organism. It will have, in that case, we have the form. We have another comment already sent. So it will be an organism that you can put inside the template. For example, it will be a no template with the comments at the bottom. So here you have the template. And finally, you add there all the things that the other parts of the page already have. And you finally have the page. But you start on the smaller piece. And that's the key. And the big question is, when should we introduce that workflow in our projects? Well, it's not the, it's not, there's no best option. But for sure, as soon as you can. You should implement it in your project as soon as you can. For example, on wireframes. It's a really good moment to introduce the components way of thinking. In that, on wireframes, we can choose between static wireframes or HTML wireframes. We choose static wireframes. The problem is that they are full of, they are abstractions. They are not the real thing that the final user or the customer will see at the end. Because you are not in the browser. You are, for example, in a PDF or in an image. So you can click there. They are full of assumptions. For example, you design a wireframe. You put the typical main menu. But you don't develop a drop-down menu because you think it's not needed. But the client doesn't see it. He thinks that it will be a drop-down menu. But he can't test it. So he won't know or he won't remember about asking it. And at the end, you will have the website ready for lunch and he will say, where's my drop-down menu? No, no, there's no drop-down. We haven't designed it on wireframes or on design. Ah, but I want a drop-down menu. Everybody has a drop-down menu. So it's full of static wireframes are full of assumptions. There can be problems with that. And also, they are never complete because you won't design everything in a static wireframe. On the other hand, you have the HTML wireframes. And the good thing on that is that they get quicker into the browser because you are doing it in the browser. Also, they reinforce the notion that you're creating a website because you are doing it in a browser. They are also interactive because you are in a browser. They will be as interactive as you want they are. They also allow annotations. That's something that sometimes it concerns us that we won't be able to annotate something there. They also let it. And also, they will be the base of the final product. And it's really important. Okay, if you haven't implemented components on your wireframes process, you can do it on your design. On your design, you can have the typical static Deli-Rables like Photoshop, Images, PDF, or you can have HTML Deli-Rables. You can have prototypes. If you decide, if you choose prototypes, you can design in the browser. What does that mean? It doesn't mean that you have to start with a white blank page, a HTML white blank page. No, it's not that. You are, if you are a designer, you maybe are thinking I can start with a blank HTML page. It means that you really have to use Photoshop or whatever you use in the planning phase, in the research phase. And then you make your composition in the browser. What does that mean? That you make decisions in the browser. And that's really, really, really important because you will decide when the breakpoint will come because you are doing it. You are having it just right in front of you. So you will decide it looks good or no, it doesn't look good. And of course, they are reusable work. The developer will know how do you want your output, which classes do you want, which levels do you want, for example. So it's really, really, really useful. Okay, another important part about components are CSS methodologies because they let us make a scalable and maintainable front-end code. And it's really, really, really important to apply it in our projects. On one hand, we have object-oriented CSS. It has already some years. It's based on the object-oriented programming paradigm. What it says is that your object should do one thing well. It should have only one responsibility and one class for that responsibility. And it should be focused on the separation of concerns because every section should have its own classes. This is an example, the typical example of an object. It will be media for the media object. So if you want to theme anything inside the media object, you just have to use the media and whatever is inside. So that's the only thing you have to think into account with object-oriented CSS. BEM block element modifier, it's a naming methodology. It's an abstraction. What it does is, for example, you have a component or a block or module or widget, whatever you want to call it. And you put a name on him. You say site search, for example. And you use the element to modify that class. For example, if you want to put a field inside the site search, you will do site search underscore underscore field. What that does is that when you call it from your CSS code, you are calling it directly to. You are not using site search as a space field. You are using directly site search underscore underscore field. Or, for example, if you are modifying your site search because you have two of them, here, for example, you have the full one. Then the modifiers goes with dash dash full. That's a really important way and a real improvement to use directly that class to style everything on your CSS or SAS. Here, for example, we have another, we have an example of an HTML output. It will be the block name. And you can have a wrapper that it's also something related to the block. Then we will have block name underscore underscore wrapper. Or the title will be block name underscore underscore title. It's really easy to implement and it really helps a lot. Believe me, it really helps. Then on the other hand, we have smacks. It's more like a style guide than a rigid CSS framework. What it does is recommends you how you should divide your files. For example, you should have a base file with everything like font style, the size of the font, the color of the links, the margins of the list. It will be the base, for example. Then you should have another file with the layout and everything that is related to the layout. For example, two columns, three columns, responding things, whatever. It will be in the layout. Then you will have the module or components in another folder or file. And finally, the states. So what you do is divide the files and you put everything in its part. Then another really, really useful thing for working on with components is having a style guide. If you haven't introduced components earlier in your project, I really recommend you that you do it on the style guide moment. Most of you, I'm pretty sure all of you sometimes have seen the typical style guide, the PDF style guide that someone's deliver you with design. And today, what it does, it visualizes your code and represent this as a UA component toolkit. It's, a style guide is a documentation of a design system. It's just a list of about everything that you will have in your website. For example, here we have our colors. Then we will have all our colors inside that style guide. Here is an example from government.uk. And you have a list of all the styles. All the colors here. And you have a list of all the titles and other lists for all the components. Why should we use style guides on our workflow? Because they improve the user experience. For example, imagine that you have a website and there you have a help link. Then you click on that. It opens a popup. And in any other place, it doesn't open a popup. It goes to another place. For the user, it's not good that. If you have a style guide that it says how it should like the help button, what should happen every time you click on a help button, if you will have the same experience across all the website. And it's really, really important for the user. Another thing that really helps is that it makes easier the onboarding of new team members because everybody who knows where they have to find everything everybody knows where's everything and they know where to find anything that they already don't know. Of course it makes efficient or design or development and it makes really easier the testing and it's really important because the tester sometimes doesn't know where to find the good code because it has changed during the development the standard world. And if you have a style guide, he will know that the thing that there's in the style guide it will be the good one. So it will be easier to know if it's fine or no. So if we have even a waterfall or agile project or whatever is your workflow, for each piece, for each feature, you have to go from the wireframes to design after you have to develop it and then launch it to production. If you want to make any change, you have to go back, go to design, design it again, develop again and go to production again. What if you introduce here in style guide? Well, you have to design, develop, production, oh no, we have to change something. You go back to design, you design everything, then you go back to development and you say to the developer, hey please, update the style guide, don't forget it. It's really important. But you are not on time, you have a lot of rush and you forget about the style guide. Well, style guides that are out of date are really useless. If we are not going to have enough today the style guide, it won't work. At least at the end of the project it won't work. So style guide driven development, it's something that really solves that. Style guides, it means that there are style guides that are generated directly from the definition resources. For example, from your SAS. If you are using SAS, you can generate your style guides from there, for example. What we are using on our projects is SAS Nile Style Sheets. It's something that is really launched with the Zen module, the new launch Zen 6. I don't know if some of you already used it. It's a really useful tool. It's an automated style guide and it's a documentation specification and a style guide format inside your SAS that you just put it on the SAS and it creates automatically and extract everything and creates a style guide for you. I'm going to explain it. For example, you have what I was saying just before about the SMACs. You have your base code, your base styles. Then you have another folder with the Lyos. Then you have the folder with components, for example. And we go to the pager component. You have the file, in that case we use SAS. Then you have a SAS file and in the same folder you have an HBS file. I'm going to explain it. In your pagers, in your pagers SAS, you have that code. You have the name of the component. Then you have the markup. You link here to the pager.hbs, a file that is in your folder, in the same folder. And you say it here that that component will be inside components.navigation.folder. And that's all. Then, of course, you have to make your code, your style there. And then you create that nice at CML. You just put it inside the pager.hbs file. You run the gulp automated thing and you have the pager on your style guide. It will run automatically. What doesn't means that you are creating your code, you are styling and at the same time, you are building the style guide. So it won't be out of date, never unless you are doing it intentionally. If you want more information about the style guides, you can go to styleguides.io. There are a lot of resources there, article, books, whatever. So don't worry, there's a lot of information. And, well, how we do everything, all that things in Drupal because as you may know, Drupal is not theme free only. It's not David is free only or Classy is free only. So we have two general approaches. We can grab components or we can change the full markup or we can do both of them. But there are that general approaches. If we want to change our components or Drupal components adapted to components itself that you might have on your style guide or in your prototypes, you can choose three ways. You can do it by code. You can do it by through display suite or you can use panels. If you are going to do it in using code, you can use fill formatters. You can use preprocess and process functions but you have to know how everything works and which one you will need to use. And of course you can use hook page altar, hook form altar, hook node view altar, whatever. Or you can create your custom functions. But you have to know a lot of things. You have to have a lot of knowledge about Drupal theme and Drupal frontend. On the other hand you have display suite. I really like it. It's really easy. You just have view modes and you design, you customize your view modes and you reuse your view modes. And here we have a component. So we can reuse it. But also display suite has filter plates on the display suite extras module. And if we do it, we can change all the markup from all fields. We can choose the expert mode and here we can put there. We can change the markup. We can change the classes. It opens, it outputs. So we can have a lot of control over our HTML at the end. And finally we have panels. I really hated panels some years ago because I thought it was a huge, huge, huge module that really just give a lot of problems. But lately I discovered that it's really, really useful for components. On one hand you can use custom panes. Custom panes or it can be also known as Thetools content type or plugin. What you do is you create, it's like creating a block. If you have ever created a block programmatically, programmatically, my English is not really good, sorry. You just create the, you just use the function hook themes admin info. Or sorry, you just use the function hook admin info and the other one hook render and you just create your plugin and you will have it on your panel's interface to choose it and it will be created for you. So it will have the output you want. On the other hand, you can create custom templates. You can use, you can create a panel, a pane on your interface inside Drupal and just change the template. Another really easy way is just adding a class to a panel pane and then just theme everything inside it. It's really, really easy. You just have to do it on the preprocess function, preprocess panel pane function. This function is the key. You can do it on template.pap on your theme or whatever. And then in any case, in that case, my pane name, for example, you choose that and in that case, you use the classes you want. In that case, it's my custom play class and then your pane will have it and you will be able to style whatever you want. However, however you want. Another thing that panels give us is mini panels. It's really easy because you do everything through the interface. It's plug and play and you just add some different, in that case, we have social media icons. You can have any other thing inside here and you have a mini panel then you can add it whatever you use your pane in a panel page or in a panelizer or whatever. And then you have a group thing that you can reuse whatever in your projects. And finally, panels give us also context. Context is, for example, if you are in content type, if you are in an article, you will have, for example, a list with three items or if I am in an article or in a simple page, you can have, for example, five news, five last news. So depending on the context, the panel, the content can change and it will help us. So that's all, that's everything about components and I think I'm on time. So if you want to learn a little bit more about any other related things with that, you can go to other two sessions related. You can go to Drupal Generating Markup, it's not your friend, use a style guide, so they will explain a little bit more of that. And another one I recommend you is Prototate and Drupal from designing the browser to implementing custom templates. So thank you for coming and thank you to MSF that let me use the examples from our customer and if you have any question, that's all. Hi, I have a question about class naming. I'm actually a backend developer so I'm not really a front-end person but I talk a lot to front-end people and so I come from a very structured way of working and they have a less structured way of working. Sometimes they have trouble coming up with naming convention for all of the classes that doesn't go out of control. So I wonder if you have any tips for naming conventions inside BEM, for example. Yeah, he's asking what's the best way for the naming conventions because he's backenderic and he says that he usually have troubles to go to a common way of naming. I would recommend you use BEM. BEM is what I was saying, a really good and easy way to put classes and it helps you, hope you put a class but it doesn't say you which is the name of the component. You have to decide it. And I think the clever way to decide it is to abstract as much as you can your component and to think all the times it will appear. If, for example, you have a culture action button, think where it will go placed and when you have all the situations you will have it then decide, not just on the first time it appears. Just have a big image of it. Next one. I was just wondering because I was using KSS on one of my last projects and the thing was that throughout the project sometimes you want to change the markup but if you're already in the project you constantly have to change twig and then you're also maintaining the HBS file. Do you have a better way or do you maintain those two files where you keep the markup in sync or is there a better way of doing it? No, we also use HBS because I think at least for us is the easier way because we try to keep the good one as the HBS. Then all the other ones should vary from that but that's a good one because otherwise you are developing something and only you know which is the good one and if you don't update your HBS then you can have that troubles. We always try to use the HBS or having at least two examples on HBS but there is the central component. Thank you, thanks. Thank you. Any other question? Do you have a document at the higher level where you work with your client and say you can't design a new page, you need to work from these components and these components work in this way and this is why we use them. Do you actually take it up so you don't actually go back to the design phase, you just say here's our style guide, here's our catalog, please choose from the available options. You mean how do you say that to your client? I don't know if it's the client so they don't get to design because the worst thing with a big site is oh yeah, I want to design a new page but actually what you're going to say is well, here are the components. Can you please choose from the ones we've already made? Well, that's a good question. You never have, well it's, that's not so usual to have that good client that understands everything and when you suggest something he says, okay, I'm going to change my mind and I'm going to do that. That's really, really, really difficult to do it but I think that at the end you have to choose that clients that really listen to you because they want to improve also and at the end, if you, I think the best way to say to a client, hey, that's the best way, doing things with components is showing them any example of any other customer and taking maybe they already designed anything, say okay, just let me check, take some piece of that and let me move it to any other place. Does it works here? No? Okay, we could do it work. So, I don't know, you should try to convince but it's really difficult usually but if you go with a prototype or with an HTML wireframes, usually when they see that they can touch whatever it is, it's usually it's really good. Any other question? No? Thank you.