Responsive Web Design

[Music]

Lea Alcantara: You are listening to CTRL+CLICK CAST. We inspect the web for you. Today we’re talking about responsive web design with special guest, Ben Callahan. I’m your host, Lea Alcantara, and I’m joined by my fab co-host.

Emily Lewis: Emily Lewis.

Lea Alcantara: This episode is sponsored by Perch. Perch is a content management system for projects where you need a lighter, faster and less expensive CMS solution. It can help you turn around small projects quicker and make them more profitable. Perch is a one-off license cost of $79 per website, and our first-party add-ons are completely free. Go to grabaperch.com/ctrlclick to try Perch and find out more.

Emily Lewis: CTRL+CLICK would also like to thank Pixel & Tonic for being our major sponsor of the year. [Music ends] Hi Lea, how are you?

Lea Alcantara: Not bad. Not bad. I had a cool celebrity sighting this weekend.

Emily Lewis: Ooo!

Lea Alcantara: I don’t know … [Laughs]

Emily Lewis: Who? Who?

Lea Alcantara: … I don’t know if it really counts, but I was outside of a dumpling house called DinTaiFung here in the Seattle area, and it was Steve Ballmer.

Emily Lewis: Oh wow! I don’t even think I know what he looks like so I wouldn’t know…

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: Well, I think he was standing behind us really, like for about at least ten minutes because this is a really popular dumpling house and people have to like wait in line and all that kind of stuff, and then suddenly you hear, “Ballmer, table for four for Ballmer!” And then my husband was like, “Oh, my God, it’s Steve Ballmer!” [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: Yeah, so that was it. It was very, very normal really because, you know. I guess that’s how it happens.

Emily Lewis: Yeah, well, I mean, that’s where he lives.

Lea Alcantara: Yeah.

Emily Lewis: Because that’s the area he is in, right?

Lea Alcantara: Yeah, exactly. Well, actually, DinTaiFung is even in the Microsoft building.

Emily Lewis: Oh, it is?

Lea Alcantara: So yeah, there are the offices just above the restaurant, like the restaurant is in a mall, and then there’s a tower on top of the mall, so I think that’s part of the reason why, but you know all these things happen and these people actually live and work here, but when you actually see someone, you’re like, “What?” [Laughs]

Emily Lewis: [Laughs] That’s pretty cool. You know, Albuquerque gets a lot of movies here.

Lea Alcantara: [Agrees]

Emily Lewis: And yet in the eight years I’ve lived here, I have not seen anyone. Like Samuel Jackson has been here, Val Kilmer, and I never see anyone.

Lea Alcantara: You’ve never even run into anyone from the Breaking Bad cast?

Emily Lewis: No. No, sorry. [Laughs]

Lea Alcantara: Yeah, no, I mean, and it’s the final season too. So uh, I’m so excited.

Emily Lewis: Yeah, I’ve actually not seen a single episode.

Lea Alcantara: Oh, wow!

Emily Lewis: I know, I guess I think that must be considered sacrilege around here, but no, it’s a little too dark for me. I like sugar-coated happiness on my television watching these days.

Lea Alcantara: Well, you know, that’s fair enough. I mean, if you want to have that type of escapism, I think that’s cool.

Emily Lewis: Yeah. I don’t need to think that my city is a meth-infested town [laughs] where I could die and then, you know…

Lea Alcantara: [Laughs] Well, and it’s hiding in your science teacher’s … and you know.

Emily Lewis: Yeah, my next door neighbor’s house.

Lea Alcantara: That fried chicken owner guy.

Emily Lewis: I don’t even know the reference, but I imagine that’s from the show. [Laughs]

Lea Alcantara: Yes, yeah. [Laughs]

Emily Lewis: All right, so I’m really excited about today’s episode. We’ve got Ben Callahan talking about responsive web design. Ben is a front-end developer and President of Sparkbox, a web design and development company out of Dayton, Ohio. Ben is also the co-founder of the Build Responsively Workshop series, which has toured the country this year to share knowledge about the best practices for responsive web design. Welcome to the show, Ben! Thanks for joining us!

Ben Callahan: Thank you so much for having me. I’m excited to be here.

Lea Alcantara: Awesome. Ben, can you tell our listeners a bit more about yourself?

Ben Callahan: Yeah, but before I do, I have to chime in on this Breaking Bad conversation. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: I’m a huge fan actually myself, and I just thought I would give a quick plug to my friend, Jeremy Lloyd. He’s the creative director here. He created a little website called Branding Bad, so if you’re into the show, check it out, and even, Emily, if you’re not so much into the show, you maybe would appreciate some design. He’s basically designed a little image for every one of the last few shows, the last season basically, so it’s like a logo basically for each shows. It’s pretty cool.

Emily Lewis: Oh, neat.

Lea Alcantara: Oh, that’s neat.

Ben Callahan: Yeah. So I’m Ben Callahan. You already said my name and the company, Sparkbox. It’s a small shop in Dayton, Ohio. We’ve got about 18 folks here full time, and we spend most of our time just trying to figure out how to build better experiences across devices, across screen widths, and so that’s pretty much what we do every day.

We also do quite a bit of speaking and writing. I love to write. We call it the culture of learning here. We really encourage everybody here to at least share what they know. We believe that there’s always someone smarter than you and there’s always someone a little further behind, so we’re trying to help people come a little further along, at least sharing the things that we learned as we do this stuff every day.

Emily Lewis: Cool. So Ben, let’s start with the basics. What is responsive web design, and is it different than mobile design?

Ben Callahan: Oh, that’s a good question. [Laughs] So Ethan Marcotte coined the term a couple of years back in 2010 actually. And he basically described it as the combination of three techniques. Fluid foundation which is shifting our thinking in terms of how we do layout from fixing the widths of stuff with CSS like the typical sort of 960 Grid thinking that we’ve had for a long time into starting to think in proportions instead. Instead of fixing those with widths, we might use percentages then, and what happens once you’ve done that is that you have content that lives inside that grid, inside the layout that you’ve built.

Now, that it’s flexible and the text itself will re-format itself and re-flow pretty well. But you’ve got all kinds of different content types, tables and videos and images and all kinds of things you can imagine, that now live inside that flexible grid, and so there’s this idea of creating flexible media, flexible content, and that’s the second of his two techniques combining.

Then finally, once the contents and the layout are really working well together, you’ve got to maybe provide some larger shifts in layout, and so you could do that using the CSS3 media queries, and that’s the combination of a media type and a media feature. And it basically allows you to, in layman’s terms, ask a browser, ask the viewport how wide it is and then apply a sub-set of CSS to only certain widths of the viewport. When you combine those three things, you can do some pretty amazing stuff in the browser.

Now, I would also say that the industry has kind of pushed that idea quite a bit in the past few years, as you can imagine. Nothing on the web really sits still. So these days with responsive web design, there are all kinds of other things that are happening. We’ve got tons of input types. We’ve got voice and we’ve got track pads. We’ve got touch screens. We’ve got mouse and pointers still and keyboards, and I can hover over my Leap Motion Controller on my system here at work.

Who knows what’s coming next, so there are lots of other things to think about, and we’re also crossing all those interaction models as we change, not just change the viewport widths, but as the devices and the types of systems we’re using to get access to the content on the web are changing.

So it’s getting ultimately more complex every day, and in my mind, I think it is very different from mobile even though this is a pretty common I think misunderstanding, especially with our customers. But it’s definitely different. Before we had these techniques and we were doing a lot of work to build mobile-specific sites. The beauty of responsive web design, I think, is that the end goal is really about accessibility. We are really trying to build and serve our content and our functionality to people regardless of what device they happen to be using, regardless of the screen size.

So that’s kind of the reason that we jumped into it. We believe in that idea of accessibility. In that sense, we could make content available at much larger resolutions than we have before. If you have a nice high-definition display, I’m sure you’ve opened up browser full screen and gone to one of these 960-ish sites, and then what happens is you end up with a big tiny column in the middle of all that content. You’ve got a bunch of space on the outside. We could be doing all kinds of fun things and responsive web design would allow us to do some of those fun things and reward users with larger screens too, so it’s about a lot more than mobile.

Emily Lewis: So when it comes to responsive web design, is it something that in 2013 should be a goal for any web-based system, or is it something that maybe isn’t a fit for everything?

Ben Callahan: Wow, that’s a can of worms. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: I can tell you I’m pretty confident in the way that we operate here, so I can answer that from the perspective of Sparkbox and how we choose to work on the web.

Lea Alcantara: [Agrees]

Ben Callahan: But if you’re following any of the progressive-enhancement conversations online (or maybe arguments would be a better word) online, you’d probably know that this can definitely be an interesting subject to discuss. So I mentioned earlier this idea of accessibility. We believe in that, and that’s one of the reasons we choose to do responsive. I’ve written before we just talked quite a bit about this idea here in that we believe responsive web design is always the right decision, but it’s not always the only decision, and so those are actually very different things. I mean, we feel like it’s a solid foundation, and it’s a really ideal scenario especially if the goal of your project, of your site is to get the content into as many hands as you can, to as many people as you can.

I would think that most people have that goal, but in the case where that’s not the goal, then I could certainly see you choosing to not do it. It’s sort of a default for us. We believe in it strongly enough that it’s how we approach most projects, but I’m not saying that we haven’t ever built something fixed-width since these techniques were all the same. [Laughs] I don’t know if I really answered your question.

Emily Lewis: Well, so does that mean when you’re bidding on a project, responsive web design is just part of what you propose every time these days?

Timestamp: 00:09:58

Ben Callahan: Yeah, that’s easy. We don’t even offer in a proposal … it’s not like a line item you can take out. In fact, I would encourage people if you want to do this kind of work, to not do it. I believe it is web design. I think Malarkey said this. He basically said, he wrote a post I think a while back that said something like “I don’t believe in responsive web design” was the title, a really controversial title. I’m talking about Andy Clarke, sorry, out of the UK, and he followed that up in the article by saying, “Actually, I do. I think we should just call it web design because I think it’s the right way to go.” So that’s the approach we take. In fact, we just kind of started doing it, not even really asking permission. [Laughs]

Emily Lewis: Well, and this makes me think of a more business or operational question. So I’ve done a handful of responsive projects. It’s a lot more work than just if I was only designing for a fixed-width single viewport kind of situation. So you didn’t even sort of like ask permission, but you’re bidding on projects. Did prospects notice the increase in your cost, or did you roll that into an internal cost?

Ben Callahan: So the first project we ever did was our own, our website, and we did that shortly after Ethan’s article … the timing was right. We happen to be starting to think about redesigning and we read that, and it made a lot of sense, and we tend to sort of experiment on ourselves before we do that on our clients. And so we did that, and I think we’re pretty meticulous about tracking our time and it took us about twice as long as what we think it should have taken, but the next project we did, it was only about 50% more.

So I know obviously those kinds of numbers depend on the project, depend on the client, depend on your team, it’s all those things, so there’s no way to say, “It’s always 50% more or something like that.” But definitely you’re right. It takes more time. In my mind, the value that you’re getting though is worth significantly more than your increase in time. So if you’re just comparing it to building a fixed-width site, then yes, it obviously takes more time.

But if you also want to build a mobile site, let’s say, something that’s optimized for phones, and then you think, “Oh, I probably want to build something that’s slightly better for a mid-tier sized, you know,” and then, “Oh, phablets just came out, and now, I’ve got these massive phones that aren’t quite the size of a tablet and they’re a little bigger than a phone. Do I need a build a site there?”

Obviously you understand where we’re going with this, so the value in my mind is significantly higher than having a single code line than it is in building multiple. So I believe that it’s something we just do, and our rates, our hourly rates stay the same, but our pricing for projects did go up, you know?

Emily Lewis: [Agrees]

Ben Callahan: And that’s the name of the game, the web is getting more complex, and our people are more specialized, so it seemed justified to me and it hasn’t caused any problems for us.

Lea Alcantara: I kind of want to backtrack a little bit because you made an interesting statement in that responsive web design, at least for your company, is essentially the default behavior, but it’s not the only choice. And you also mentioned that, well, it’s not like you’ve in the past few years that all the websites have been responsive. So I’m curious about the sites you guys did design despite this very strong stance towards responsive web design. Why did you decide not to go that route for specific projects in the recent past?

Ben Callahan: That’s a good question. I can tell you I am thinking of one sort of immediately that comes to mind, and the reason that we didn’t use responsive techniques in that project was because our client basically said, “I do not want you to do responsive web design.” [Laughs]

Lea Alcantara: Oh, wow!

Ben Callahan: Yeah, and we were kind of brought in. We do a couple of different kinds of projects at Sparkbox. We have a whole Rails team here, so a bunch of back-end devs, and we do a lot of Rails work. We do some PHP. We also have a bunch of very specialized front-end developers who are all primarily focused on responsive techniques. We also have content strategists. We have director of usability and that kind of thing as well, but the bulk of our effort here is, I would say, we cut our teeth building Sparkbox by doing like very flexible web construction on the front end.

So we have a reputation now, and all of our customers generally come to us asking specifically for responsive, but we also play a role occasionally where we’re just what we call like a front-end consultancy where we end up being the people writing the HTML, CSS and JavaScript on a project where there is a different organization designing and a different organization doing integration with the back end of some kind, and so oftentimes, it’s on bigger projects where that’s the case. In those scenarios, maybe we don’t have that initial contact with the client and so we haven’t been able to explain why we think it’s a good idea, and depending on our scenario in terms of how busy we are and all those things, we may take a project like that.

So I’ll talk to you today pretty much about how I view the world in terms of — I’m pretty much an idealist — but I also run a business, and we also have to make decisions that are very, very business driven, and our clients are doing the same thing, so I’m not naïve enough to think that we’re ever going to be just doing a single kind of work. Does that answer your question?

Lea Alcantara: Yeah, absolutely.

Emily Lewis: For that kind of situation where you got involved with the client and they did not want responsive web design, I’m curious now that your default is to go responsive. Did it actually take more time to not be responsive in that project?

Ben Callahan: I don’t know, but that’s an interesting question. I don’t think so. One thing that is interesting as you shift into doing this kind of work is you have to make a decision pretty quickly when you do your first project, and maybe you’ve been through this, “Should I start with the small layout first and grow the layout as my viewport increases, or should I start with that large layout and then undo styles as I get smaller?”

Emily Lewis: [Agrees]

Ben Callahan: And the first site we did, we did the large resolution first, and pretty quickly we realized that we’re writing so much CSS stuff, undo stuff, and it just got to be kind of frustrating. So we now have this default stance of — you’ve probably heard it called — mobile first, although I don’t really like using those words to describe it because I think it gets confused with the more sort of theoretical conversation that Luke Wroblewski started with his book, Mobile First, but it is technically sort of starting with the small screen, with a small viewport width first, I guess is what you could call it, but that’s a bit of a mouthful, and so that’s our default.

What that meant is when we’re working on this project that was, I think it’s around 1,000 pixels wide, we kind of had to start there, and it takes a while to shift out of that thinking and to shift into thinking, “What is that small-screen experience going to be, and how do I write the HTML in a way that will allow me to achieve a more complex layout at a larger resolution?” So I think it did take us a moment of sort of stepping back and saying, “Oh, wait, we’ve got to think like we used to think here. What’s the right way to do this?”

What’s interesting is that as we worked on individual components for that specific project, we actually still used percentages and things like that in the hopes that at some day, maybe when this project is done and they’re looking for a phase two and they, all of a sudden, want to support smaller screens, maybe we can use the same kinds of styles that we’ve already established in that fixed-width layout and just, I guess, set them free for lack of a better term, you know. [Laughs]

Emily Lewis: [Agrees]

Ben Callahan: So I still think that those techniques can add value even if you’re not building the entire thing to be responsive.

Emily Lewis: Now, in terms of your projects, especially now that you’ve had time from the first project you did of your own site to the client projects, have you noticed any commonalities in terms of the process, costs, resources needed that you can kind of factor in moving forward to projects?

Ben Callahan: Yeah, absolutely. I mentioned that we’re pretty meticulous about tracking our time. I would encourage anybody who’s doing this work, you have to track this, so if you got to be able to go back and report on it…

Emily Lewis: Like are you tracking it just like, let’s say, on a task level like CSS or even narrower it’s saying small viewport CSS?

Ben Callahan: We really focused on sort of design like UI design, UX design, content strategy, front-end development, but we do break out. In our front-end development, I guess you’d call it a bucket of time, we’d capture HTML, CSS, and interactive JavaScripts. If occasionally we’re doing some type where we’ve got asynchronous calls back and building the DOM and that sort of a thing with JavaScript, that’s a separate kind of JavaScript in the way that we track, but it’s really the front-end development tasks that we watched.

One thing we’ve done, back to the comment about process, is we’ve had a significant change in the way that we work, and I think a lot of organizations have gone through this, but we used to be very linear in nature. Even three years ago, we were still on websites. We were still thinking very much about, “How do I get the design approved, and then hand that off to somebody to write the code and then hand that off to somebody to integrate with the back end?”

This is sort of what people call the waterfall approach, and that’s really where I’ve seen the most change for us, and I don’t think it’s that responsive dictates this new process. I really think the process wasn’t ever really working very well, to be honest. We were kind of doing things to kind of make it work and people were sort of becoming experts in their specific discipline and all that, but really we’re forcing ourselves to make decisions so early. How naïve is it is to think that we can make all of the UI design decisions before we’ve ever written a line of code, you know?

Emily Lewis: [Agrees]

Ben Callahan: It’s just that… I don’t know. I feel like we pretended a lot of things. We simplified things in our minds just to kind of help us get through the day without feeling guilty maybe, I don’t know. But what we do now is very different actually than that, and we talk about this idea of a one deliverable workflow where we have the one deliverable which is, let’s just say, we’re building a pretty simple website, that is our deliverable.

Timestamp: 00:19:48

So instead of spending a bunch of time making wireframes look beautiful and getting them all perfect and all that, spending a ton of time refining a wireframe. Instead of doing that, what we might show a customer is more like a progress update, and they’ll come in to here, where we work, or we’ll get on Skype with them or whatever, whatever is appropriate for that customer, and we’ll show them pictures of stuff from a whiteboard that we sketched out, or literally snapshots taken with an iPhone in our creative director’s sketchbook instead of taking those things and then dropping them into the Illustrator and making sure everything is perfect.

I don’t have any interest in perfecting and refining those things. What I’m interested in is spending my time refining in the medium that we’re going to deliver in, so we, like a lot of shops these days, we push to get them into the browsers as quickly as we can, and we have deliverables now like Style Prototype which is something that’s kind of like Style Tiles, if you’re familiar with Samantha Warren’s static image deliverable. She calls it a mood board for the web, a really cool concept. Rob Tarr from my shop and I had an opportunity to see her present that, and it must have been two years ago at Southby, and we were literally walking out of the door of that session and looking at each other and we both had the same idea, “We should totally be doing this in the browser, you know?”

So if you’re curious I can give you some links, but Style Prototype is something that we’ve been doing quite a bit now, and it’s basically like Style Tile but it’s HTML and CSS. Tons of benefits for doing that. I mean, we can show real web type. We can show interactions with such simplicity now. Hover is available, instead of in the Photoshop duplicating layers and changing things and exporting. I mean, you guys are familiar I’m sure with what the frustrations of these static tools, right?

Emily Lewis: [Agrees]

Ben Callahan: And not to mention that we’re setting all kinds of weird expectations now. If I show them a static picture of a site, it is at some resolution. It is at some width. When I hit File New in Photoshop, I had to pick a width for my canvas, so instead of those kinds of deliverables upfront, we’re trying to show very simple things, but colors and textures and maybe iconography, how are we going to treat photos, what our headlines going to look like, and we completely separate that from the content.

So it’s really more about how is your brand communicated, and we can do that in a day, and that way we haven’t spent a week in Photoshop designing some home page or something that we’re hoping is going to be perfect, and then it went in the wrong direction, in that case, we’ve wasted a week. With the Style Prototype, we can literally make some changes in CSS right there in the meeting and get it refined to the point where they say, “Yeah, this feels right.” And now we’re 80% sure of the direction we’re supposed to go in. [Laughs]

So we’re doing things like that now, and when it comes to the process for actually building stuff out, what I found is that the key is, at least of what we’re believing right now is, the way we’re operating now, to figure out when our designers switch from solving design problems into refining those solutions. And if you can identify when that switch happens and at least move into the browser at that point, then you’re going to handle the refinement, which is usually half the amount of time in a process. You can handle all that refinement in the medium where it’s actually going to be delivered and it’s going to save a ton of time. You’re not wasting a bunch of time making your pictures look perfect, pushing pixels around forever, and so that’s kinds of the mentality.

We ended up doing something we call design pairing a lot, which means my creative director Jeremy Lloyd will go into the room with all the devs and they’ll sit down and say, “Hey, let’s take a look at this project,” and they’ll share with him what they’ve done so far. A lot of my front-end developers are more than capable designers, and so they could, in their own right probably get a job as the web designer anywhere else, but we call them developers here because they write HTML and CSS and they have a really good design sense. So he can get a direction going and hand it off and let one of these front-end devs take it and run with it, and then they’ll sit down and refine things literally in the browser. So it’s changed the way we work significantly, I think, for the better.

Emily Lewis: Have you had any pushback from clients who aren’t used to that kind of process since it’s so different than we’ve traditionally done in our industry?

Ben Callahan: We have. What we’ve learned about that is that this requires sort of a constant communication about the way that we work. It’s almost like, and I guess you could say that we’re re-educating our customers about how they should think about building on the web, and that’s one of the reasons though that we do things like the Style Prototype. We do that very early, and that starts to set the expectations with our clients that almost every deliverable we give them is going to be in the browser, and one of the things we love about it is they can open that thing up, and we ask them to open it up in whatever browser they want, so they may choose to open it in IE7 or IE6. If that’s what they use every day, that’s what I want them opening it in.

Now, all of a sudden, we know our decision maker’s favorite browser, and we can have conversations about border-radius, and is that supported in your browser? If it’s not, then is it okay if things were square? [Laughs], and we get to help them understand that what it means to support an older browser can be different than just pixel perfection.

Emily Lewis: [Agrees]

Ben Callahan: So I think it’s really about spending time with them and helping them understand, but that’s part of our process from the get-go. Our estimates talk about how our process is going to run differently than maybe what they have expected in the past, and we still have people who reach out and say, “Hey, you know, I’ve already done all the planning and I’ve got all the designs done. I designed a 320, a 768 and 1024 design, and I’ve got 40 templates all designed out in three different resolutions. Will you guys code it for us?” And at that point, I tend to take a step back and sit down with them and try to get on the phone and say, “Hey, it’s awesome that you’d put so much time into this, and you’ve really put the thought in, but let’s talk about what the expectations are for this project, because I want to make sure those are going to be something we can get aligned with before we jump in.”

Emily Lewis: Well, that’s a nice segue I think into what I know had for a while been referred to as breakpoints, and now I hear people referring to them as optimization points.

Ben Callahan: [Laughs]

Emily Lewis: And basically I’m talking about the viewport width, and so have you discovered are there standard optimization points or breakpoints?

Ben Callahan: No. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: No, I mean, let me, I guess, I’ll explain it a little. I wrote a post maybe I don’t even know, a few months back called “There Is No Breakpoint,” and I wrote this because every time I speak about responsive web design, one of the most common questions that I get is, “Hey, how should I decide where my breakpoints should be? You know, how do I decide that?” And several folks in the industry have talked about this. Stephen Hay significantly has, I think, been quoted as saying, “Just start small and make your browser wider, and when it breaks, put a breakpoint in. When the layout breaks, fix it.”

That’s sort of the approach we take, but I think even before he was talking about it like that, Stephanie Reiger had written about this idea of major breakpoints and minor breakpoints, and this is kind of where we are at this point. There are definitely breakpoints. With my post, there is no breakpoint. It was really more in trying to transition our thinking away from asking the kind of question that you just did which is, “What should those breakpoints be? And is there a universal set?”

I don’t believe that there is because what we’ve found is if you’re building breakpoints based on devices, you’re really just doing the same thing we used to do, but you’re doing more of it like saying, “Hey, let’s do 320 and 480 and 768 and whatever they are.”

Emily Lewis: [Agrees]

Ben Callahan: And who knows what the next device is going to be. And if you just build that foundation in a flexible way, then what you’ll find is all the stuff in between is going to look just fine. So we do have this idea of major breakpoints, and those are when they are major changes in the layout and the components that we’ve built into the system that exist all have to exist all have to make a change in unison, and so that’s what those major breakpoints are for.

But then we just look for anything that needs done. It’s really like this level of detail thinking that happens, and when I talk about this, I show it. I pull up a website that we built recently, and one of my guys is Rob Tarr, he built this little media query bookmarklet, and if you click this thing on any page, it will show you the current width of the viewport and height in pixels and in ems, and it will also show you every single media query that’s firing right now, and it’s really very helpful for doing the work every day, but it also makes a point, and when I open this up on our projects, you’ll see that there are sometimes 20 or 40 media queries that are being fired.

I show that because I want people to understand that it’s really not that big of a deal. If something needs fixed, just go fix it, and if you have to use a media query to do that, then do it. Now, depending on how you structure and serve your styles, that can be more complex than it needs to be, and so we’ve done a bunch of thinking about what the best way is to serve responsive style sheets, and with that, we could probably spend a whole podcast talking about that.

Emily Lewis: [Laughs]

Ben Callahan: [Laughs]

Emily Lewis: Well, if there’s no standard breakpoint, what are your proposals look like? I guess, my question is like, what are you scoping in a project to a client? For example, I know we have clients come to us and ask, “We need this to work on an iPhone.” Like they specifically know exactly what device they want, and so in our proposal, we may say something, “This will be optimized for the iPhone.” But that’s very narrow, I think in terms of what our goals are as front-end developers.

Ben Callahan: Right.

Emily Lewis: So how do you convey within a project proposal or even in the earlier discussions with a prospect about how the project is going to proceed and how those optimization points are translated into, I guess, lay terms?

Ben Callahan: Sure. So if a customer said that to me, that’s an opportunity right there to help them understand what we’re really doing, and that is to say, “Well, I understand your desire for this to look good on an iPhone, like everybody wants that, especially if you look at your stats, right? iOS devices are usually killing it in terms of the amount of people browse with those devices, right?”

Timestamp: 00:29:59

And we have customers say that all the time, but I would probably say something like, “Instead of focusing on that device, because that device is popular today, let’s try to build a solution that’s going to work a little bit more into the future for you.” At least, that’s the hope, right?

And this is exactly what Brad [Frost] and Jason [Grigsby], all the folks that were at the event where this whole future-friendly thing was born. I think it was called Mobilewood, [laughs] and the thinking that’s in that for a future-friendly stuff is really the ideal, and we don’t know what the future holds, but we definitely know that it’s going to be more than just iPhone and iPad, and so how do we build in a way that at least helps us get part of the way there, and that’s this flexible nature of the web. The web has never been fixed width, and we still think about it that way.

Emily Lewis: [Agrees]

Ben Callahan: We still think about, “Well, I want it to look good on the iPhone, or I want it to look good on the iPad when it’s in portrait orientation.” And certainly there are probably business reasons that some organization has to do that, but the amount of work that it takes just to make sure that it looks good at 750 and at 768 is really not that hard. So if you’re going to go through the trouble of making it look good at one specific width, you could just use percentages and make things work well in between as well. So it’s really this idea of trying to prepare as much for what is coming, whatever that is, as we can, and that’s an opportunity to educate your customer. And if they push, push, and push, that’s somebody that I’m probably going to pass on as a client. If they don’t understand the higher goal here, and you have to reassure them that it will look on an iPhone and it will look good on a Kindle Fire, and it will look good on whatever other device you want this to throw at. We’ll make sure that that’s good.

We also back that all up with device lab where we can talk about the kinds of devices we have here and the testing that we do, and so I think all those things combined, usually people are like, “Oh yeah, of course. As long as it’s good on an iPhone. [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: So…

Lea Alcantara: Well, I’m a little bit curious over the process, and perhaps it’s just like my old-school thinking still with the fixed viewports.

Ben Callahan: [Laughs]

Lea Alcantara: Because you were saying, “Well, it’s not really that big of a deal to optimize for 750 versus 768,” which is absolutely true, but does that mean you still optimize for 768 first then test below it? Do you know what I’m trying to say?

Ben Callahan: Yeah, so we start small, or most people think small and they think 320, but there’s actually full-fledged fantastic browsers running on 240-pixel-wide phones now, and they have been for a long time, but people don’t think about those because they don’t see them pop up right away in their analytics, and there’s probably even smaller than that to be honest. So we start with the smallest, and we just literally as things start to or as line-lengths are getting a little too long to read, we’ll throw in a breakpoint and maybe move to a couple of columns or something like that.

I mean, it really is a different way of thinking about how to build, so we literally don’t talk at all about specific devices. I mean, it’s part of our testing, and as things go, as we do most of this stuff to get started in Chrome on a desktop system and I would caution all of your listeners, don’t think that that’s enough in terms of testing, but it is a really good place to start, and it’s quick and dirty and it’s easy to get an idea at least of how things are going to lay out at different resolutions, different viewport widths.

But I feel like the question you’re asking is one that we get a lot, especially in the workshops, and it really just takes getting in and starting small and as you increase, look for places where things are breaking and start to add queries to fix those, and then what you’ll find is you don’t have to worry about specific devices or specific resolutions because really it looks really good everywhere, and that’s what we really want, so I wouldn’t say that we optimize for anything first other than the smallest that we can possibly do. [Laughs]

Lea Alcantara: And so you basically add to the design as things start looking awkward when you are increasing the width of your browser?

Ben Callahan: Yeah, and I would say that I tend to talk generically about this. I say, “You know, as the viewport increases, we enhance the layout, but actually what’s happening now is there’s all these interesting ways to do layout on small screens. There’s a ton people who have written about this idea of Off Canvas, and I think we saw it in the native world first. I think with Facebook app and some others.

Now, every native app does this. If I click on a little menu thing, everything slides to the right and I get this menu on the left. People are doing that on websites quite a bit. If you go to Disney’s website, it does that, and there’s a ton of them, and so what’s happening now is that the layouts are actually just as complex, if not, more complex at small screens, so that does mean what have to think about is something like Off Canvas what we want to do on a small screen, and if so, that definitely has an impact on how we’re going to write that code, how we’re going to write the markup, but in the styles.

Emily Lewis: [Agrees]

Ben Callahan: So it’s not quite as simple as probably as I made it sound, but that’s definitely sort of the line of thinking that we follow.

Emily Lewis: Now, I want to be sure we get to talk to you about responsive web design in context of a CMS, but since you did mention testing, and you mentioned you had a device lab that Sparkbox devs can reference.

Ben Callahan: Yeah.

Emily Lewis: What would you say to a dev who doesn’t have a device lab anywhere near him or her and they don’t have devices? What are the tools that you recommend for testing?

Ben Callahan: Well, this is a tough question because the tools that I recommend for testing are devices. [Laughs] You can certainly use things, and there’s a ton of little plugins and websites that will resize your site and all that stuff. They would throw in an iframe and give you a bunch of different device widths. In the end though, there is absolutely no substitute for holding the thing in your hand, literally walking around in the sunlight with it, sitting in bed at night with your lights off, trying it on an EDGE network, trying to make sure you can navigate with your big, fat finger instead of your perfect, little mouse.

I mean, there are so many things that are different. It’s so many, even just the distance that you hold it from your face. I see people walking down the street with their phone crammed into their face because some designer somewhere thought that it looked really nice on their desktop with a small font, and it’s like it’s really how people use it, so I certainly would encourage people to get their hands on it if they can just get two or three devices. Go to Craigslist or eBay. You can buy these things to use. They’re really not that expensive. If you can’t do that, then look for folks in your area that have a lab already and buy a couple of devices.

Emily Lewis: [Laughs]

Ben Callahan: Or buy one device and say, “You know, I want to contribute to the lab. Would you give me access?” Start sharing a lab.

Emily Lewis: [Agrees]

Ben Callahan: Or maybe (you didn’t hear me say this on your podcast) but go to the Verizon store. You can go to the AT&T store.

Emily Lewis: [Laughs]

Ben Callahan: I mean, seriously, it’s like those devices are just sitting there. Just go and try it. Take some notes and then head back. There is emulators and things like that that you can use. There are stuff like BrowserStack, and we use a lot of those things too, but it’s just really hard to beat the actual device.

Emily Lewis: All right, so before we finish up, I want to make sure we talk about content management systems a little bit. So I’m just curious, generally speaking, not getting too specific into a specific content type, but does responsive web design factor into CMS development for your team, and to that, what kind of CMSes do you guys work with? Do you roll your own, or do you work with out-of-the-box systems?

Ben Callahan: Yeah, okay. I’m going to answer it in the opposite order, so we do a lot of ExpressionEngine work here. We love it because it gives you a really nice framework to build actually some pretty complex things, I think, and so we like it for that reason. Now, we do WordPress work because there’s a million people out there with WordPress sites already, and a lot of times they want some help, and if they’re familiar with the system, then we’re happy to work within that framework. If we do custom development, it’s usually with Rails.

Emily Lewis: [Agrees]

Ben Callahan: And so we do a lot of that kind of thing. Now, we also build hybrid scenarios. We have ExpressionEngine managing Rails apps in kind of weird places, and it’s because the client that we’re working with already was familiar with the interface that EE gave them, and so we could save a ton of time and a ton of money for them just to build a nice, little interface in ExpressionEngine. That’s something they wouldn’t have to relearn, and then build a back end that’s in Rails that’s taking that data, and basically just using EE at that point from Rails’ perspective as an API. So we’ve done some really cool stuff with ExpressionEngine. We love it, and we’ll keep using it as long as we can. [Laughs]

Now, to your question about responsive and how it integrates, so this is actually a really common question, and it’s always been odd to me that people ask this because if your content management system is really good, it shouldn’t matter what kinds of front-end techniques you’re going to use. So if you think about responsive from a purist’s standpoint of just like fluid foundation, flexible content, and media queries, then it’s really quite simple, and it has no effect really on it as long as you can write your own templates like you can in ExpressionEngine or in WordPress or most systems that are out there, it’s very simple to integrate.

But then you also have individuals who use these content management systems in a different way, I think, than a shop like Sparkbox would, and that they maybe go and find an existing theme or set of templates and use those, and so in that scenario, now you’re looking at someone else’s code and trying to figure out how to modify it to be responsive, and you’re kind of shifting into this idea of retrofitting, so we could talk about that too.

But there’s also this other side, which is that responsive is getting more complex. I mentioned that those three techniques are sort of the original definition, but it’s definitely growing to encompass more techniques and more things, and Luke Wroblewski about this idea of RESS, which is responsive plus using some sort of a server side component.

Timestamp: 00:39:53

So I think for his app, I think maybe it was Bagcheck that he wrote about this with, but he had this idea of like keeping the overall layout responsive, but if there’s a specific component that you’re having a really hard time with in terms of making it work at any resolution, at any viewport resolution, then maybe you’d do a little detection on the back end and you serve for smaller viewport width or you serve a different version of the same component, one that’s slightly optimized for smaller screens.

So in that sense, he is combining what we used to do a lot which is this server side user agent sniffing and all that and serving different version of the HTML down, so if you’re content management system has some of that kind of server side stuff built in or if you can generate an API with it like you can very simply with ExpressionEngine, then you can just get that as JSON or something and parse it into the DOM.

Again, all of this at this point, it opens up in to probably a thousand conversations about how you want to build and, and in that case, like what’s the solution for no JS? Are you going to support that in some way? So generally, we don’t have any problem in implementing these techniques with what whatever system we’re building, so we tend to be the kind of folks that fully customize is though.

Emily Lewis: When we’re talking about CMSs, up until now, we’ve talked about the client’s content. What about if the CMS itself needs to be responsive? Have you worked with any systems that offer that?

Ben Callahan: That’s a good question. I don’t know of any that offer that. We have built our own custom Rails apps that have admin interfaces that are responsive, and in that sense, I guess, whatever it talks about as responsive web apps, even though I do believe that the lines between websites and web apps are totally blurred, right?

Emily Lewis: [Agrees]

Ben Callahan: I mean, it’s like every site we build is more and more complex. So anyway, so we have built those kinds of things. I wouldn’t be surprised if somebody has built like an admin theme for ExpressionEngine that is responsive, but certainly you could do it.

Emily Lewis: Is it something that you’ve gotten a request from from clients?

Ben Callahan: Oh.

Emily Lewis: With people who want to like be at a conference and be able to update their site from their phone or something.

Ben Callahan: Oh. No, I don’t think I’ve ever heard somebody ask for that. The scenarios where we built those admin interfaces in responsive ways have been scenarios where people need to manage things from the field.

Emily Lewis: [Agrees]

Ben Callahan: So they are may be walking from door to door or they’re out in the field somewhere checking on some sensors where they need the data and they need to be able to enter it, and they want to do it on their phone or maybe their organization has distributed iPad Minis to everybody and so on some more specific use cases like that, but it’s been great. I mean, it works really well. We’ve combined that with some performance techniques that just make stuff really fast using local storage and allowing them to work a little bit off line, and so yean, I mean, really, the stuff you can do these days is really incredible.

Emily Lewis: [Agrees]

Lea Alcantara: So before we wrap up, I’m curious with all these new techniques and things you need to do for responsive web design. Do you have any special tools or software you’d like to recommend for those that want to do responsive web design?

Ben Callahan: If you are not using a CSS preprocessor…

Emily Lewis: Yeah. [Laughs]

Lea Alcantara: [Laughs]

Ben Callahan: I would say get on it. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: Because, I mean, it’s dramatically changed the way that we work, and I would say we get more efficiency from that one tool than from anything else that we’ve added to our arsenal in the past couple of years.

Emily Lewis: [Agrees]

Ben Callahan: I think we use Sass because we do a lot of Rails work, and it comes shipped with Rails, but we use it on non-Rails projects all the time. We integrate it with ExpressionEngine all the time. It’s not a big deal. The barrier of entry is almost minimum. It’s almost nothing, I mean, because you literally can take a standard CSS file and change the extension to be .scss, and it’s immediately a valid Sass. So you don’t have to do anything fancy with it.

We use it, as I mentioned earlier, the way that we serve and link responsive styles, that is primarily where we take advantage of it and it gives us the ability to support older versions of IE that don’t even support media queries, and we serve large layouts even though we’ve started with the small screen first, and so it’s really changed the way that we think about it. But also it allows you to break your styles up into nice, small chunks the way that a larger team can work on those together and not step on each other’s toes.

If you’re doing local dev, something like CodeKit is really nice because it will do all that preprocessor compilation for you. Rob Tarr’s media query bookmarklet is fantastic. I mean, you just go to the Sparkbox site and search for that, media query bookmarklet, it’s so simple and it just really helps in the browser as you’re working to be able to see like which queries are firing and all that. It’s just really helpful.

Emily Lewis: You know…

Ben Callahan: Yeah.

Emily Lewis: Not to interrupt, but yeah, I am interrupting you. [Laughs]

Ben Callahan: [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: But we’ve talked a lot about the actual like front-end process, but I am curious, are there any resources that the designer can turn to when they’re — I know this is a little abstracted from what your current process is where you guys are designing in the browser a lot sooner…

Ben Callahan: Yeah.

Emily Lewis: But if you’re dealing with a more traditional workflow where you have a visual designer who may be generating comps. Have you come across any resources for that person to sort of guide design choices or trends that are common in different devices in responsive web design?

Ben Callahan: Sure, and I hope I didn’t imply that we don’t do any design in static tools either. We definitely do a ton of sketching and I think most recently Jeremy Lloyds, our creative director, he’s been using Sketch, the app Sketch, to do a lot of design. And we use it specifically to do the design of the independent modules on the site, but also to mock those things up together and to see how they’re going to look when they sit on a page next to each other. So I would say certainly looking at something like Sketch where there are specific types of tools that you can use inside that app that make things, designing for the web, a little easier than maybe traditionally something like Photoshop.

There’s a bunch of those tools on the market now too. There are other little tools, Acorn and Pixelmator, and then you’ve got things like responsive web design tools like Macaw, which came out recently, which lets you do, and literally you can go in and set breakpoints, and Adobe has I think Edge Reflow, and then you’ve got a website called Froont. All these things are visual ways to design a responsive site, and they let you establish points where there are larger shifts and layout, and they let you do that visually, and then on the back end, they spit out a bunch of the HTML and CSS, you know?

Emily Lewis: [Agrees]

Ben Callahan: If you’re not familiar with the techniques, you could get in to play around with those and generate some markup to look at and help yourself learn. We use those kinds of things really just for prototyping and not for production code.

Lea Alcantara: [Agrees]

Ben Callahan: But that’s kind of how we’ve always operated, so that may just be a preference, you know?

Lea Alcantara: Very cool. [Laughs]

Emily Lewis: [Laughs]

Ben Callahan: [Laughs]

Lea Alcantara: Yeah, I’m looking at the app, the Sketch app, on iTunes right now. It looks pretty cool.

Ben Callahan: Oh yeah, yeah, I’ll have to have you get online with Jeremy and have him give you a little rundown on what he likes about it. It’s pretty neat.

Lea Alcantara: Awesome. Cool. Well, thanks Ben. That’s all the time we have for today. Thanks for joining us!

Ben Callahan: Well, my pleasure. Thank you so much for having me.

Emily Lewis: In case our listeners want to follow up with you, where can they find you online?

Ben Callahan: I’m on Twitter, just @bencallahan, and then they can just shoot me an email if they want, [email protected]. Those are probably the easiest ways.

Emily Lewis: Great. Thanks again, Ben!

Ben Callahan: My pleasure.

Lea Alcantara: [Music starts] We’d now like to thank our sponsors for this podcast, Perch and Pixel & Tonic.

Emily Lewis: We also want to thank our partners, Arcustech, Devot:ee and EE Insider.

Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website, ctrlclickcast.com.

Emily Lewis: Don’t forget to tune in to our next episode when special guest Jenn Lukas is joining us to talk about Ladies in Tech. Be sure to check out our schedule on our site, ctrlclickcast.com/schedule for more upcoming topics.

Lea Alcantara: And don’t forget to update your iTunes! Now that we are CTRL+CLICK , we’ve ended the EE Podcast feed. So if you listen on iTunes, you need to update your subscription. The link is in our show notes for this episode.

Lea Alcantara: This is Lea Alcantara.

Emily Lewis: And Emily Lewis.

Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!

Emily Lewis: Cheers! [Music stops]

Timestamp: 00:48:27