 So, hello everyone. Welcome to Portland. I hope you guys are really enjoying DrupalCon. I know I love Portland. I've been here a few times and like the food and beer here is amazing. So like I'm just, I'm really excited about that. And it's also crazy that there's so many of you guys. Can you speak in the microphone please? This microphone? Yes. There's so many of you guys here to see this. This is crazy. I thought there'd be like five people showing up for this and because it's not like core development. So this is awesome. So I'm going to try to keep things pretty short and to the point since I'm sure everybody's got beer plans afterwards. We can just talk about brewing beer instead if you want. So this is the Zen of HTML prototyping and designing working wireframes in the browser. So my name's Josh, Josh Riggs. I'm a senior user experience designer at Lullabot. If you haven't yet, come by and see us in the expo hall. We did have some really awesome screen printed posters that we were handing out. I'm not sure if they're still available, but we have all kinds of goodies and we're just a fun group of people. So come by, talk to us and hang out with us. If you're not familiar with Lullabot, we're an interactive strategy design and development company. We of course specialize in Drupal. And most of our work involves creating large scale responsive websites for enterprise clients with very, very specific needs. This of course creates a really unique design and user experience challenge for us. And this presentation is basically going to be what I've learned and what we've learned as a team from the mistakes and successes that we've had in creating wireframes and HTML prototypes. So I have kind of four fundamental goals that I'm hoping to accomplish today. The first is to remind us of why we actually wireframe in the first place. Why is it in the design process? I want to convince you guys that static wireframes are useless and creating HTML prototypes are the bee's knees. I want to show you guys that getting started with prototyping is pretty easy and I want to talk about some of the options that you have available. And then I want to talk about how prototyping fits into a modern responsive web process and how to get your team and your clients on board. So I have a couple of disclaimers. The first one is that what I'm going to tell you is not a be all end all set and stone process. It's a constantly evolving process. It's largely trial and error. It's not going to cure cancer. It's not going to like shoot rainbows. It's going to be, I'm going to discuss basically things that I've done and things that have been a success for me in the real world. I'm also going to discuss some things that haven't worked so well. Disclaimer two is that I am a designer. I come from kind of the old school web design days when the job of a web designer included user experience, information architecture, wire framing, design comps, HTML, all that stuff. I know that today that front end development has gotten really, really extremely complex and so now that it's its own specialization, I tend to focus mostly on user experience and design but I still have a solid front end development background. We have our own front end development team at Lullabot that handles a lot of the really detailed stuff. I'm going to keep this at kind of a higher level 10,000 foot view talk. Focus on more why we should adopt HTML prototyping into the design process and of course if you want to talk to me some more, please find me at Drupalcon. I'll probably talk your ear off about it. The first thing I want to talk about is what's the difference between wire framing versus prototyping versus HTML prototyping? You've probably heard these terms used interchangeably. Wireframes typically refer to static documents that describe the actions of a website or an application. They can be made with illustrator, fireworks, omnigraphal, balsamic. I've even seen some Microsoft Paint wireframes and they were horribly ugly. They can also be sketched on paper and then in contrast, HTML prototypes are clickable demos of websites or apps that are actually made with good HTML and CSS and they run in a browser. Since we've cleared those things up, have you seen this movie yet? Me either, so. A long time ago in a galaxy far, far away maybe it was last week at an agency near you, we used wireframes as a first step in our design and layout process and it makes sense. It seems like the right thing to do because we would make a blueprint before we build the house, right? A website isn't a freaking house. As websites become more complex and responsive, static wireframes just don't cut it anymore. So in our hero, the HTML prototype or if you're Sally Young, it's HTML. She's British and she makes fun of me every time I say HTML. So if you know any British people, it's HTML. So this is a static, or excuse me, this is a screenshot of a working responsive HTML prototype. Looks like a wireframe but it's made with valid HTML and CSS. I tend to use Zerb Foundation or create my own HTML prototypes and they're completely responsive. Cool, so let's talk briefly about why we wireframe. Why do we do this thing in the first place? It's been part of the design process for a really long time and how many of you guys have created a wireframe of some sort in your career? Pretty much everybody. It's like as common as Beards in Portland. So why do we do it? We need something cheap and ugly and this is not a your mom joke. One goal for wireframing is that we need to create something cheap and ugly that helps clients focus on making good UI decisions. We need something cheap, meaning lightweight and quickly produced, not spending a whole lot of time on it, and ugly meaning mostly devoid of style and they should be somewhat disposable. Even though we're supposed to be cheap and ugly with our wireframes, how many of you guys like me have sat at your computer and tortured yourself over pixel perfection on a wireframe? Come on. In the design process, we need to separate the user experience which is the layout, the content structure, component hierarchy, functionality, etc. from the pretty stuff, the typography, the colors, the textures, photography, illustration. Those two should be separated so that we can focus on getting each one right. In my opinion, we shouldn't be talking about color, texture, and typography when we're reviewing wireframes. Assuming that you've already done the work in your process to understand purpose, to understand content and structure and priority, wireframes are just a way to further clarify and test things. If we've gone this long creating static wireframes, why should we put the extra work into making responsive HTML prototypes instead? Why not just keep doing the same things? Why not just draw websites instead of actually build them? I'll give you several reasons. Traditional wireframes are static documents but we try to use them to describe multi-dimensional user experiences. The keyword is describe. These are just blocks on a page and we're attempting to describe and communicate how a website or app will work. So prototyping is rendering ideas to understand them better. That's according to Jared's school. I'm sure you've all heard of him. Prototype is an early sample or model built to test a concept or process or act as a thing to be replicated or learned from. This is directly from Wikipedia. An HTML prototype is essentially a working wireframe created with HTML, CSS, and JavaScript and viewed in the browser. This creates a living breathing environment for users to interact with. The goal of prototyping is to discover and solve design problems early on in the process by iterating, testing, implementing, and refining. We all know that the earlier on you find a problem and solve it, the less expensive it's going to be. If you can get this done when it's more of a conceptual thing versus later on in the development process and you've already built 90% of your project, it's just going to be so much better. It's really hard to do that with a set of PDF wireframes. This is kind of the reoccurring theme of this talk here. If a picture is worth a thousand words, a prototype is worth a thousand meetings. This is true. I've had meetings about meetings about meetings about meetings about wireframes. If you give a client a prototype that actually renders in a browser, then that leaves far less up for interpretation. Prototypes show real interactions. Wireframes describe. When you need to demonstrate a complex user interaction to a client or a developer, describing these interactions with a static wireframe just creates too many unanswered questions. Here's an example. This is a traditional wireframe. We've been living under this illusion that static wireframes are cheap. They don't cost that much in effort and time to produce. But if you've ever tried to use a picture like this of a website, instead of an actual website, it can be really frustrating and confusing and not the same thing at all. Because static wireframes don't actually do anything. Nothing here does anything. We often wind up writing a lot of documentation just to describe things. What do these things do? How do they do it? When do they do it? For example, what do the menus do? What happens when you click this button? All those little blue dots are the notation for that. Even before responsive design came and kicked us all in the shins, it got really out of hand. Basically, wireframes just get really complex. If I was being presented something like this as a client or even worse, as a user, I don't know where to start. It shouldn't be this complicated. We should just show how it works. So that gets a big WTF. With an HTML prototype, everything is responsive, and everything functions just as it would on a live site. All of your components, sliders, content blocks, tabs, menus, etc., they all actually work. There's not much need for a complex notation because you can actually click around. You can resize the browser. You can try to break things if you want, and you'll actually see how it works. For example, you won't need to write about how the main navigation dropdown has this crazy flyout, do-hickey thing, and then drops down and does this whizz-bing animation, because it'll just do it. You can actually do it in there. You put it in there for the clients to see it, for the developers to see it, and everything works. Working software always trumps documents about working software. Prototyping forces you to discover and solve problems early on. I did say that earlier on, and I will be repeating a few things because I feel like they're important. This is where designing the browser comes in. Just to be clear, I'm not telling anyone to dump Photoshop. It's kind of like a love-hate thing. People love Photoshop. Some people hate it. I still use it. It's part of my process, but when it comes to designing layout and designing content flow and things like that, I go straight to the browser for that. Plus, you can't replicate Desert Chrome and CSS yet. So, here's an example. Let's pretend you're working on a content-heavy, responsive Drupal site. For the sake of this presentation, we're creating wireframes for three breakpoints. A 1024 pixel-wide wireframe, a 768 pixel-wide wireframe for tablet, and a 320 pixel-wide wireframe for mobiles. It seems like a good idea, but as you'll see, a lot of stuff can actually happen between these breakpoints. Things can get really messed up kind of in between a 1024 and a 768 layout. The thing is you won't notice these problems until they're actually been implemented, until it's in the theming phase or it's in the development phase. So, things like menus can break. Menu might look fine at 768 pixels-wide, but maybe you get down to 600 and it breaks. Or you have a centered layout, and centered layouts can look really strange once you get to about 600 pixels or a little bit wider. Margins of padding can get really, really tight, almost unacceptably so, right before a breakpoint. And some layouts just look like complete ass when they're between a breakpoint. But again, you're not going to know these things if you don't do an HTML prototype. You're not going to find this out until later on when you get an IM from your front-end developer saying, dude, your menu broke, and you need to redesign it. And it's like, well, I don't have any more design hours on this project, what am I supposed to do? That's also one of our front-end developers right there. So, I envy that before. With HTML prototypes, you can see how things look at all widths just by resizing your browser. So, if you want to know if your menu breaks between the common sizes or if the margin padding's going to be off or what the vertical rhythm on an iPhone 5 is going to be like, you can do it. These are all things, again, that you want to solve before the development process begins. Prototypes are more representative of the final product. So, to me, this is one of the most compelling reasons for you guys to start using HTML prototypes that work in a browser instead of traditional wireframes. So raise your hand if you've ever designed a website using traditional wireframes in a PSD. It's probably everybody in here. Keep your hand up if the actual implementation of your design ended up being wildly different than what you had in mind and without you knowing until it was too late to change. Yeah, that's what we're trying to avoid here. So, there's a quote from 37 Signals book and it kind of sums this up and it says that getting real delivers better results because it forces you to deal with actual problems you're trying to solve instead of your ideas about these problems. It forces you to deal with reality. So, basically, you want to make something real as quickly as possible. HTML prototypes makes your developer's job easier and lets them focus on what they do best. A lot of time can be wasted filling in some of the gaps on responsive products or projects going back and forth and, you know, hey, man, I need this for this break pointer, this layout, and you say, oh, well, I thought I did that already. Well, there's still, like we said earlier, there's still a lot of gaps there and we just don't want to leave things up for interpretation. Easier iteration, design, build, test, and evaluate for the win. With an HTML or a Photoshop, you can easily change layout, sizing, et cetera, with CSS. Adjust typography on the fly. Since we all know that our responsive website should be content first, isn't typography one of the most important things that we're going to deal with in the design process. Add or take away break points. Easily copy and paste segments. So if you've got, you know, if you've got blocks that, you know, say you have a section of repeating news items that you want to have going down the page, maybe five or six, it's an easy copy and paste of, you know, some P tags and some H2 tags and et cetera. And ultimately you can use, if you really want to get fancy, you can use CodeKit or PHP to do some includes and kind of create components dynamically, so that's always fun. You can get immediate feedback for testing and iteration. This is awesome. So put your prototypes on a server somewhere and load them on any device with a browser. Like if you want to know how something looks in an iPhone, you don't have to send your client a PDF and then tell them to open it up on an iPhone and like try to resize it so it's the right size. Just put it on a server and give them the URL. You can create a Git repo of it, put it into source control so that you don't have to worry about accidentally deleting it. So this right here is a photo of Jeff Robbins, our CEO at Lullabot, and he was perusing the Tesla dealership in Rhode Island. And it's a Lullabot website loaded on the browser and the center console of the Tesla Model S. If you wanted to test your HTML prototypes on a Tesla Model S, it's easy means. Not so much with a wireframe. So wireframes can't handle responsive design. That's a bold statement, but a major pain when it comes to responsive design projects is scalability. So these are photos inside of Amazon.com's warehouse or one of their warehouses. And they're a quintessential example of economies of scale. So Wikipedia defines economies of scale as the cost advantages that enterprises obtain due to size with cost per unit of output generally decreasing with increasing scale as fixed costs are spread out over more units of output. So what the hell does that have to do with web development? So basically if you make a tiny change, the more components you have, the more those changes are going to add up. So let's consider a fairly typical responsive website project where we would be creating traditional wireframes. So in this project we're making wireframes for four sizes, iPhone, tablet, medium width desktop, and a wide desktop. So already just for the home page, we have four wireframes we have to make. So let's say this is a very complex content heavy website and we might have several things in the UX that we have to nail down by using wireframes. So what if we have eight sections? So maybe there's like a media section, videos, blogs, recipes, products, news and contact. These are fairly typical for a Lollabot type website. Now we have 32 wireframes we have to keep track of. And that's not including any menus or widgets or additional components that also need to be wireframed. So keeping track of that is just insane. Imagine if a client comes back and says, all right, we've made some organizational changes and now we need to reorganize the menu and change some footer links and now we need to switch out some widgets. I mean, you're going to easily spend three to four hours just updating your wireframes. That's crazy. If you had HTML prototypes instead, you'd only have eight prototypes that need to be updated because they're responsive. I also learned this one the hard way. So basically what I was trying to say over the last few slides is creating static wireframes for responsive design is a nightmare. And then lastly, one of the most important skills in responsive web design, according to Trent Walden, is the ability to control the layout of how the content shifts and reflows at various widths. This is true in so many ways and using HTML prototypes that you can put real content in just helps this so much. Cool. So we've discussed why we wireframe, why prototyping is better. So I hope that I've actually sold you on this. So where do you start? What do you do now? First of all, every team and project and situation is very different. So start by evaluating these. Some important questions to ask yourself. As a designer, what is your level of HTML experience? Are you part of a large team or are you going to be working solo? Will you be handling front-end development or is someone else going to be doing that? Are you working with legacy content, a legacy site, or are you working with site migration, which is a huge challenge? Or are you building a new product from the ground up? What's a future forecast for the product you're working on? Meaning, is it something that you're going to build that is going to last for a long time and needs to have constant iteration and updates? Or is it something that's going to last for six months and then be taken down like some type of ad campaign or something? And then of course, it will just be a Drupal project because that actually does matter. So once you've evaluated these things, there's really two different approaches you can take to making HTML prototypes. They can either be disposable or reusable. So to elaborate a little more, when I say disposable, I mean that the HTML you create in your initial prototypes will not necessarily be used in the final implementation of the product. You can kind of throw it away when you're done. They're only meant for communicating. That's communicating ideas to clients and to developers. This lets front-end developers create their own HTML and CSS to their preference. This really, really makes them happy. As a designer, nobody likes to be told how to design. Well as a front-end developer, of course nobody likes to be told how to front-end develop. And then of course the last time is needed in the prototyping phase because they're more lightweight, but more time is needed in development and theming phase. Now on the other hand, you can have prototypes that are reusable. The idea here is that you use the prototypes to create the final HTML structure of the product. This comes from a concept of not wanting to waste anything. This is a little bit more challenging. It's something that we're working through at Lullabot and to be honest, we don't have a perfect solution for it yet. But it does require a lot of collaboration between the designers and developers. It is something that does have a lot of benefits if it's done right. It can take a little bit more time in the prototyping phase, but it can really cut time out of the development and theming phase. So those questions that you asked yourself in the last slide, those are really going to help you determine which method you want to go with. Of course, the big question is mobile or desktop first? Yes. I personally like to start with the most complicated interactions, but make sure that my HTML and my CSS is mobile first. Of course, become friends with your developers. I can't say this enough. Prototyping with HTML does require collaboration, and it has to have that to be successful. So does anything. Most clients and internal stakeholders expect a waterfall approach. It's your job as a designer to change this. In my experience at Lullabot, I've found that most clients are willing to do things a little bit differently than they have done before, if they know it's going to give them a better product. It's okay to push a little bit. The worst that someone can say is, no, we can't do that. So let's talk gear. So you can either, for prototyping with HTML, you can either use frameworks that are already out there, like Twitter Bootstrap or Zurb Foundation, or you can homebrew your own. There's, of course, benefits to both of these and downsides to both of these. So some of the pros of prototyping frameworks, like Zurb or Foundation, is that they're really quick. There's all kinds of baked-in stuff for you to use, like grid systems, common styles, components, typography. Typically, the people that make the frameworks are really, really crazy passionate about it, so they like to update them a lot. They like to make sure that they're working. And they've already done the browser testing for you, which is huge. They also have, at least in the case of Foundation and Bootstrap and several other prototyping frameworks, they all have very extensive documentation. Some of the downsides is that working with someone else's code, if you're really particular about your front-end code, that's fine. You might not want to be locked into a framework looking at you. There's a learning curve. Anytime you're dealing with somebody else's code, it's always, there's always a knowledge transfer time where you have to figure out what they meant by what they're doing. And then in the case of, like, Twitter, Bootstrap, and Zurb, there's proprietary markup and presentational classes. So, like, an example of this is Foundation's class-based grid system. If you want to have a div, that's going to be three columns. You have to include a class that says, you know, class equals three space columns. To a lot of people, that's a big no-no. And then it also might not be the best fit for your situation, which is a big deal. And it can be tough to get some frameworks to play well with Drupal's markup. I mean, let's be honest, Drupal's markup likes to kind of do what it wants to do. And we have to work with that. So, some of the pros of custom prototypes is that it gives you ownership of your code. You'll have more flexibility and not be limited by the assumptions and systems that someone else has built. You can customize until your heart's content. And then one of the biggest ones, enrolling your own framework, assuming that you know what you're doing, it's way more likely to create a basic structure and layout for the system that can become your final product. And you can also build up a library over time, which is great, because, you know, after a few projects, you might have a lot more components that you can pick and choose from. Some of the downsides is that you can wind up spending a lot of time planning this stuff and not actually getting to work on it. You'll have a whole bunch of choices to make about things that you want to use, like grid systems and JavaScript libraries, all that stuff. It's kind of like if you go into a big mega store and you're looking for a TV and there's 8,000 TVs, you don't know exactly which one you want to buy, so you end up leaving frustrated. It could be like that. You're on your own for support and testing. If it doesn't work in IE8, that's your problem, deal with it. And you have to provide your own documentation, so if you quit your job or if you hire somebody else to work with you, you're the one that's got to explain that. Some of the popular frameworks, ZERB Foundation and Twitter Bootstrap are the two biggest ones. The option, the one that I use mostly is Twitter Bootstrap. Sorry, wow, that was a big mistake. Sorry, snowman. Foundation 4 is the one that I use the most. It's mobile first. It's got, you can turn off the presentational classes by using SAS, which is great. And it's a lot more semantic in this update. It also has a lot of different templates and pre-baked components, so if you're somebody that wants to have a bunch of different things to choose from, if you don't have time to sit there and code out sliders and modal boxes and things like that, they're there. They keep working on it, so they're constantly doing updates and they actually have training available too, which is nice. The biggest downside is that out of the box, there's one break point baked in. I've had projects where one break point was fine. I've also had projects where I needed five break points, so again, that's kind of where you need to evaluate it for yourself. Some of the components that it comes with is navigation buttons, forms, typography, and some other components. So this is an example of the navigation patterns. You can go to www.bakedinpagination.com foundation, I forget the URL, but I'll tweet it out later. I mean, there's just so much to choose from. You've got baked in pagination, navigation, sub-navigation, top navigation, mobile navigation, I mean, it's all there. They have a number of previous styles you can use for buttons, tabs, pills, really anything that you might need. Forms, creating forms in HTML is a pain. Then they have typography, which is nice, lots of links, subheadings, block quotes, all that's there. And then there's just a bunch of extra stuff like if you need to float something to the left or you need progress bars, pricing tables. Again, that's all baked in. Stuff that would just take you a lot of time to do on your own. Twitter Bootstrap has also gotten popular. It's got a lot of documentation to it. It has five baked in breakpoints that you can utilize. And it has a really good number of templates and components as well. The downside is, and this is kind of a kicker for me, it's not semantic and it uses presentational classes for everything. And there's no option to switch out those presentational classes. It's still not mobile first, but I hear that they're actually working on an update for it. That'll be really cool when that happens. So basically desktop styles are the base and then it uses media queries to apply those styles downward. So if you're in a mobile first process, that's a deal breaker. Of course there's a ton of other frameworks. There's less wire fry, semantic, GS, SAS has a responsive framework, CodeKit. There's so many of them out there that it would probably take for the rest of Drupal Con to cover all the frameworks that are available. And there's even more than that. So if you Google HTML prototyping, you're going to get a list that's a mile long. So really the best thing to do is kind of know what your needs are and go play with some things. Go download some stuff, mess around with it and see what works best for you. So how do you make your own? How many people in here are interested in making their own prototype framework? Wow, that's a lot. Okay, cool. Well, basically all you need is a grid system and basic styling and that equals a prototype framework. I know everyone has kind of their own definition of basic styling, but in my experience it's best that you have a prototype that's just plain enough to not call attention to aesthetic. But it can't look terrible either if a client, a prototype that's just plain HTML, they're probably not going to know what to do with it. It has to be, as much as we hate it, it has to be a little bit pretty. So we've talked about why, what and how, so let's talk about how to get clients on board and how to get your team on board to this new process. First question is how much does it cost? So I'm sure you're going to get that. Anytime you talk to a project manager, sales person or a client and say, hey, we have this new thing we want to try, that's going to be the first thing that comes up. So Brian Hoff says, imagine asking a real estate company how much does a house cost? It depends. First off, what are the essentials you need? Do you need three bedrooms because you have two kids? You need central air conditioning because you live down south. Now that we have the essentials, what are some of the less essential yet nice features? Basement, extra storage, large backyard, three car garage, what if you could have it exactly your way? How about a pool? Sounds nice. Those things are all like, it's just like the design process. Every project is a little bit different and you can't just say it's going to take this much time or it's going to take this much money. But the real important question to be asking is what's it going to cost if we don't use prototyping on a wireframe or on a responsive project? So, you should already have allowed time and budget for wireframes, right? So overall, the amount of time you spend creating HTML prototypes should cut down in front of development as compared to traditional wireframe approach. There might be some initial time investment on your first project, but you should make that up with a quicker development cycle. Allow some time for experimentation. New things always, always take time to learn. So talk to your team on how to best approach this. It's okay to try new things and to learn to grow. And don't be afraid of the new process. Step up and own it. You know, at Lullabot, if we didn't experiment with stuff, and the only things we did were things that we already knew about 100%, we'd still be making Drupal 5 websites at 800 pixels wide for IE6. How does prototyping fit into the process? We've made the sales people happy by talking about time and money, so let's talk about design stuff now. It fits in because for me, HTML prototypes exist kind of in this area between three components of purpose, content and hierarchy and systems and style. You might have seen this from Jared Ponchot's talk about designing on purpose. That's not a coincidence since we work together and use my creative director, so we share the same design process. It's enormously helpful to think of the design process as more of a circular thing instead of a linear process. Our value of designers is not in our ability to use a particular tool or make responsive wireframes and visual mocks. Our value is that we help discover and communicate purpose and create meaningful order and systematic elegance. HTML prototypes are just a tool to help us do this just like Photoshop is. Sketch first. It's a quickest way to iterate. Absolutely quickest way. Sketching allows you to filter your good ideas from your not so good ideas and you can do this really quickly because to be honest, not every idea that we have is a good one. Maybe some of you guys, not me. It's really lightweight and it allows for really, really easy collaboration. If I have an idea, I can quickly share it with a client, quickly share it with a developer or with a front-end developer or whatever the situation is and quickly get feedback. For me sitting down to code before at least roughly sketching something out is just extremely difficult. We need to shed the notion that we create layouts from the canvas in. We need to flip it on its head and create layouts from the content in. That's Mark Bolton talking about content first design. In HTML prototyping, basically, is it design? Is it strategy? Or is it front-end development? The answer is yes. It's all the above. We need to think of responsive web design as a holistic process that includes all of these things. It's Drupalcon. Let's talk about Drupal. Try to keep my process pretty platform agnostic but there are some tips and tricks for creating HTML prototypes for Drupal projects based on my own experience and doing these things will make your developers happy little trees. Keep your markup free of presentational classes. I can't stress that enough. It's a challenge with Twitter Bootstrap as a framework but it can be done with SAS if you're using Zurb Foundation and if you're making your own, that's up to you. If you're using a grid use the same grid for your prototypes. I said earlier that a prototype framework is essentially a grid plus styles. Let's say you're using ZIN grids for your Drupal theme, use that for your prototypes. Divide your HTML and CSS into partials like Drupal does. This does get kind of complex. This is one thing that we're messing around with at Lullabot but basically you just want to structure it like Drupal. If you do that, it's going to be so much easier in the theming phase. Then they actually have Bootstrap and Foundation themes. If you're planning on using either of those for your prototypes, give it a shot. See if it works for you. That's all for me as we like to say at Lullabot. Ta-da! If you have any questions, please step up and ask away. Also, I will be posting, keep checking back on Lullabot.com I'm going to post the resources and links that I used on this as soon as I get a little bit better Wi-Fi connection that's a little bit more reliable because I have a lot of big files to post. Just keep a lookout for that. You touched upon a lot of stuff that Stephen Hay has talked about in his responsive web workflow and what I found was difficult was getting from the prototype to Drupal. What I did was I kind of made empty content types in a way and did the wireframing with a sub theme. That's a good idea. Do you have a particular sub theme that you like because content first or design, you know, they kind of go hand in hand so you can't really design content unless you know what your content is. So have you explored that process and do you have a particular theme you like to use for kind of quick mock-up? Yes and no, sort of. That doesn't really answer it but it's kind of a two-part thing. So as far as understanding what your content is we try to always do at least somewhat of kind of like a content exploration or content audit before we start any of the design process because it's so easy to just design something that you as a designer think is good but it's not really reflective of what the actual content is going to be. So if you can manage a first step of doing like a content audit or, you know, working with a client to first just discover what the content types are, start with that. That's typically even before the design process starts and then as far as a sub theme I don't have really one that I can recommend but if you're in a situation to where you're working with a little bit more complex theme and, you know, you don't, you may want to consider doing something that's a little more throwaway like using, you know, one of the frameworks or just creating your own framework but not with the intention of taking the HTML to the final process. So I would use it as more of like a roadmap of how you want to build it. Hi, first of all, thank you so much for the presentation. You're welcome. My question is, so I'm the guy who sits at the desk and gets the wire frames and then gets the PSD and then has to put the two together with Drupal and the... You sure are amazing. Well, and that's the issue is I feel like the more specific my PSD is and the wireframes are the more challenging it is to kind of like wrangle Drupal into making everything match exactly. And to me, to build multiple responsive designs like this and have a very specific way that they're going to collapse down, you know, for the user page and for each content type and for the home page, that seems like adding a lot of additional work that could be really challenging to implement in a specific time frame. So can you speak to that process of how specific do we really want to be when we're deciding early on in a project, for example, what is going to happen as things shrink down? Well, okay, that's a good question. Um, so the way I tend to look at it is the last thing I want to do is telephone and developer exactly how to do what they're doing. So I tend to look at prototypes as kind of like this is how I'd like it to work, this is how you know, this is kind of how things should work, and then this PSD here or these style tiles or the visual design, this is like the extra layer of style, but I'm kind of giving it to you to have freedom and kind of make it look like that, but I'm not expecting you to completely just be mindless about it and completely just duplicate it. There is an art to front in development and when it comes to prototypes they're really they're just kind of more to guide you and like not have unanswered questions of what happens when it's between break points or when it's at 646 pixels but the wireframe you gave me is for 700 pixels. That definitely makes a lot of sense, I really appreciate that the challenge is communicating that to the client when they've seen these wireframes or these prototypes that collapse down the way they do, and I feel like that would be something that could be resolved for sure too. I think a lot of that it kind of goes back to being able to have an open line of communication with your client and say that these are prototypes, this is the final product, the final product is going to come after lots of refinement it's going to look similar to this, it's not going to look exactly like this and maybe I've just gotten lucky but I've actually found that clients don't always care if something isn't exactly like it was on a wireframe or prototype, a lot of times it's within the agency like a project manager or something like that that are actually, because that's their job is to make sure that you're delivering what you promised so it may actually be more of a change what you're promising type of thing. Awesome, thank you so much. You're welcome. I know earlier you mentioned using like PHP Includes or CodeKit, have you tried using like an extremely light CMS for prototyping like Jekyll? I have not. Combining that with Zurb Foundation might work. It's a Ruby project but like the liquid templating is kind of similar to twigs you can really easily just get like a menu or blog role or content just in text all are marked down. That's cool. We've been experimenting with our own Ruby based system. Serve, yes. Yeah. What he said. He works with us. For posterity, repeat that on the mic. Wait. How did you get started in Jekyll and move to serve? I can hear you just fine. I guess for the earlier question sometimes I'll get a really tiny brochure site. I'll just pick a random, just like Bartik and if they have any content put the content in there and say does this navigation make sense, does this content make sense? And then from there to starting a sub theme just kind of iterally go through it and I found it works for simple projects. So I say that I'm a fan if possible just going from sketching to iteratively designing in a browser. As long as if you have regular check-ins you can find yourself backtracking less. I'm sorry, I'm having trouble. Sorry. If you check in with the people you're working with you can find yourself backtracking a bit less. Yes, this is absolutely true. But you have to find the right person that's okay with being like don't worry about the padding, don't worry about the colors just tell me about how it works and functions. Yeah, that's absolutely right. Have you had experience using foundation where foundation ends up in production or is it just strictly like a prototyping thing and then someone else has to come in afterwards? So the most recent project that we did with foundation that was actually with foundation 3 before they kind of did the mobile first update and that one was used as more of a guide. We intended to use it for I believe they were going to try to do some decoupling magic, basically decoupling the front end of Drupal from the back end using Node.js didn't quite work out as planned so it it was supposed to be a front end basically a front end structure but it ended up just being kind of a throwaway thing. But it still worked out really well because after doing those prototypes I gave those prototypes to the developer and then I did a few design mocks but not a lot and between those two things we were able to build out the entire website so it worked really well for us. Not quite as intended but I have two jobs in my freelance I can use whatever process I want. Awesome. But because it's just me but on my other job I work for university and I have kind of the same problem as the other guy where you're given your designs locked in a picture and then you take that picture from a different department and you make it go in Drupal and I'm having a lot of trouble convincing the people who design that they need to learn that this is a fluid medium and they're print designers so it's really hard to break them out of that mold do you have any suggestions to help designers? So I actually worked in a similar situation for a healthcare company so is it a very large organization? And I'm assuming you probably work in different buildings as these folks? Across campus. They're probably I'm going to say that they're probably a subsection of marketing whereas you're probably an IT. Yes. So You know everything. Yes. You know unfortunately well unfortunately it depends on how you look at it the best thing that you can do is go to lunch with those designers or go buy them a beer it's most likely the communication breakdown it's not that the designer is saying yes stupid Drupal developers they don't know what they're doing it's somewhere in between you and them it's somewhere within the organization if you actually go to them and explain some of this stuff I would have a hard time thinking that they wouldn't want to accommodate that. Because they're great with branding. Yeah. The color schemes and the font A lot of times when you're dealing with a large organization where everything is separated it's just that people just don't know what you have to deal with. So if you communicate that to them this is a giant pain in the butt and it's very, very difficult if you could just do these few extra things then it would make more allies easier and then I'm sure there's something that you could do in return that's not an easy technical solution but I've been traveling like crazy I've I've got like three hours sleep in the last few days so it's Wednesday go drink