Responsive Design and the Web Design Process - Ben Callahan22:57 with Allison Grayce Marshall
Ben Callahan, president of Sparkbox, sits down with Treehouse to discuss responsive design, the web design process, and the Build Responsively initiative.
This video doesn't have any notes.
[? Music ?] 0:00 [Treehouse Friends] 0:03 [? Music ?] 0:07 Hey guys, it's Allison Grayce here for another episode of Treehouse Friends. 0:15 I'm here in Orlando, Florida at the In Control Conference 0:19 with Ben Callahan, the president of Sparkbox. 0:23 Ben, thanks for being here today. 0:26 My pleasure. 0:28 So tell us a little bit about Sparkbox and also the Build Responsively workshops. 0:30 [Ben Callahan] [President, Sparkbox] Let's see, we started officially in 2009. 0:35 There were 4 of us at that time, 0:40 and we went by a different name at the time, Forge, 0:42 and that's actually still the company name, but we work as Sparkbox now. 0:46 We kind of reinvented ourselves in the beginning of 2011, 0:50 and we really started to feel like there was some space 0:54 available for us at least to specialize a bit more 0:59 on trying to build sites that worked at any resolution, 1:02 responsive web design in particular. 1:06 At that same time, we had purchased a domain called Build Responsively, 1:08 jokingly thinking about the idea of drinking responsibly, 1:12 and weren't quite sure what to do with it, 1:15 and we had been learning a ton the year previous about how to do this stuff, 1:18 and somebody had suggested that we start to share some of the things we were doing, 1:22 and so we started to do that on our blog The Foundry on our site. 1:28 And we just really got the itch for this idea of a culture of learning 1:33 in our office itself, and so we started to speak a bit more about it 1:37 and organize the whole workshop series that we did last year. 1:43 We mostly focused in the Midwest, but we did maybe 6 or 7 events, 1:47 and they were 2-day events, which took a lot of work. 1:51 This year we decided to try and attach to some bigger conferences, 1:55 like In Control, actually, and so that's worked out really well. 1:59 We've got at least half a dozen lined up for the year. 2:02 We're really excited. 2:05 We try to think about the techniques that are needed in responsive web design, 2:07 but we try to think about it from an approach of 2:10 looking for common problems that exist in the industry 2:13 and ways that we can solve those problems with these techniques. 2:16 That way we're able to bring multiple disciplines into the conversation 2:20 as opposed to just speaking to front-end developers 2:25 or people who write CSS. 2:27 I think the goal is to try and keep more people engaged. 2:29 We're trying to invite some of the rest of the disciplines into the process with us. 2:31 So how involved are you with putting on the workshops? 2:35 Is that something that you do by yourself, or do you have a team of people? 2:38 The first one we did was in Cincinnati. 2:42 We had every single person from my company speak. 2:45 At that time, I think there were 8 of us, 2:49 and it was an amazing time. 2:51 Most of my team hadn't spoken in public before, 2:54 so I was asking a lot of them to get up in front of people 2:59 and share what they'd learned, but everybody really did it. 3:01 I mean, it was really neat. 3:05 Since then, there are 2 or 3 of us who really enjoy presenting a lot more, 3:07 something that we're pretty passionate about-- 3:12 there are actually 4 of us probably-- 3:14 and so the 4 of us focus on doing most of the presenting, 3:17 but everybody helps with content development, 3:20 and we have 2 or 3 folks in the office who are really organized 3:22 and can help make sure things are running smoothly 3:25 and on schedule and getting the events planned and all that. 3:29 Well, while we're on the topic of speaking, 3:32 have you always been comfortable with speaking in front of people 3:35 and sharing your knowledge, and what advice can you give to people 3:37 who are thinking about maybe teaching or 3:40 starting their own workshops or starting a blog? 3:43 How do you find the confidence to start sharing what you know? 3:46 You know, it's funny. 3:49 For a long time--I actually haven't done much speaking, to be honest. 3:51 Let's see, I guess last year in January was the first time I ever spoke in public, 3:54 and that was at CodeMash up in Sandusky, Ohio, 4:02 which is a bunch of devs that get together and eat a ton of bacon, basically. 4:04 But it feels natural to me, so I don't know that I have anything to say 4:09 that's wisdom for how to do it. 4:15 It's just I guess at some point enough people told me 4:17 that we were smart, and so I don't really feel like 4:20 we're that far ahead of other people, but I do think that 4:25 we're just willing to share everything that we know. 4:29 The truth is as I've traveled around and met a bunch of people 4:31 who come to these workshops and other conferences, 4:34 everybody that I meet has something that I can pull from, 4:37 and so these engagements for us and what we're speaking 4:40 are more--we get just as much out of them from speaking 4:44 and learning from the people who attend as they do from us, 4:48 maybe even more, so encouragement, I would say 4:52 you have something that you're good at, and if you're good at it, 4:55 write about it to start with, just start documenting what you do. 4:59 It's good for you. 5:02 Even if nobody reads it, it's good for you to be able to go back and find that stuff, 5:04 but you'll see that you'll quickly get an audience, 5:06 because there are people hungry for this information. 5:08 Speaking of an audience too, 5:10 you're currently redesigning the Sparkbox website live 5:13 for everyone to see. 5:16 Tell us a little bit about why you decided to do that. 5:19 Most people don't invite people into their process like that, 5:22 so that's a really cool idea. 5:25 Why did we do it? Let's see. 5:27 There are probably a handful of reasons. 5:29 Like I said before, I feel like we're trying to build 5:31 a culture of learning, and so for us, it's not easy 5:34 to write all of the time, but we require everybody in the office to write, 5:39 and this gave us some really poignant subject matter, 5:43 I think, to cover, in terms of writing. 5:47 It's an opportunity to introduce the rest of the team 5:49 to writing more about the things, the problems that they're solving. 5:52 It's also a little bit of accountability for us. 5:56 If you're out there and you had to redesign your own site, 5:59 you know how hard that can be. 6:03 And putting it out there for the rest of our peers to see 6:05 and give feedback on has been an opportunity to say to us, 6:09 "Look, this is important to do." 6:13 "We have to make time for this." 6:15 We have to make sure that--we have obligations to clients obviously, 6:17 but this is just as important as that work too. 6:22 And for a year, we've been using our website 6:25 as an example of some things not to do in our workshops 6:28 because it's one of the first sites that we built with some of these techniques. 6:32 We've learned so much in a year or two, 6:35 and so it was time to do it. 6:37 Yeah, I bet that pressure too of letting everyone see your timeline 6:41 and opening it up for people to see really makes you stick to it and get it done. 6:46 Yeah, I mean, the holidays hit right in the middle, 6:51 so we've actually been a little quiet, 6:53 but later this week we're kicking it back up. 6:55 But to be honest, if you have the illusion 6:59 that what you're doing on the Web is private, 7:04 then you're probably mistaken, because all of our work is out there. 7:06 People can view source on pretty much anything we do, 7:10 so it's kind of the nature of the industry too. 7:13 You mentioned how your site was an example of what not to do. 7:16 What do you mean by that? 7:19 A perfect example. 7:21 If you go to the Sparkbox Foundry and go to any post, 7:23 and you're on, say, a small device, 7:26 what you will see will actually look more like a 404 page 7:29 than an article, and that's because we didn't think so much 7:32 about the usability of the site when we did it. 7:35 We were obsessed. 7:38 We got caught up in the 3 prime techniques of responsive web design. 7:40 What we ended up doing was taking a big site 7:45 and cramming it on to a small device, which is not how this should work. 7:47 There is a lot more to it than that, 7:52 and that work was primarily done by front-end developers, 7:54 and so one of the things that we talk a lot about in our workshop 7:59 is that you have to invite the rest of the team into the conversation, 8:02 and we speak about this idea of collaboration. 8:08 Obviously, everybody who has talked about this stuff and has done it 8:11 knows that you've got to have the right team members 8:13 in the room to make decisions. 8:16 We've actually found that we end up-- 8:18 we do something--I don't even know if this is new or not, 8:21 but we call it natural decisions, because in a more linear process, 8:24 a more traditional process, what we've seen is one person 8:27 or one discipline feels like they need to finish their thing 8:30 and get to the deliverable and hand it to the next person. 8:33 They feel like they have to make all of the decisions 8:36 about that specific discipline early in the process. 8:38 What we try to do is delay decisions as long as we can. 8:41 We're waiting until it's the right time to make those decisions, 8:45 so I'm not forcing my UX people or whoever is doing wireframes or whatever 8:48 to have all of that done and figured out before we've gotten into the code. 8:52 That just doesn't make any sense. Things are too dynamic, too fluid. 8:55 I was talking to Samantha Warren last night, 9:00 and she said, "There is no responsive process." 9:03 "The process itself has to be responsive." 9:05 "It has to change for the project," and that's very true, very true. 9:09 So speaking of the process, there is all this about designing in the browser 9:14 and trying to figure out that process, because I think saying that 9:20 a process is responsive, bosses and clients don't like that, right? 9:24 So how do you think that's going to work moving forward? 9:28 Do you think that designers--there is less of a deliverable at the end for them? 9:33 Do you think that maybe--like how do you envision that process changing? 9:38 I said a little bit earlier that I feel like it's really more about collaboration. 9:43 For us, we end up putting front-end developers with designers. 9:46 If you know about pair programming, we do that with 9:52 content people and technical people. 9:55 We do that with every person, every discipline in our office 9:57 pairs with other disciplines, and we do that because 10:01 I want all of my team to broaden their knowledge 10:04 about the Web as a whole. 10:07 That gives them the ability to be informed at least 10:09 and help make better decisions when they're tasked 10:13 with doing something on their own. 10:15 But early in the process, I'll put my technical director 10:17 and my content director in the room, lock them in the conference room together 10:20 with a projector and let them figure out how to get a basis 10:23 for the site started. 10:27 Those are the 2 people that really need to be there at the beginning. 10:29 Somebody has to get the architecture of the thing, 10:31 something functional built, the technical director, 10:33 and somebody who understands the content early in the process. 10:36 Those are the 2 that have to figure out how this stuff is going to actually live together, 10:39 so we put them together early. 10:42 They get something built that we can actually use 10:44 during our dev process, and then we do something called style prototypes, 10:47 and we run that in parallel with something called a content priority prototype. 10:52 These are both deliverables that happen in the browser for us, 10:55 so it's HTML, and it's some CSS, and they're separate at this point. 10:58 We try to make sure that deliverables we offer 11:02 that aren't intended to focus on design 11:05 look as ugly as they can, 11:08 because I've been in too many meetings with beautiful wireframes 11:11 where my clients are commenting about colors 11:14 or layout or something, and it's like, "Okay, let's just cut this stuff out." 11:16 We show pretty much unstyled HTML 11:22 in what is like a prototype but with real content, 11:25 as much real content in it as we can very early, 11:28 and we do that in a linear way 11:30 so that they can see priority. 11:32 The linear nature forces us to prioritize things. 11:34 And then at the same time, we're working on a style prototype, 11:37 which is like an evolution of style tiles from Samantha, 11:40 but it happens in the browser. 11:43 Just a basic, basic HTML page, no real content at all, 11:45 and it's really about typography, color, texture, 11:49 some of the core design principles that we have. 11:51 Our designers build those on their own. 11:55 If they need a little help, they'll work with somebody who is a specialist in CSS, 11:58 but we're trying to get them to build these on their own, 12:01 because they need to know CSS. 12:04 I mean, there is a big conversation. I don't want to open up that can of worms. 12:08 But I actually believe that it's very true if you're going to design 12:11 for the Web, you need to learn some CSS. 12:15 I think this is true too. 12:17 If you're going to write content for the Web, you should probably learn some HTML. 12:19 That's semantics, right? 12:21 Yeah, because you used to be able to get a job as a web designer 12:23 knowing just a few CSS, a little bit of CSS, a little bit of HTML. 12:27 Now it seems like the expectations are so much higher 12:32 with having to know HTML5, CSS3, LESS and SASS 12:35 and all this stuff, so what do you think 12:38 a web designer needs just to get into the door these days? 12:41 A web designer? 12:44 What does that even mean? [laughs] 12:47 I mean, do you think there is a bigger gulf now between 12:49 a front-end designer and then maybe someone who is a front-end developer 12:51 than there used to be, or do you still think that someone should wear both hats? 12:55 My technical director is Rob Harr, 12:58 and he keeps saying this thing in the office 13:01 where he says that SASS--or LESS I think is one of the more popular 13:03 first preprocessors, but he says, "These preprocessors for CSS 13:10 were like a gateway drug for front-end devs." 13:15 What he's trying to say is that this whole front-end development thing 13:18 has gotten so complex. 13:21 I feel like front-end devs who lean technically, 13:24 technical in their nature are shifting towards all of this complex 13:27 local build process stuff with running node and grunt 13:31 and all this stuff to get a really cool, easy-to-use front-end development. 13:35 Well, easy to use if you're a technical person, 13:38 a front-end development tool, or environment running. 13:40 But then you have designers who started maybe branding in print 13:43 and are trying to move into this space, and they're going to learn CSS. 13:46 They're going to learn some HTML. That's great. 13:49 But they're going to shy away from even using something like SASS, 13:51 if they have to install Ruby or use the command line. 13:54 Andy Clark goes on about this. 13:57 "Why is this a command line?" 13:59 "Make this easy for me to do." 14:01 He's got a really valid point, which is at some point 14:03 the tooling that we use for doing this stuff 14:06 is going to settle a little bit I hope, 14:08 and we'll start to see there are some clear winners 14:10 in terms of what you should be doing. 14:12 And then I think the people who are less technical 14:14 will be able to come into that and embrace it a bit easier. 14:17 So there still is a place for them to co-exist. 14:20 It's not like-->>Oh, yeah, absolutely. 14:23 What is the biggest mistake you see web designers making 14:26 when designing responsive websites? 14:29 Designers like to control things, 14:31 and if you're going to design for the Web, you have to let go of that. 14:35 That's probably the biggest thing is I talk to people all the time about this, 14:40 and they say, "Well, when do you actually design the site?" 14:44 "When do you design the site?" 14:47 And we still do a lot in Photoshop, 14:50 but it's becoming more like a sketch pad for us. 14:54 And the implementation of that is happening in the browser, 14:57 and that's where it needs to happen. 15:00 We're trying to get away from making pictures of websites 15:02 as so many people are saying these days and actually building sites themselves. 15:06 I don't know if that answers the question. 15:10 So you think designers maybe get too fixated on perfection 15:12 of every single pixel and then the type, 15:16 and then they get uncomfortable when they see it actually live in its environment. 15:19 We used to--oh, gosh, we were so ridiculous about this stuff. 15:23 My creative director, Jeremy Lloyd, is obsessed with type, typography. 15:26 He loves it. 15:33 He comes from a branding background, and he cares about this stuff. 15:35 And I can remember times where the type in Photoshop 15:37 looked beautiful, but as soon as we would move it to the Web, 15:42 obviously it's going to look different, 15:44 and then the client, we were showing static comps 15:47 that were exported from Photoshop, 15:49 so clients get an expectation about type and color 15:51 and how these things are going to look, and I can remember times 15:53 when we would literally move this stuff into the browser, 15:57 get the Web font rendering, do a screen cap of the type 15:59 in the browser and bring it back into Photoshop 16:03 so that we could show accurate web type. 16:05 That's ridiculous. 16:07 Why don't we just put it in the browser? 16:10 I think it's really about letting go of control. 16:12 That's the biggest thing that I see, because we've wasted so much time 16:15 making things perfect in Photoshop 16:18 knowing that they're never actually going to look like that. 16:21 It's just not realistic. 16:23 So as far as responsive images go, 16:25 there are a few things out there, like picture fill 16:28 and some great options but nothing really solidified or set in stone. 16:31 What do you think is the best solution right now? 16:34 Well, things are getting solidified. 16:38 I think the first draft is out for both picture and source set, 16:40 if I recall, very recently. 16:45 Those things are happening. 16:47 There are lots of heated dialogue still happening about those things, 16:49 and I think that in the end, that's going to be what we really need. 16:56 There are tons of solutions for this stuff, though. 16:59 There is everything from proxy-based solutions 17:01 where you've got Resrc It, R-E-S-R-C dot I-T, 17:04 which I haven't actually tried yet, but I know that it's similar 17:09 to some of the stuff Sentia was doing. 17:12 And what that does is basically you can modify the URL of your image, 17:16 so it's easy to implement, 17:19 but it does come along with some other interesting implications. 17:23 What happens is you're modifying it by changing a server, 17:27 putting a new server basically on the front of the URL. 17:31 Someone else gets the request, a different server. 17:33 They parse out your image, which is still in the URL, 17:36 take it to their server. 17:39 Also, they inspect user/agent stuff, so they're doing some device classification, 17:41 scaling that image, sending it back to you. 17:45 Performance concerns obviously. 17:51 You're dependent on someone else to solve that problem for you. 17:55 Maybe you don't want it to be set to the size of the resolution of the device. 17:58 But a very easy to use kind of solution. 18:02 You can also do that same kind of thing on your own server 18:06 with a little bit of htaccess and basically grabbing 18:09 any image type and doing the exact same kind of thing 18:13 but doing it on your box. 18:19 Actually, picturefill is a really good solution. 18:21 Scott has done a fantastic job with that, 18:24 and if you're going to implement it, I would say do something 18:27 where you in your CMS give the ability 18:30 to at some point in the future generate the actual picture syntax 18:33 when it's ready. 18:36 But it's very well tested. 18:38 People are using it with great success, 18:41 so I think that's a very valid solution right now. 18:43 There are all kinds of other crazy things that people are trying, 18:47 but in the end, I think we need a little bit better HTML element. 18:51 Yeah, definitely. They're working on it, right? 18:55 What do you think will be the major improvements 18:57 to responsive web design this year? 19:00 Well, I feel like some bigger organizations are finally starting to get on board 19:02 with some of this stuff, so some of the requests that we're getting 19:05 for 3 or 4 ROI case studies we'll finally start to have some of that data available, 19:09 which I think will only encourage more to do so. 19:14 I think there is going to be that move from some bigger companies, 19:18 some big e-commerce type stuff that's going to be happening this year I know, 19:21 so that's really exciting. 19:25 I talk about this a little bit, and I wrote an article called 19:27 "The Responsive Dip," and it's based on the idea of how 19:31 humans learn things, and you move through these 4 stages of learning, 19:34 and I feel like we are at a stage where we 19:39 are finally starting to actually understand that 19:42 we're not really doing this quite right. 19:45 We have to rethink a lot more of what we've done. 19:48 Sometimes you actually get worse at doing something 19:51 before you get better, but that's kind of the idea. 19:53 I think for us as an industry that's part of what's happening here. 19:55 In Jakob Nielsen's study not too long ago 19:59 where there was so much--and Josh Clark responded-- 20:03 so many people wrote back about-- 20:05 Jakob said based on data of testing, 20:07 mobile-specific sites versus responsive sites, 20:10 he found that the usability of the responsive sites was much worse, 20:14 and his recommendations were to do something like 20:17 build a mobile site, cut content, cut features, 20:20 and give them a link to a full site. 20:23 Obviously, many people in the industry said, "Wait a second." 20:25 "What are you talking about? That's a bad idea." 20:27 "You're making a lot of assumptions about context and all these things," 20:30 which I agree with. 20:33 But I understand how Jakob arrived at the conclusion that he did, 20:35 and that's because we've built very non-performance sites 20:39 with lousy user experiences. 20:42 We're learning. 20:45 I think in some respects we've gotten worse at doing web design 20:48 by trying to figure this stuff out. 20:53 But we're going to come out of that dip of learning, 20:56 and we're going to be, I think, in a much better place. 20:59 We're starting to see some sites come out that are demonstrating 21:01 that this stuff can really work, so I think this is going to be the year 21:05 where we start to see some really creative responsive type solutions, 21:09 and we start to see real organizational change, 21:14 which is required to invite this kind of process to happen, 21:18 at a bigger company in particular. 21:23 I think there is so much happening there, 21:26 and so for me, the future of this stuff, at least for the next year 21:28 of what I see, it's really more about the hardest stuff to figure out, 21:32 which is not the technical stuff. 21:37 It's the politics of the organization that has to adjust. 21:39 That's the hard stuff. 21:43 All the people who build sites, they see this stuff, 21:45 and it's obvious. 21:47 This makes sense. This is how it should be. 21:49 We're finally embracing the fluid nature of our medium. 21:51 But it's the people who aren't as technical 21:55 but who are making money decisions, financial decisions 21:57 in an organization and have to say, "Yes, it's okay 22:01 "for you all to sit together in the same room 22:04 "and for me to not know exactly how long this is going to take 22:07 the first couple times you do it." 22:10 That's a hard decision for a financial person to make, 22:12 business person. 22:16 Well, I think that's a great place to wrap it up, 22:18 with the future of responsive web. 22:20 Where can they keep up with your work and keep up with you? 22:23 The Sparkbox website, SeeSparkbox.com, 22:26 and on Twitter, just BenCallahan, all 1 word. 22:29 I have BenCallahan.com if you want to see 22:33 where I'm going to be speaking or what I'm writing about, 22:35 those kinds of things, and then the Build Responsively 22:37 workshop is coming around, so try to find one of those, 22:41 and we'd love to meet you guys there. 22:43 Cool. Well, thank you for joining us today. 22:45 My pleasure.>>Until next time. 22:47 Thanks for watching. 22:50 [Treehouse Friends] 22:52
You need to sign up for Treehouse in order to download course files.Sign up