[? 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