 Howdy. So my name is James Mohan. I'm a lead developer at Astonish Design. I have been born and raised here in Texas, so I'm a native Texan. I am also a Texas A&M Aggie. And if y'all aren't from Texas, that means a lot given our current proximity to a school that's very close to here. I haven't heard anyone discuss this, but I wanted to point out since I have a captive audience that all branded DrupalCon North America paraphernalia is maroon and white, which is Texas A&M's colors. And so I thought it was a perfect fit given our situation. It was pretty funny for me. As a very quick note, if you're here to hear about cool client-side JavaScript frameworks like Ember, Angular, Backbone, I will not be discussing any of those things. I would be happy to talk with you later, but there's probably a better session at this time for you to go to. All right. So let's dig in. So today I want us to talk about a lot of different things, some about workflow, a lot about what we keep in mind when we do implementations of front-end frameworks. So we're going to discuss prototyping, what a front-end framework is very briefly, what foundation is, again, briefly talk about why performance matters and why we need to plan out what our theme is going to have in it ahead of time. We're going to talk about some of the things that we need to think about when using foundation with Drupal. We're going to talk about the tools of the trade that help us to make this process easier and simpler. And sort of lastly, we'll talk about how we should approach upgrades in light of the fact that things change and how we should think about that. So we have a problem, I think, in web development. Typically we build things without a picture, and so we're going to get half-finished products or maybe finished, but we don't know what that product really should look like until it's done. I think that often the moment that you truly know what a project should look like is when it's finished. And often our clients and partners do not know what something should look like until they see it and can give feedback on it. So what do we do? I think we need a collaborative process to iterate, to understand business need in addition to planning for user experience. And so at Astonish, we like to build things twice. And that is primarily because when we're implementing things like really custom applications or even Drupal websites, we want to have that first pass in a very simple, easy not connected to a database, very, very low-level clickable prototype to help us. And so Foundation gives us a great platform for that. And we'll get into that in a little bit. So the focus of our prototyping effort is to, again, gain that understanding into the business, to gain and gather requirements and constraints, to understand those, in addition to proposing solutions that we know as software developers, as Drupal developers, are going to be difficult to implement in Drupal when it comes time to do that. So maybe we don't need everything. Maybe we need to propose other ideas and other options. And I gave a talk yesterday about this exact thing. And so if you want to look that up and watch it, great. But it's about managing clients' expectations and scope. A couple of us from Astonish, a few of us from Astonish gave that. If you give a mouse a cookie, you can look it up. But the last part of this prototyping process is implementing creative design. And so we then need to transfer this into our theme. Sometimes this can also look more like a component library, and we're going to go through some demos in a bit. So the outcome of our prototyping process is going to be a limited amount of pages, somewhere between two to five, maybe up to 15 or more. We're starting to get a little bit bigger with our prototypes. But they're going to be interactive. You can click around, type in forms, do some basic things, see modals, accordions, tabs. But it's not going to be dynamic. No database connected, right? Not hooked into Drupal. What you're going to get with it, HTML, JavaScript, CSS, and maybe some assets like images, icons, whatnot. But we're getting a blueprint or a picture of what our application is going to look like. And I think that's really important for every application we build, even marketing sites, because there's so much nuance to people's visions, right? And typically this outcome, this last deliverable of the prototype is going to have the entire framework in it, just because it's simple and easy to throw all of the JavaScript and all of the CSS in there. There will be a little bit of overlap in work in prototyping and implementing that prototype as a theme in Drupal. So let me show you a few examples. So we have, oh boy. So I'm going to get out a keynote and jump into a browser. Bear with me. We have a prototype here that's pretty basic. No theme or no design has been implemented. But we can get a feel for the kinds of things that we can do to show and paint this picture, learn more, doesn't really go anywhere, profit a lot. We can go to these other pages, see how these tables work. This is all done in foundation, right? So we have this pretty touchable, feelable, go and play around with it. Do it like that. Give me your feedback. Go use this thing and tell me how you feel about using it. So this will save us a lot of pain in communication with our clients. So we have a better product at the end. This is one that has a lot more design in it. We have a few treatments, maybe some tabs, some pop-ups or some accordions, content. And then lastly, more of a component library. So this was developed using foundation as a form type library. And there's a point to talking about all of this prototyping effort. Let me start back up. So now we understand where we're at with a prototype. So let's talk about frameworks. I picture a framework like that of a bowling lane. With bumpers, we have a really broad lane that I have flexibility to go down the lane and meet my ultimate goal, which is to knock over those pins. If I hit a side, I get bumped back in. I can hop the lane, but it's going to be a little bit painful. I won't have those constraints in that scenario. But I also have freedom in the lane. Maybe I need to curve that ball in if I'm a pro. They're going to curve their bowling balls. I often think that we get confused on the difference between a framework and a tool set and a library. And so the definition of a framework is the basic structure of something, a set of ideas or facts that provide support. So it's going to help guide us. It's going to help us get to our goal. It's not going to be the means, it may have elements of the means, but ultimately it's not the thing that's going to do it for us. We're going to have to get all of these pieces playing together. So let's talk about some metrics of how frameworks are used around the web. So two very popular frameworks, Foundation and Bootstrap. There's a website called BuiltWith.com. It's pretty much the only place that I could find relevant metrics for these frameworks. And so BuiltWith.com reports that of the sites that it has indexed, 46,000 of them are using Foundation. And on Drupal.org, there's been 52,000 downloads of the Foundation theme. And Bootstrap, likewise, has 2.5 million installations on the web and about 154,000 downloads on Drupal.org. We can see that this trend is growing. These are the usage statistics from D. O. Bootstrap had a time period as a note that they switched from Twitter Bootstrap to just Bootstrap. And so that's why there's kind of a, I didn't put both those in there, but they had a good user base. And so they're growing and it's getting to be almost a more exponential level. Foundation is becoming more popular. So what is Foundation? And what does that mean? So Foundation claims a few things about itself. It says that it's semantic, meaning that it uses proper HTML markup and structure and naming classes and conventions that make sense. You can read it, you can understand it, alert, error, div, form, nothing crazy. It's responsive. So it's going to be, and then following that mobile first, so it's from the ground up, it's meant to work for all kinds of devices. You name it. It's got grid systems and all kinds of different flexible videos and such. It's customizable, which is probably the most exciting part of Foundation, how easy it is to customize it. And we'll talk about that as well. It's accessible, so they built it in a way that people on the web will be able to understand and screen readers and such can get access to it. And they really built it as a tool for rapid prototyping. So I want to share a story. I have a friend and co-worker named Tone, short for Anthony. He is at the moment speaking at this very time on a business track session about agile scrum. Well, he had commented how he wished he could be here to heckle me, so he had to be the example in the story. Tone loves bowling. And so in his pursuit of bowling, he decides that he wants to put a make his bowling efforts easier. He wants to get really good at bowling. And so he makes this this tunnel for his alley or for his lane, and he puts this this tunnel over his lane, and he begins to practice. Well, he realizes very quickly that that's not necessarily the solution he needed. So sometimes he would throw the bowling ball at at the lane, and he would miss the hole, and it would end up in the concession stand. Or he would throw the ball down the lane, and it would rattle around down down the hole and not have enough velocity to knock over all the pins. You know, you can kind of get the picture. So he made this really oppressive, potentially you could call it useful situation, but it did not meet his goal of consistently being able to to hit the the pins. And so he needed a little bit of help, but not a lot of bit of help to be able to have the freedom to learn how to bowl. So he needed to practice his form, not implement tools. Okay. So why? Why does this matter? Why have I been talking about this? So we understand prototyping. We understand what foundation does. We see that, you know, if we are too heavy-handed, we're going to have problems. What's the reason for that? So I'm going to butcher his name. I think it's Ia Gigorek. Sorry, I'm, he is from Google. He knows a lot more about performance than I do. Recommend going and watching his YouTube videos, reading his books, well published, well documented. Share a few things with you that I learned from him. One, when cell phones make communication, they do it in a very weird way. Well, what I call weird. They have these steps of negotiation that happen, right? So we have a negotiation period. We have a DNS lookup, a handshake, another handshake, and a request, then page load. All of that happens. His data shows that 3G and 4G speeds relatively have a very large latency overhead. Anywhere from 200 milliseconds to 3500 and 100 to 600, respectively. So we need to be thinking about these performance metrics and others when we're implementing large sets of things that our browsers are going to have to download on our phone or on our computer. Naturally, not as big of a deal on a computer, but, you know, internet's becoming more and more widely available, but not necessarily at the speeds that we would like. What about other countries? What about on planes? We have access on planes now, but is it good? So some more information for you. Connection persistence. So when a phone communicates with a cell phone tower, this is one of his metrics. I'm going to oversimplify it in every phone radio frequency connection type. All of those things, whether it's LTE, 3G, you name it, has a different way of communicating. But for simplicity's sake, it makes a communication attempt with the tower becomes active, has a period in which it could stay active if requests keep coming through. If not, it is given an idle flag, moved into varying states of idleness, depending on the connection type, and then goes back to dormant status and then goes back to idle if it doesn't have enough connection. So what does that mean? Someone hits your page, reads it, scrolls down it for three seconds, whatever the timeout period is, hits another link, they have to re-establish and go back to that overhead that we discussed. So you're not only having to handle the HTTP request, maybe some things are cached, maybe not on mobile, I don't know, but you're making that overhead again, or you're having that overhead again. So that causes us to think about several things. First and foremost, you do not need the kitchen sink. Foundation is one of the key things that they have in their docs is that the kitchen sink is a list of all things foundation on one page. That's awesome. I like to see how they implemented it, but I don't need that. So we need to plan for performance. What do you really need? I doubt that many of us can raise our hand and say that we would need more than 25% on a given day of what any one of these frameworks has to offer in general. The framework doesn't have to do everything for you. There's a lot of grid systems out there. There's a lot of ways to handle sliders. There's a lot of various you name it for any of the features that you're planning on implementing. It doesn't have to do at all. When does it make sense to allow your framework to handle that feature set? I think typically when you're going to have three to five, maybe more features that a framework can handle, it makes sense to just go ahead and do everything in that framework. But there have been times where maybe we had an off canvas menu that was just really all it was as a button toggle or something like that. We just wrote custom JavaScript for that. There's no reason to try to shoehorn something in or pull in a whole nother chunk of the library or whatever. So as an example, I showed you that that NorCal prototype. This is not even everything, not even everything that foundation offers out of the box. And this is a mixture of SAS CSS and JavaScript. So not all of this is necessarily one of the two areas that you have control over. But this is a picture of how much we actually used. I didn't do the math, but it's a very small subset that we're actually using. So where do we go? How do we implement foundation into Drupal? I think that like anything in the theme layer in Drupal, Drupal has its bias, its defaults. And so we're going to have to override those. Consistently, we do some we do things similar to that in the back end. I am a full stack developer, so I go from custom modules all the way to the theme layer and more whatever that may be. But I'm in the back end changing a lot of things often, maybe not to the API level. I'm not necessarily overriding Drupal's APIs, but I'm changing some a lot of its default behaviors. And that's more important in the in the front end than I think in the back end. We can follow the docs, right? Foundation has great documentation. Excellent. They'll tell you how to implement anything and everything that they have. There is a lot of people out there that have done a lot of good work. The bootstrap and foundation themes that are on Drupal.org, I think, are great examples of parts and features of things that we can use, right? So if we're implementing a new a new site and we need some pieces that we haven't used before, we'll go grab the breadcrumb code out of foundation theme or we'll go grab the pagination or the alert or whatever. There's also contributed modules that don't really rely on the main foundation theme. They just require you have foundation running. So there's people that have done work in this regard. And I think if you're not able to find it in a contributed fashion or or something like that, you can you can do it yourself. We can come up with unique solutions to solve those problems. So in and in several apps, I've written custom theme functions or more importantly, custom modules to implement sections of foundation that aren't necessarily available by downloading or or just by plugging and playing. So I wrote a module that's 250 lines. So it's not very big in the respect of typical modules. And what it does is it overrides the entire Drupal form element and form functions. And it allows a abide, which is foundations client side validation tool to run on all Drupal forms. And so on on the admin side, I did something probably that I shouldn't have done, which is include the all the JavaScript and CSS so that the admin forms work. And then on the client side, I relied on or on the on the main theme side, I relied on the fact that I knew foundation was going to be there. But I overwrote how all of those those field elements and the and the inputs needed their validation steps for abide. Pretty, it was it was really straightforward. It took me less than I mean, just a few hours to do something like that. So I think another another thing that we have in our in our arsenal are these tools of the trade, so to speak. So Bauer grunt npm kind of just because it's there, it's not really used for much, but grabbing dependencies. So is Bauer, SAS node compass. And so let's talk about a few of these things. Bauer handles our dependencies. It's one of the ways that you can include foundation. The other would be through a Ruby gym. My personal preference is using Bauer. The reason being that we don't have access to some of the cool function SAS partials that foundation has, if we use the gym or as easily as I found in addition, you're going to have to include JavaScript, most likely. And if you use the Ruby gym, it's not going to be there in your repository. So you're going to have to download that separately. So why not do it all at once? And so I'll explain more about that and how grunt can help us because it's easy to in our compass files and things like that to include include statements, but grunt will bridge that gap for us. SAS so we can use all of SAS's cool variable variable options and function calls compass as a framework on top of that even more power node is what grunt is how grunt runs. So it's listening for changes. It can be used to do watch much like compass watch and things like that. So grunt is just one of those task runners that we have at our at our hands, so in our hands. So foundation has one of the one of the options that it has when it comes when you get the gym is that you can run a command that will deploy a basic site for you. And so we've done we did that once and then we grabbed how they deploy everything out of it. So they give us this really cool file that has all of the foundation dependent foundation dependencies in it. And we can mark those off if we wanted to. So I don't need accordions. And this is this is CSS. So I don't need accordions. I don't need alert boxes such and such. I'm going to pair those down. We talked about planning. So we've planned out what our what our applications actually going to use all the features in it and how that relates to what foundation has. So check off the ones that you don't need because otherwise they're just bloat right in the old days. I used to work with Twitter Bootstrap prior to version three which is a lot more like this than it used to be. But in the old days I would grab all of the JavaScript and all the CSS and throw it on the site only so that only so that my site would be responsive and have a responsive menu. That's it. It's all I use from Twitter Bootstrap. And yet I had the entire minified CSS and JavaScript files for what I mean for what else you know. We're past that we have to be. I think so be mindful of what we're doing out there. So the ways that that can an excuse me a tool that can help us is grunt. So here is a very simple grunt file that I have configured that listens for where I have foundation. So you see they're the import path at the top grabs import directives from another directory not necessarily my theme directory. And then the rest are looking for my theme information and telling it how to output that. And I can have varying types of output compressed with comments with not I can have watch commands to listen for when I make changes to my sas to automatically use live reload built into grunt to reload your browser when you make a change. All that's really powerful and really cool. And then another option and this isn't the only one that you have on the table when it comes to grunt which is a task runner that's open source. But one that made sense for me is Aglify. And Aglify is basically a JavaScript compressor I guess compiler. It's going to take all those files that you have outlined and it's going to put them into one large file for you. So in other projects I've done a little bit more than this where I've actually defined the exact files that I want. So in the case of that NorCal app I think I had the main foundation JavaScript and Abide and maybe one or two other JavaScript files of the I don't know 15 to 20 that have that comes with the framework. In addition to my own custom JavaScript files that I can throw in there. Okay that you know that sounds great. And I think the reason that we get bent around that are wrapped around the axle often is because we're worried about how upgrades are going to happen. Especially in the in the fact that if you're approaching something like a theme on Drupal.org that is going to support as much of that framework as you can and something changes that's kind of a big deal. I like to think of upgrades and a little bit of a different way. I want to build my my theme for the features not for the framework. So I'm not trying to build my theme so that all the framework features will work naturally because I may never use a slider I may never use a breadcrumb. So why struggle with that why waste time on that. I acknowledge that version changes will happen so most likely when I get started I make the decision that the features that I implement are the ones that I'm going to live with and if I need to implement something later I'm going to backport it ported in do the work of upgrading if necessary. But chances are when you start a project and you implement a theme it's doing probably everything it's going to need to for the life of that software application. Now there may be additions and that can you know you can deal with that but I think that there's there's flexibility that's there. Specifically when I implemented that NorCal app keep using it but it was the one that I've spent the most time on. Foundation 4 was what came out when we prototyped and so foundation 5 came out right in the middle of that process. Foundation 5 had some cool features specifically in a bind when it comes to validation equals there are some others I'm having trouble off the top of my head. In addition there is a problem with how client side validation and how Drupal did it. Let's see we had a field element that was conditional so conditional fields. There was a problem with how that worked and with how a bind wanted to play with it and so the conditional fields had a cool extension a cool API talking point that I could tell a byte on how to look for that so that knows if a field is hidden and so I wrote a little bit of code and and it wasn't that hard and sort of forked a byte at that point by back porting a few features from 5 and up upgrading it so that it actually worked with Drupal. I think kind of all of what I was saying there really goes to the thought that when you implement your theme it's no longer foundation it's your theme. Theme x, theme y, theme z and if we treat it as such then we don't have to worry about the next version because it worked right when you when you launched it if not then you're not meeting your requirements and then so you got to figure out something else but probably when you get back around to it you're not going to need to upgrade foundation for that to work. So let's recap a few things. I'm going to leave I think sometime here for us to talk and chat for questions but we talked about why prototyping is important in this in this kind of workflow and really the only reason that we choose to use foundation is because prototyping is easy we probably wouldn't use foundation if we just had to implement things maybe say from PSD into Drupal maybe depending on the requirements of the job. We talked about frameworks in front-end frameworks and what they're good for and how they should be used. We talked about performance thinking about it from the mobile perspective mostly but in addition not not needing or wanting to include all the bloat that comes along with a large framework that does a lot of things. We talked about how to plan it out right so being mindful of the things that we're using and we talked about some things and I can go into more detail if anyone has questions about how to implement specifics in Drupal and some tools that will help us when we're developing and then how we handled upgrade updates. So here is some contact information you can find me on the web I'm on Twitter you can email me I will take questions comments angry discussions such-and-such please go and rate give me feedback is one of one of not necessarily the first times that I've done this but it's one of the first time so I would appreciate feedback. Hello thank you for the presentation very enlightening my group is definitely looking forward to prototyping and browser doing wire frames and such. One thing is I've used a foundation in in my Drupal templates and one thing as I came across as it sounds like you've come across is like having to override a lot of things whereas when you have like a like a SAS driven grid system something like Zen grids or omega or something like that you can just apply it in your SAS and then you're good to go. So in your opinion knowing this what to use foundation and be productive with foundation what kind of techniques have you employed to cut corners and save time so that you can use foundation which is fantastic sure but not have to bang your head against the wall whenever you need to override a certain thing. So there's a lot there so there's a lot there I think in grid systems it's pretty it's more it's simpler than anything else because you have control at the template level of your HTML and if you know as a developer how that grid is supposed to semantically be according to foundation docs then you can pretty easily just kind of go through it and understand the different places and so when you get into views and things like that you're going to need to add classes using views and panels and whatever you need to do you can add those classes because a lot of those things offer those kinds of very easy attachments so to speak or you just pop them in and they automatically output I'm not going through the effort of necessarily writing new templates and things like that for views and what not to be more foundation e for panels I think the foundation theme and some other places have panels templates that we typically grab and throw in our theme but yeah so did you have it was that it or did you have no so basically you go into the view and then you just add classes inside the view mm-hmm and you can do that in particular fields if you want to so that's how you usually implement themes right unless it's at the template level of the main kind of content layout so the main content layout you of course control the html pretty nuanced so in views I will hopefully select elements that make sense and then throw classes where they need to be thank you so I'm not a hundred percent sure how to phrase this but I was interested in this topic because I just recently learned that foundation seemed very different from bootstrap and that you don't have to necessarily bring through all the CSS that comes with it because like you're saying obviously don't want to include everything you're not using so when you're mentioning that you could use like the optional sass exactly so let's say you you pick one of those the buttons and there's just some aspect of it that you want to override can you do that through like through a mix in like are they are they exposing mix ins through that or do you just literally add sass on top of that yeah so what I did not include and I'm glad that you brought this up is a screenshot of the of the settings file that comes along with this as well so the settings file comes by default with with foundation and so there's all of this crazy stuff that you can uncomment like button colors button corners rounding borders on buttons buttons on buttons on buttons colors on colors typography I mean basically you name it there's a variable for it and you can override that variable at this settings file level so it's set automatically by foundation but you're overriding it here so it's not the old way of doing bootstrap or another framework name it where you import that library and then you're having to write all your custom code to override it that's how I would do it so I would bootstrap CSS and then I had to do all my overrides this is this is native to sass overriding so that that original foundation code of like blue buttons and you wanted green buttons never gets put in so that that makes a lot of sense it the original file where you're showing like you're importing all the different foundation pieces if you do that let's say you decide you need all of them are you getting a lot of css like it's printing all the css out of the box basically and tell you yeah you specifically commented out or so like here it's if I say import foundation that's everything okay and then from there I can if I if I comment that out then I need to select specific ones and it says sometimes it'll tell you required buttons required for buttons of forms requires buttons and top bar requires grid and I think there's some basics about the grid and the you have to include global it says like always required and things like that is there documentation on the variables to that makes sense but yeah yeah so there is those those variables all have I was just in line then yeah they're in line and there's there's semantic so if I read one here sub header line height right I they're they're all relating and then they have titles for the sections thank you very much no problem is there been any push to possibly have like a framework theme at in core like either foundation bootstrap or both so this is the area where I get myself in trouble I promised I was not going to make any arrogant one-sided comments but I sure hope not and the reason that that's the case as much as I love foundation and working with it is that as you as I feel based off of the the themes that are out on Drupal dot org we're not being mindful about what we're including and so I feel that that would enable us to be lazy in addition there's a lot there's a lot there so there's a lot in foundation that we will never use in Drupal I think or I may never use one of the pieces and there have been people that have asked for it I've seen there was a front-end some Morton put out a front-end questionnaire I think and it was that was one of the questions but I hope not let people make that decision on their own so are you using the foundation theme on Drupal dot org or you roll in your own we're using it as a tutor in the sense that I'm not rewriting like alerts or something like that we're going and grabbing that out of that theme and putting it into our own theme and so I'll acknowledge that there is another way to handle this and so I'll explain that in a second but the reason that I do that is because it helps me be cognizant of those things that I'm adding to my theme and what I'm choosing to use so the other way as some co-worker of mine has pointed out a few times is we could sub theme off of something like the main foundation theme or bootstrap theme etc and then tell it somehow override its import of its JavaScript and CSS and do our own JavaScript and CSS import at our sub theme level and then still have access to all the template directives because often those template files like template dot PHP they won't really run until you're called and until they're called on principle I feel that that just seems like a lot of code that I'm never going to use and I want to take that time to think through all these things that I'm including so I'm only going to port in what I need and so that's kind of what I was saying so they're they're there as an example I think and I would treat them as such personally. Thanks. Great job on the presentation I just had a quick question about why you chose foundation over bootstrap I personally chose it because it uses SAS and bootstrap at the time used less I'm not sure if it still does but if somebody asked you you know why why did you choose that what would you say? It's a great question I think the the foundation of foundation was very different they took a much different approach to web design they took a mobile first approach which I know bootstrap does and did but I think that bootstrap's iterated itself to be almost what foundation can do it can do less in SAS now and you can include things and not maybe I'll be honest there was a little bit of bad taste about bootstrap but foundation being marketed and being easy for rapid prototyping made more sense at a general level okay great thank you okay great I appreciate the comments and I'll be up here if anyone wants to talk about anything else