 OK, so component-driven front-end development, so who am I? I'm John Enew, I work for Deeson, a digital agency in the UK. We provide full design build services and deliver reasonably large websites. Our typical projects are about six to nine months and our primary technology stack is Drupalate but we also work with a number of front-end technologies like Anglia React and we do development using applications such as Symphony React and Laravel as well. So what's this talk about? I'm going to be describing the journey that Deeson has gone through over the last three years where we've gone from a very waterfall design process and development to take on these ideas of component-driven development which I believe requires a very agile approach to the way that you actually run your projects. So maybe you'll see some parallels from your own experiences and your own businesses and I'm not suggesting anything in here that's the one true way. Some of our approaches will work for you and others depending on your business and your team and everything. Probably you all disagree with some of the things I have to say. There's nothing... OK, so there's nothing revolutionary in this talk. I'm going to summarise a series of ideas by others and I'll reference them where appropriate to give you our favourite reading material and where you can find the best descriptions of some of these concepts. So the format of this talk is this. For the approach to work, I firmly believe you need to embrace agile with a big A and break yourself of a waterfall design process. In developing design systems, I'll describe the move from designing full pages to producing a design system which is a component library and a style guide. Finally, we'll look at how you can make that style guide, a living style guide so that the design system itself is a part of your Drupal website. First and foremost, websites are built by people and projects succeed or fail primarily on the quality of the communication and the decision making that comes about through collaborative work. The agile manifesto values individuals' interactions over processes and tools so the more collaboration on a project and the more engaged all the team members are then the more likely it is to succeed. So you might recognise this kind of waterfall approach to delivery and this is certainly what we were doing two or three years ago. Each discipline only gets involved with their phase of the project and we thought that we were being very efficient with this with people's times but this is a false economy. Value is lost and members of each discipline fail to inform the stage before. So we tended to have a very large design phase up front and designed the key pages where we designed the key pages of the site. In fact, we'd often design all the pages of the site and then give clients free range to waste their budget endlessly discussing those. Brad Frost, who I'll mention a bit later on as well who's got some of the ideas in this talk, he describes this process well with a little story about the idea of producing these beautifully completed designs and they've been delivered to the front end team who might be in a different part of the building or in a different country or continent and these design package gets pushed under the door with a note on it saying, it's all signed off so nothing can change and by the way we've only got three weeks of budget left. Then everyone kills themselves to get it delivered in a rush but no one is ultimately pleased with the end result. So we need to stop doing this. What we wanted to do is move to a process that looks more like this, a collaborative workflow involving a continuous cross-disciplinary team working throughout the entire process. While the amounts of active work might change for each discipline they're always consulted in order that their knowledge is always present in every piece of work that's produced from start to finish. This is hard to start doing and often at the start of a project new clients will still want to work in the old water four-way they see a safety net in the sign-off process and it's difficult to break them with this and start them trusting you to work collaboratively. Our creative director usually gives a little speech now at the beginning saying that they need to be brave and they'll get an award-winning website but they do have to trust us to deliver. So in part two we're talking about developing design systems. So when our clients came to us thinking about websites what they were really thinking about was a collection of pages and that concept of a page is very key in the language of the web and the way that the web has evolved. So typically there's questions around how long will a page take to build or how many pages will this website have in it. And the problem with this is the design level is that each page developed becomes a unique collection of things. And of course it's those things on the page that are actually going to be built and are actually going to affect the cost of development. The more things that are defined by a designer the greater the size of the project so that a project with only a handful of page designs can be much more complex than a project with many page designs which are much simpler. So fundamentally we need to stop designing pages and stop sharing those pages with clients. Page designs are static and they don't accurately represent what the design is going to present on the huge number of devices that the page will end up on. I think it was Stephen Hay who said something like presenting fully formed photoshop page designs to the client is the most effective way to show your client what the website will never look like. So we're not designing systems of pages instead we're going to be designing a system of components and this is a key concept to teach your team. All the disciplines need to understand this from UX to design to front end to back end. We're looking for the individual components that are used throughout the design. Modularity is the key to successful design and a successful project. In the waterfall approach laid out earlier the front end developer does not have a chance to input their wisdom into the design process. Indeed when your design team is completely separate from your front end and development teams it becomes increasingly difficult to evolve the design as the technology and the results of the implementation are seen and understood. So what exactly is a component? Component is a concept, it's hard to give it an exact definition. A simple one might be a small collection of things on the page or a single feature that the site is going to produce. The important thing is that the team agrees on what the components are what their names are in such a way that their purpose is truly understood and this has to be a collaborative effort. So here are some examples from a recent project we've done so perhaps you consider the head of the site a component, a content listing or the footer. A chap called Brad Frost did a lot of the work on coming up with this idea of atomic design three or four years ago which puts additional rigour around the component way of thinking and it defines an approach to producing a design system and a way of thinking about design systems. I highly recommend that blog post and the book that he's written as well. So in his idea we break a design down into smaller and smaller pieces so he has the idea of atoms into the base type of graphical elements such as headings and buttons on the page and then from those base parts you can then combine them to produce molecules which may be slightly larger elements such as a search form and then finally up to organisms and so forth where the heading might be an organism on the page or some component of the page which is then reused. Adapting the atomic design principle system gives you a consistent approach to how you go about setting up a design system for your web project and there's a tool that goes alongside this called Patent Lab which I won't go into in this talk but you can find out more from Brad Frost's website. So the end product of this approach is a style guide. A good style guide isn't something that just shows off the various aspects of the design. Used properly they are a collaboration tool bringing the design and the development teams together and bridging those two teams and acting as the focal point of your collaborations. It's a tool to break down the user interface into its component parts rather than thinking about it as a whole or as a series of pages. The client can browse through it and see it working and because it is in a browser we can see how the components will react on every device. They also serve as a resource for new designers and developers to get an understanding of the entire system in one place and it helps future work where the team can locate existing patterns and combine the smaller elements to create new larger sized elements. This helps lock the design system in place and prevents the creation of large numbers and new stylistic elements every time a new feature on the site is commissioned. So what's the point of developing a neat design system? I like this image. This is from one of Brad Frost's pages but without a design system the bits of your design end up being like the scatter pile of LEGO bricks. All the bits are there but you have to rummage around to find the right parts. If you can't find it or you don't know a bit, it actually exists you might be tempted to bring in a new piece to complete your project further enlarging and complicating that pile. I think if you looked at any older Drupal themes then working your way through them might feel a bit like shifting through a pile of LEGO bricks. So taking the time to organise your pieces allows you to approach the development of new components in a consistent and efficient manner. Certainly there's time involved in doing this but it's time that pays off in the long run. Now the new feature builder can see exactly what is available for them to use and now the changes to the design system can flow through to all the backend systems that might make use of it. The development of new features is much simpler. So here are some real examples from a project. Here we see a single atom being an example of a button, a molecule which is a piece of teaser and then an organism which may be the panel listing. So we start thinking about what would be a good process for your team in order to produce this. For us this starts at the UX phase where the UX analyst has identified a pattern in the emerging project. They name it and they define its purpose. This is the point where the team then gathers together to work on these patterns, to understand them and truly understand them. At this point the team will get involved to annotate the data attributes and their types and in theory this is sufficient for the entire rest of the team to work on a component in a single sprint. The designer will then design the component in collaboration with the front-ender who is building it out in our component front-end tool system. This may be pattern lab or it may be another tool. Whilst the back-ender is building the content types and views necessary to support it in Drupal. It's possible that when you get good at this you'll find that the designer doesn't even need to share photoshop designs or sketch designs with the client for sign-off at all even at just the component level and the component library itself for all that needs to be shared. You can get to a point where you're actually developing an evolving solution where the front-ender can start by producing placeholder elements given that they know what's involved in creating those elements because there was the collaboration beforehand and as the design becomes available we're building the gaps and refining the output. So that's all great in theory. We've built a neat design system. We've used a tool like pattern lab and we have a fancy style guide to showcase what's been designed but what happens? We try and bring this into Drupal. Drupal uses a template-based theming system. Here on the board we can see that the templates folder of one of the core Drupal themes. Markup is organised in the theme of the dimensions of the CMS. So we have things in there that you have to know all about Drupal in order to work with this. Blocks, content, views for example. Code is duplicated across these templates. It's not uncommon to find, for example, a content template file for each content type in a Drupal website and much of the markup in each of these content files is repeated from one content type to the next. Or you have single templates with an awful lot of switches or nested ifs inside them. So in this case the markup isn't dry which is an acronym for do not repeat yourself. The code isn't modular in the way that the code in our style guide will be. Now if we want to make a change we want to introduce a new template to our Drupal theme. We start to see some of these problems. For a new content type we have to build a new template and copy and paste the markup and if we make a change to the base styling we don't want to go searching for every instance of a pattern through all the templates. Also if we have a design system and a style guide then we are copying and pasting markup from the style guide into the CMS system and there is code duplication again. And finally changes made as the project evolves are unlikely to find their way back into that style guide. The usual project strains and time constraints are naturally going to mean that changes get applied directly to the CMS and the Drupal theme and the style guide will slowly drift out of sync with the systems that it's supposed to be supporting. When this happens the style guide ceases to be useful and in fact can be a cause of misdirection and confusion between the project team members as they reference different versions of the truth that's stored in different places. What we need is the style guide templates and CSS to be pulled into the right points of the Drupal theme so that it's sharing the same code. Here's another theme in core this is the seventh theme. Separation of concerns here relates to the ability to put similar bits of code together so that it's easy to reason about them. The concern should be around a concept or something that developer knows that they're going to work on one thing. The approach taken by this theme which is a fairly standard Drupal theme pattern is to organise the elements of the theme by file extension. So all the CSS is in a folder together all the JavaScript is in a JS folder and all the HTML markup is in the templates folder. So this is separation by file type not by concept. When developing a component we want everything about that component to be contained together it's markup in the form of twig templates it's CSS and it's JavaScript and any JavaScript associated with it. The problem with this approach is that developer must jump around to make changes to any specific element. It's likely that they will work on the HTML and the CSS concerning a single page element at the same time but must hunt down the bits they need in order to change. With a component based approach all the aspects of the component should be stored together. The folder should be named after the component and in it we should find everything we need to work on it's markup, twig file CSS and any JavaScript. To further modulise the CSS we use the SAS and the block element modifier or BEM approach to ensure that the CSS defined in the component only affects that component. This avoids problems where changing CSS can have unexpected consequences on other parts of the code base. If you're not familiar with the BEM standard then I recommend looking it up. So here's a trivial code example of what a component might look like. This is the template code for a button on a page. So we've defined the variables that can be passed into this template a URL and the text of a button. Then what we want to be able to do then is to use that template that was built for our style guide for our styling system. I want to be able to use it in Drupal and I'm going to just describe two approaches to doing that. This is one we've used a small amount of and then there's another one that we use slightly more often. This uses some libraries that we built for our front-end process and the link at the bottom there will give you more information about exactly how this works. But we're using a modern build tool setup so webpack, docker etc. We've got an integration library each component that gets created inside of our front-end system gets its own theme function inside of Drupal and this is auto-generated code that we include there inside of that documentation so that within Drupal the Drupal developer can then use any of those components that got created inside the style guide as they wish within the Drupal theme. The other approach is to include the design system templates directly inside of Drupal templates so Drupal is acting as a bridge or the Drupal theme is acting as a bridge between Drupal itself and our design system. The use of components module for Drupal 8 and the instructions for this are on the components module page. So with this approach you need to specify where your additional twig templates are stored in relation to your theme inside the themes info yaml file. Then you can include those templates as I've done here with another trivial example. This is the page title HTML twig template file which normally just contains the fixed markup of a H1 element for a page. And all we've done here was to the variables supplied in a Drupal way to the variables that we defined would be needed for our component. So the component itself doesn't include any specific Drupalisms within it and makes no assumption about the names or the naming scheme used for the individual variables. The idea with both methods that I've described there is that you're not creating markup inside of your Drupal theme. Markup is pulled from your design system. So hopefully with these examples you can see the power of the options that are available. By using includes or custom theme functions the Drupal theme can be used as a bridge between the design system which was specifically designed for a client, the client's domain language and the client's project and the Drupal CMS. We've removed the need to introduce Drupal naming conventions and standards to the design system or static style guides. We've also removed the need for the front-enders to know Drupal at all front-end developers who can work entirely inside the design system concentrating their energies on the development of awesome front-end. The Drupal developers are also freed from the complexities of implementing the design and only need to work on bridging of the two systems. And finally we've created a living style guide as opposed to a static style guide as Drupal is using the same templates as the style guide itself so any change from one will be carried into the other I think. Briefly in conclusion decoupling your UI elements from your application development process is beneficial. Using component design process to focus on reducing complexity and increasing reusability and most importantly I think move away from a waterfall design process into one that is truly agile and encompasses the entire team. So this is my list. I'm sure a number of you have seen quite a few of these things before but if you haven't there are some really good examples there from Brad Frost's blog post and event apart video where he describes the atomic design approach and pattern lab. The Lonely Planet guide there talks about the creation of a maintainable style guide and why that's important. Four kitchens did a Drupal tutorial tutorial videos which cover many of the things I've described here today as well. And then finally at the bottom there we've got Desons approach to front-end development which includes some of the libraries that I described when integrating the templates into your Drupal theme. So thank you very much we've got two minutes if anyone wants to ask any questions. I don't know if there's a mic. Hi So how do you present the modular based kind of aspects to your clients if you don't present them a whole page for example? How do they cope with that? Yeah it's difficult and it's a process that you have to go through I think to be able to get to that level of trust. Early in a project cycle we run something called a Feasibility Workshop very early on and it's part of that we sit down with the client to describe both the approach in quite some detail but also to understand the feasibility of their project both from a cost perspective a technology perspective, a brand perspective but also from the team perspective so we have to understand from them is your team ready for an agile project and in the case on what comes out of the end of the feasibility workshop will be a report that says your team likes the ideas at that point even at that point there's certainly an element of but we still need to see some designs we need to sign off on something at some point so through the foundation stages of a project which we wouldn't want to last more than two to four weeks we developed something called the Design Direction which is essentially focused on those lower level building block elements so it's kind of this is the feel for where you're going but it's not it's not the entirety and it's certainly not the finished product so don't look at this and think this is what you're going to get because it won't go that way and it's that continuous conversation that builds that trust and builds that understanding how it works I find people are easier to talk to about agile these days anyway because it's kind of in a lot of people's minds but certainly isn't university true Hi, I'm just curious to know your thoughts on a component based approach with Twig where you're having to try and couple things together and try and structure your file system together to get everything you know closer decoupled but coupled compared to something like view where you have a view file where you'll mark up your JS and your styling language is and your thoughts on like how Drupal could possibly move forwards in this area Yeah so it's a good question and I think when you get into this the examples in here are pretty trivial and you'll certainly come up with some some blocks along the way of things like how do we actually implement this inside a Drupal in four kitchens have got some good their video tutorial system series goes into this in a bit more detail we've really got the time to go into it now but yeah certainly there are approaches that you can take in all of these things but I think the key thing is to be quite flexible with your approach so again as with any project you're going to hit row blocks along the way to be things that are going to be difficult to do but that good conversation between your Drupal developer and your front-end developer rather than sticking to a very rigid well our front-end is only going to look like this and being able to be flexible in the way that they work as well so that the two things can work together is the most important thing so keeping conversations open and being collaborative is the bottom line Do you find it hindering though to stick within the Drupal front-end system of using something like twig whereas like I recently tried to take on a project where I combined I kept within Drupal as the front-end layer and tried to combine view into it and I just felt that it was far too much of a struggle to still try and work within Drupal whereas if I just go headless which seems to be the theme of this Drupal con it was a lot simpler to get a component driven design yeah certainly headless systems as well so I think there's pros and cons to both approaches but yeah I'll talk to you later Have you thought about implementing these start-get components as plug-ins of some sort like form-meters, views plug-ins and does it do you see the match there or do you think that some should be separate? Yeah I mean there's elements of things you can do there but the need to separate the two I think is quite important so we have some if you have a look at our demo site if you follow that bottom link and start to have a look and explore what we've done you'll start to see some of the examples of the way that we've kind of thought about some of these things but yeah I don't think there's any specifics around how we're going to do that yet I mean if you would be interested in that I have the module called RenderKid which is aimed to have more smaller fine-grained components to these kind of start-get components RenderKid Everyone check that out Maybe I will make a buff about that We've run out of time so I'll take some questions afterwards but thank you very much