 Sure, definitely. There's a lot of designers in here. Is this? Yeah? Is everybody in here designer, front end developer? So it's nice seeing all these design folks at a code conference in one room. So cool. So I'll go ahead and get started. Hello, welcome to the last day of the DrupalCon sessions. So as the screen says, my name's Josh Riggs. And I'm a user experience and visual designer at Lullabot. Before we start, Lullabot is hiring. So if you're a designer, front end developer, Drupal developer, or I think a account manager, we want to talk to you. So yeah, I've worked at Lullabot for about two years now. And I specialize in designing extremely large-scale Drupal sites, mostly for media and entertainment companies like the Grand Beans and NBC Universal. Greetings from Portland. So just a little about me. I was born and raised in Florida. But now I'm a proud resident of Portland, Oregon. Last year, my wife and I, we decided we were tired of sweating our asses off in Florida. So we sold everything that went and fit into a five-byte pod. And we drove across the country with our dog. And that's one of the great things about it. Here's another plug for Lullabot. Working for a distributed company is it allowed us to do that. So besides design, I love photography. Cooking, photography of cooking. I tend to take a lot of photos of dinner on Instagram. So if you follow me on Twitter or Instagram, you'll probably see a lot of that. And apparently, this makes me a hipster. So last year at DrupalCon, I gave a presentation on HTML wireframing and prototyping. And I thought it was a pretty good and informative talk. But actually, I've kind of changed my mind on some of the things I talked about last year. Things just change so much over the course of a year. To me, the most important piece of information from that talk came at the end during the QA session when a woman asked, she was asking advice on how to implement some of these things in the responsive redesign that they were doing. She said that at her company, they were having problems with designers who designed things that couldn't be built. They just didn't get it. And when she was describing her situation, she was saying that design and development were in two different departments. They may have actually been in two different buildings. And they actually didn't regularly talk to each other. And when she said that, I had an aha moment. I realized that her company's problem wouldn't be solved by designers simply learning how to design in the browser or learn to code. They needed to have this wall between design and development torn down with a sledgehammer. It was a problem of technology, or excuse me, it wasn't a problem of technology. It was a problem of process, which brings me to building a self-aware droop full front end with skynet.js. You guys awake after lunch, fall and sleep? No, actually, this is not going to be much of a technical talk. It's more of a process talk and responding to responsive designers guide to adapting. Basically, we're all experiencing the growing pains of building the responsive web. There's a lot of talk about some of the dialogue is like, we need to kill Photoshop, or that designing the browser is going to save humanity. I have my opinions on this, but we'll talk about that later. But I don't think we can solve these fundamental process problems by changing what app we use to build our design mocks. So instead of giving a super technical presentation about a new method or technique, I just want to have a conversation about design thinking. Responsive design is fucking hard. Let's just get that out there. Let's submit that. You know, sometimes it feels like an uphill battle, which is why I chose that photo there. If it wasn't hard, we all wouldn't be in this room. I mean, there's a lot of people here. I think there's like 11 Drupal con sessions this year talking about or mentioning responsive design. So we're all here because we want to learn something and hopefully something that makes it easier. Right now, our entire industry is kind of trying to figure out how to build things better responsibly without going insane. So if anybody says they have it all figured out, they're lying. So why is it hard in case you haven't noticed? It was already hard enough to build single-width content managed websites and test them on three or four browsers in a few operating systems. Now I have infinite widths, thousands of screens, hundreds of devices, dozens of browsers, and operating systems to worry about. So it's not just a technical challenge to do all this, but it's also an organizational nightmare, especially the larger the project and the larger the company is. A lot of our clients sometimes still cling to older advertising project management styles. Or if we work in-house, a lot of our executive teams still cling to these old processes. And raise your hand if you've worked on a responsive project that's been grossly underestimated, or the budget was completely blown, timeline was completely blown. Yeah. All right, me too. So how can we make it easier? Does anybody who practices Buddhism or the concept of Zen will tell you that the journey to improvement starts within? We first have to embrace that responsive design is a huge challenge, but it's a challenge we can overcome. So for the rest of the time together, I want to talk about things that have made my life a little bit easier over the last few years of building responsive Drupal sites, and some of the things that didn't work so well. First thing I want to talk about is the craft of web design, what it means, and how we can become better designers by refining our craft. Second, I want to talk about how we need to evolve our process in order to create better responsive designs. And we do that by we start by tearing down the wall between design and development. And then finally, I want to talk about how you can take all this information and actually make it happen for yourselves. So the elephant in the room, I just want to go ahead and get that out there. There's been a lot of talk about designers learning to code and designing in the browser. It's like, if you've heard all designers should code, and Photoshop's dead, and you're a horrible, terrible designer if you even think about using Photoshop. I don't think about it because you're going to be fired. I actually even read an article that was very thoughtful, rebuttal, saying that developers should learn to design. And I have opinions on that, but I guess I'll start off by saying I'm a designer who can code. And by code, I mean I know enough HTML and CSS, SAS and some JavaScript. I can build static versions of the things I designed. I played around with other things, the last foundation, learned some Jekyll. But I've been working with Drupal developers long enough to know what's going to be a huge pain they ask to develop. So I've heard the term coding designer. I've also heard the term unicorn. So what do I think? The late comedian Mitch Hebberg had a great bit about how comedians in Hollywood are expected to be all things to everyone. He said, when you're in Hollywood and you're a comedian, everyone wants you to do other things. So all right, you're a stand-up comedian. Can you write us a script? That's not fair. That's like if I worked hard to become a cook and I'm a really good cook, and they say, OK, you're a cook, can you farm? I think Mitch is right. So for us to expect designers to be on the same level as front-end developers with code, or for that matter, for developers to learn to design is actually a little belittling to both of these crafts. I definitely think that it's great to have cross-discipline knowledge and for designers to learn about code and developers to learn about design. But as designers, we think in hierarchy, colors, textures, typography, and we don't think in algorithms and arrays. We can certainly be trained and taught to think that way, and it comes with practice, but our brains just don't typically work that way. And they're only so big. So if designers are also expected to become front-end developers, does that mean front-end developers also need to learn sysadmin or SEO? So I think we should be aware of shits. So like saying things like, what if we said all musicians should compose their music on a piano with written notation? Does that sound limiting? If that was the case, most of the great rock bands wouldn't exist like The Beatles, Who Slayer. These musicians, they used whatever instruments they could and whatever methods they were comfortable with to create. Or if like we said, you're not a real photographer unless you shoot digital, you have expensive lenses and you process with Lightroom, that's just false. So we don't say stuff like that, but we're really quick to tell other designers exactly how they should create. So we're digital craftsmen. Building the web is a craft, and designers and developers are craftsmen. And I don't mean like crocheting is a craft, although that's really hard and I have a lot of respect for that. When I say craft, I'm referring to a trade that requires skill and artistry. Photography is a craft, woodworking is a craft, architecture, masonry, these are crafts. We're like the builders of the internet. We're like free masons, but digital free masons, if that makes sense. We're highly skilled, we're highly creative people, and we build very complex things for a living. There's an art and a science to what we do. And some of us are better at art, some of us are better at the science, and that's okay. So with that in mind, let's take a look at what exactly the craft of web design is. So as I said a few minutes ago, I'm also a photographer. In many ways web design and photography are pretty similar. Both photography and web design have highly technical aspects. It's what I'm referring to in this talk as technique. With web design we have our CSS, SAS, HTML5, JavaScript. I mean, it's an infinite list, but it's basically the tools that we use to create the work that we do. With photography you've got your F-stops, your focal lengths, your lens types, your camera sensor sizes, filters, whatever, same thing, very large list of tools that help you create. Photography and web design also have highly conceptual and creative aspects. This is what I refer to as vision. Web design has your overall user experience, your typography, your colors, your textures, your lines, planes, your motion, motion, animation, things like that. Photography also has colors and lines and textures. To me the technique refers to the science where the vision refers to the art. And I'll be blunt here. I'm gonna say this. I think we've become a little bit too concerned with our technique and tools for designing responsive products that we've kind of lost track of vision, style, and substance. So in order to design the best responsive experiences and master our craft, we need a clear vision as well as a solid foundation in technical skills. So I picked up photography about seven years ago, but it wasn't until I read a book by a Canadian photographer, David Dusherman called within the frame that I actually started to really grow as a photographer. The subtitle of the book is The Journey of Photographic Vision. And the mantra of the book that gets repeated over and over again is gear is good, vision is better. I'll repeat that. Gear is good, vision is better. And what David Dusherman is saying is that technical things like camera gear, lenses, hardware, software, and all that stuff, what program you process your photos in, all of that, it doesn't matter as much as having a solid photographic vision. A photographer can know every technical detail about a camera. She can know everything about f-stops and shutter speeds and all that, but if she doesn't have a solid photographic vision, her photos aren't gonna be interesting. For photographers to master their craft now, not only do they need to understand the technical aspects, but they need to work hard on defining and refining their photographic vision. So reading this book and applying this philosophy to my photography, not only made my photos better, but it got me really thinking about what I do for a living, which is responsive web design. Yeah, we need to understand the box model and we need to know about how browsers interpret things and render things, but we also need to be the visionaries of the user experience. So just for fun, I asked David to define vision in his own words on Twitter and he said this, vision is the larger story, goal or message, which we align our work. It's the why that informs the what and how of our work. So to me, that was like mind blown. Like to me, I can see how that applies to the dialogue right now in web design. So I don't know if you guys can see that, but to me, it's like, I feel like a lot of our dialogue has been about the what and the how and not necessarily the why. So just to clarify, design vision is the why that informs the what and the how. What problems are we solving for and why? What are our business goals and why? What will our design principles be? Why are we using the UI patterns that we're using and why do we need to fucking care of ourselves? I'm mostly kidding, but I'm not really kidding. So vision is a very abstract concept and it's different for every designer. It took me a long time to like, I knew I wanted to think about, or I knew I wanted to talk about this topic, but like just taking this abstract concept and putting it within 60 slides for a presentation was really difficult, whereas technique is concrete. So what are some ways we can bring vision to the forefront of our responsive design process and not get completely bogged down by technique? I'll get to specific processes and deliverables later on and I will talk technique later on, I promise. But I wanna start with some more general thoughts. So first thing is design systems, not pages. This is the concept at the core of component-based design which you may have seen other presentations at DrupalCon about that, which I'm all on board for. However, most of the articles I've read on the subject tend to focus on front-end development and techniques like how to use SAS extends or mix-ins, things like that, which is certainly great, but having a solid design vision means being able to design a system of bits and pieces that can be rearranged if needed and still work together, especially with Drupal and content-managed websites. We know our content can be extremely variable. We know it can go from one end to the other of having very little content to just having so much that you don't know what to do with. And one of the best ways that we can account for this variance is by creating a well-thought-out system of UI patterns that sees everything from more of a bird's-eye view. So again, systems and not pages. We need more visionaries and less coders. Now, I realize this is an old statement and I'm not saying that designers shouldn't learn code. I'm not saying we don't need awesome front-end developers because we do. We always need front-end developers. But what I am saying is that as designers we should also embrace our unique ability to be visionaries. We have this ability as designers to take something from nothing. We can take business goals and organizational challenges and user needs, kind of just grab them from the ether and create something visible and tangible. This is what we get paid for and this is a skill that requires a lot of practice. So let's not define ourselves by the sass mix-ins that we know. Yeah, we need to know the rules of the DOM but as we start obsessing more and more about code we kind of start to box ourselves in and limit ourselves to solutions that we personally know how to build. The tools you create should never get in your way. Design is about creating ideas in the quickest and most natural way with the least amount of resistance. For some people that could be Photoshop, it could be sass and browser design and HTML for others. For me personally, it's a combination of sketching, high-fidelity mocks, browser design. And that's cool and I'm gonna show some of that later. But the important thing to remember is that these tools should help you create and be an extension of your vision. They should not limit you to find your make design decisions for you. Don't trade style for tools. I read an article recently by designer Dan Maul on Web Standard Sherpa. And then Dan was asked this question. Somebody said, now that I'm no longer using Photoshop for prototyping, I wonder if it still has a place in my workflow besides just image processing. His response was pretty long but for me one of his best points was this. He said, when I'm writing code, my brain isn't in creation mode. It's in debug mode. All sense of expressiveness is usually stifled in place of correctness. Then he said, and no offense but most sites I come across that were designed in the browser look designed in the browser if you know what I mean. So one of the things that I've been reading a lot is that, and I've kind of started to notice is that a lot of responsive design is starting to look a little bit ubiquitous. We're starting to see a lot of the same design patterns. And I think it's because we're all right now using the exact same tools to create stuff. We're all different in special flowers. As I said earlier, designers and developers are different. We think differently. We solve problems differently. Because we're working towards a common goal of creating a great product, there's often a lot of times overlap in our skill sets and that's cool. We're all so human and we choose for different. And some designers are really technical. I'm more of a technical designer. Whereas others are extremely artistic. Is Justin Harrell here? I'm gonna call him out. I hate that guy because he's an awesome illustrator. And he's definitely on the artistic side. But that's cool. Having designers with a variance of skill sets creates interesting work. Some of us are unicorns, but I don't imagine that there's a lot of people that can do everything perfectly amazing. And if they do, it's probably because they're not getting sleep. So just because someone isn't proficient in SAS doesn't mean they can't solve complex UI problems. And just because someone isn't a visual designer doesn't mean they can't have great conceptual ideas. So, well, it's not rigidly define ourselves by saying we must always use our tools in a certain way. So I'm gonna make a bold statement and then I'm gonna stop making bold statements. Success or failure of a responsive design has never depended on whether or not the designer used Photoshop. We'd like to think these tools are so important in life altering, but they're not. They're little pieces in the whole process. It's not because of a lack of browser design or designer who doesn't code. It's because of lack of a communication. Often there's a virtual or even physical wall between designers and developers. And to me, this is the problem. This is the wall that needs to be docked down, which brings me to evolving our process. So yeah, responsive design is hard. In the next bit, I wanna talk about how I can build a better process that helps us to make it easier. I have a quick project case study I'd like to share with you. And then I wanna do a little bit of an overview to what I consider to be an ideal responsive process. And I say ideal in quotes because we'll see you later. First, I wanna talk about the wall. That's Betty White on a wrecking ball. So, any of us who've worked on a large responsive design projects, know the biggest challenge is designing for all the complexity. This challenge is much more difficult when we have a project plans that separates design and development to two different phases. But that's kind of always been the traditional way of doing it. On top of that, if you add in some variables like design and development being done by different teams in other buildings or even from one state to another. I mean, some companies maybe have like a UX department in San Francisco and a development department in Seattle. Or God help you if design and development are done by two different agencies or vendors at two totally different times and different countries. And I've seen that happen before. Situations like these tend to create virtual or physical walls between designers and developers. So, here's an example of kind of a typical enterprise process here. It looks kind of like this. UX, visual design, or excuse me, strategy. UX and visual design and development are all happening in large blocks of time one after another. And in between these phases, there's these giant walls in which people just throw deliverables. It's like, hey Josh, here's your strategy jocks. Email me if you have any questions, but make that happen. And then I go into my silo and I'm designing stuff and then this is the greatest thing ever and then I throw it over the wall to the developer. And it's like, all right, here's my design, make it happen. That's not the way to do it. Doing it like this creates just a lot of confusion. Context gets lost, purpose gets lost. For example, you don't know why there's an executive order to put a carousel on the homepage. You were never given a chance to suggest anything else. You just know that the person paying you wants a damn carousel, so you get to work and you make a carousel. So, if we remove the walls from the process, it starts to look a little more like this. Maybe the core team can't be in the same building together, but if we get strategists, designers, developers working together from the beginning, there's gonna be a lot less confusion. The goal is to create an iterative process where strategy, design, and development are happening at least somewhat in parallel to each other. There's always gonna be last minute requests and fire drills, but when you know why you're being asked to design or build something, it's a lot easier to deal with. So what if you're somewhere and you're stuck behind a wall? Maybe you're working somewhere and you're in a project that's already in progress and you can't just go, you know, you can't just change everything up. Well, first thing is don't try to be a hero if it's a high pressure project. There's always gonna be additional projects for you to try new things on. Now, I'm a huge fan of trying new things, like that's kind of, I'll get to that a little bit later, but that's something I've always done. But if it's a project to where you're gonna lose a client if you don't meet a deadline and people are gonna lose their jobs, don't start browser design if you haven't done it before. Find out who's gonna be developing your work, get in contact with them, stock them if necessary, not that type of stock, but email them in Pestrum, because the best work really comes from an open communication between designers and developers. And most developers I know would be happy to work with a designer. They're used to designers not actually reaching out to them. So be really thorough. If you're sticking with Photoshop comps, annotate everything and create as many designs as you can because the biggest, the most difficult thing for front-end developers is having to fill in the gaps between deliverables that they're given if they're not being given code. Explain why you've created everything in your designs. Give context. So if you just throw developers a design over the wall, they usually don't get any explanation. Instead, they're just kind of told to shut up and build it. And that never works out well. My experience telling developers why you made your design decisions goes a really long way in making sure that those design decisions get implemented rather than just thrown back at you over the wall. All right, so I wanna talk about a project that I worked on earlier this year for the NAM Foundation. Hi, Adam. Adam's a developer for the NAM Foundation. He's probably cursing me under his breath for all I know, but just kidding. So it's kind of a case study in separating ideation and production. So the NAM Foundation is the National Association of Music Merchants. They're a trade organization for musical instrument manufacturers and retailers. They run the largest trade show in the US, which is the NAM show in Anaheim. Obviously, if I'm saying anything wrong, just tell me I'm wrong. And NAM Foundations are a nonprofit foundation for music advocacy. So they hired Lollabot initially for design and content strategy with the intent to develop the responsive site in-house. So right there is kind of a unique experience in that we need to create something that can then be passed on. So the great thing is that we had a chance to work with their whole team from the beginning. I also had a limited time to produce my work, which basically means that our goal was to make our work as thorough as possible. So instead of giving them PSD files, we decided to make our deliverables be fully designed HTML wireframes that were completely styled. This way their developers could see exactly how everything is supposed to work and behave responsibly. I do a resource availability and scheduling. I was also the designer and the front-end developer, which I'm definitely more on the designer side, the front-end developer side, but I was definitely up for the challenge. Yeah, so I was gonna be doing a lot of browser design. So one thing that helped me was to separate this project into ideation and production and using the right tool for each. So if we think of building a responsive website like building a puzzle, we can't put the pieces together until we've actually painted a picture. So ideation is like painting the picture and production is like putting the puzzle pieces together. So ideation is about starting from a blank canvas and creating conceptual ideas. This is extremely important and vital part of the design process. It includes important design decisions like art direction, UI concepts, visual problem-solving, exploration and sketching. So going back to the Dan Maul article on web standards, Sherpa, he says there's no need to care at this stage whether what you're designing is a good idea or even possible. The main goal here is expressiveness. I'm looking to establish art direction and the touchy-feely stuff. So as a recap, ideation needs a canvas where you can easily move things around and play with position, hierarchy, colors, typography and textures. It needs iteration and the ability to experiment with multiple solutions. It needs to be quick and messy. It's like the equivalent of sketching your idea on an app and at the bar, which I've done. It's about the bigger picture and creating an overall design language. And lastly, ideation can't be inhibited by merge conflicts or Ruby dependencies. Nothing kills my creativity like spending two hours fixing a merge conflict. So in other words, for me, Photoshop is perfect for ideation. It gives us all these abilities. Photoshop doesn't get merge conflicts, it doesn't require a plug-in to a plug-in to work and its output looks the same in all browsers. Production, on the other hand, is about completing the conceptual ideas and making them concrete. So this is an equally important part of the design process and that includes taking the design language that you created in the ideation phase and applying it throughout the whole system. Includes breaking things down into reusable components, testing and validating the design system in a browser and filling in any gaps. And this of course needs to be organized and efficient, needs to be precise, needs to be easily repeatable. Provide detail and clarity for big ideas and it's where we test and validate. So production is where I switched to code. I do this once I've already created a general design direction. Only then is when I can switch my brain over to be more analytical and computational. I can't do both of those at the same time. That's okay, I'll admit it. You know, I just, I can't start with a blank browser window and then start with code. That's cool. So yeah, name design and deliverables that were actually seen by the clients. I did a lot of sketching and exploring, but I kept that to myself. So we created working responsive HTML wireframe frames. We decided on 15 displays, displays kind of like a more modern term for pages. We did a set of style tiles. We did some high fidelity PSD mocks. And then we took the design language that we created and the style tiles and the high fidelity PSD mocks and we applied those to the wireframes. And then finally we created an HTML interface style guide, which basically has all the text and content styles of every possible thing that they could need to create new parts for the site and update the future. So I wanna talk about a little about the wireframes and how I broke that down into ideation and production. So to me the ideation phase of the wireframe is paper sketches and doing some quick illustrator mocks. Like starting out with sketching ideas and then once I get kind of a little bit of an idea, taking it into just more of a canvas program doesn't have to be illustrator. It could be Photoshop or fireworks or whatever, paint. Just making sure it works. And again, these weren't seen by the NAM team. This was just between myself and the Lollabot team. And then from there we created the HTML wireframes based on the sketches. We used Jekyll for templating, which is great because if anybody's used Jekyll, I highly recommend checking it out. It allowed us to create basically components similar to how Drupal would create components. We did SAS partials and HTML. Again, to mimic the Drupal structure. And then the idea was that the code would be refactored later because this was still early on. So here's an example of a screenshot of the first set of wireframes. If anybody hasn't used Duo, the browser, it's a great browser for, you can see your mobile view and your desktop view at the same time. So visual design. We separated that into ideation by creating style tiles, high fidelity PSD mocks for the five displays, and then icon design. Production of the design was we took those, styled the visual design determined in the style tiles and the PSD mocks and we styled the wireframes completely in the browser. From there we did an HTML style guide and then we ended up refactoring some of the HTML and SAS as we needed. So here's an example, two style tiles that we started with at the beginning. Whoa, got dark. So the one on the left was influenced by blue note records and the one on the right was just kind of influenced by more of a modern design and ultimately they went with the one on the left. Here's five PSD mocks that I created based on those style tiles. Some detail. And then because we need to show some code porn at Drupalcon, this is a screenshot of fully styled HTML design mocks. It's really complex to show all this stuff in a slide show so if anybody wants to see kind of the nuts and bolts and how this was done, please come see me afterwards or at the lullabop booth. And then we also gave, or excuse me, this is a screenshot of the HTML interface style guide. And this was again just all the additional bits and pieces that they might need to build the site out. So why do we choose a process with NAM? Is this the ideal process? Well, no, NAM was a very specific scenario. Because of scheduling, I was the lead designer and front end developer. Lullabot acted as a consultant to NAM. We were working directly with their development team. These are all factors that helped us to choose a design plan and choose the tools that we use to design this. So for example, if we had had a dedicated front end developer on the project, I probably would have done far less front end code. I would have maybe focused more on visual and UX and front end developer would have done that. If I was working in house at NAM, maybe I would have had a totally different process. But that's, to me, that's just really important to consider. So is there an ideal process? The truth is there isn't one. Every responsive design project has a very specific scenario with unique people and teams. The important thing to remember is that you have to pick the process in a way of working that works for you. There's a ton of methods and opinions out there like Brad Frost pattern lab and component-based design. But that works for Brad Frost. But that's his style and his method. And it may or may not work for you. It's not a good idea to take somebody's specific process and apply it to your own without customizing it. But that's cool. We need to use the methods and process that best suit our needs. This will probably change next time. Skip to slide, sorry. So if I have to choose, I like to start out with UI sketches. Keep this internal. I like to make responsive wireframes not focusing on production ready code. I've just found out that there's too many variables to start out with production ready code and wireframes at the beginning and then expect things to transfer smoothly. Plus, it's no fun as a front-end developer for someone to say, here's your code and make it happen. That's, as a front-end developer, that's your art. That's what you do. The key here is to basically communicate ideas to clients and developers with these wireframes. I like to start a style exploration. Nothing is formal as a style tile but basically just messing around with things whether it be sketching or playing with things in Photoshop. And again, the key is to get my creative brain working. There's no right or wrong at this stage. Style tiles is next and that's where I like to get a little bit more specific. And this helps me to kind of take all the crazy ideas that are floating around out there and just kind of just get a handle on them. And this also helps make the client, helps get them to kind of pick a direction before you go too far down the rabbit hole. So I need to do high-five mocks. I need to do Photoshop mocks because I need to see how everything fits together. Some people maybe don't need to do that but for me it's like, I don't know, that's just how I think. And once I've done that, I'll switch to code and finish the styling, the wireframes and the browser. And then finally an interface style guide or a new thing we've been messing with is a component collage which is basically, you can decide whether you wanna do a fully working HTML style guide or if you wanna do that in Photoshop and give it to your front end developer. Either way, as long as you're designing all of the bits and pieces that need to be used. This might change though. Ever since I've started designing responsive websites, I've not used the same processor deliverables exactly the same way twice. Partly because things change so fast and partly because every project needs a custom process. For example, as I said, I decided to stop aiming for production ready code in my wireframes just because it got to be too difficult. So, make stuff happen. Most of us here are part of a team of some sort. Maybe like a small internal team or a large enterprise team or like me, I'm on a consultancy team. We usually can't just come in guns blazing with an all new process and expect everyone else to follow suit. Especially if we're working on projects that are already in progress. So let's talk about some ways we can make a responsive design process better no matter what your situation is. So, we don't need to be embracing new techniques. I heard somebody say this, I can't remember who said it so if it's you and you're in this room, I apologize for not attributing you but your job as a designer is to be a professional learner. Nearly every project I've worked on has required me to learn at least one new thing. This time a year ago, I knew ZeroSas. Now I've worked with it on a daily basis. Two years ago, I had never built HTML wireframes but again, I kind of do that on a daily basis now. Sit next to a developer for six months and then ask them tons of questions. Find a developer in your company, one that won't get annoyed by you and sit next to them. Even if you don't know anything about code by the time six months are up, if you continue to bug them with questions on how to do things, you will know it. That's how I got my start with HTML and CSS. I sat next to a .NET developer at a time share company and any time I had a question about something, I was like, hey man, how do you do this? And he told me and it kind of set my foundation for coding. I also had to learn to great respect and understanding for what developers do. Commit to something you don't fully know how to do. So obviously you should pick something that isn't a high-pressure project, but start small. If you haven't yet built HTML responsive wireframes on a project, commit to doing that. But give yourself time for a learning curve. Then one of the most important things to me is to do personal work. Create something for yourself by yourself. So I'm not saying freelance work because that's a totally different thing but work that's solely for the purpose of learning and trying something new. Could be like a personal photo blog or a website for your upcoming wedding or an app or something. But doing this personal work for yourself, it allows you to try new things without budget constraints. Allows you to get better at something that needs improvement. So like for example, I'm not the strongest illustrator probably in the room and I know this so I created a personal project for myself where I create an illustration every day no matter how bad it is. And over time, as I keep practicing, it gets better. There's no catastrophic consequences if something doesn't go according to plan. You're not gonna get fired for not launching your personal project on time. You can work in whatever way you want. So like if you wanna try a new version of Sketch which is an image editing app kind of like Photoshop or you wanna try using BEM syntax for the first time, you can. And the best thing is you're gonna end up with a really cool piece of work. So this is a project I did for a couple in San Francisco for their wedding. They saw a site that I created for my wedding a few years ago on an inspiration site and they liked it and they asked me if I would do freelance work for it. And at the time I was kind of busy and I was like, you know, I'm not really looking to do freelance work right now but I was like, well, here's the thing. If you guys give me creative freedom and let me try some new stuff, like I've been wanting, this was I think two years ago, I've been wanting to build a responsive site myself. I've been wanting to mess around with Bootstrap, wanting to learn CSS pre-processor. If you guys give me the creative freedom to do this stuff, I'll do it for free. And I also treated the project like a real client project where I did like a branding exercise. I've been built it on WordPress. Don't tell anyone. And you know, this allowed me to experiment and create something really cool. And it was a great process and you know, it was something to where like there wasn't the pressure of a client project. There wasn't, you know, there wasn't all of these deadlines that had to be met and bills that had to be paid. It just allowed me to experiment. And at the end I had a great portfolio piece. You know, and maybe some of you guys out there, maybe you know, if you have a family, you have kids and you don't have time to spend any time outside of work. I mean, I can't imagine any boss, if you go to them and say, hey, I've got this idea for a project, I want to put a little bit of extra time in at work and you pitch it to them the right way. I can't imagine anybody saying, no, you can't do that. So lastly, get your hands dirty with some new tools. Some of the things that have helped me kind of understand and wrap my head around responsive design and using code as a design tool. ZERB Foundation, which is completely responsive framework, they have awesome documentation and it's a great way to get started with creating responsive wireframes and prototypes. Even if you don't use foundation later on in your project, it's a great teaching tool. SAS, I mean, I can't imagine building any type of responsive design without it. Just the way that it handles all the various mix-ins for your media queries and things like that is just so much easier than doing it in straight CSS. Jekyll, as I mentioned earlier, is a static site generator. It does a lot of shit that's over my head, but in a nutshell, it allows you to create templates and reusable components with HTML, which is very, very useful. And then Sketch 3 is a new image editing app and creation app. And it's great for responsive design because it allows you to have multiple flexible canvases and you can output layers to CSS. And I'm actually most likely gonna be using that on the next responsive project I work on instead of Photoshop. So lastly, Frederick Douglass says, if there is no struggle, there is no progress. TLDR, responsive design is hard, but it's only going to get more awesome if we keep working at it. Ta-da! Please feel free to ask questions or heckle or go get a beer. Yes? What's it like working at Lullabot? It's pretty awesome. So you mentioned kind of their distributed? Yeah, a completely distributed company. The owners are based out of Jeff and Matt, who started the company, live in Rhode Island, but everybody else is across the country. Actually, I should probably talk in the mic, sorry. Everybody else is completely distributed across the country. We have a few Canadian Lullabots sitting behind you. We have somebody in Denmark, a few in the UK. So yeah, it's a pretty cool place. I would highly recommend applying if you're looking. Yes? Yes, definitely. So in a lot of experience that I've had, you have situations where, let's say, you need to, how do I phrase it? Presenting someone with a problem allows them to solve it in their own way that may actually be better than what your initial solution is. It allows the person that actually knows the most about it or has the most experience in it to do it in their own way and kind of have ownership of it. I think a lot of issues in responsive design like between design and development come from someone just being presented with, here's the solution of how we're going to do this thing. But the problem may actually be something completely different and you may not actually be solving that problem, you're just solving something. Yeah. I have a question about Lullabot being a completely distributed company. How do you guys do that? Do you meet up, talk every day in the morning because in Kansas City we're looking for more people and there's just not much great talent? We, the funny thing is that we actually communicate with each other more here than I've ever communicated with a physical company. We have an IRC chat room that everybody signs in when they're working. We have weekly calls Monday and Friday. We have project scrums that are typically daily and we use a lot of Google Hangouts. If you're working with clients that are not near you, Google Hangouts are awesome. Not only is it free, but it's close enough to being in person that you can really tell if there's any type of tension or what the mood's like and if everybody's happy or if everybody's not happy. Cool. Thanks. Yeah, no problem. Hi. I am an in-house marketer and novice designer. We're a very small company so I end up doing a lot of design work. And what you said about designers being professional learners was really interesting to me. I'm wondering if you have any recommendations for online resources for learning, best practices for web design or stuff like SAS. Because I know there's Code Academy and stuff, but there's less of the best practices style and stuff. So as, you can kind of break that down into design and design thinking and technical things like SAS. For the technical stuff, Code School is really awesome as is what's the treehouse. Those are kind of the two that are my favorite. Of course, I have to plug Drupalize Me if you wanna learn about Drupal. But as far as design fundamentals and design thinking, is doesn't really change depending on what medium, if it's interactive design, web design, print design. I'm not saying to approach a web design project like you would a print design project, but your fundamentals of design, you can pick up from going to like a Barnes & Noble and looking at their graphic design section and you may find that you're really inspired by the Bauhaus movement or something like that and you can take those concepts and apply that to a web design. Very cool, thank you. I was wondering if you had any experience or experimentation with things like reflow or mock flow, web flow? I have, and that's, it's just a little bit of experience, but I believe, is it Macau that's? Macau, yeah. Yeah, Macau, is that one that's, I know there's one that's like, I'm kind of waiting patiently for them to kind of bring out the final version of it, but yeah, like after spending, attempting a few times to like create, hand create HTML wireframes in the browser and basically having that kind of become a front end development process instead of a design process, like it kind of gets frustrating and so I'm really hoping to try messing around with something like that so like I can not focus on the code and focus on the design aspect. So I think there are definitely ones to watch. Reflow looks pretty good. I'm probably gonna mess around with that for the next project. Cool. Cool, well thank you very much.