 Good morning. How's everybody feeling today? Welcome to the second day of DribbleCon. Hope you enjoyed the party last night. This is user experience design for every screen. My name is Aaron Stannisch. I'm a co-founder and designer at Four Kitchens, web design development shop in Austin, Texas. Enjoy design, user experience, typography, and all of those passions have taken me now to responsive and mobile web design. And when I'm not creating websites, I like to ride road bikes and mountain bikes. So I'm not gonna cover much of the background of responsive design, because I feel like it's pretty much been beaten to death at this point. But what I'm gonna talk about today is kind of the changing process of how we've been building sites for the past decade and how that's changing now that we have to build one website that works on many screens. So for the past decade, we've been building, we've built comps like this that eventually turn into web pages like this, you know, fixed width or fluid width. Generally you're building one page template that is relatively uniform across all operating systems and browsers. But now as we venture into responsive design, we have to make it look good on tablets and phones, which changes the layout and even smaller and less capable phones. So we're creating one website with many layouts, different designs, changing content, et cetera. Trent Walton is a really awesome designer. He runs a company called Parabell and he wrote this article called Redefined and he said to design responsive websites effectively and responsibly, I had to completely redefine the way I view the web. And I thought that was a really powerful statement and really gets at the crux of this whole talk today. So, you know, we know the basic process of the past decade, collect requirements or start doing some planning, start building your design artifacts, site maps, workflows, wireframes. Those eventually get turned into comps which go through iterations with the client and eventually finish the design, build, style the website, release it. This way is changing. So, still have the requirements planning phase. I didn't mention strategy in the last slide, but you know, obviously it's there, but I mentioned it here because I think it's even more important and you haven't read Luke, I'm gonna butcher his name, Roblowski. Mobile first, it's really awesome and we're really lucky to have him being our keynote speaker tomorrow morning. But this is all about really getting your clients really focus and think about the content on the strategy and really focus on what kind of experience they wanna provide to their users across the different, you know, context and devices that they're using. I think there's also a big shift to using design systems rather than relying on comps. You know, now that we're designing for multiple different viewports, we can't just spend all this time creating, you know, a different comp for every different page for a different device, you know, it doesn't make any sense anymore. So, I'm gonna talk about some of the ways we can kind of save some time and, you know, use your client's time and your team's time more effectively by leveraging some of these design systems. Prototyping, if you're already doing prototyping, building your FixWiz websites, that's awesome. I think it's gonna be absolutely necessary as we move towards this and you can really use, leverage those design systems against your prototypes to kind of rapidly create these kind of interactive experiences that you can show to your clients and actually make your team work more efficiently as well. From there, you know, the process is a little less straightforward than just taking the comp and turning into design. It's more like design, build, iterate, build, design, iterate, et cetera, until you finally get a working product that you're happy with and then you launch it. So what's really changed between these two processes? We really don't have the idea of a page anymore. You know, before we would create the single kind of page template that would work across browsers, but we don't really have that anymore. The layout, the templates are not consistent across devices, so I don't even know how much longer we'll call them web pages, really. Comps are no longer golden. They should not be the gold standard from which, like, you must have the comp for every kind of iteration or different section of the site before you can move forward. I think they're gonna become less important for sure. That kind of goes along with elements are no longer static on the page. You've got images, media, text, navigation buttons, they're all changing, you know, to adapt to the different devices to provide better user experience. Prottyping's having much earlier in the process. You really kind of use it as a tool for your designers and developers to work together to kind of understand each other's vision as well as the client's vision, and it kind of helps the client get it sooner. Already mentioned, designers and developers work together. This whole process also requires a much higher level communication with your client. Even if they've kind of seen responsive websites and kind of seen them work on different devices, they may not kind of get it when it's their own product. It's one thing to see how it works for other websites, but once it's their own content, their own product, and it's changing and looking at all the different devices, they're gonna be very, very skeptical, and they're gonna think there's a lot of risk involved, so it just requires a lot higher touch with the client to make them confident. So what's the plan? I'm gonna throw out two buzzwords because I strongly feel that we should all follow them. One is future friendly, and the other is mobile first. So I think it was a couple of months ago, maybe a year ago, a group of designers and developers, sequestered themselves in the woods to really kind of think, well, what is this explosion of devices on the scene really mean? How is it gonna change the way we're gonna build websites? So they brought all these devices, piled them on the floor, used the internet, and kind of just had this really open, kind of camping experience, and this is what they came up with. It's kind of a manifesto. It's a really simple one page website. It doesn't get very technical or specific to any kind of technologies. It's just, it's what responsive design is really trying to do, and that's what you're trying to do is make your sites future friendly, you know? You already know some of the devices that are out there, and there's so many of them, but you don't know what's gonna be down a year or two years from now, and you're really trying to provide strategy and a website for your clients that's gonna be sustainable for the foreseeable future. Also I mentioned Luke wrote this book mobile first, and he wrote this article too. You see the timestamp, November 3rd, 2009, and the book just came out last year, so obviously there's been a lot of, you know, he's been working on this for a long time, been thinking about it. It's part of the Book Apart series. If I would recommend buying all their books, they're very short, kind of concise, easy to read, and they capture a lot of the important, you know, web trends that are really important right now. But in his book, he kind of focuses on these three things. Growth, obviously they're trying to adapt to this explosion of devices that creates opportunity because now people are using your website in many, many different context places, things like that. They're also places of constraints. We've known what websites can do, what browsers can do for a long time, but phones, they have much smaller screens, they have different ways you interact with them, and that really makes, when people are using their phones they might have less attention span, and that really makes you forced to focus on the kind of user experience and concept that you're delivering to your users. But these devices, though they may be small, they're also quite capable. They have GPS, they have cameras, they have touch screens, so we should really, you know, kind of leverage that innovation and really use their potential. So this is a quote by Bill. He was kind of trying to change the face of what people think of as a bank, with this product bank, simple. And they were creating a web app for iPhones, and androids, rather than starting with the desk, or rather than creating a responsive website. But I think this point is really key. So designing the mobile app first forced us to strip down to essentials. They built the app first. They had full plans to build a website, but really they wanted to focus on the app first, and that really kind of carried the focus of their product and the user experience that they wanted to have. And it really kind of made the user experience very simple and straightforward as it carried, you know, as expanded to tablets and onto the desktop. So I've been tossing around mobile first, but what really is important is the user first, and that's kind of synonymous with the content. You know, user first is content first, and that's what you should be focusing on, and then you should worry about your mobile strategy. So let's talk about content. Over the past couple of years I've since the iPhone come out, everyone's talking about the mobile web and what that really means. What I really wanted to find was a picture of a guy or a gal on a couch using just their cell phone, kicked back, you know, maybe while they're watching TV, because I think that kind of really, there's a wrench in the idea of what most clients think about their mobile users. They probably think, oh, they're at the grocery store or they're waiting in line for something. They're kind of just using it to pass the time, but really, you know, look at us at home. You know, if you're watching TV and you're on your phone that already dispels two myths. One, you've got a fast internet connection. Also, you're not just using it because you're bored. You're actually going to be spending some time on their website and kind of exploring the different content. So I don't think we can really consider, you know, mobile users, all that different from desktop users. So without going into it too much more, I would definitely suggest reading these two, this article on this slide show. They really get at the key and they throw out a lot of really great statistics about really dispelling this myth of the mobile user being radically different than a desktop user. Mark Bolton, he helped actually redesign Drupal.org and kind of re-ran Drupal. He's got all interesting thoughts about this, you know, extending this content-first idea and kind of turning our idea of how we build websites on its head. So before, you know, we think about the page, you know, kind of construct your template and start plugging in the content into that. You know, now as we have to kind of focus on the content, you know, being in the crux of the user experience, really using that first and then kind of designing, you know, the page or whatever you want to call it around that, you know, around the content. So there's a good article on this part a couple of days ago and they were really talking about how to make your content, you know, future friendly for this. So, you know, the first thing is, you know, one of the tenets of mobile-first design is like, you know, reduce the amount of stuff you're doing and really focus. You know, the first exercise you might do with your client is really what is, what are you putting on your site and why? Does it even really need to be there? If you're creating a certain type of, you know, slide show or video, does it actually need to be there? Is it providing any value? Second, make it modular. Luckily with Drupal, this comes quite naturally. You know, we have fields. So, you know, a blog post isn't just a blog post. It has a title, byline, lead image, maybe embedded images, slide shows, video. It links to the author. But really kind of separating this content out, which Drupal already does, will make it travel better in the future. Again, what's really important? So, you define what is the content? What does it consist of? Now, as it's changing across devices and tablets, what, you know, does the layer start to shift? What's really important? If things need to go away, is that going to be, is that going to matter to users? If something gets smaller, is that going to reduce the value? And also, how do we organize this stuff? Luckily, we work with a great content management system. And it has all kinds of ways to organize content. We have taxonomy. We have context. We have relationships. So, we have a really powerful tool to carry this content across all devices to kind of mold it and transform it to create the different experiences on all the different devices. So, now that we've structured our content, made it organized, made it modular, now it can travel. So, I'd be lying to you if I said that you will definitely get the content first from your client before you can start building this thing, right? But fortunately, we can kind of come up with some kind of tools that might help them. So, this came from 24 Ways, and the author came up with this idea of page tables. Where instead of, you know, really just like trying to get the actual content from them, just have them think of hierarchies. So, you know, here we have, you know, just give us the page title, give us the most important content, and then kind of just prioritize it from there. Give us secondary content, tertiary content, and then that way we can kind of just think about, you know, this idea of what's on the website as you're viewing across different devices, and you know, as we need to organize it and shift the layouts and stuff, we can really make sure that the most important stuff is always at the forefront. So, like I said, the page is dead, but content's not going anywhere anytime soon, so long live content. Let's talk about design. So workflows really relate to, you know, going back to the user and kind of defining your personas what you're really trying to get here is just creating the best user experience, period. I think wireframes are still a pretty valuable tool. We've been using them for a long time, especially as now, you know, we use grid systems and things like that. You know, the grids are flexible now. You're losing columns as you move from a tablet to a phone, and this really helps both, you know, design development and the client think about how's my content going to move around on the page and shift and prioritize, you know, as it flows when the screen gets smaller. Design systems will save you time and they will allow you to create patterns to make your, you know, design process more efficient, and I'll talk about those a little bit later. Protyping is really all about helping your team fail faster. We're tackling a lot of tougher problems now that, you know, content is shifting all across the page, elements are changing sizes, they're changing, you know, the literal format of the button or navigation element might change. It really helps them kind of think about these problems much quicker, and it also helps the client kind of get it sooner, you know, as they kind of see, can work with an interactive prototype. So, responsive design is really all about providing the best user experience. You know, it's not that this is fun or we really like doing it, but we're really just trying to make, you know, we've been lying to our clients who said, oh yeah, your desktop site is totally fine on the phone. I mean, phones are pretty capable about, you know, pinching and zooming and zooming on the content, and they might say, you know, oh, my site works fine, why do I care about this? But let's be honest, it really does provide a better user experience if you can kind of focus on the content and provide the best experience for the user. And I'd be lying to say if it was, I mean, ideally you'd want it to be the same across all devices, but you can think of a few contexts like a restaurant, you know, you might want it to have, the desktop site to be very attractive and kind of create a moved and atmosphere of the restaurant, but on the phone, you really just want to get them at the map hours menu. Wireframes, like I said, wireframes are still necessary. I think they really help think about these hard problems and layout. I don't think it has to be a tool necessary. I think you'll find yourself doing a lot of like paper sketches and maybe whiteboarding with the client. It also helps everybody on the team make sense of this radical concept of the no more page idea. So we've got a very, we're very lucky to have Samantha Warren in our Drupal community. A while back she came with the idea of style tiles and I think just before South by Southwest, she spoke and relaunched an official website and it's very similar to the manifesto that I was talking about, the Future Friendly. It's called style tiles as you see there and it's really, if you're not familiar real quick, it's all about creating mood boards over comps. So you're really, rather than iterating and creating tons and tons and tons of comps, kind of creating different feelings and moods and colors and texture, using colors and textures and patterns, text, to kind of get at what kind of feeling they really want to have on their website. This directly leads you into being able to create a style guide behind your, extend your style tiles and create a style guide and then reuse a little pattern library. So you can create, you can't just design a button anymore. Like what does that button gonna look like on the desktop? It probably doesn't need to be very big, but on touch device, it needs to be big enough so that they're not gonna be accidentally clicking other elements in the page. A comp is probably still necessary, but not for every page at every viewport. We recently relaunched ican.org and we, following this process of using style guides, our style tiles, then the style guide, we were able to create three comps, one for the three different viewports and after already iterating through maybe 10 or 15 of these style tiles, we were able to just nail the comp the first time the client saw it and they said yes, that's it, go start building it. So that was really, really amazing to us and that was the first project we used style tiles on and it will absolutely be part of our process going forward. All of this is to get to the goal of getting the designs to the browser quickly. Like I said, this is really where the magic is gonna happen, both for the design team and the client. You know, even with traditional websites, if you're trying to, you can kind of create your wireframes and your comps, but I think we all know how much the client can just get caught up in the details of a comp, they're like oh well why is that here and most of the comp, you don't have the contents you just had to put for placement only content and that gets them all confused. So if that had them confused in a static wireframe or comp or even if you had some kind of interactive prototype, the changing of contents sorry. And a responsive design is vastly different than what we've been doing before and I think this is really where a lot of discovery is gonna happen. It also allows for richer conversations between the designers and the developers. You know, before it was kind of easy for a developer to kind of look at a design, well actually it's not that easy. I work with a lot of developers that, you know, they're great, great coders but you know, not very design savvy which is totally fine. That's why we have designers and developers but it's really exciting to see this new kind of relationship form between them where you're creating a living website that the developers are trying to ask different questions about content flow and stuff like that and the designer really has to kind of understand where the developer's coming from and how to build this stuff and the challenges that they face. Like I said, I think all of this kind of leads towards the client just kind of getting it sooner. And as mentioned, fail fast, succeed fast. I think you'll find a lot of similarities between the process of creating a responsive website similar to your agile processes for project management if you use that. It's all about iteration, showing the client, making changes and that's gonna happen with the client and I think it's gonna happen internally with your design team as well. Let's talk about best practices. So when I use the word best practices, I don't mean definitely do it this way, always do it this way, this is the convention. What we're really trying to get at with best practices for any device that you're on is really just trying to create the best experience. Brad Frost came up with this great website called Mobile Web Best Practices and he's trying to create kind of a catalog of all these different ideas and kind of conventions that we've kind of sort of established in a way to provide the best user experience for our users and he kind of splits it up into these different areas. First of all at the crux of all this is understanding your users. How the user devices, why they use them, when they use them. Overlying tenant will also be content over navigation. When we're building desktop websites, the client really likes to get caught up in making sure that the navigation is perfectly organized and clear to the user so that they can find absolutely everything and creating these really complicated drop-down menus and stuff. Users on mobile devices are probably getting a link and just go into your website. They don't really care, I mean they may not care about exploring it but really they don't wanna see a big navigation thing. What they wanna see first is the content. Real estate is really kind of scarce on these mobile devices so really getting at the content versus key. I mentioned that we try to keep these experiences uniform across the different devices as much as possible. So I think the problem that we've seen a lot with these m.websites and creating a mobile website for your desktop version really strays. They're like, oh well, we'll remove all the cruft. We'll have no design at all. It'll just be plain links and I don't think that's a really good solution. I don't think you should limit it. I mentioned earlier, there is no mobile web. There's no, this mobile context is kind of a myth so don't assume that they don't want everything and allow them to explore if they want to. And really the key point that I'm gonna keep going back to is just maintaining clarity and focus and that's gonna be really important. So what makes for a good experience? Make it readable. These are small screens. Make sure the text is adequate size. Make it relevant. Make sure that when you're sending someone to a page this is all about the hierarchy of content, making sure that the things are most important from your product and to provide the most value are at the top of the page. Getting to the little bit specifics, unless your site is all about forms like an e-commerce site which is definitely becoming more popular, people are using their phones to buy things more and more every day, really keep forms to the minimum. Even if it has a physical keyboard or not typing is kind of a pain on a phone. So if you were constantly asking them to fill out forms and stuff, that's gonna provide a really poor user experience. Also avoid modal overlays. These are already annoying on desktop sites that are even more annoying on phones, like you just don't expect them at all and it's totally jarring. The last point kind of gets more into the development side of things but I think it's also something to keep in mind as you go apart. People want to do stuff, whether it's on a desktop or tablet or phone. They wanna do stuff and they wanna do it fast. So make it snappy. There's a lot of things you can do on the client side and the server side to kind of reduce the size of megabytes that you're sending to the user. But also, if you have a clean UI, that also provides a snappy experience. So they can get to the content quickly and kind of switch between, pivot between content quickly. That also provides for a snappy experience. So when we first, the iPhone came out, it was pretty much the first smartphone on the market that was widely accepted. Now we have hundreds and hundreds of Android devices. It might have been possible to design just for the iPhone back in the day but that's kind of impossible now for the devices. So really what you'll, the common trend you'll see in responsive design is really designing for the view ports and screens rather than the devices. So this kind of, the technical term for this is called break points. And that's basically just kind of finding these commonality kind of sizes for phones and tablets and having kind of adjusting the user experience based on those sizes. We've all familiar with fluid layouts. We've been doing that for a while as opposed to fixed. This is even more important. This applies not just to the page width. We also have scaling text, scaling media, scaling images. Just keep in mind that a lot of things need to be fluid. And if you can kind of, convince your client that this is fine, this is okay, things will change and be fluid. I think it'll be better for everybody. Another big shift in design thinking is thinking proportions, not pixels. For a long time, you know, the client wanted to see this pixel perfect kind of design and he really got down to Photoshop and thought about, you know, well this thing's gonna be this many pixels wide and this thing's gonna be this many pixels wide. You know, start thinking, throw that all out the window and start thinking about proportions. Luckily this kind of aligns with our content strategy and kind of thinking hierarchies. You know, if this thing is this important, you know, it should be this big. If this thing is smaller in importance, maybe it should be smaller in size or not appear at all. Also consider device orientation. So just because, you know, your users using their phone in portrait mode, you know, most common, if they need to type something, they're gonna switch it over to portrait mode and then what is the content gonna happen there? If you're on a tablet device, you know, they're widescreen devices. If you, you know, they're using a landscape, you know, orientation most of the time. If they switch it the other way around, you know, that's a drastic reduce in width and you know, what's gonna happen? So the Boston Globe was really exciting project a lot, I think launched last year and it kind of took the traditional model or newspapers kind of had a stodgy design and they are trying to kind of figure out how to stay alive in this digital era. And I think a lot of them were like, oh well the iPad's out, we'll just create an iPad app or create an iPhone app or an Android app and that's the way we'll go. And I was really excited to see that the Boston Globe said no, we're going to just create a mobile website available on every device. No one has to download anything. You have to pay, of course. But they kind of went nuts here. They created for six different viewports. And so this is only four of them and you can already see, this is just the header and you can already see how many different elements have had to change. The logo changes size, different elements related to the weather and the upper left hand corner change. They went from this horizontal kind of stacked layout and as they got further down they had to change it radically to vertically stacked. So you can imagine not only the kind of thinking process the designer had to go through but then also conveying this to the developers as well about okay, this is what I want and here's how it's going to change. And you can also see that navigation elements, that's really important for a newspaper, they're sections. As you get down to the smaller sizes you got to let them go. And you might defer to using, you probably have to defer to using a drop down menu. Luke W wrote an awesome blog post a couple of days ago where he really, he went on the site of media queries, mediaquery.es, which is a collection of hundreds and hundreds of responsive websites that have been built in the past year or so. And he went on there and he started just digging through all the different websites and he tried to find commonalities between them. I was like okay, you've got all these websites out here but all of them can't be just creating radically different layouts. So he started identifying some of the commonalities and patterns between them. So if you look at Trent Walton's website, it's very simple. It's a blog, it's two columns. This is what Luke would call mostly fluid. As you stretch or reduce the size of the screen the elements actually are totally fluid. You can see that the header totally gets smaller, the text size gets smaller, the column width gets smaller and then even as you get to a mobile phone you drop that left column and you just have a one column layout. Embedded images will be smaller, headlines will be smaller, things like that. He also identified what he called the layout shifter. This comes from FoodSense and he identified this as sites that shift the content around as you move to smaller screens or from a phone to a bigger screen but that for the most part the elements stay the same, same size. So the text relatively seems the same size and what's interesting here is actually when you think about moving from your desktop site to a mobile site you would want your images to get smaller to conform to the screen. What they've done here is they've actually taken the smaller images on the desktop website with a four column and then as they reduce it to a two and one column the images actually get bigger. So I thought that was kind of interesting. All right so let's go on a little tangent here. If you went on a website and saw this button or icon what would it mean? A list? Yeah, so Starbucks recently made their site responsive and they're using it for navigation. So you can see there's no other clue. On desktops you have across the header names of all the sections, they're clear as day, you click on it and you go there. Starbucks took a chance. They said they started to see this kind of pattern across other mobile websites of kind of using this thing that kind of resembles the drop down menu which is a pretty common convention. So they're like let's just use that and that will be the signal to users to click on that and then they'll expand the drop down. I've got a link down here to Andy Clark who and he has a nice blog post where he's like we need a common, we can't, if content is first and navigation comes later we really need to have a convention for letting users know that hey, this button, there's no navigation on the page, don't freak out, but hey if you click this thing that has three lines on it that's where the navigation is and then you can go nuts. So yeah, being used to that, content over navigation. Also I think you'll see, don't try to make your drop downs a work of art. We've had plenty of trouble designing them for desktop websites for many, many years. It only gets harder on mobile devices. If you've ever used a select list on an iPhone or an Android you can see that they actually handle it in their own way. The operating system actually takes over and doesn't really care how you've styled your select list. I would also say don't try to get too fancy with your drop downs either. Just make them simple and usable because while it may not be that sophisticated kind of feature on desktop site it definitely will be on phones and you'll be hard pressed to really kind of create a unified experience across them but why would you anyways? You just want people to get to the navigation. Getting to the little specifics, one of the conventions coming out is putting, if you're gonna have a fixed toolbar put it at the top rather than the bottom. The bottom is where the Chrome of the operating system and on Android it has its hardware buttons at the bottom. You don't want people accidentally clicking the operating system buttons or the hardware buttons when you want them to be clicking the toolbar on your site so put it at the top. This last point I mentioned a little bit about the toolbars. Also how many of you have seen a mobile website that has a back button in the upper left hand corner? This is a convention that I think they stole from a lot of iPhone applications that always have the back button primarily the upper left hand corner but do you really need it? Mobile Safari already has a back button right there at the bottom of the screen. Android has a hardware back button so maybe it's not necessary. Responsive images is probably the most interesting and difficult thing we have to think about right now. Fortunately it's kind of tied up in some very high level technical discussions with some very smart people and they're trying to get the W3C on board to come up with a standard to kind of solve this problem because arguably images are pretty important on websites and we'd like to carry them over into tablets and phones but it also makes you rethink about how they're gonna be scaling in your designs as you're moving to these different layouts. Another best practice would be simply reducing the number of images. It's all about focus. Images are large. We're getting faster cell phone connections with 4G and whatnot but not everyone has that so images are quite large still on the internet so simply reducing them can actually really get you with that snappy experience that we were talking about. Also if you're using huge images they're also trying to figure out a way to provide multiple different, rather than just scaling it, if you're scaling a large image on a phone you're still downloading the whole thing so until we figure out a way to provide, I mean there is a way to now but a really really good way to create multiple widths of your images and have them scale so you're only loading the image that you need for your device at that time. Real quick mobile text, I think it's pretty easy, make it readable. Also consider the flow of text. You know what was a nice long headline or sub headline on a desktop device might take up a lot of real estate when you get scrunched down on a phone. If you've ever been to a good experiment is going to the wired.com's website on your desktop and then looking at it on your phone they did a really smart thing where they're using one font face or typeface on their desktop site but then when you go to the mobile they actually use a very skinny and narrow font so it uses the real estate very wisely so I thought that was a smart move. Also font hosting services, I'm a big fan of typography and I love these font hosting services that have come out. They've allowed us to get all these fonts that weren't previously available but there may be a little bit of a performance issue with them so if you need to use a font hosting service on your mobile device definitely test the performance and make sure that it's not gonna be slowing down your users. Suggestures, this is a really unique thing that we can take advantage of even on the web today. Mobile apps have been taking advantage of them from day one as a very unique and they're exploring very creative ways to use them. If you kind of think about how you create it went from like links on websites to buttons it's kind of a hack. We basically just made it larger and made it take up more space so that it was easier to visually see and find. On mobile devices we wanted this also to be adequate size but really we're just using the same old conventions and carrying them over. Now science fictions have been talking about using mobile as the future of interface design for a long time but now it's here. So let's use the gestures in the way we can on the web but make them obvious. There's no such thing as hover or anything on a website and you're limited in screen real estate so I think a lot of designers are having this problem with how do I make my gestures obvious? Some of the conventions we have obviously tapping something is very simple. You seem swiping like if you have an image gallery you can kind of swipe left and right. That's way better than clicking the right button to advance to the next one. On the desktop that's all you have but on the phone what's more natural? Like actually swiping it or just pushing a button. I think the answer is obvious. JustColork has a really good presentation and he wrote a good book called Tapworthy and he says don't make your users read a manual. I think a lot of magazine apps have made this mistake because they try to do these really radical kind of interface designs on the iPad and stuff like that but you have to read a full page manual or two page manual before you even get to use the thing and you're already bored by that time and it's like no I just want to use it. So I think we're really trying to figure out how to come up with conventions to make the user interface natural without making people read a whole booklet beforehand. So I think one way we can get away with this is using visual cues and coach marks. Anytime Facebook or Google or somebody like that redesigns their websites and things have moved around and the interaction is different. What do they do? Do they make you read a whole page that explains what happened or video? No, they just use little pop-ups that are attached to little items in the corners. They call these coach marks and it's like hey, check out this thing. If you don't care about it, it's easy. Boom, you just click a button and it's gone. So like I said, there's a need to come up with these universal conventions. We've got a few of them. I think we'll start to see more. I think we've already seen stuff like pulling down to refresh and things like that or pinching and zooming obviously if you're looking at a map or you want to zoom on an image. They aren't quite as capable as apps but I think as HTML and HTML5 progress, we will get there. But we'll have to be considerate of competing operating system and browser gestures. The iPhone already has the pull down for your notification center. If you're pulling down to refresh, you could get stuck and accidentally look at notifications and all you wanted to do was refresh. Also, all devices are not touched yet so definitely provide alternatives to gestures and don't make that the only way and don't assume they have touch capability. You should really embrace the physicality of touch. We're all humans. We have a really unique opportunity here going from just pointing and clicking in browsers to actually touching the object and actually kind of using these natural gestures, interface design with our hands and it's actually kind of puts the user closer with your web experience. As a general rule of thumb, I think if you've ever, someone had a really eye-opening thing where they took apart and looked at all of the iPhones, iOS patterns and design patterns across the whole operating system and you'll kind of see this pattern where everything's roughly 40 pixels. Now I know I said, you know, things in proportions not pixels and definitely as we have retina displays, a pixel on one device is not a pixel on another device but I think this 40 pixels thing came from the original iPhone for 40 pixels so however you do the math to extend it to other devices that's generally how you wanna size your touch elements. And as I mentioned, not every device has touch capability yet so definitely think about them. All right, let's think about tools. So like I said, I don't think that software is necessarily the answer. I think as we're starting to think about, I mean, hopefully I hope a lot of you are already digging into pen and paper and kind of using that to kind of sketch out your ideas before you immediately jump into the software. If you're comfortable all the other way around that's totally fine. If you've read the responsive books, they talk about the three tenants of responsive design, fluid grids, responsive media and media queries and so we'll talk about how you can use these tools from a design and UX perspective. Grids, so we're all familiar with, we've been using grid systems for a long time and we know they're good. But what happens now as the, you're using, instead of using a 960 grid where each column is 60 pixels wide and your gutters maybe 20 pixels wide, they think about percentages and proportions and even how you lose entire columns as you start to fold it in smaller devices. So these are a few of, if you're just gonna start doing some prototyping and things like that, there's just some starting places that kind of try to tackle the problem of the fluid grid. This last one, Grids set app is actually coming from Mark Bolton and it hasn't launched yet but what I've seen him write about it seems really, really interesting. He's really trying to combine all of the tools and thinking that goes into creating a grid system and then providing an online tool for it. Wireframing and prototyping, I wouldn't know what to tell you to use. Everybody's different. I think whiteboarding is a really good idea. I think especially if you're having an in-person meeting with your client and you're starting to sketch out ideas, allow, giving them the marker, giving other people on their team the marker to kind of draw these things. They all use phones and they all use these devices. They might actually have some ideas and have some value. You can use Balsamic for wireframing in design. I thought it was an interesting one. That's what the Boston Globe used. Obviously they come from a print design background but has anyone in this room ever used InDesign to wirefram? Okay, a few, awesome. Yeah, the case they made for that, I thought it was actually kind of interesting. It made a little bit more sense. They've said Photoshop is great for images but it sucks at text and Illustrator is awesome for text but it sucks at images. InDesign does both really well and it has done for print medium for a long time. It also has the advantage over Photoshop and Illustrator that you can kind of create these reusable patterns and templates. I was very weary when I first started reading this blog post by Upstatement, the guys who designed the Boston Globe but their reasoning for using InDesign actually made a lot of sense. Actually, I haven't used it personally but I hear a lot of people use it. I was trying to do some research and find out whether they had any kind of responsive templates or tools to use in Aksher and it looked like there was still a forum thread and they were still trying to figure out. I don't think the tools have really changed all that much but I think just getting your ideas from the wireframe into prototyping is very, very important. Here we have responsive media and so I talked about images earlier and that's really, really important but we also have other things to consider as they need to shrink on these smaller devices. Slideshows are one. Videos and text. So I've got two links here, FitBidJS and FitTextJS. These both come from a company I mentioned earlier, Paraville. I really like them not just because they're in Austin but they're really smart guys and they've been doing some really cool stuff and really trying to solve some of these problems that have come up from switching from digital design to responsive design. So check out those tools. Videos basically will take any embedded video and make sure that it scales proportionally to the device and then FitText allows, I was mentioning earlier about wired how to do kind of a hack to make their text. They opted to switch the font out to make it fit on mobile device. FitTextJS, these guys are really, really good designers and everything they make is beautiful so they wanted their headlines to look really beautiful so they are actually trying to figure ways that instead of just switching the font actually making the headline use as much space or as little space as necessary as it adapts to different layouts. If you want to start diving into, your developers will definitely need to do this. If you need to dive into some of the problems around responsive images. The top link is the W3 and they actually created a working group to start to solve this problem. So there's a lot of, I think that's probably where the solution will come from but then you've got some other guys that have some really interesting ideas. And this last point comes from Mark Bolton. You know, one thing I think we've kind of ignoring talking about these things that need to kind of adapt and respond as we change sizes is advertising. And so the Boston Globe kind of had to figure it out obviously so I'd read about what they did and then Mark's got some interesting ideas on how we might have to let go of these notions of like fixed, you know, MPU ad sizes and things like that. So I told you this would not be a technical presentation but anybody that's involved in a responsive design project is gonna hear media queries come up at some point. This basically just our way to deal with these viewports or device widths that we need to do to adapt our layout as we move across the devices. This is what it looks like in code. Basically has two elements to it. One, you're just asking it, what kind of media type am I looking at? You know, one of these devices that I wanna look at. Then you query for the media feature. The most common thing is width because that's the easiest thing to kind of learn about a phone or device. But also you can query things about height if that's important to you. Orientation, so you can actually ask it, is this device turned, is it in portrait mode or is it landscape mode? And then you can also tackle issues of pixel density so that you can make sure that, you know, just because the device has more pixels it doesn't make, just because it has higher pixel density it doesn't make things smaller. It'll actually make it kind of consistent across, you know, whether it's an iPad one or two or three. So prototyping, I said, we need to get it to really quick. I didn't mention any, there's a few Drupal sub themes and things like that that help you get up and started with frameworks. But if you wanna take a step back from that or even to just do some raw HTML prototyping, just, you know, if you don't wanna mess with Drupal and just get it done kind of quickly to kind of sketch out some ideas. Here are a few things. Twitter actually made one called Bootstrap that is really, really popular right now. So it's cool to see them kind of giving back. So yeah, you might actually, you know, whether you use these for, you know, you're just your own rough prototyping things, you might actually find that some of the techniques used for them might actually make sense to adapt them into a Drupal theme. There's also some touch frameworks. So jQuery, you know, is widely popular for creating interaction designs on websites. So they actually have a whole subset of library tools called jQuery Mobile. And this allows you to, you know, one thing it could really do is you could create something that looks like an iPhone app inside a browser. You know, so they've already got the conventions, all the buttons, make them highly themeable. They've already built out your, you know, navigation system stuff that you don't have to rebuild all that stuff in scratch if you wanna go that direction. Censha is going, I was talking earlier about, you know, iPhone and Android apps are really capable touch devices and their apps are extremely capable of taking advantage of these gestures. So what Censha is trying to do is they're really trying to bridge the gap from what mobile apps can do to what the web can do. So they've got some libraries and so they're doing some really cool stuff to kind of bring some of these advanced gestures to the mobile web testing. So this is probably, this is another big change and you may or may not think it's fun, but it's absolutely important. And especially when you have this to deal with, depending on your client's requirements, you know, if they're a global company and they have a lot of people in developing nations that don't have super awesome smartphones with fast connections, you know, you might have to build for, you might have to think about all the different devices you have to build for. So I would actually suggest if you have the means actually buy some real devices. You can get some second or third generation Android phones pretty cheap now. For the other things, some of you wanna try to test on some of the latest and greatest devices, you're just going to have to shell it. And I think it's just a cost that we're gonna have to come to bear. You know, if this is something that you really, really wanna do and you wanna build sites for clients that demand this kind of thing. I know we recently had to, you know, buy a bunch of different things and we actually brought them up our table. So if you have any devices that, or if you have any websites or projects that you're working on, but you haven't been able to test it on a Kindle Fire yet, or iPad 2 or, you know, Galaxy Tab or something like that, we've got a bunch of them on our booth if you wanna go try them out. This is a really cool tool. So this is me at my desk running Adobe Shadow. It's really cool to see Adobe kind of move from, you know, making all these tools for print and then, you know, trying to take the web by storm with Flash and now they've even admitted, you know, Flash is dead. So now they're like, okay, well, we still have all these employees so we gotta have them work on something. So like, it's clear that, you know, these open, you know, HTML, CSS, that's the future. So they're really kind of, it's really cool to see them kind of form this like web team to really think about some of the, you know, hard problems and, you know, innovative ideas and what they can do just on standard technology that's kind of open to the public. So they created this program, Adobe Shadow. You run it on your computer, it kind of runs in the background. Then you go into like Firefox or Chrome and install an extension. Once you do that, you go on your devices, tablets, phones, install the Adobe Shadow app. This is all free. You, on your browser, you click the button in the extension. It'll start to, you know, make sure all your devices are on the same wifi network. It'll detect them and you click on and then like magic, it just appears in all the devices. So if you've already been doing some mobile testing and you've already felt the pains of like, okay, here I'm on my iPhone, I gotta go to this URL and I gotta go to my tablet, I gotta go to this URL. You just control it from one place and you, as you navigate across web pages, it automatically refreshes fairly quickly on all these devices and even you can actually change the experience. So like if you have the web page on a certain spot on your desktop, you actually go on the tablet and it's pulled up that page and you can scroll freely through it. So, and it won't affect the other devices. So it's a really interesting product. And I think if you don't have the means to have these, you know, all these different devices, if you're not already using browser stack for just regular web development, it's really, really cool. It allows you to emulate any number of browsers, both in Windows and Mac. It basically runs a virtual machine inside your browser. So you don't have to have three different browsers or three different VMs on your computer to test every version of Internet Explorer. Now what's more exciting is in the past couple of weeks, they've added mobile VMs. So here I am loading up the fork engine's website on a Google Nexus One, all virtual. So, and you can kind of just play with it and navigate around like we just do a regular phone. You don't really get the same fidelity, obviously, if you had the actual device, but you know, if you need to just kind of get a general sense like things are terribly broken or not, that's a good solution. That's fairly cheap subscription. Opera, though their browser's kind of been forgotten. They still have, they still make really good products and they're still, whatever, I don't know how they're surviving, but they're doing it. And they've actually come up with a really good process, really good product, which is just an application you run on your computer and it does a really good job of emulating the Opera mobile inside of multitude of devices. Blazio has this thing called Mobitest, which is good for testing performance. You type in your URL, you type in what kind of device you want to test it on. You can actually tell it what region. So here I went to, I wanted to test Microsoft.com on an iPhone using iOS 5.0 and having it come out of Canada. So here it says average load time, average page size, and even kind of like everybody is running these tests. So they collect all that data and then they can kind of compare it to the other devices and other tests that people have run to show where you see. So it looks like Microsoft's doing a pretty good job faster than 60% saved websites. Another kind of quick and dirty tool, obviously we've done the whole thing where you stretch the browser to kind of show how content shifts, kind of emulate as you're narrowing the viewport. There's some quick and dirty stuff. This guy Matt came with this website where you basically type in a URL and then inside the browser it'll just automatically pull up an iframe with each of the different widths. So concurrently you can see how it looks. Your one website looks at all different viewports all at the same time. So to kind of sum up things, users first equals content first. Definitely put them at the forefront, make sure the experience is fast and responsive. Then you can kind of think about how you can adjust it to the mobile experience and focus it from there. Focus creates clarity and usability. I think if you really focus on mobile first and make it look at a phone you'll see a lot of benefits that like, hey maybe my desktop, just because it has all the screen it'll say it doesn't mean it has to be cluttered full of junk. Maybe I can provide the same clean experience I have for my mobile users. Use design systems that'll save you time and money. Get to prototyping quickly. Much, much more beneficial for the team and the client. Really think about and watch how your design and developer team kind of comes together and starts working closely together. I think that's really exciting. And always iterate with the client early and often. This is really radical kind of technology to some people and getting them to buy in on things sooner than later will be really valuable. So I think this pretty much sums it up what Luke said. If you start to hear customers asking for your desktop web experience to be more like the simple, easy to use mobile one, you're doing it right. So I'm not sure how we're doing on time. One thing I've come up with this conference I was in a bof yesterday and this is a big question that came up. So if you want, we've got five minutes. I can either take questions or I can kind of share some of these ideas about how to sell responsive to the client. What do you guys think? Zelling? All right. Do your clients need a responsive website? No. Sounds shocking, but it's the truth. Your clients users don't care whether a site is responsive or not. The users do need to get stuff done and they need to do it fast. So I think I had a link back here, this Cloud 4 blog. He said, instead of trying to totally redesign your website and start from scratch and make it mobile or try to take your existing theme and kind of adapt it and make it responsive, the most valuable thing you can do is just make it fast. Like you can just increase the performance on the device or on the website as it stands today, that's gonna provide a lot of value. Like I said, phones already do a pretty good job of pinching and zooming and adapting to content. So they don't care if it looks nice and the focus is nice, if it takes like 20 seconds to load. If that same desktop site can load on the phone and it can load in a matter of seconds, then that's what they want. I think if you just ask them, their behaviors, their family behaviors, their friends' behaviors, how they use devices, the desktop-only era is over. I mean, you can sit at home and see how your family uses all the devices at all times and they're all different. It just doesn't make any sense. So if you can kind of convince them, make them think about that, I think that's kind of really, really obvious and powerful. Another thing to consider is the power of the URL. They're like, well, I don't know, I really wanna create this app. Think how ubiquitous the URL is. Someone said links open websites but they don't open apps. Not every phone has your app, but every phone has a browser. So whether they're opening an email, they're opening a link from social media or whatever, that will immediately open in their browser. But if it's like, oh, if you want to view our mobile site, go download their app and maybe cost money, they have to go download it, it's just a pain. So why not just provide the best experience possible to all of your users and all of your devices? Thank you. Yeah, so I'll put them on the For Kitchens blog and I realized I used the full URLs for everything, so I'll either go back and write a blog post that just lists all the URLs or I might go back and create URL shortness, but yeah, that'll definitely be online.