 All right, I think we're going to go ahead and get started. Good afternoon. Welcome to a responsive process. Basically, I talk to sharing what I've learned on my own and with my company, working on responsive web design projects and how that affects all the different parts of our process, not just design and front end, but basically reaches out across all areas. And that's what I wanted to share today. A little bit about me. My name is Dave. I'm a web designer at Phase 2 Technology, a web design and development firm located just outside of DC. When I'm not designing, I have a few other passions as well. One is coffee, not just for the caffeine benefits, but the art of pulling a great shot of espresso. Also, the subtleties that come with various different roasts. And we have a lot of great coffee houses around DC too, which I enjoy visiting with my wife. I'm a huge sports fan, mainly football, soccer, and basketball, which March is a great time for. I enjoy playing and watching just about any sport. It's a great way to relax and also exercise. And then technology. I'm very passionate about technology and love how I've just been able to see it change people's lives growing up in different areas. Can you go through the mic, please? Sure. Sorry about that. So I love technology. And I think that's kind of what led me into the profession I'm in today, designing primarily on the web, but also different mediums as well with the advance of the personal computer, desktop publishing, and things like that. So a responsive process. Why another talk on responsive design? I know we've had a few that have touched on this already here at Drupalcon. And it seems like there's a new article being published every day. Someone's blogging about a new technique they're using, whether it be Ethan Marcott's great book on the subject, which I would definitely recommend reading if you haven't already. Or the various people are just publishing new thoughts on it every day. I feel like there's a lot of information out there and a lot of good resources on techniques and how to implement things, but there's not really a lot of info on how it affects the rest of our process. Design and development are very important. Myself as a designer, definitely recognize that. But responsive web design affects a lot of different things. It affects timelines or projects. It impacts the type of content we write, how we write that content. How does responsive affect the deliverables that we produce and what we show to clients? All these different areas that I'm going to touch on today and just relate what we've learned working on different projects. Why is mobile such a big thing? Why are we doing responsive? If you went to the keynote this morning, you saw even more statistics in this on how important mobile is, how quickly it's growing, how many people are using and accessing your websites and your client's websites, just using a mobile device, not necessarily the desktop PC they have at work or at home. And this is only going to continue to grow. So we need to be prepared for this. It's a really fun technique to design for and plan for, but it's also beneficial for our clients as well. A lot of you are even taking notes today on devices that didn't even exist two years ago. Things like smartphones and tablets that weren't even on the market yet, and yet we're using them today as our primary device or a secondary device. And this is only going to keep growing and spreading. Mobile devices are going to overtake PC devices in the next few years as the most popular way to access the web. And responsive design prepares us for this growth market. And it's beneficial to our clients because we're setting them up to be prepared for the future as well. But when we get down to it, it's not just about these devices, it's about the people behind them. It's not about the glowing rectangles, it's the people looking at them or into them or touching them or interacting with them, or also our desktop users as well. Not just small screens, but larger screens. Behind all of these, there's actual people using these devices, and that's really who we should be designing for. Charles Eames says that the role of the designer is that of a very good, thoughtful host, all of whose energy goes into trying to anticipate the needs of his guests. They're not spoken specifically towards responsive design. I think this captures pretty well the opportunity we have as creators and builders on the web to serve our audience in an impactful way that takes their needs into account. I think if you were having someone over for dinner who grew up in a different culture, who has different dietary needs, if you're a good host, you're going to recognize that and plan for that. And when they come over, you're going to serve them according to their needs. That's kind of what we're doing with responsive. How our users interact with our sites, the context that they're in when they're viewing our projects, our client sites, this is all things we need to keep in mind and not just worry about what breakpoints we're going to use or what devices we're going to cater to. Remember that there's people behind these devices. This actually helps our users, responsive web design does. It's not just for the approval of our peers. So when we launch a site that is responsive, they can go and resize their browser in ooh and ah, and they can send us a congratulatory tweet. I mean, it's always nice to get good feedback, but if we're just doing it because it's the new cool thing to do, I think we're taking the wrong approach and we're missing a really good opportunity as well. So being a good host to the guests of your design, to your site, to your client's project. What does our process look like, or the traditional process look like? Usually it goes something like this, depending on the size of your company or the people you have. Gathering requirements, doing some type of IA, planning, getting the client to agree to that. Then moving on to UX and wireframing, get them to sign off on that. Then move on to design, usually producing comps in Photoshop, giving the clients JPEGs of that to view so they can sign off on those. Then move into site development, and hopefully eventually launch the site. It's pretty linear, pretty waterfall. And responsive design, as we found out, changes a lot of that. Most importantly, we found it's not just an option. You can tack on at any point of the project. It's not just a checkbox that you have the client check on a work agreement. Because it does affect this entire process. It's not just one thing you can add on and hope it works out OK using the same process that you've always gone through. So where does this all start? Well, it really starts with the client, your initial meeting with them. Relay the expectations, relay the deliverables that you'll be giving them. And we'll obviously go through those in the talk today. But it's very important that you communicate with your client, no matter what their knowledge base is in terms of design or responsive itself. We work with a lot of publishing clients. And because of the success of the Boston Globe and the great work done there by multiple teams, other publishing clients have taken notice of that. And they come to us asking for responsive design. But they're not always aware of everything that goes into it. They think responsive is just about three breakpoints sometimes. You just need a little more CSS. And then everything else is going to work out OK. That's not actually the case if you've ever done any type of responsive work. You know that. Responsive can affect timelines, deliverables. And if you're going to be working in this new way, it's important to communicate to the client up front what these are, especially if they've already been through a traditional process. So they know what's different, what's changing, what they can expect. So they're not surprised by a prototype that they get. And they were expecting a full-fledged design comp at a certain stage. So relate these things to your clients up front. Hugely important. Then knowledge sharing within your team, a mind meld of sorts. It's very important to educate internally as well. If you keep your responsive design knowledge enclosed in your design team or your front-end team, and no one else in the company knows what's going on, you're going to come into some angst when someone sells a client project and then you get into the middle of it. And then you figure out there's not enough time to do what's necessary to produce an effective responsive site. Or when you get into development, the developers are suddenly surprised by what the site needs to do, what it needs to respond to. So educate your team internally. Make sure everyone is on board. Make sure they're at the kickoff, too, so that each department can offer feedback and suggestions when it comes to considering the constraints that come with responsive design. You can do this a few ways. We do, at Phase 2, we do lunch and learns every week where we all grab lunch and we have someone internally just talk about what they're learning or something new they discovered on the web that week or share something about a client project that was difficult, a great way to knowledge share, also a training budget for your employees to send them to conferences like this or just a smaller workshops that are more specifically geared to responsive and give opportunities for each of your employees to go and discover this methodology of design so that they know how to prepare for it in their piece of the project. The biggest way the process has changed, I think, is a shift in understanding of how the typical project process works and that it's not a relay race, it's not where one department focuses on their deliverable, they get it ready to go to the client, the client approves it, then they hand it off, you know, if I was a designer I would get the design comps approved, hand off to the developers and then I wouldn't have to worry about the project the rest of the time until it launched. Not a really good way to work in any project process, but especially in responsive design, it's crucial and you'll find that you'll do a lot of cross-pollination between disciplines and we'll get into a few examples of that. One way to start this off the bat again is to have everyone at the kickoff to offer their perspectives, you can hold page review sessions in the project once you get to designing pages or flows, have the whole team gather around these and give their feedback based on their expertise and then not just a one off on a deliverable, it's very iterative, I find in responsive where you're designing, then you're critiquing, then you're kind of rinsing and repeat over and over until you arrive at something final that's workable and usable across the different break points and that's really going to be useful for your client. So let's jump into the process. Now we start with content, content is king as the familiar phrase goes and that's really what drives our designs. If you're not designing around your content, your client is just as well off going to buy a template for $100 off a theme shop and putting all their content into there. Content helps frame our design decisions, it helps us produce better design decisions and that's really the message that we're trying to get across. It's not trying to make the web page look fancy, which I think most of us designers understand it's about getting that message across in a way that can reach the users, those people behind the screen. So in content this is kind of where we start to see a cross poll nation. When you're designing responsive it's not, I don't think it's really feasible to ask for all your content upfront, which I've been guilty of doing in the past myself as a designer, kind of demanding that the client or the content strategist on your team that kind of gather every piece of content, lock it in so that we know exactly what we're designing for and then once that happens we can finally move on into the project and start designing stuff. Mark Bolton wrote a great article a few months ago on kind of the battle between this and it's really a content and design together in the process and not one before the other. And so as your content person, your publisher or your content strategist within your team or working with the client, we found it's useful to work with your UX person who's whoever is doing the wireframes so that they can kind of work together, establish hierarchy, kind of rough out even on just sketching how the page is going to work across different breakpoints. So even right now at a very low fidelity point in the project you're working through how things can respond even though you're not really presenting that to the client yet. You're just setting yourself up for being most efficient throughout the process, things like how the content will affect the grid that you choose and how it affects different breakpoints where your content breaks at a certain resolution and then forming your breakpoint from that. So the most bare bones part of content is the written word, right, our copy. So how do we craft our words responsibly? Flow is a very key concept here and I think this is a great point to start with mobile first. I'm not really going to get into the details as Luke gave a great keynote this morning. But even starting mobile first on your content, it helps you focus on the essentials. So starting with the smallest screen even when you're writing and thinking of those constraints that you have with smaller screen sizes and then building up from there. It's not just beneficial for us as a project team to be constrained by those, but it obviously also benefits the client as it prepares them for growth. We've seen the statistics on how fast mobile is growing, how it's continuing to grow. I mean, who knows what kind of devices there will be two to five years from now. And so if you're focusing on this experience first for this highly for this rapidly growing market, that's only going to serve that awesome experience to more people down the road as more and more continue to buy devices like smartphones and tablets. So starting small kind of prepares you for that growth and it benefits the client in that way as well. And you can even use that as a selling point with them when starting mobile first or using responsive in general. A few practical ways. Keep flow in mind when you're writing your content. Don't assume an input method or a page structure when you're writing your content. This is an example from the Minneapolis St. Paul Business Journal, just an article I was reading one day. If you can't see highlighted, they say click to the right to view this gallery. Well, you can imagine on a smaller device as that shrinks, that gallery may not be to the right anymore. It may be underneath or further down the page or maybe these instructions won't even be there. Who knows? So keeping in mind content placement, but also input method. Avoid using terms like click. If you don't know what device they're going to be using, they may be using their finger and using the input of touch, for instance. So things like, you know, check out links in the sidebar for more information, which is which is pretty common. When you shrink to a different breakpoint, those links are going to shift under and your user is going to be wondering where where that content go. I don't even see a sidebar. You say these are important links, but I can't really find them. That kind of leads into a different point. Use caution when hiding content from users, especially on smaller screen devices. I think this is a trap a lot of people fell into when responsive design first started getting going. And they wanted to build their own site. They would especially even when starting from a desktop, an existing desktop site and just creating smaller media query style sheets for mobile devices, they would just hide a bunch of content. So everything would kind of flow nicely when you got onto the phone experience, the tablet experience. But a lot of times that content of stuff users actually want to use. I think it's very dangerous to assume context on these devices as well. Luke shared a couple of great examples this morning again how people are using phones not just on the go. They're using a lot of people are using them in their homes while they're watching TV or even when they have long periods of time to do things if they're out and about like sitting in line at the DMV. For instance, they have time to accomplish these tasks that we present and allow in our full desktop site. But a lot of times people hide these and minimize these. And I think it's very dangerous to do because you'll just leave your users end up being frustrated. It can also confuse them if they're coming into your site from a Google search because if Google is indexing all this content you have on your desktop experience or your high res experience. So to say, and then they come to it on a mobile device and that content is hidden. They're going to be really confused again about, well, Google says this content is on this page, but I can't find it anywhere. What's going on? And hiding content doesn't remove page load. I mean, it's it's all getting loaded in any way. So it's not like you're saving your user speed or anything like that. One example I came across just in the past few weeks is ESPN.com. It's March Madness. I created a bracket and this is an example of punishing your users because they're on they're viewing your site on the quote unquote wrong device. We already talked about how users want this full experience even on small devices. And so when I go to this on a desktop site or even on my iPad and use the desktop version of presented with this typical bracket layout that I'm accustomed to as someone who likes sports and enjoys March Madness, I can kind of see the tournament and what team is beating who and before it started I could click on teams or touch on teams and advance them to the next round. But by default when I'm on the iPad ESPN sends me to this page where it's totally different. There's a super confusing navigation to get to different regions of the bracket. They have that drop down, but I don't know what team is in the east or what team is in the Midwest. This list isn't really how a tournament or bracket is usually set up. So it's a much different experience trying to scan and read the content that I want to access. But if I'm on the tablet and I use the desktop version link that they provide, I can get back to this normal view. But why even separate that in the first place. So just make sure you're taking those considerations into account when crafting content. Now there may be times when you do need to hide content for whatever reason. Maybe really complex or long tasks that users might perform that because you know your users, they're probably not going to want to accomplish those when they're on a go when they don't have as much resolution to view things, maybe things like filling out a significantly long form, something like an application where they have to input a ton of data and copy and paste from different different places, something that can be cumbersome on a smaller device. So there are instances where that's possible. I would just advise you to be really careful. This is an example, a quick demo that a guy named Frankie Roberto did. Basically he's just adding a custom class to sections that he wants to hide. I think he called the class additional info and he's just hiding that on smaller breakpoints to remove content and you could use this obviously on a much larger scale. But just take caution when doing that and make sure you are doing it because it serves your users and not just for an aesthetic purpose or just to save flow space. What about other types of content? There's media like images which really is a work in progress right now. There's not really a perfect solution and you'll really find this in a lot of areas when designing responsibly. It's such a new technology. There's always new methods and techniques coming out. It's really important to stay on top of these things but also keep in mind a lot of this isn't to the ideal point that we wish it were especially when it comes to things like standards and accessibility. So depending on your project make sure you're aware of what these techniques are and how you can use them. Obviously with images we want to serve up mobile friendly images to those with low bandwidth but this is also hard. There's JavaScript out there to do this in some ways but since that's been developed for instance I think the Boston Globe wrote their own JavaScript method but since they did that browsers are now doing what's called image prefetching and they're allowing images to be fetched before the entire page is parsed. So that JavaScript is kind of broken in those browsers and so even that solution that was very well thought out at the time you can see as the internet changes as technology changes things are prone to break as in all areas of technology actually. So this is a good stop gap I think it's developed by Josh Emerson it's called Responsive Enhance and it basically takes the Instagram approach of giving your users the illusion of speed even if you're not actually making things faster at all. What it does is it serves up multiple resolution, multiple images of multiple resolutions to the user but it loads the smallest one first and displays it on the page and it won't load the next one it won't show the next image until it's completely finished loading so users aren't getting that pop-in effect or that jerkiness that comes to site loading if they're on a super slow connection they're still seeing the image in the page but as it continues to download as they have more bandwidth and depending on screen size they're served up in either even higher quality of an image. So again not a perfect solution but I think a good stop gap as it gives the appearance to speed of the user and I think that's something that's important at this point. For video obviously you want to serve up your video in mobile friendly formats not just serve up one that's only going to work on web browsers or one that will only work on mobile obviously there's a great JavaScript called fitfids.js I think the guys at Paraval produced. It's very lightweight so there's not a lot of page load to add it's really easy to use and it works with embedding video from sites like YouTube and Vimeo so very useful for videos. Advertising is something we've come up against again as having a lot of publishing clients when you're using responsive and even working with different breakpoints the problem with ads is that they usually come in at a fixed width and if your column sizes are constantly changing and your content is shifting around if you're popping in these fixed width images you can imagine how that's going to break page flow and make things look kind of dysfunctional so it's again this is something you'd probably want to touch on very early on with your client and see if they want to serve up ads if they have existing ad server or if they're just starting try to work with them on how they want things to work there's not really a perfect solution for this yet either so there's going to be there's going to have to be some compromise do your clients mind if their ads show up on mobile is a good question to ask we recently worked on a site I'm still working on a site with Associated Press and I think they just decided since it was going to break things and they felt responsive as important heading forward they would just hide ads on lower breakpoints to keep things consistent for the user there are some ad publishers and ad servers like buy sell ads who say that they're working on techniques or trying to accommodate these things but again it's it's a work in progress and there's really no perfect solution so again work with your client every project is different obviously some techniques aren't going to work for everybody so make sure you're talking with them and figure out what what their needs are concerning advertising and how you both can move forward in the project taking that into account okay so wire framing how does responsive design affect our wire frames are our deliverables the same what do we show clients do we wire frame each breakpoint all these are questions we had going in I'm sure you have some as well obviously again I would recommend starting small with mobile first and if you've already started writing your content that way you've already started working with your your UX person that way you probably already have a good set of page structures at this point so you can transition into wire frames pretty easily I think wire frames are the best stage in the process to kind of statically comp up every page in a very bare bone sense wire frames are great for that and that's one of the original purposes that we use them for because this is a very low fidelity point in the project and we'll see this across different areas and I think that's a battle you'll come across to is this battle between fidelity and finality right your clients want to see finality they want to see the project and the process progressing visibly so that they know they're getting closer to getting a full site that they can hopefully be proud of and love but at the same point we're battling fidelity so we want to keep things pretty loose early on and especially when we're dealing with responsive design if a change request comes in when you're further down the line in the process like if you did a design comp for every page in every breakpoint or you're into development and these big change requests come in those change requests are going to take a lot longer and a lot more manpower to execute than if you kind of head that off early on in this wire frame stage so I would recommend and it's worked for us to wireframe out every page and breakpoint this step but also complement those with prototypes again this is where collaboration comes in kind of between your UX and your front end developer right now to kind of test out your breakpoints this is the benefit that prototyping brings it allows you to test your breakpoints how your content is flowing even at this early stage and it also lets your client kind of see that we're just showing them a bunch of static images at this point that's not really giving them an accurate picture of what they're going to get at the end of the project their site is going to be a fluid living thing flowing between all these different devices and breakpoints and I think as soon as we can give them kind of an idea of what that's going to look like I think it's beneficial for them as well and also for us as we try to design the best experience for them again this helps us attack content flow problems here and also client feedback problems here at a low fidelity low fidelity stage in the project so what could this look like people at Headscape have actually put together this little demo that I could see being very useful on different projects it's basically just a demo page where you cycle through the different breakpoints and you could even show this to your client and they can click through the different break points you have available and at a very low fidelity but informative stage of the project they can see how their content is going to flow between all these devices and so working with your front end developer can be a great asset at the stage in the process whereas it would typically wait until after designs were done to get involved in the project what about design my favorite part of the project a little bias at this point it's really not financially feasible we found to create comps and breakpoints in Photoshop for every page it's just I mean if your client has an endless amount of cash to spend maybe but I really don't think it's beneficial to the project no matter what your budget size is again now we're getting into the more high fidelity stage of the process where change requests are going to take more time you've seen this even when comping up individual pages clients try to come and take things from this example or that and they want you to kind of change your comp into these different things and it takes time and obviously you build in time for those change requests but when you're dealing with all these different pages and break points it just becomes very unwieldy so how do we approach design then and responsive process Oliver has a great quote the tool doesn't make the craftsman I think as designers responsive design gives us a great opportunity to step back and kind of evaluate the available tool set that we have for us I know my process has changed a little when moving into responsive projects and you may find yours as well you may need a different tool set or a different workflow than you have you probably will so what does that workflow look like for us well we start with style tiles which Samantha my co-worker is kind of championed she's also put together the site about it style tile.es great companion site but style tiles are kind of a low fidelity intro for the client into the design process they're kind of quick and dirty change requests don't take nearly as long because it's just a snapshot to set kind of the visual tone for the site that will go and apply to the rest of the pages and the rest of the break points it also benefits the client because it gives them an early opportunity in the design phase to get feedback in on the visual part of the design I know as designers we kind of shutter away from client design feedback because you know we're the ones that went to art school right what what reason they have to comment on colors or placement or anything like that but client feedback can be very important I wouldn't ignore it and this is a great place to get started especially visually this helps us avoid when we get into the comp stage that we're kind of used to of clients making those change requests again take more time or they're kind of frank and comping if you will which is a phrase Samantha likes to use where clients will take examples from one thing and another and ask you to kind of combine that all after you've already kind of established the content in the wireframe for the site and that kind of feedback changes everything which isn't really useful and just makes the project drive on it makes timeline slip and make things very frustrating for everyone so styles I was really helped combat that and it also avoids kind of the do or die presentation that we designers have sometimes gotten ourselves into where we start the design process we go off into our little hole do all these comps come back show the client and just hope they like it and if they don't and the feedback is significant you know what you're going to do sometimes they ask you to start all over and that's not good for anybody so this helps avoid that as well so style tile dot ES style TIL dot ES is a great companion site if you want to check that out explains things much more in depth you can download a template example to get started yourself a really useful tool in our design process moving on from there I'm kind of getting to the traditional comp stage and there's kind of been this debate or battle recently in the design world about designing in the browser or designing in the static program like Photoshop or fireworks or in design like the Boston globe team use which I found pretty interesting basically arguments are you know again the site that your client is going to get as an aesthetic page so we should design the browser and give them the most accurate representation we can however this doesn't really work depending on the project team I think it's really a both in the responsive process it really depends on your skill set if your designer knows a lot of front end development they know HTML and CSS very well JavaScript etc and they can jump into the browser I would recommend doing that as fast as possible because again it gives the client a fast representation of what they're going to get into the in the end but there's also awesome designers who aren't really that skilled in front end development maybe you came from a traditional print background of design and you're just kind of getting your feet wet in web design it's probably not most cost effective for you to get into a project and then kind of work your way through all this having to take a bunch of training courses in the middle of a project to figure out how to design in the browser so it really depends on your skill set so just evaluate these tools for yourself as a designer figure out what works for you experiment a little try to have fun personally I found myself jumping back and forth between sketching Photoshop and the browser myself because different programs or different ways of designing are better for different things the programs like Photoshop or fireworks they're better for I find at least they're better for fidelity they're better better for getting in to the details getting things looking exactly how I want them to using the tools available in Photoshop actually I saw Adobe released a beta of Photoshop 6 today that actually makes web design a lot better it seems so I'm excited to see what they have there but then the browser is a lot better for flexibility you know if changes come in you can make them a lot easier in CSS and have them apply to all the pages you've set up and all the break points you've set up for your clients so jumping back and forth between these tools depending on what works best for you another thing I'd recommend is actually sitting near a front end developer during this part of the process especially if you're not going to be doing a lot of that front end in building the design comps to show the client that proximity I think is really undervalued you can work with them as a partner again this cross collaboration between different parts of the process or project can be really yeah okay sorry this better I'll lean over like this okay I don't know if we can get the volume turned up so even sitting close to a front end developer in this part of the process can be helpful working with them so they know what you're designing they know what's coming if they're the ones building the comps in the browser as well and we also supplement we found it real useful to supplement these comps whether it be in the browser or what I found useful is to design just one or two pages in Photoshop and the accompanying breakpoints for them and then also designing a sort of style guide to either give myself reference or the front end developer whether it's a PSD or whether you want to do it as HTML documents to give the developers later on in the process a reference point because you're not giving them a comp for what every single page on the site is going to look like but you can give them a reference like this that they can go back to and say oh, a block quote needs to look like this or a call to action box needs to look like this icons need to look like this etc. we found that pretty useful the BBC did this when they redesigned a few years ago theirs is actually really really detailed and they go through things like defining every single element on the site a downloadable style guide you can actually go check this out yourself I'll be including resources links when I post these slides so giving your entire team these types of tools to be most efficient even later on especially in this process where we're not designing each and every page for the client but we're still able to set up these styles and these resources for the team down the road I think it's also important to hold what I would call page review sessions basically just as you design these first few pages especially in the project kind of gather your team and get their feedback if you've already built them in the browser have everybody pull out their device and test them on their own device so they can give feedback as well for how it's displaying to them and kind of meet at set intervals throughout the process so you're not kind of designing this one set of pages then showing the client and getting approval but you're also working with your team and iterating there and getting feedback from them as well because they also know the constraints of the project and again some more cross pollination here they can give valuable feedback they can look at this page and say well if we do this it's not really going to work at the smaller break point because of this constraint or something like this so make sure you involve those before even showing the client and kind of leaving your teammates out to dry when they have to try to piece together and make things work that you've designed as a designer I think we've all kind of made those mistakes especially early on in our career where we haven't considered other people in the process when designing we just wanted things to look really sweet and you can even do this with clients too when you're showing them these pages it's also an iterative process as well I would try to set that expectation with the client at the very beginning obviously you want to build in a certain number of revisions and rounds of feedback but I think as much feedback as you can get is helpful as you're designing across all these different screens and even have the clients I've actually found this to be pretty cool have the clients pull up the site on their whatever mobile phone they have even if it's not something you specifically designed for or their tablet it's a little scary but they've also found it to be really cool too even if it's a lower end device not a low end but a low not as capable device like a blackberry or something like that where they don't have a full browser on these older mobile phones but if you've set up your design well it can still scale and they kind of have that personal connection with the design because they're seeing it on their actual phone and not just up on a screen when you're presenting it to them or even in a browser they kind of realize and get that wow this is really going to work for multiple devices and for multiple people in this growing area as far as development goes we haven't really seen a huge impact on the process in terms of a mind shift or a huge change in how our developers work especially on the back end but there are a few things we found really important it's that they're involved as early as possible so again hopefully in that kickoff meeting rounds of feedback etc so they can give that perspective from their area of expertise so again we're not kind of setting them up to piece together what we've designed or what we've decided content wise or in our wire frames they kind of know what's coming and even if your front end person is creating things in the browser if they're theming for instance have them in constant communication with your back end developer so that they can kind of communicate and your front end developer can say well I'm going to need this class name when it comes time to integrate into the CMS so they know that when the CMS spits out this stuff they're not going to have to reconfigure a whole bunch to get things looking right or to get things integrated this is true also if the design is being outsourced on your project as well otherwise all of you don't have a full project team maybe you're a freelancer and you work with an agency or your shop only does development and you outsource design it's pretty important to understand this workflow as well our developers have found that especially when it's time to integrate with a CMS like Drupal it's not really beneficial for our back end developers to get handed everything built out in front end code in HTML and CSS because when it comes time to integrate with Drupal everything doesn't really match up it's not useful as our developers prefer to work more from that style guide that I mentioned earlier where they can go and see that resource they can look at the CMS know the visual style know what a few pages need to look like build those and then from that style guide kind of build up from there one of my coworkers, Josh Cooper wrote a great article on our blog detailing that process called Death of a Cut-Up Man where he talks about kind of that frustration of being asked to go from a fully fleshed out HTML and CSS kind of package of the site migrating that to Drupal where it saves a ton of time if he's just handed the design a style guide and he can work out from there to kind of build things from scratch and then with Drupal there's also tools like Omega which I'm sure some of you are familiar with to kind of get you started in a responsive process I think it's a great starting point if you're working with Drupal especially when setting up your grade it allows you to change that according to what your content is so that you can get a good start when integrating into Drupal itself so after we've kind of designed and built the site there's a lot of testing that needs to happen this is actually where we found there's the largest increase in time spent in a responsive process is on the testing end obviously you can just resize your browser to see how your site is going to respond but I don't think that gives you a super accurate picture of how it's going to really work for the everyday user there's also great web tools like BrowserStack Adobe Shadow but these don't always accurately translate either I think they're really useful and I think we should definitely use them for concrete testing results Brad Frost wrote a great blog post on why we need to use real mobile devices and how we can do it without breaking the bank especially if you're a smaller agency you're not going to be able to afford and go buy 40 different devices so you can test your site on he gives some really practical steps on how you can kind of cut costs by buying either second or third gen devices for instance buying an iPod Touch instead of an iPhone that's tied to a cell plan so you can still test within mobile Safari but you're not paying that monthly fee or you're not paying for an unsubsidized phone why should we test on mobile devices as well because the display varies depending on the browser you're viewing in just like the desktop between iOS, BlackBerry, Android and it even varies things like fonts can render totally different even if it's the same device and the same version of the OS so all these things are good to keep in mind it's doable on a budget again I'll be posting the link to Brad's blog post with my slides and it's worth investing in these I think because this market is growing and it is expanding and if you're committing yourself to this these are going to be really useful tools for you in the future if you need some help deciding what devices to buy Stephanie Rieger has a great blog post on strategies for choosing one and she recommends a pretty good set that you can go with that doesn't cost a whole lot I'll be posting that as well also test for bandwidth this is a pretty big deal as well ReadWriteWeb they did a study and found out that one of four users abandons your page in a few seconds and this is kind of a disturbing trend that I think since since 2000 page sizes or page load sizes have increased by like 10 times or something like that and so these things are kind of fighting each other because we need to be serving up resource friendly pages on the web the trend is to make all these rich graphical pages that are actually taking up more space so make sure you find a good compromise there obviously I see the benefit of serving up a great visual experience to the user but don't let it cost your client things like conversions or user retention where they're going to lose people viewing their site if it takes too long to load you can actually test this out even on your PC the benefit of being in a location where you always have great cell service there's programs you can use that I'll post that you can actually use to limit the bandwidth coming into your PC or your Mac so you can even test these on your own and obviously there's extensions like Y Slow that give you some recommendations on how to improve speed but keep in mind it's not just for mobile phones people could be on a laptop or a netbook using a 3G or 4G card and their speeds could be limited and phone could be on a super fast connection like Wi-Fi or 4G the new iPad is now on 4G networks and that has faster speeds than I have at home with my ISP so don't make a mistake that just because it's a small screen that don't have any bandwidth it's still a consideration to take into account however what about when it comes when it comes time to hand off the site to a client I think we all know that the site really isn't done once it's launched it's continuously living and breathing thing even if we've given total control over to the client I think we still have responsibility to set them up and to prepare them especially in this new area of responsive design so that they're not breaking things I mean I think it's a fear we all have especially I do as a designer I don't want to hand off the site to a client and see them start uploading images at the wrong resolution that are going to break the layout or input all these images into the main slideshow on the home page that are just totally ugly and pixelated or get stretched and out of proportion and that's a fear but I think it's our fault if we don't take responsibility and set them up for these things we shouldn't be setting the client up for failure just handing them off and letting them run at the site we need to be preparing them giving them training even the content producers of the site because we have all these different content flows across these breakpoints and if our content editors don't understand how to write these headlines what fields to use in the CMS things are going to break pretty quick so try to build in some time to actually train these people on the client side or your stakeholders so that they're prepared to maintain the site if you aren't the one helping them do so you can do this through documentation and training you can do this through things like style guides for your client Starbucks actually recently redesigned their site to be responsive and they also released this companion style guide it goes through all these different areas of content and tells their content producers how things should work, what the grid is what resolution their images need to be how to serve up different resolution sizes for different breakpoints and you can actually go and see this yourself so this is probably for their internal team but it's something that I think is easily reproducible especially once you get a template going you can kind of turn it out on multiple client projects on giving them this leave behind or this documentation so that they're just not left on their own to run their own site and hope that things turn out okay so we've kind of seen instead of a linear process like this I've been mentioning throughout there's a much more flexible one there's a lot of cross-collaboration cross-pollination between disciplines at different points in the project that you wouldn't normally interact with these team members and that's really one of the fun parts for me I get to talk to a lot of team members I don't usually get to at different points in the project and just hearing from their perspective how I can make my design better and I can give feedback on how they can display content better and things like that so your disciplines aren't siloed anymore they're not contained as a designer just to my desk on my own I can get feedback from these people and I need to throughout this process and it really helps you work as a real team it's much more organic instead of that linear or relay race process that I talked about at the beginning so these are all kind of important considerations across all these areas you can see because it isn't just limited to media queries CSS and even just the designer it really affects all these different areas from content all the way to how clients maintain the site afterwards but we're also just at the beginning of this I think as a web community I'm not claiming we have all this figured out I'm sure some of you in this room have better ways of doing things than I just shared responsive design is kind of at the beginning I think even though it's been around for a few years the techniques have at least and so these things are going to keep changing I mean I'm sure this talk will be out of date within six months to a year because there's going to be new techniques new processes and as the standards people get on board hopefully we can start to craft these sites for our clients and for our users that will serve them in the long run that will be future friendly and it will take advantage of this growing market of multiple devices and multiple screens and even bigger screens like you know the rumored Apple TV or I don't even I don't know who wants to surf the web on their TV actually but screens are getting bigger I mean there's rumors of Retina displays for desktop computers now obviously the new iPad which released a few last week I think and so there's all these different considerations that keep changing how we work and that's really why I love this industry these changes are challenging and they allow us to be more creative in our thinking and how we can best serve our users so make sure you just keep these thoughts a priority throughout your process if you have any other thoughts please come talk to me I'd love to learn from you as well and remember responsive isn't just about resizing your browser and having a cool site in the end it's really about helping save you time and iterating or redesigning the site a couple years down the road but instead being future friendly and forward thinking it helps save your client money in that respect and it really gives both parties a site they can be proud of and one that hopefully your users will love so that's my talk thanks very much yeah I'll post my slides later today and there'll be resource slides with links on those as well if anyone has any questions feel free to step up to the mic I think we have a few minutes at least hi question regarding your style guides and involving that in your process are you building that into your project plan for the client as in that's an additional feature or how are you able to justify the additional time it takes to produce a style guide in addition to the site itself how do you handle that normally okay the question was about the style guides and how we allow for additional time in the project how do we estimate that, how do we bill it etc obviously it takes more time to produce that so we've kind of estimated that across the multiple times we've used this and tried to build that in obviously as you do responsive on your projects the first few times depending on your team you don't really know how long things are going to take so it is kind of hard at the beginning to estimate that one thing that might be helpful is just to try to build one on your own for a fictional project or maybe for your personal site and just pretend that you're building it for someone else and see how long it takes you and use that as an estimate or just build in enough of a buffer your first few projects so that you have that time allowed for you does that make sense I have a question about the prototype and wireframes do you usually do those or your developer is just going to do those or you do it together sorry can you speak a little louder about the wireframe and prototypes like in the process do you do those like designer or your developer like a judge going to do those we have we have you ex people that are responsible for wireframes but I understand every team is kind of built differently like in my previous company for instance I did do the wireframes myself so it really depends on the people you have and the resources you have it just depends on your project team make up I would say hi I'm Jodi Mesa and I work for examiner.com I'm the director of user experience over there I've been there for about four years and two years ago we switched over to Drupal and one of the biggest challenges that we've had from like the creative perspective and you kind of touched on it a little bit is the fact that the themers don't really want to build a static HTML and CSS site that we could use as sort of a prototype you know for user testing and things like that we usually have to wait for the development to happen and then the themers go in and then they stylize it so I was wondering if you could just kind of expand on your process and what you found has worked to integrate Drupal while still allowing you to do prototypes in a small time frame sure how it typically works is like instead of comping up every page like a designer typically would in Photoshop and showing those those would be kind of instead of comping up every page I would build one or two out in HTML and CSS not like not the whole site in HTML and CSS I don't know if I was clear on that sorry if not so does your creative team do that like before it goes to the themers or yes our developers are kind of it kind of doesn't happen in that water like our developers are kind of building the back end depending on your makeup again like work with your front-end developer and kind of build those I mean you're going to want to show the client these things before you start theming again it's that battle between fidelity and finality again because you don't want to build all this stuff have the client reject it and then you have tons of change requests to make that take up a ton of time seems like it would help with testing as well because the problem is we have to comp out every single page so that the QA team is going to be a mess right or not okay thank you I think I'm supposed to put up this slide if you want to go make comments on the presentation I'd greatly appreciate it I'll let me know your feedback thank you again