[? Music ?]

[Treehouse Friends]

[? Music ?]

Hey guys, it's Allison Grayce here for another episode of Treehouse Friends.

I'm here in Orlando, Florida at the In Control Conference

with Ben Callahan, the president of Sparkbox.

Ben, thanks for being here today.

My pleasure.

So tell us a little bit about Sparkbox and also the Build Responsively workshops.

[Ben Callahan] [President, Sparkbox] Let's see, we started officially in 2009.

There were 4 of us at that time,

and we went by a different name at the time, Forge,

and that's actually still the company name, but we work as Sparkbox now.

We kind of reinvented ourselves in the beginning of 2011,

and we really started to feel like there was some space

available for us at least to specialize a bit more

on trying to build sites that worked at any resolution,

responsive web design in particular.

At that same time, we had purchased a domain called Build Responsively,

jokingly thinking about the idea of drinking responsibly,

and weren't quite sure what to do with it,

and we had been learning a ton the year previous about how to do this stuff,

and somebody had suggested that we start to share some of the things we were doing,

and so we started to do that on our blog The Foundry on our site.

And we just really got the itch for this idea of a culture of learning

in our office itself, and so we started to speak a bit more about it

and organize the whole workshop series that we did last year.

We mostly focused in the Midwest, but we did maybe 6 or 7 events,

and they were 2-day events, which took a lot of work.

This year we decided to try and attach to some bigger conferences,

like In Control, actually, and so that's worked out really well.

We've got at least half a dozen lined up for the year.

We're really excited.

We try to think about the techniques that are needed in responsive web design,

but we try to think about it from an approach of

looking for common problems that exist in the industry

and ways that we can solve those problems with these techniques.

That way we're able to bring multiple disciplines into the conversation

as opposed to just speaking to front-end developers

or people who write CSS.

I think the goal is to try and keep more people engaged.

We're trying to invite some of the rest of the disciplines into the process with us.

So how involved are you with putting on the workshops?

Is that something that you do by yourself, or do you have a team of people?

The first one we did was in Cincinnati.

We had every single person from my company speak.

At that time, I think there were 8 of us,

and it was an amazing time.

Most of my team hadn't spoken in public before,

so I was asking a lot of them to get up in front of people

and share what they'd learned, but everybody really did it.

I mean, it was really neat.

Since then, there are 2 or 3 of us who really enjoy presenting a lot more,

something that we're pretty passionate about--

there are actually 4 of us probably--

and so the 4 of us focus on doing most of the presenting,

but everybody helps with content development,

and we have 2 or 3 folks in the office who are really organized

and can help make sure things are running smoothly

and on schedule and getting the events planned and all that.

Well, while we're on the topic of speaking,

have you always been comfortable with speaking in front of people

and sharing your knowledge, and what advice can you give to people

who are thinking about maybe teaching or

starting their own workshops or starting a blog?

How do you find the confidence to start sharing what you know?

You know, it's funny.

For a long time--I actually haven't done much speaking, to be honest.

Let's see, I guess last year in January was the first time I ever spoke in public,

and that was at CodeMash up in Sandusky, Ohio,

which is a bunch of devs that get together and eat a ton of bacon, basically.

But it feels natural to me, so I don't know that I have anything to say

that's wisdom for how to do it.

It's just I guess at some point enough people told me

that we were smart, and so I don't really feel like

we're that far ahead of other people, but I do think that

we're just willing to share everything that we know.

The truth is as I've traveled around and met a bunch of people

who come to these workshops and other conferences,

everybody that I meet has something that I can pull from,

and so these engagements for us and what we're speaking

are more--we get just as much out of them from speaking

and learning from the people who attend as they do from us,

maybe even more, so encouragement, I would say

you have something that you're good at, and if you're good at it,

write about it to start with, just start documenting what you do.

It's good for you.

Even if nobody reads it, it's good for you to be able to go back and find that stuff,

but you'll see that you'll quickly get an audience,

because there are people hungry for this information.

Speaking of an audience too,

you're currently redesigning the Sparkbox website live

for everyone to see.

Tell us a little bit about why you decided to do that.

Most people don't invite people into their process like that,

so that's a really cool idea.

Why did we do it? Let's see.

There are probably a handful of reasons.

Like I said before, I feel like we're trying to build

a culture of learning, and so for us, it's not easy

to write all of the time, but we require everybody in the office to write,

and this gave us some really poignant subject matter,

I think, to cover, in terms of writing.

It's an opportunity to introduce the rest of the team

to writing more about the things, the problems that they're solving.

It's also a little bit of accountability for us.

If you're out there and you had to redesign your own site,

you know how hard that can be.

And putting it out there for the rest of our peers to see

and give feedback on has been an opportunity to say to us,

"Look, this is important to do."

"We have to make time for this."

We have to make sure that--we have obligations to clients obviously,

but this is just as important as that work too.

And for a year, we've been using our website

as an example of some things not to do in our workshops

because it's one of the first sites that we built with some of these techniques.

We've learned so much in a year or two,

and so it was time to do it.

Yeah, I bet that pressure too of letting everyone see your timeline

and opening it up for people to see really makes you stick to it and get it done.

Yeah, I mean, the holidays hit right in the middle,

so we've actually been a little quiet,

but later this week we're kicking it back up.

But to be honest, if you have the illusion

that what you're doing on the Web is private,

then you're probably mistaken, because all of our work is out there.

People can view source on pretty much anything we do,

so it's kind of the nature of the industry too.

You mentioned how your site was an example of what not to do.

What do you mean by that?

A perfect example.

If you go to the Sparkbox Foundry and go to any post,

and you're on, say, a small device,

what you will see will actually look more like a 404 page

than an article, and that's because we didn't think so much

about the usability of the site when we did it.

We were obsessed.

We got caught up in the 3 prime techniques of responsive web design.

What we ended up doing was taking a big site

and cramming it on to a small device, which is not how this should work.

There is a lot more to it than that,

and that work was primarily done by front-end developers,

and so one of the things that we talk a lot about in our workshop

is that you have to invite the rest of the team into the conversation,

and we speak about this idea of collaboration.

Obviously, everybody who has talked about this stuff and has done it

knows that you've got to have the right team members

in the room to make decisions.

We've actually found that we end up--

we do something--I don't even know if this is new or not,

but we call it natural decisions, because in a more linear process,

a more traditional process, what we've seen is one person

or one discipline feels like they need to finish their thing

and get to the deliverable and hand it to the next person.

They feel like they have to make all of the decisions

about that specific discipline early in the process.

What we try to do is delay decisions as long as we can.

We're waiting until it's the right time to make those decisions,

so I'm not forcing my UX people or whoever is doing wireframes or whatever

to have all of that done and figured out before we've gotten into the code.

That just doesn't make any sense. Things are too dynamic, too fluid.

I was talking to Samantha Warren last night,

and she said, "There is no responsive process."

"The process itself has to be responsive."

"It has to change for the project," and that's very true, very true.

So speaking of the process, there is all this about designing in the browser

and trying to figure out that process, because I think saying that

a process is responsive, bosses and clients don't like that, right?

So how do you think that's going to work moving forward?

Do you think that designers--there is less of a deliverable at the end for them?

Do you think that maybe--like how do you envision that process changing?

I said a little bit earlier that I feel like it's really more about collaboration.

For us, we end up putting front-end developers with designers.

If you know about pair programming, we do that with

content people and technical people.

We do that with every person, every discipline in our office

pairs with other disciplines, and we do that because

I want all of my team to broaden their knowledge

about the Web as a whole.

That gives them the ability to be informed at least

and help make better decisions when they're tasked

with doing something on their own.

But early in the process, I'll put my technical director

and my content director in the room, lock them in the conference room together

with a projector and let them figure out how to get a basis

for the site started.

Those are the 2 people that really need to be there at the beginning.

Somebody has to get the architecture of the thing,

something functional built, the technical director,

and somebody who understands the content early in the process.

Those are the 2 that have to figure out how this stuff is going to actually live together,

so we put them together early.

They get something built that we can actually use

during our dev process, and then we do something called style prototypes,

and we run that in parallel with something called a content priority prototype.

These are both deliverables that happen in the browser for us,

so it's HTML, and it's some CSS, and they're separate at this point.

We try to make sure that deliverables we offer

that aren't intended to focus on design

look as ugly as they can,

because I've been in too many meetings with beautiful wireframes

where my clients are commenting about colors

or layout or something, and it's like, "Okay, let's just cut this stuff out."

We show pretty much unstyled HTML

in what is like a prototype but with real content,

as much real content in it as we can very early,

and we do that in a linear way

so that they can see priority.

The linear nature forces us to prioritize things.

And then at the same time, we're working on a style prototype,

which is like an evolution of style tiles from Samantha,

but it happens in the browser.

Just a basic, basic HTML page, no real content at all,

and it's really about typography, color, texture,

some of the core design principles that we have.

Our designers build those on their own.

If they need a little help, they'll work with somebody who is a specialist in CSS,

but we're trying to get them to build these on their own,

because they need to know CSS.

I mean, there is a big conversation. I don't want to open up that can of worms.

But I actually believe that it's very true if you're going to design

for the Web, you need to learn some CSS.

I think this is true too.

If you're going to write content for the Web, you should probably learn some HTML.

That's semantics, right?

Yeah, because you used to be able to get a job as a web designer

knowing just a few CSS, a little bit of CSS, a little bit of HTML.

Now it seems like the expectations are so much higher

with having to know HTML5, CSS3, LESS and SASS

and all this stuff, so what do you think

a web designer needs just to get into the door these days?

A web designer?

What does that even mean? [laughs]

I mean, do you think there is a bigger gulf now between

a front-end designer and then maybe someone who is a front-end developer

than there used to be, or do you still think that someone should wear both hats?

My technical director is Rob Harr,

and he keeps saying this thing in the office

where he says that SASS--or LESS I think is one of the more popular

first preprocessors, but he says, "These preprocessors for CSS

were like a gateway drug for front-end devs."

What he's trying to say is that this whole front-end development thing

has gotten so complex.

I feel like front-end devs who lean technically,

technical in their nature are shifting towards all of this complex

local build process stuff with running node and grunt

and all this stuff to get a really cool, easy-to-use front-end development.

Well, easy to use if you're a technical person,

a front-end development tool, or environment running.

But then you have designers who started maybe branding in print

and are trying to move into this space, and they're going to learn CSS.

They're going to learn some HTML. That's great.

But they're going to shy away from even using something like SASS,

if they have to install Ruby or use the command line.

Andy Clark goes on about this.

"Why is this a command line?"

"Make this easy for me to do."

He's got a really valid point, which is at some point

the tooling that we use for doing this stuff

is going to settle a little bit I hope,

and we'll start to see there are some clear winners

in terms of what you should be doing.

And then I think the people who are less technical

will be able to come into that and embrace it a bit easier.

So there still is a place for them to co-exist.

It's not like-->>Oh, yeah, absolutely.

What is the biggest mistake you see web designers making

when designing responsive websites?

Designers like to control things,

and if you're going to design for the Web, you have to let go of that.

That's probably the biggest thing is I talk to people all the time about this,

and they say, "Well, when do you actually design the site?"

"When do you design the site?"

And we still do a lot in Photoshop,

but it's becoming more like a sketch pad for us.

And the implementation of that is happening in the browser,

and that's where it needs to happen.

We're trying to get away from making pictures of websites

as so many people are saying these days and actually building sites themselves.

I don't know if that answers the question.

So you think designers maybe get too fixated on perfection

of every single pixel and then the type,

and then they get uncomfortable when they see it actually live in its environment.

We used to--oh, gosh, we were so ridiculous about this stuff.

My creative director, Jeremy Lloyd, is obsessed with type, typography.

He loves it.

He comes from a branding background, and he cares about this stuff.

And I can remember times where the type in Photoshop

looked beautiful, but as soon as we would move it to the Web,

obviously it's going to look different,

and then the client, we were showing static comps

that were exported from Photoshop,

so clients get an expectation about type and color

and how these things are going to look, and I can remember times

when we would literally move this stuff into the browser,

get the Web font rendering, do a screen cap of the type

in the browser and bring it back into Photoshop

so that we could show accurate web type.

That's ridiculous.

Why don't we just put it in the browser?

I think it's really about letting go of control.

That's the biggest thing that I see, because we've wasted so much time

making things perfect in Photoshop

knowing that they're never actually going to look like that.

It's just not realistic.

So as far as responsive images go,

there are a few things out there, like picture fill

and some great options but nothing really solidified or set in stone.

What do you think is the best solution right now?

Well, things are getting solidified.

I think the first draft is out for both picture and source set,

if I recall, very recently.

Those things are happening.

There are lots of heated dialogue still happening about those things,

and I think that in the end, that's going to be what we really need.

There are tons of solutions for this stuff, though.

There is everything from proxy-based solutions

where you've got Resrc It, R-E-S-R-C dot I-T,

which I haven't actually tried yet, but I know that it's similar

to some of the stuff Sentia was doing.

And what that does is basically you can modify the URL of your image,

so it's easy to implement,

but it does come along with some other interesting implications.

What happens is you're modifying it by changing a server,

putting a new server basically on the front of the URL.

Someone else gets the request, a different server.

They parse out your image, which is still in the URL,

take it to their server.

Also, they inspect user/agent stuff, so they're doing some device classification,

scaling that image, sending it back to you.

Performance concerns obviously.

You're dependent on someone else to solve that problem for you.

Maybe you don't want it to be set to the size of the resolution of the device.

But a very easy to use kind of solution.

You can also do that same kind of thing on your own server

with a little bit of htaccess and basically grabbing

any image type and doing the exact same kind of thing

but doing it on your box.

Actually, picturefill is a really good solution.

Scott has done a fantastic job with that,

and if you're going to implement it, I would say do something

where you in your CMS give the ability

to at some point in the future generate the actual picture syntax

when it's ready.

But it's very well tested.

People are using it with great success,

so I think that's a very valid solution right now.

There are all kinds of other crazy things that people are trying,

but in the end, I think we need a little bit better HTML element.

Yeah, definitely. They're working on it, right?

What do you think will be the major improvements

to responsive web design this year?

Well, I feel like some bigger organizations are finally starting to get on board

with some of this stuff, so some of the requests that we're getting

for 3 or 4 ROI case studies we'll finally start to have some of that data available,

which I think will only encourage more to do so.

I think there is going to be that move from some bigger companies,

some big e-commerce type stuff that's going to be happening this year I know,

so that's really exciting.

I talk about this a little bit, and I wrote an article called

"The Responsive Dip," and it's based on the idea of how

humans learn things, and you move through these 4 stages of learning,

and I feel like we are at a stage where we

are finally starting to actually understand that

we're not really doing this quite right.

We have to rethink a lot more of what we've done.

Sometimes you actually get worse at doing something

before you get better, but that's kind of the idea.

I think for us as an industry that's part of what's happening here.

In Jakob Nielsen's study not too long ago

where there was so much--and Josh Clark responded--

so many people wrote back about--

Jakob said based on data of testing,

mobile-specific sites versus responsive sites,

he found that the usability of the responsive sites was much worse,

and his recommendations were to do something like

build a mobile site, cut content, cut features,

and give them a link to a full site.

Obviously, many people in the industry said, "Wait a second."

"What are you talking about? That's a bad idea."

"You're making a lot of assumptions about context and all these things,"

which I agree with.

But I understand how Jakob arrived at the conclusion that he did,

and that's because we've built very non-performance sites

with lousy user experiences.

We're learning.

I think in some respects we've gotten worse at doing web design

by trying to figure this stuff out.

But we're going to come out of that dip of learning,

and we're going to be, I think, in a much better place.

We're starting to see some sites come out that are demonstrating

that this stuff can really work, so I think this is going to be the year

where we start to see some really creative responsive type solutions,

and we start to see real organizational change,

which is required to invite this kind of process to happen,

at a bigger company in particular.

I think there is so much happening there,

and so for me, the future of this stuff, at least for the next year

of what I see, it's really more about the hardest stuff to figure out,

which is not the technical stuff.

It's the politics of the organization that has to adjust.

That's the hard stuff.

All the people who build sites, they see this stuff,

and it's obvious.

This makes sense. This is how it should be.

We're finally embracing the fluid nature of our medium.

But it's the people who aren't as technical

but who are making money decisions, financial decisions

in an organization and have to say, "Yes, it's okay

"for you all to sit together in the same room

"and for me to not know exactly how long this is going to take

the first couple times you do it."

That's a hard decision for a financial person to make,

business person.

Well, I think that's a great place to wrap it up,

with the future of responsive web.

Where can they keep up with your work and keep up with you?

The Sparkbox website, SeeSparkbox.com,

and on Twitter, just BenCallahan, all 1 word.

I have BenCallahan.com if you want to see

where I'm going to be speaking or what I'm writing about,

those kinds of things, and then the Build Responsively

workshop is coming around, so try to find one of those,

and we'd love to meet you guys there.

Cool. Well, thank you for joining us today.

My pleasure.>>Until next time.

Thanks for watching.

[Treehouse Friends]