 I'd say wait for people to find this place, but it looks like everyone's already found it, and then some. So I'm just going to kick off here. My name is Micah Godbolt. That's all my info here. So I want to say if you want to follow me on Twitter, Micah Godbolt, I will make sure to tweet out not only the slides for this later on, but also I've got some demo code that I've kind of moved around, so I need to create a new repo for it, but I certainly want to make sure that's available for you as well. So that's a little carrot to follow me, because I'll be tweeting that information out so you can get a handle on it. A couple other things about me. I'm a friend and developer at Lollabot. I've been there for about the last year or so, and it's awesome. I love Lollabot. I just have to say that and contractually obligate to say that. So I said it. We're done? Good, all right. Lollabot.com slash jobs. Yes, we are hiring. All right. Trip Lies, capital D, capital. Anyway. So a couple other things about me. I'm from Portland, Oregon, out in the States. This is my second DrupalCon. Obviously, my first one was when it was in Portland this last year, which was quite nice. But my first time speaking, so thank you for crazy stuff in the back and everyone that's wanting to come out here and shove in. There's some more room up front, so if people want to still come on in, we'll try and, I don't know, we'll fake it till we make it. A couple other things about me. I am also the creator of a series of videos called SassBytes, which you can also follow on Twitter at SassBytes or YouTube.com slash SassBytes. If you're interested in front of development and especially Sass, using Sass to really power your front of development, that's what SassBytes is all about, so weekly about 10, 20 minute presentation I give on everything from directives, loop statements, mixins, functions, all that kind of stuff. So if you're curious, you can check that out. Those are obviously recorded and put on YouTube. Also, the founder of PDX Sass, a Sass Meetup that we meet monthly out in Portland. We're coming up on our fourth month, so it's kind of nice. Those are also recorded and posted live, which is a blast. We actually have two or three people. I think there's someone from Italy that watches every week. It's kind of cool. We can just broadcast Italy. So we do that every month, second Thursday of the month at 6 p.m. Pacific time. Again, it's recorded, so you can find it. And the next one we're going to do is actually, hey, that's kind of cool, is you still see the slides. The next one we're going to do is an actual Sass Bootcamp, because we've been doing it for a little while and we want to make sure that all the new comers get a chance to just kind of get up to speed and we'll have some hands on stuff there. So if you're out in Portland, please stop by. Or you can check us on at PDX Sass on Twitter, get some links to all of our videos and those kind of things. So let's get on to what this talk is actually about, and not me and my little side projects. But clicker works, cool. Creating responsive Drupal prototypes with AngularJS. It's a nice packed title. The title has two parts. The first part is this, is creating responsive Drupal prototypes. So what we're talking about that is actually starting, not in Drupal, but actually starting in code, building as much of the site as possible from prototypes and wireframes all the way into an actual design process before we even get into an actual Drupal install to do as much as that is possible when code is cheap and when changes are cheap. Because once you get into Drupal, you know that changes are not cheap whatsoever. So that's what the first part of this is going to be about, is explaining why this is necessary. And then secondly, with AngularJS is going to talk about how we can leverage a system like AngularJS to make that possible. So let me give you a quick idea of what we're going to be talking about during this entire presentation, what to expect. The first thing is with creating responsive Drupal prototypes. This is an approach. What I'm going to be talking about is not specific to Angular. It's an approach to designing prototypes in the browser for Drupal or really any content management system. It is about designing in the browser. So if you're not designing the browser yet, this is going to be your call to say, it's time to start. It's time to think about it because the tools are actually there to make this happen. Thirdly, it's about getting the front-end developers involved in the process much earlier. I've been on way too many projects where the designer is done, it's designed signed off, and it's passed off to me as a front-end developer. And then it's my job to go like, oh, why did you make those decisions? Why did you do that? And to spend all that time that if I just had a chance a little bit earlier in the process to maybe make a small few tweaks, that life would be a lot easier for me. So that's really what this is about, is getting the front developer in earlier, because there's code instead of Photoshop files, and we can deal with code, right? And so the second part with AngularJS, what I do want to say is this is not the only way to accomplish what's on the left. AngularJS is just one of the opportunities, one of the possibilities. When I started this project, I actually started in Jekyll, and then after a little bit of Jekyll, I actually moved to a Ruby gem. And then after that Ruby gem, I moved to Angular. So this has been through three iterations already. And after the twig presentation I saw yesterday, I'm like, this might eventually move to twig. Because there's a lot of the concepts in twig that are really similar to what I've been doing in creating with Angular. So especially when D8 gets really solid and twig is there, and we kind of know what this final template's going to be like, I'm really hoping to maybe start using twig for the same thing. Again, and we need help for that. And we need help for that. So just to say, Angular is not the only approach to this. The other thing is, this is not an Angular app. This is usually what scares my designers. It's like, I don't know how to write Angular, and I don't want to learn how to write Angular. I'm not asking you to be able to write an Angular app from scratch. What we're doing is, actually, let me do this. So this is not an actual web app. This isn't like a software as a service where you go to a page and click on things, and you get pages to do stuff. That's not what we're trying to do. We're also not trying to create a full MVC just for a prototype. Really what we're doing is we're using the view layer of Angular, and using Angular as an actual templating system, kind of similar to how you'd be using twig in D8. But of course, we're still dealing with D7. So Angular works really well for that. So along with templating and also the directives that are included in Angular, there's a lot of power that lets us accomplish this. So that's what we're going to be talking about. There's kind of these two halves. The first one talking about why we need to be doing this. And then secondly, how we can accomplish this with AngularJS and really with any framework. Any framework that supports these concepts. So oh, and also Angular is also the foundation for Tractor. Tractor is this project I'm currently working on that is built with Angular to do this. It was actually originally called Protractor. Then I found out somebody is using Protractor. Protractor is such a great Angular name. I was so mad. The life goes on. So it was shortened to Tractor. And it just happened that Emma Jane had a huge picture of a tractor in her place. And I was like, there's my inspiration. It's based off a picture in her living room. So this is what a built page would look like when using Tractor. As you can see, what you're doing is you're just just like you would really design in the browser, write HTML in the browser. And that gets compiled into a page like that. So on the left-hand side, we have a page manifest which describes all of your layout, describes your blocks, regions, whatever you want to call them, and also the parcels inside. So if you saw Fabians talk yesterday, it's exact same concept. I was like, he's stealing my stuff. I swear. So you can define your layouts. You can define your regions and put content inside of that. It's also the concept of parcels. So all of your HTML is broken out into smaller parcels that can be reused over and over again and then placed into those page manifests. You can also put straight HTML in there as well. It doesn't have to be necessarily a partial. But typically, you want to break everything out as much as you can. So again, this is a quick mockup I did for a project a little while ago. This is more in the prototyping phase. Once this was done and the customer is happy with this layout, we move in and design using this exact same tool, just applying designs and styles and some kind of design pattern to everything. So this is what we're going to be working with in the second half. So I just want to give you a little teaser to kind of know what our finished product is going to look like. This is Tractor today. Small. It's still a work in progress. And there's a link as well if I want to take a quick shot of that. It's our Lullabot GitHub account slash Tractor. I'll have a slide at the end as well, so don't worry about that. But this is what I'm hoping Tractor is going to be when we're actually finished with it. It's certainly a work in progress. Every chance we get to add a little bit of functionality is pretty cool. It just adds another tool that makes the life of a designer and front-end developer a lot better. And I was just able to do one actually just a couple weeks ago when I was really happy to get in there. I'll demo that in a bit. But it's a great process. Continue to refine it, add in functionality, and hopefully we'll get that beast when we're done with it. So before we take a look under the hood of Tractor, and I keep going to have notes here, cool. All right, what we want to do is take a quick look at why we need to do this. What has led us up to this point? And what are the frustrations that we're really trying to meet? And to do that, I want to tell you a story. I love telling stories, as everyone here, well, and we hear that knows me can say. And I like to talk a lot. So it just seemed like a good fit. I'll tell a story. But just to note that the people in this story are fictitious. They are made up. And so any resemblance to people either living or dead or in the future is completely coincidental. So it is taken from personal experience and experience that co-workers have had. So I'm not making this stuff up, but it certainly did not happen in these order of events. So this story, like any other good story, starts in a bar, because that's where all your good stories start, especially in Prague. So I was meeting with a designer friend of mine on Friday night, as we do every Friday night. It's kind of our Friday night ritual. We just get around and just talk about life, talk about work, talk about whatever. But this time, the designer, with a nice, really healthy shot in his hand, would not stop talking about the golden age of web design. Me being a little curious and maybe a little bit too naive, asked him to explain, what is this golden age of web design that you're talking about? And he said, well, back in the day, because he's one of those back in the day designers, back in the day, when you want to create a prototype, it was simple. You would just open up the most current version of PowerPoint, and you just start laying out your headers and your footers and your sidebar and your sidebar and your third sidebar. We really love sidebars. And you just lay out your content and the client would go, yep, that's perfect. That's the number of sidebars I want, and you can move on. After you're done with that, you would just open up Photoshop, go 960 pixels by, well, you know, that fold, that magical fold that everyone wants, you hit that point, just perfect. And you make your design. It's beautiful, it's gorgeous. I seriously, to find this, I look up horrible web designs and just Googled it, and this is what I came up with. So if you design this, I'm really sorry. So when you're done with this, all you had to do is get signed off by the client, pass it to the front-end developer and go to Fiji because your job was done. Yeah, as long as a front-end developer was competent enough to make a website that looked exactly like this by slicing and dicing and doing whatever you need to do, your job was finished. That was it. It was easy. That was golden age, and it was wonderful. But then something happened. I think we all kind of know what happened. It was this guy, and it was that thing. That happened. Now everyone's, instead of looking at the websites on his big monitor, they're now looking on these tiny little phones. So now I've got to do two different layouts and got to do two different designs, and that's twice as much work. I don't like that. All right, and then this happened. Crap. Now we've got three of them. I have to do three different designs because they want to know what the tablet's gonna look like and the desktop, and they want to know what the phone's gonna look like. Well, and then just the dam broke and this happened. This is Samsung's current offering. Actually, this is even a little bit old. 26 different devices. 16 different screen sizes. When there's a great website out there, I think it's screensizes.es.es. Yes, at the end or something. The basic catalogs, all the different screen resolutions that are out there. And there are 50 plus different screen resolutions on mobile quote unquote devices. That is a lot of break points. And there's no chance we're gonna hit every single one of those with Photoshop design, with a prototype, or anything like that. So, what in the world am I gonna do? And so, that was his spiel. And of course, as a friend developer, I've got an easy solution. Start designing the browser, yo. What are you doing? Because everyone knows that a text editor plus a browser is ponies and rainbows. So, that's what you need to do. Obviously, as a friend developer, that's what I say. So, incredibly inspired by my amazing speech. Remember, it was probably just the ponies, but incredibly inspired. He goes off to do exactly that. So, week goes by, the next Friday night. And this guy definitely wants a picture. I'm gonna wait for that. The next Friday night, we made it up for drinks again. I'm expecting, you know, it's gonna be a good story. We'll see how this goes. So, back same place, same time. But there's two drinks on the table now and his face looks a little concerned. So, I ask, how did it go? And so, he starts off. Well, I started by doing extensive research. And after five minutes, I found this. Solved all my problems. I could quickly put together a page with my headers and footers and buttons and rotators and more rotators and more rotators because that's what they want. And life was great. I had my design up and going in no time. But there were some problems. Well, those problems, I asked. Again, at this point, I was probably just egging them on. Well, the first thing is, the client didn't wanna end up on this site. And if you can't read it, it's yet another Bootstrap Tumblr log. Bootstrap sites tend to, if you don't put a lot of effort into it, look kind of the same. You got the bar up top that's sticky and the navigation that works just the same and the buttons look kind of the same and might be different colors, but you have to spend a lot of time really customizing it to get away from that look. Secondly, the front-end developer wasn't too happy. He was actually really kind of upset that he had to include a 25K JavaScript file just to get this navigation that the client fell in love with. It's like, that's a lot of weight for mobile nav. It's that, or I have to build the whole thing over again. And thirdly, the back-end developers got a little annoyed after my 30th pull request to add yet another span something class to a div. This is Drupal. What are you thinking? Don't do that. So the process didn't go too well. In the end of it, no one was really happy and I don't think I'm gonna do that again. So just to backtrack a little bit. I don't hate on these foundation, Bootstrap, those types of things. I'm not a fan of them. I know a lot of people use them for prototyping. But if you were just prototyping, and this is perfect, Sam is here. He didn't know he was gonna be called out. If you're just prototyping, I went one too far. There we go. If you're just prototyping, you need to remember that that prototype is probably gonna disappear. It's probably code that's just gonna be developed for one particular purpose and eventually tossed. And you need to be prepared for that if that is what your plan is. But what I'm trying to propose, and we were trying to do it a little bit, is we're trying to take this prototyping, we're trying to take the wireframing into prototyping all the way into the design phase and into the Drupal site. And so with that in mind, my response to him was, yeah, but you need to build it with quality in mind that you might be stuck with that. You might be stuck with that JavaScript. You might be stuck with those classes and all of those behaviors. So when you're doing this process, you need to be thinking from the beginning, like, is this the code that I wanna inherit when I start building a theme? Is this a SAS structure that I wanna inherit when building a theme? Is this how I wanna apply those styles? Am I gonna have to put span classes on every single div in this entire site just to make this layout work? Think about that stuff when you're building. And that's really why I think that something like Twitter Bootstrap Foundation is not the best solution for this. Because it gets you up through prototyping, but it doesn't get you into designing and theming. So my advice to him was skip the Bootstrap or anything like that and just write straight up HTML, CSS as if you were with the end goal in mind. So again, extremely inspired, but no ponies this time. I just must be doing better for some reason. He goes off and does it. Next Friday comes along. I'm thinking this will be good. We'll see how it goes. Unfortunately, this is his order. So after a row of flaming moes, if anyone's seen it, I knew it's gonna be an interesting evening. So I asked my designer friend, how did it go? I will really wanna hear. So he says it started out fine. This is this story. I built a page. Built a page from scratch, just used a grid framework within Compass and that worked out really well. It was very easy. It was about one page, about 50 lines HTML, about 100 lines of CSS. That was pretty good. I liked it. It was nice and clean. I would be happy with this code in production. It works. But then, of course, this happened. We don't need just one page. They want around 20 different pages. So 20 pages, about 1,000 lines HTML, and about 2,000 lines of CSS. It might be a little exaggeration, but math is a lot easier when you just multiply. So just suffice to say, there's a lot of pages. There's a lot of HTML. There's a lot of things to keep track of. Because after that happened, the inevitable comes in like navigation. Can you just add one more item and that sidebar block? Can you just switch the order with something else and add a class to that one thing right there and change request after change request? Change request, which was multiplied by 20 because all these different pages repeated HTML over and over and over and over again. This process is so difficult to maintain. By the end of it, I'm trying to remember where we're at. Oh yeah, oh sorry. Then after that, I built a mobile navigation. It was great. I spent days on it. I loved it. The client said, no, I'll just have a drop nav. Click on it, go to the footer, we're good. There's two days lost. All right, then I spent two more days working on some awesome tabs, like all the JavaScript behaviors and all that just so it works perfectly. Then I remembered, wait a minute, Drupal just gives you that for free, doesn't it? Why am I spending days on this? Seriously, these are things that have happened. So the amount of time that was put into this project just to make some of these simple things happen, it became unmanageable, unmaintainable, and seriously, in the case where this happened, for me as a friend and developer, I pretty much looked at the mock, so I went, okay, that's nice, I'll build it again. So in this case too, it's not something that's gonna get you all the way into production and it was scrapped and pretty much tossed in the garbage. So after the 10th Flaming Mow, we felt pretty defeated. And when a couple of developers feel defeated, there's only one thing the respectable developer can do and that is karaoke. So unfortunately, that was the end of our night. That's the end of that story, but that's not the end of the story for Tractor and AngularJS, because I was able to take all of those frustrations, all of those things that I've learned over that time, and Tractor was born from that. Tractor is a wireframing, prototyping, and design framework. It's really just an empty shell that gives you the tools to be able to create these pages in an organized way. It uses Angular as more of a templating language and also, if you're familiar with Angular, and actually I forgot to do this before, who is familiar with Angular? Pretty familiar, that's probably why you're here. Secondly, who's used Angular, or built something with Angular? All right, and how many people have used Angular to prototype HTML webpages? Okay, good, not too many, otherwise this would be way too short. Joke's a lot better at the beginning of the talk. So what we're gonna be using is Angular as a templating language, but also as a way to extend the DOM, because that's what Angular is awesome at, is creating new tags, new directives that add functionality. So that's what we're gonna be using Angular for. And it was created to address a lot of these problems that we found, a lot of the things missing from these frameworks and these other approaches. So that is why we need it, hopefully that's a lot of those things resonate with the developers and the designers in the room. I know they did with me, which is why I created this talk. And so what we're gonna do is we're gonna dive into a tractor and talk about how the tools within tractor allow us to address these problems that we just talked about. So the first one is we want to be able to write more modular code. If you get into SAS a lot, it's really about being dry, about breaking things into small functions and not repeating those things over and over and over again. So why aren't we doing that with HTML? If you're in the twig talk, that was a big push, is let's be dry with our code. Let's not write that thing 10 times because it shows up 10 places. Let's write it once because it's always the same thing used 10 times. So in our code example, you can see on the right-hand side we have three blocks that are pretty much identical. Some different layout, which is just all CSS driven, but the content in those three blocks is identical. So there's no reason that we wanna write that HTML three times because those blocks might show up 50 times throughout our 20 different pages. And when the client comes back and wants one minor tiny little change, you don't wanna have to go and find every single instance of that. You wanna have one canonical source you can make a change to, and then that would be updated throughout your entire project. So I'm gonna show you a little bit of the underneath of Tractor in this case and some of the Angular. I'm not gonna dive too much more into it in other examples, but just wanna kinda show you how this would work. What you'd have is you'd have a partial, this bundle small.html. It's just a standard HTML file with an opening closing tags at the top and the bottom with code in the middle of it. There's a few more, actually this one's clean, nevermind. And that code we can just repeat over and over again within our pages. And we do that by using a partial directive. And I talked about one of the powers of Angular is that we can have this type of markup. We don't have to actually have div with some like data dash element equals. I mean, we can really customize the markup to be not quite sort of verbose and really to the point. Easy to read and really easy to understand. So we can define our region and we can define partials and what partials go into that region. If we need to add yet a fifth or six of those blocks, just a matter of adding an additional partial to it. If we need to add some more stuff inside of it, we can just put another partial in between and we don't have to worry about, did we close a tag, open a tag, delete something we weren't supposed to. Yeah, so that's what we're able to use. Oh, there we go, partial. This is what the JavaScript looks like in Angular. It's just a directive call. So if you've written any Angular, you're just creating directives, which in this case, we are creating a directive that uses the E restrict, which means that it's an element. It allows you to create elements. You can also do ones that are attributes and classes, but so we can create an element that has functionality. In this case, it's really simple. It just goes out to folder, grabs an HTML file and brings it in and renders it. So just it's really simple as far as this one goes. Some of the other ones get a lot more complicated, which I certainly won't be diving into one, but the code's all there. Relatively well documented, I'm sure it could be better, but this gives you a quick idea, and that was not the right button. All right. Of what we're doing is we're using Angular directives to be able to bring this functionality to bear. So when the page loads, Angular is going to look at all of the directives you have on the page. It's going to pull in all the partials and create the page for you. So the second thing we want to be able to use is the concept of template inheritance. And again, Fabian stole it from me, or actually maybe some gave you a taste of it before this, so it makes even more sense. The idea of template inheritance is that we have these different layouts on our pages, and they're commonly used over and over and over again, but just the content inside of it's going to change. So what we want to be able to do is actually create a template, like so, that has regions in it. We can define those regions. We can define the elements that are used for those regions, whether it's a div, a section, or a nav, or whatever those are. We want to be able to assign classes and IDs and those types of things. We want those to be consistent from page to page to page. It's just like in a Drupal theme, where you're gonna have a bunch of different template files. You want to be able to define what those are and use those over and over and again. And the advantage of this is it's going to challenge you, force you to say like, I need a new template. And so you actually have to create a new template rather than just create a new page that's oh ever so slightly different. So it allows you to keep track of all your templates, and when you're done with the process, you're like, I've got 10 templates. I need to make sure I make that in the theme. So we define the template, we define the regions, and then when, let's see if this is my next, yes. Okay, there are our regions. You see, we just define them with name. And then back in our, here we go. Back in our homepage, we're actually laying out all the content. You can see we have the regions. Oh, okay, I zoomed in. We have the layout, we describe that up top, so we can easily change that from one layout to the next if we need to. And then we define our regions and define the content that's inside the regions. So again, we can use partials. We can use just straight HTML if it's just like a one-off piece of HTML. But it allows us to use this template inheritance where if you've got 10 different pages that use this one template and you need to change the order of the primary and secondary within the DOM, you don't need to go to all 10 of the pages and change them and hope that you change them all the same way in every single page. You can go to that template, you can make that change, switch the DOM order, add a class, add an ID, whatever you need to do for all of those templates to then inherit that code. And naturally the power of template inheritance, you'll find it in Twig and it really makes this process a lot better. And I think I just highlight them. There we go. All right. Oh yeah, so just going back to show. So this is the template, those are the regions, the partials and content that you put into that code, it's just gonna get placed right in there. It's just gonna get substituted in and that'll be your, this is like if your final result code. So all the classes use, all the IDs use and those types of things. So the third thing, the third driving principle is that we want to spend less time building UI, especially UI that we don't need to build as prototypers. I made a couple examples of that with say like navigational menus, tabs. So as I said, I was able to, just like we could go so, I was added into some tabs directives. Forges came right from the Angular websites. They had some really good code example. So I was able to inherit that and bring it in. So as you can see what we have is we have some more custom directives. We have tabs, we have a pane. So these are really descriptive, they're not super verbose, you know, data tags or anything like that. And you see we're just describing the title of the tab, it's tab one, and we're putting content into each of those tabs right there. And what we get is an actual tab. I've put some CSS on here of course, but it's going to take care of laying out all of the markup. It's going to take care of the jobscript functionality, of changing the classes of not just the content below, but also the class of the tab as well. So it takes care of all that for you. I mean, two minutes and you've written your tabs instead of two days. And little things like that, you're gonna be doing over and over again is certainly a really powerful and time-saving thing. So the next thing that we can do, and this is really handy, especially in the prototyping phase, is we can create placeholders. There's no reason that we need to go into Photoshop and create an image of a certain size, you know, your 200 by 300 pixel image, import that in, get it into the assets, get it in the get, you know, place it in your page and do all those types of things. Through JavaScript, you can build all of these things. And I'm gonna show you a couple of the ones that are currently built-in to Tractor. And of course, there's tons more you can do. But the first one, which is really nice, is you can actually create full-on images from code. So instead of having to import or create an image, bringing in your sources directory, you can actually say image. In this case, I did use the image tag because it makes a little more semantic sense. And then pH, placeholder image, and then you can describe not only the size of it, but also the text that goes inside of it, the background color, text color, and I'm sure you could go on from there if you really wanted to do more customizing within JavaScript. But what the output of this is not just, you know, some HTML with stuff moved around, this is actually a canvas image. So it's going to stretch, it's going to squish, it's going to behave like an image on a page. And if you need to change the color, change the text, you don't need to go back and Photoshop and export all these assets. So in the prototyping phase, this saves you a lot of time. Or at least I hope it's gonna save you a lot of time. The other thing you do is placeholder text. Just a real simple addition, instead of having to go somewhere and find some lorem ipsum or get that within your IDE, you can actually just have a header that says placeholder words, 10. And that gives me a header one with 10 words. And it's really nice because it's gonna be 10 random words. And this is a really nice thing when you have a design that's like, that header is perfect until that header has three more words and now it's two lines and now it's not perfect. So this is completely random. And I mean, you'll get 10 words every time, but the word links are gonna be different always. So you'll have smaller headers and longer headers. Every page refresh, you're gonna have a slightly different content on your page which helps for just kind of seeing how this is gonna look as things change. Secondly, you could have a paragraph that has a certain number of sentences and that would give you a paragraph with three sentences. Lastly, you can actually do numbers of paragraphs. So just building out your content on the pages is very simple. Changing the content on those pages is very simple. And this is just one example of being able to spend less time doing some of these manual tasks and letting Angular do those tasks for you. Yep, two paragraphs. All right, so the fourth one, using a single style code base from wireframing to prototyping to theming. This isn't specifically as much like Angular JavaScript. This is really more just within the approach that Angular allows you to do. What we really wanna do is we wanna create one style system that's going to work here and is also gonna translate into a Drupal theme. I actually did get a chance to do this on a recent project where we had a theme that was built up, moved it over, and the process was, there's always gonna be some work to be done, but we want the process to be as smooth as possible. If you are designing, modulating your SAS as well, you're probably gonna have a file structure kind of like this. It's broken up into base and components into globals and layouts, separating your layouts from your actual styles. Doing this is gonna allow you to attach those styles to the actual Drupal site a whole lot easier. You also might have, if you're using the extends, I use extends pretty extensively, so instead of actually putting the styles directly onto the selector, I have like an H1 styled up as an extendable, and then any time I need to use that, I can just extend it from that class. So what you end up having is on the left, this is like my little bundle small, I'm going to extend the white box, and then on my H3, I'm gonna extend my title. Now of course, that's not gonna be the markup that we're gonna actually have in the Drupal instance. We're gonna have some long, crazy little view thing that's built by Drupal, and it's gonna be different. But it's the exact same styles, the exact same extends, and the selectors just need to be changed. It's the same content, it's the same styles, you just change your selectors and you'll be able to attach all those style behaviors to your new design. When I went through this process, it worked pretty well, there's always gonna be a little bit of work, but it's gonna be a lot less work than trying to design a completely new system. So that's one of the things we wanna do is be able to create the system that starts with the prototyping and designing phase, and actually will roll directly into your actual Drupal install. So the last thing we wanna be able to do is work in teams more efficiently. We don't wanna have that instance where the designer designs and designs the designs in a silo and gets done, and then passes it off the front developer and the front developer crafts his pants, because it's, ah, that happens too often. So by doing this, we can get the developers, the front developers, into the process a lot earlier. I'm trying to remember where, yes, okay. So one of the advantages of using something like Tractor over whether it was Jekyll in the first place or Ruby gem called serve in the second place is this is just HTML and JavaScript. The entire thing that you need to run this entire system is HTML and JavaScript. You don't need a server. You don't need compiling. It will run on anything. You can throw it up on a shared hosting and you'll be able to view it. You can make changes and those changes will be viewed. So there's really nothing necessary other than that. So the barrier of entry is small. There's no downloading command line tools and Apple this and 500 make patches of that. You can just start using it. But, oh yeah, no compiling. But it also comes with grunt server built in. So if you're familiar with grunt, grunt is a task manager and it's a very awesome task manager. And with a simple MPM install after you get other stuff installed, you'll have a grunt server that allows you to spin up the server, compile your JavaScript, live reload, all those types of things as well. So for the power users that wanna do that versus using like CodeKit or something like that, that's built in as well. And again, we can build in even more things in the future if we need to. So yes, a simple MPM install and grunt server for the when you're up and running. Or again, you can just toss it in front of a map, you can throw it up on a server and it works. There's no compilation process and it makes it nice and simple. So obviously in that case, it works great with version control. You can even go into Git and make changes in Git or like to the GH pages or something if you have it in there. And those changes would be live, no compiling, nothing else necessary. Have you ever tried putting a Photoshop file in GitHub? Not a very good process. So what this allows us to do is get that friend and developer in early. The friend and developer is gonna be involved in taking all of your content types and all those deliverables and actually creating that initial markup. The designer is gonna be able to start designing. And as that goes, the friend and developer can continue to be involved refactoring where things can be refactored, giving suggestions on maybe different ways to approach something that's going to be more efficient down the road or easier. And in the end, you should have a product that is better and also a process that is faster because once you get to the point where the design is signed off, the friend and developer's job is almost done rather than just starting. So the hope is we can make this process faster, we can make everyone happier in the process and we can start designing the browser a lot easier than we did before. Yeah, that's basically what I said there. So there are a couple of bonus wins as well for any backend developers that happen to accidentally stumble into the room. When we create, things we get for free, when we create these manifests, what we're also doing is we're describing different pages. We're describing all the content as it's going on to these pages. So as a backend developer starts building all these views, all of these blocks, all of these nodes, they know exactly what that content is going to be pretty early in the process. They know the order of it and like the, do you want a div tag or do you want a paragraph tag? Some of those decisions can at least be hinted at the beginning that allows the developer to start that much earlier. Down, there we go. And also it provides that list as well. So if you're using panels, if you're using context, I had like kind of an ah-ha experience where I was looking at the context list for a particular page and the context list read exactly like the page manifest, like add that block and then the view and then this and then that. And so that context, all of the nodes and everything that was going on the context was exactly like that manifest. So you're able to get some of these things set up beforehand and set in place that allows the backend developers to start building that data out a little bit earlier and a little bit more defined. So those are the bonus wins. And our takeaways is we need testers. I need people to use this product. I need to find out what's working and what's not working. What are stumbling blocks? What are things that would make it better? I would also love to have contributors. I am not an AngularJS expert. I really hope that's not what you're expecting when you came to the room. I've used it to do some cool stuff. A lot of the work that is in Tractor has actually come from some other contributors that I know of that have done especially some of the heavy lifting. So if you do have a pension for it and you've got some great ideas, I would love to get some pull requests coming in or at least some ideas into there. And what we really need to also be talking about is what are other ways that we can get developers and designers working together. Another small epiphany I had a couple weeks ago is that I really want to consider changing my job title from front-end developer to more of a front-end architect because I'm really no longer writing CSS. I'm no longer saying, okay, I want this button to be orange. So background equals orange. That is the designer's job. So what's my job now? My job is to take those styles and create systems from them, systems that can be reused, systems that are efficient. It's not really a developer anymore. It's really more like an architect. So what are other ways that we can get front-end developers involved to make this process even more valuable? And again, do as much as possible before we get into that theme. Do as much as possible while code is cheap and while changes are cheap. All right. And that is the end of my presentation. Thank you. Forty-one minutes. Three. And it looks like we're pretty good for time, right? Got like 15 minutes or so? So do we have any questions? We'd be more than happy to take some. Yes. Use the mic. Yes. Well, I might just kind of be able to see what you did here. Did you see what you did? We had to work through it. There's a microphone. Use it. Or that one. So I think I saw here, by the way, doing kind of the same system just in clear jQuery and that was horrible. So I'm really looking forward to this, no problem. So you begin to build all these classes. You're beginning to build all these things and you kind of want to change the markup because you have to move that stuff into Drupal. Wouldn't it be wonderful in Drupal 8 if we didn't have to do that, if we have decided on the classes and the whole architecture? I think this is the first time in the world. Okay, so. I think I did. Write that down. The thing is, if you saw what this wonderful young man did was having a bunch of classes that, oh, I have to move them into Drupal. Now I have to change them. Wouldn't it be a wonderful thing if we didn't have to do that, if we already could decide of all these classes as we want them? You're just pushing twig, aren't you? Oh yeah. I'm pushing the twig lag. We're gonna have a discussion in about two hours, two 14, where we're gonna talk about these things and I wanna have you all there because we need front-end developers to take charge on this. Else it's just gonna be me and probably be you. Hopefully. Well, hopefully not just me. Else just my steel element box, look for that. Yeah, on that, like twig, from the talk yesterday on twig, that is certainly where we're gonna be going. When Drupal is solid, I could see this, you do this entire process and you've already built your theme without even needing Drupal to be bootstrapped at all. You can build your content types and little JSON arrays and pop them on in and you can start building out your views in twig files because it's the exact same process. We're gonna just move the microphone, it's wireless. Yeah, because I can't hear that well either. I think this is also work. I just booked a meeting with the senior PM to tell him we'll be using Tractor for this. But you said one thing that made me twitch. You had, on your left-hand side, you had the CSS for your prototype. On your right-hand side, you had your selectors for your Drupal side. Yes. I just wanna be saying, if you started out using an object-oriented approach for your CSS, you wouldn't need to change it for the final site. You would just inject those classes into your Drupal side. That depends on the approach that you wanna take. I typically go from those, extending those extendables with a selector that's there. And I don't like changing classes in Drupal, mostly, because I'm more of a friend and developer and not as much of a Drupal developer. Yeah, depending on your approach, I agree. If you're more of an OO approach where you create classes that you apply, that's perfect. Our approach is just slightly different, but you get the same result in that you get to build, what's important is building the styles. What does that each one look like? What does that button, what does that box look like? And once that's built, you don't have to build it again. You might have to change selectors. You might need to add selectors, whatever that process is, but you've already built it. So you don't need to go through that process over again. So once you're designing the browser, hopefully you should be able to take those styles and move directly into Drupal with those. Any other questions besides when can we start? Awesome, cool. Well, I appreciate everyone coming as my first talk, the fact that people are standing out there and still standing out there. I love you all. A bigotry last slide.