 okay cool all right i'm going to get started now um sorry about being able to see my entire computer i can't get that to go full screen without going black over here so i'm going to need to be able to see my notes so um let's get back there that's better okay my name is josh walker um i'm a front-end developer at calamuna um i'm also a metalhead um you may notice that i have a strange accent but um it's actually you guys that have the accent i speak very normally um but i need to um say if there's anything that i say that's weird or you don't understand just like let me know because even after living in canada for six years i still find myself saying things and people like don't really understand what i'm saying um so yeah um i have been working with drupal for almost nine years and um in the last few years i've been concentrating on specifically front-end development um but i also have a background in graphic design as well and film and television as well so um that's me um a little bit about calamuna um calamuna is a web development shop based out of oakland in california um we have our trusted leader here with us today andrew supporting me and uh we like to work mainly with mission driven organizations um not for profits higher ed um that's that's what i think and we uh um we're a partially distributed team there's a bunch of people in the office down in oakland and then there's three of us in canada and we've got people spread out in america and then one over in europe as well so that's us um here's some of our clients um so you can see yeah there's a lot a lot of higher ed there um and that's pretty much who the kinds of people that we work for and the kinds of the size of the projects that we're working on sorry about that okay um so today i'm gonna i want to talk to you about um design driven development this is something that we've been working on over the past few years to try and kind of flip the table on traditional traditional workflows when it comes to development um if you think about the the normal life cycle of a project after the discovery and um there's a design phase that's happened um generally you know you get your back end developers come in someone's working out an information architecture um so that they can build out the content types the entity types the fields and drupal they go away they build that and then once they're done with that it's then the themeer's job to try and somehow nail the design onto what drupal is spitting out um this is just this the way we've approached it for years um but but you know there's there's some inherent problems in in that um and what we wanted to do is try and have the design be the thing that is that is informing um what drupal looks like and the actual html the markup for css um so i'm gonna like pull pull apart our workflow a little bit and show you how we've um been out being able to do that um if you think about um you you hire a front end developer because they're good at html css and javascript you hire a back end developer because they know drupal's apis they know database abstraction layers and and all that boring stuff um but um with drupal we kind of end up with this kind of in-between job of the themeer where they're they're kind of like what are they are they are they a back end developer are they a front end developer like they need to know they need to kind of ride that middle ground and and in some ways they're a bit of a unicorn because there's there's not a lot of people that that are that are really good at both things um so in in a in a way we're trying to empower front end designers uh developers to do what they do best and and leave the back end developers to do what they do best and try and limit the amount of crossover that happens in in that space so the thing that we use um to the the the main people that that are involved in in this process are these people here rob loach who is probably the most drupal famous canadian um myself tiago who is a designer and front end developer derrick draps who's a uh um drupal guru um no i wrote wizard here he he used to be more of a wizard but he's shaved off his beard now so yep and then also andrew who is our spiritual leader guiding us through the rough seas um i spoke on a similar similar subject last year with rob at um drupal north in montreal um so i'm going to be covering some of the same things but um lots has changed um in the drupal world i feel like we've gone for last year it was drupal seven you know drupal eight was here um you know like we're starting to play with it but you know in terms of like big um heavy production sites it was still kind of not quite ready for prime time we weren't doing a lot of uh i don't think i don't know if we'd done any at the time um but so between then and now um we've switched over to basically all all new sites that we're doing in drupal drupal eight sites um so far and um yeah so that that means a lots of different things and it's it's opened up a bunch of capabilities because of you know drupal's adoption of twig and that sort of thing so um lots has changed on on our end too and in our um in chastatic about the framework that we're that i'm going to be talking about um because we no longer have to deal with uh drupal seven as a as a thing um okay so just quickly um white prototype um prototyping is is definitely something that uh you know probably doesn't happen as often on smaller projects so the kinds of projects that we're working on um you know it definitely that that can dictate to the fact that that we're prototyping um but the the main the main crux is that when you're building a large site um we want to minimize risk because we don't want to we don't want to go down a rabbit hole you know and end up having to backtrack you know we want to we want to be able to like prove our work um and minimize the risk before before uh before we get too far down down the uh development road i'm sure if any of you are uh uh back end developers you know you've probably had you've probably had situations where you thought you knew what needed to be done and you did it and you've nailed everything to the floor and then you realize it would have been better if we did it like this because of some other requirement that you weren't thinking about or a new requirement something like that um so uh yeah you can you can waste a lot of time on that sort of thing um so um when you're using when you're using static content files in a prototype you don't have to wait for the cms to be set up um to start entering content um which is which is great also not only um for building building stuff out with real content but it's also helpful for actually proofing the content because content content needs to be user tested and and and iterated over as in the same way that our development does as well um so being able to explore design ideas um without it affecting the build um is also a useful thing um most of you are probably familiar with agile um development methodology um you know the idea of of you know like doing what you can in a sprint and then iterating um it can you know we like to apply that to the design process as well you know so that we're we're um you know getting user feedback early and and iterating on that feedback and constantly improving uh and and with a prototype you can do that before committing to the actual hold build um there's another big advantage um with the way that we work is that front end and back end um can happen ahead or simultaneously to the to the uh to the back end um so that helps to be able to you know like work at the same time save time in terms of timelines if the front end people can be working on the same component as the back end people you know and hopefully they converge in the middle rather than having to wait until it's already built out in Drupal I think it's crashed let's go oh here we go okay so this is kind of like a diagram of our workflow um so over here initially we've got the um you know the discovery uh that happens and then the result of that we end up with uh design comps and style tiles sometimes both sometimes one or the other and so as soon as we have that as soon as we have that stuff the front end developers can get to start working on the components of the design um and they can start building the html to css to the javascript that's required to to build out um the comps um they're doing that with the css and twig layouts is all part of that um and then at the same time we've got the the Drupal developers up here building out their uh building out side side building and you know also any custom code that needs to happen um so that's uh that's that's what it looks like um and then this one is is kind of like between me and tiago we kind of like hold this the holy grail because we're you know like um tiago is a designer um he's he's not from a Drupal background he's been working with Drupal but we we love the idea um of and i think pierre was talking about this um just at the end of the last session um the idea that you can that your front end is agnostic from your back end you can be building out the styles and the twig templates from a from a design yes we're going to use it in Drupal but you know what else are we what else could we use it in if you think about like a large organization that um that has different platforms across different departments or whatever you know that something like this can enable them to to you know one department to have a Drupal website and then another department to reuse that same twig templates and styling for you know any any other frame any other like back end framework um yeah okay so calla static is what we call our front end framework um essentially um it is a prototyping framework um it generates static sites um and it supports markdown and jason um to for the content it is also a living style guide in the same way that you're probably more familiar with something like pattern lab um it's a similar kind of deal there um where we're taking um it's basically just a list of a configurable list of all the components that you've built out on that you can use on the site um we don't enforce atomic design uh like atomic principles in the same way that pattern lab does um but we agree that it's a good idea so we so we do use atomic um uh principles to like um to group all our components molecular molecularly is that a word um but uh yeah we we're we're using we're using that kind of methodology to to keep things sensible and sane you know in your folder structure um and then bring that bring them into bring the components into triple steam layer um and yeah in general it's it's just a it's a solution for lean ux and if you're familiar not familiar with lean ux is what I was talking about before about an an agile uh methodology and an agile approach to to designing and you know iterating getting user feedback early so that you can iterate and um end up ultimately end up with a better product um so um anyone that's looking to develop prototypes or style guides if you like the idea of sharing style guide components um the CSS the JavaScript between a prototype and Drupal Drupal seam layer um if you're interested in sort of decoupling um you have a requirement to maintain a mix of cms and non-cms pages um or just you know rapidly and the need to rapidly build out a bunch of components um then this could be for you so we're talking front-end developers that's having designers um and a back-end dev that you know is working in collaboration with the front-end dev um any in-house teams and agencies we actually have some experience recent experience um using calla static um in an internet interagency kind of space um and I think it's been successful um the couple of times that we've done it um so yeah but you know if you if you think about you know sometimes you get like if you're a you know a back-end heavy Drupal shop and you know you work with with a with a designer a different agency that's a designer or front-end developers and you know there's there's lots of space for like collaboration there um what was it oh yes how it helps so prototyping in the browser um and testing early is is one of the main things that we find is fantastic about it um there's nothing worse than getting through to the end near the end of a of a development cycle and having the clients start looking at and playing with it in the browser and having them go this isn't what I what I thought um this this isn't quite the same you know like looking at a static comp and they can go yeah that's cool though I think that's good but when they start actually looking at it in a browser playing with it resizing their browser doing all those sorts of things um that you actually do with the website there can be problems so when you when you're prototyping you can address those problems earlier and you've got time to iterate before before you really like nailing down the information architecture or you know building out content types and entity types and fields and stuff um yeah the I'm having a style guide is great because it acts as documentation um you know so a lot of our projects start off in a big push um in to to build them and then once they're done that they then go off to a support team um who aren't necessarily always the same people that built the site um so having a style guide is great in in in that sort of circumstance to um you know inform those people if if a client comes back to you and goes you know what I need these three extra components done um it's not going to come back as a it's not a big project so it's not going to come back to the people that built it it's going to stay in the support but those support guys have this style guide that they can base these new components on um visually and you know like um programmatically and um functionally um so that's that eases things in that sort of a situation um calisthenic um has um um been around we it started development in dripper seven um and has and we've now moved on to using it in dripper eight um we made the decision whilst but before it was dripper seven we weren't actually using twig but we knew dripper eight was going to end up with twig so we at some point we switched our templating engine to twig um and so one of the advantages of that even if you're using calisthenic on a dripper seven site is you know migration is easy you can you can inherit those templates you know if a migration happens down down the road um and um we also wrote a little module called the twig shim module which lets you use twig templates in dripper seven um and I'll show you that a little bit later um but I'm not going to harp on it because like I said most of the stuff that most people doing now I think are eight so um calisthenic is calitastic my wife made me put that in I'm sorry um yeah so what what about small projects you know like not everyone has the budget for the these big builds with you know like prototyping and iterating and all this stuff um the cool thing about calisthenic is you can build you can build just static websites with it as well um our company website calisthenic.com is built with calisthenic um and it's not driven by Drupal at all um because it didn't need to be because Drupal's not the answer to everything but that's a whole nother talk right um yeah so you can you can be on your page one day at a time um using markdown for content is is great um and you know you can throw any you know we we use bootstrap for a lot of our projects but there's nothing in calisthenic that is tying you down to using bootstrap you can use in in combination with any other front-end framework um so just really quickly I'm sure most of you are familiar with the principles of atomic design it's just a way of organizing your um your content your uh components um in a sensible fashion um so you've got small elements like an input or a or a link or a heading as an atom bigger components is a collection molecule is a collection of atoms and then an organism is a collection of molecules um and then uh that's just an example from bradfrost where he's taking the content sticking in a layer adding the components and boom you have a page um so that's the general principle that we that we stick to but again like I said before there's nothing inherent in calisthenics enforcing this on you okay so now this is going to be hard we have to sit down I think I just want to show you what it looks like because I've talked a lot of theory here but uh let me show you in the code editor what it actually looks like okay can you guys see that should I zoom in a bit it's okay okay I tried to go with a light background because it's so everyone can see it um so the um the very first thing to look at um I didn't mention um calisthenics is actually a node module um so you can see here we've just added calisthenics to our dependencies so all you need to do um is either do that or in the command line just go um the npm oops uh npm required oh no it's not required anyway you know how you know how the npm works I've been using composer too much lately um yeah so you just need to install install that and um and that will bring it down for you and you can start using it straight away basically um the the main thing that controls it is this calisthenic yaml file so this is where we set up all the options um for things for things that it's going to use you can tell it where it's living uh where calisthenics is going to live within within your site we generally stick it in the theme because at the end of the day the drupal theme needs to suck in the javascript and css um so it makes sense but there's no there's nothing inherently saying you need it needs to live in your theme um you can you can tell it where it's going to build out to there's a bunch of different options there um that's uh more detailed but um you know you can control how your sass gets built you know with node sass um twig namespaces is a is another interesting thing we've set this up so that so that in our templates we can just reference atoms and it and it will it will uh know where to look for the templates that you're referencing um and say for molecules organism layouts um the other thing that we've done for drupal integration is to we've rewritten drupal's twig filters um in in javascript so that uh so that we can use the same filters both in a static in the static prototype as well as in drupal so you'll notice these are some of the same twig filters that you can use um in drupal uh one note the trend the translation one doesn't actually work we like we haven't got that far yet it's not actually translating anything it's just returning the string that it was passed but but it means that that we can use the same templates in drupal and cala static and it won't throw an error saying it doesn't know about that filter um and then we have uh set up for kss and i'll i'll get into kss uh soon because that that's kss is what's actually building a style guide for us um so uh yeah there's a bunch of options there um if we dig down into the folder you can see it's just in themes i called my theme my theme that's not confusing at all um and then we just got a cala static folder there and a source folder inside of it um so let's look at a component so you can see that we've got and we've got them laid out atoms molecules organisms layouts we've got that extra pages one which is which is kind of more of a drupal thing because you you know sometimes when you have like a views page or something you need to start specifically but uh let's look at no let's look at a tout so yes this tout is a single component so a single component is made up of a sass file adjacent file and a twig file um so you can see this is just a regular twig file looks fairly familiar if you've done drupal 8 development um there's nothing interesting or different about that um the jason file stores the content uh that populates the twig file when we're building out the style guide um and then the css uh the sass is just it is sass the only the only interesting thing about the way that we do sass I think is um we use use the extendable um extendables to define our styles and then apply the extendable to a class we find this is useful when theming things because it means that we can especially in a drupal context because you know like we've all experienced like drupals awful divs and classes that it spits out not so much in 8 it's definitely getting better but in 7 it's definitely been a problem you know and so targeting the right thing here um targeting the right right thing with your css has always it's always been really tricky but here you know we can we can add this this other top blah is is also get stalled like this that's the advantage of using extendable so that um you know we can we can throw this style in any direction that we want um yeah and then up here we have the the kss comment so this is the this comment actually um kss passes these comments and actually uses it to build out the style guide so I will show you what the style guide looks like now um all we're going to do is start her up of course oh i'm in the wrong window sorry it's this one okay so um we have browser sync installed in this so as soon as it starts up um browser sync uh starts up and then it automatically pops up a window which has our prototype in it which one is too big so let's visit the style guide first did i steal that wrong i can't see there we go okay so this is our style guide um and you can see we have a whole bunch of components listed over here um so we're coming here and let's find the top that we were looking at is this one so just so you can see you can match up the uh the oh no we were looking at this one so you can see these comments get passed and turned into a style guide component um and so any any sass file that has the kss in there is going to get um pulled in and becomes part of our out of our style guide um you can click on the markup button and it's broken of course oh there it is okay so so it shows you the markup that's that's been used to generate that that components and uh and that's really cool um so there's some other things um to do with the prototype um let me show you a prototype page inside this uh the inside this folder so the prototype is built with metal smith it looks for these markdown files and any any markdown file it's going to know that you have that's a page you want to generate in the in the prototype um we just tell it which layout to use give it a title that these are arbitrary variables that will get passed to the page template that's you being used to build and then you can add all sorts of content in here alike just as um static content there and so it's going to come when we when we run npm it's going to come into it's going to find this index dot twig which is here and you can see all we're doing here is including this component as well as printing out the contents which will be this what you know any content that's here so that that is that is how we're generating where did it go sorry it's really hard to see the screen from there okay so that's what that's what we're using to um to generate the prototype so this is my hero component that I had printing out on the page um and then that's the content that that we saw before so other interesting things is um there is a config which uh which lets you set up config for the for the prototype itself so you're just telling away your style sheets are where your JavaScript is and you can put JavaScript in both the header and the footer um because it is it's using this page template sorry there's actually no dot twig which is going to print all those variables out at the various spots on the page so that's that's kind of the basics of calisthenic um it's kind of involved but it's once you get a hang of it it's super useful and it's very quick at being able to build out lots and lots of components and then you just start because of the power of twig being able to just include things on the page it's very easy to build out big you know layouts and lots of different different pages to build out a prototype um all right let's go back you know i've lost the present button the internet has died awesome what's going on does anyone else get kicked off the wi-fi jeez i have no wi-fi sorry you know what i can do that it's loading really of course i've got like one bar of free g so sorry about this guy um okay where were we back on track okay so most importantly how do we start using it with the Drupal okay the very first thing that you're going to want to do is install the components module um so the components module um adds namespaces for um your twig comp for your twig um templates so you saw before where i set up namespaces on the calisthenics side so we had atoms molecules um organisms and layouts that's that's for that's for the node side of it uh the component components module lets you do the same thing but for Drupal so you define you can define um twig namespaces in a theme like your your theme info info yaml um and so that way you can you can pull in components just by just by saying at atom you know and then the name of the of the component um it just it's it's just kind of like syntactic sugar it's just enables you to go faster be less verbose um when you when you're writing templates um oh yeah and that's one thing that we yeah that we noted it's only in a theme file you um rob has submitted a pull request to to let modules do it as well but um that still is outstanding so um that's what it looks like so it's it's easy to find it's it's like very familiar because it's yeah it's yaml um we'll come back to that okay paragraphs so you everyone's probably familiar with paragraphs is everyone used paragraphs before yes yeah um if if you're not familiar it's just a it's just a a way to kind of like componentize your content um on Drupal's back end um but the reason that we use it is because it maps really well to the way that we're componentizing things on the front end so um that's really cool but um you already said that um okay what calligraphs we we started using paragraphs and and initially it was really cool we liked it we liked the way things were integrating between the front and the back end but we found that things started to get really verbose uh we ended up with lots and lots of paragraph types um and when you have lots of paragraph types it bloats out the the node edit forms so you've got these huge lists of different paragraphs that um you needed um also we found we're ending up with a whole bunch of different fields um for those paragraphs but what we noticed was that that for the most part most of the components that we would that we were you making paragraphs for had very very similar types of fields so they often it was a title a text field an image field and a link field and between those four things we could make most of the components that we were trying to make so Derek went about and decided to write the calligraphs module um basically what it does is it is it creates a single paragraph type on your site um with those four fields set up um so that makes that means there's less bloat in the you know in your database there's less bloat on your edit forms um but the cool thing is that is that you can you can switch between the different types of components without losing any data so if the content editor in the previous um iteration um did up a did up a paragraph with a whole bunch of um text out of the photo did all the tweaks that they wanted to do and then they were like hold on this was the wrong this was not what i wanted to do there was no way for them to convert this paragraph into another type of paragraph but because we're using a single paragraph on the back end it's easy for us it's the the data is the same it's just what it's just a visual look of the component that's changing right um so that's really cool and that's something that that the um clients have found really handy to be able to switch switch between component types all right so let me show you what it looks like in Drupal if i can find my cursor okay so this is Drupal so you can see we have let's go paragraph types ignore this sub component one for now that's uh that's something else but um it's it's out of the single paragraph type call component um and you can see um it just it automatically makes this paragraph with these fields again ignore the sub component thing um we've this is we've still got a bunch of things in development and improvements that we're making but um yeah so that's what it looks like and that's the the the kind of the basic entity so then if we go to add some content oh sorry no i should show you what the got a basic page and show you the fields so we've added the we've added the the field which references components um to this content type um i think you can see oh well i'm not limiting it but you know you can limit it to just adding the the calligraph component um so if we go and then we add a page um we've got a title like any any other node but then we get we here we get we get this list so we've got a single component that we can add so we add a component but then you can see first off you get to choose which type of component you want to add um but on the back end all of these have exactly the same fields so you can see a cta has all of them title text links and an image whereas this call out component we're hiding most of them because this call out just requires text for that component but in the in the back end this text field is all the same so if we've got we do have subtitle uh as an extra field sometimes um so that's the that's the way it works and it and other than that it it works exactly the same as as all all other paragraphs workflows um with the added advantage of being able to change what your paragraph looks like based on uh this display as drop down so in the back end it gets a little bit ugly but it's getting better really really soon so currently the way that you define these um display types is using a constant in a custom module so yes that's very ugly um but where we're kind of like just getting over the um development hump um to make this much more sensible and usable um but you can see here that let's find cta tau so you know it's just an array of information um what this is called will actually map to the template that it looks for so by calling it cta uh tau dash dash cta um calligraphs when it's when it's outputting the the view for the um for the paragraph it is going to look for tau dash dash cta dot html dot twig and because we set up the namespaces with the components um Drupal Drupal knows about this and um it will find it so then uh oh sorry you have to specify this path too as as part of that because it lives inside the molecules but other um but other than that it will find it and then here's just where you define which of those fields that you that you need on that paragraph so the future will involve uh us being able to define this information inside of this component in in the theme so the that you know in here we'll either add it to the j we're still trying to work out um which way to go we'll either add it to the json array um as a special um a special item in that array or add it as a yaml file which will make it probably a bit more Drupal e if it's a yaml file um but but that gives that gives us a way to define the the content structure and what fields are going to end up on that on that um component um without a back end developer having to do anything and you know when a when a front end developer is coming here and they're building their tweak template based on their designs they already know what variables are going to get stuck where so so we already know that information but um so they can just they can just annotate that in another file in there then there's even less work for a developer to do to come to come along as soon as you save that information um refresh the page you don't even need to clear the cache uh cache sorry that's my that that's me being Australian again uh you don't even need to clear the cache um and it will turn up if you add it a new one it would turn up in this list as a as a new component that you can add and it's autumn you know as soon as you save the node it's going to get it's going to get stopped so let's uh let's feel like um testifying so let's find a really bad photo of me i don't know why i have like these terrible photos sitting of me and sitting on my desktop um and then we'll save it and you can see there it is on the page styled in the same way you will see if we go back to the style guide we'll find the testimonial component in here somewhere just a minute and you can see that it's it's styled the same way because it's sharing exactly the same twig template css so that's kind of it that's that's the kind of like magic source um like i said before we're you know like we're trying to ease the um ease the gap and the friction between the front end and the back end we want to let front end developers do what they do best um we want to we want to let the back end develop developers do what they do best and and try not to like have too much of that middle theming ground where you know where there's just kind of like whose job is it um and who's good at it um the last thing i will throw in as what's the time we're getting close so we are getting close um the last thing that i'll throw in as a bonus but what about Drupal 7 um this might be interesting for some people um yes we worked out a really easy and simple way to use twig in Drupal 7 and and without adding any sort of overhead basically at all um in terms of like render um Derek wrote the twig shim module and basically what it does you and saw like composer like with our composer with uh like with ultra plate um the main thing that it does is it defines this twig shim render function which takes um a path to a template and takes a set of variables which is the content that's going to be popular that's going to you're going to you're going to populate the template with and you end up using it like this so you can override a theme hook so this is like a for a single a theme hook for a single search result you can see um and all we're doing is we're said we're telling uh which template to use and then we're just pulling we're just pulling the the actual data out of the variables that have been passed into the theme function and then returning twig shim render and all twig because at the end of the day a theme function just returns markup like um if you look at any Drupal theme function in 7 all it's doing is returning a string of markup and that's all twig does too it just returns it's a string of markup populated with all the variables populated with the content so um you can you can do this sort of thing and um oh there yeah there's an example of the uh of the actual template itself so it you know it's just vanilla twig um and then the the uh the end result is twig templates in Drupal 7 so that could be handy for someone I don't know but um we found it really useful while you know in the in you know before we started really heavy Drupal uh Drupal 8 development and that's it everything that we do is open source so if you guys find this interesting please talk to us contribute um there's calisthenic on github um calligraphs module is really close to being published on Drupal.org we just want to get over that last hump of getting rid of that big constant array because that's ugly um and and we want to make it more useful for regular folk and uh yeah talk to us about it hit us up on the github if you're interested um and and let us know what's cooking that's it any questions we've got two minutes yes it's just twig files and sass and JavaScript I didn't really show you the show you the JavaScript but we um we you know like we we would like to get to a point where where each component has its own JavaScript file potentially you know if there's a if that component has its own JavaScript and you know like we have a way in calisthenic to concatenate for it to just look through all the JavaScript files and concatenate concatenate them all into a bigger JavaScript file um and we also have a little trick to uh to write our JavaScript on the static side using behaviors so that it's compatible with Drupal so it's just a matter of like defining you know the behaviors object and then calling it after your your own JavaScript is as has been run but yeah there's little tricks like that to you know just make it easier with the people but yeah that's it no one else cool thanks guys