RWD Podcast #35 : Nick Schaden

Justin Avery: Hey, everyone. Welcome to episode number 35 of the Responsive Design podcast. My name is Justin Avery and I’m your host and curator of the Responsive Design Weekly newsletter. It’s a weekly newsletter all about, you guessed
it, responsive design. This week the podcast is brought to you by Media Temple, so thank you, Media Temple.

It’s mediatemple.net. They’re a web hosting company who incidentally provide the hosting
for Responsive Design Weekly as well as another out of the bunch of sites that I run on the side as well. I’ve got one for my little boy who have just started uploading images and videos, so hopefully he’ll be able to see them in the long future.

I’m relying on Media Temple strongly there. They’ve got a huge range of different
entry points as well, so whether you just need a single WordPress blog or a full stack development box, they’ve definitely got something for you. You can check out their new WordPress hosting product as well and I think they will have just launched their Google apps for work.

We’ve got a special discount rate for all of you listeners. If you use the promo code, RD25,
you’ll get 25% off your web hosting. Go to mediatemple.net, enter your promo code so they know that we’ve sent you and sign up there.

Now, before we get started as well, I just wanted to say a big thanks to whoever the listeners
were that may have nominated us for Podcast of the Year with the Net Magazine, the Net Awards, so we made the long, long list which is awesome. There’s a whole bunch of really awes. The only awesome podcast that’s not on there is the ShopTalk show because they won last year and you can’t win 2 years
in a row.

There’s some fantastic people there, so just to be up against those guys is a really, really
kind of humbling thing and I just wanted to say thank you for those people out there that did vote. If you want to see this go a little bit further, please head along to the netawards.com, check out the podcast section and vote for this one.

Ethan and Karen’s responsive design podcast is up there as well and they’re awesome, so
you can only vote for one. You should vote for this one, but I’ll understand if you vote for another one because there’s some pretty good ones there. There’s a whole bunch of stuff too, Side Project of the Year, Game Changer of the Year, Talk of the Year.

There’s some really cool stuff so it’s your chance to get involved and say thank you to
some of the peers out there that you love and respect. That’s enough for the start. Let’s turn our focus towards our guest for this week, and I’d like to welcome Nick Schaden to the show. Welcome, Nick.

Nick Schaden: Hi, there.

Justin Avery: How are you doing?

Nick Schaden: Pretty good, pretty good.

Justin Avery: Excellent. Now, I’m sitting in a kind of warm London. Whereabouts are you dialing in from today?

Nick Schaden: I’m dialing in from a fairly cold day here in the Lower East Side in New York City.

Justin Avery: Nice. You’d do with some cold … I’ve spent all winter just wishing for hot weather and now the … It doesn’t seem to be … London doesn’t seem to be sorted for hot weather. It just struggles.

Nick Schaden: Yeah. I know. It’s actually this time of year here in New York City, I mean, it’s cold comparatively, right, but I’m very much looking forward to it because I’m sure in about 2 to 3 weeks, the summer will hit in,
in full stride here in New York and then we’ll be a bit humid, high humidity, 80 degrees. Actually, all things considered a colder day at this time of year. It’s pretty nice in New York City.

Justin Avery: I do like it. I’ve only been to New York once and I really loved it, I really liked it. It was on a holiday. I didn’t have to go for work which was good. Now, but for those who … I haven’t even mentioned where you’re
working or your history so I’ll let you take that away. For those that haven’t heard of you, can you just give a little bit of background of how you got into the web and some places that you worked and where you are today?

Nick Schaden: Sure, yeah. I’ve always done pretty much web related projects, both technical and design related. Since I was mostly a teenager, playing around with the internet, especially in the ’90s, it was fun, and in addition to that,
I really did it professionally. Actually, a little bit later in my career, I actually started out post-college, always in technology, but I actually worked in finance technology and I worked primarily on trading applications.

You sit on a trading floor. It’s very much the front end of those things, so you’re dealing
with user interfaces and kind of hardcore old school C++ and Java and this kind of thing. It was really fun. I really enjoyed it, but then after a few years, I had always the web side of me kind of grew, and grew, and grew and I realized that I think longer-term it’s what I really loved.

I wanted a change of pace. That brought me to the web side full-time and I’ve been doing
that since, what year, since about 2007. It’s been about what, 8 or 9 years at this point and I’ve worked for a few different eclectic sets of companies. I actually started out at Gucci. I worked on their e-commerce platform and their e-commerce team.

I was there for about 3 1/2 years. Again, really interesting culture, 180 degrees from what
you see in finance, which is actually, it was great. It’s really fun to do. I was there for t3 1/2 years which led to one of the redesigns of their e-commerce site in 2010.

After that, I went on to a few other companies. One of which was Animoto more recently.
They’re actually a video start-up located here in New York City, and currently today I’m actually working for Pocket which is a save for later service, pretty popular that’s based out of San Francisco, even though I work full-time in New York City and then I just commute there a few times a year.

Justin Avery: Nice. I originally came across … I used Instapaper which is kind of competitor. I imagine a competitor or someone in the same space and then I started using Pocket because it just seemed like a kind of nicer interface
and then I realized that I had the web app side of it as well, and I was like, “Oh, this is kind of a cool responsive web app. I wonder who’s in charge of it?” Then so I got in touch with Nick and reached out.

Nick Schaden: Cool. The responsive side of Pocket was a long-time company. I’ve been at Pocket for now almost 2 years and basically we’re a very small team. We have currently, I believe, counting them now, I think we have 17 employees
right now, full-time. Of that, in terms of, especially on the web development side, I’m pretty much the primary contact for that.

When you first drop into a startup, there’s so many things you’re trying to do of course
to stand up various processes, redesign different … redevelop different parts of the site and the timing, there’s always something else that’s pressing given that we’re trying to focus on growth or other activities.

We had a master plan of really mostly redesigning and then re-architecting for a response
of … most of the rest of the site first because of its lack of overall complexity and then we just had to find the right window for where to make the web app itself responsive.

I think it was a good time and place because in the last year, I’m sure like a lot of sets,
when we look at our own analytics, the amount of traffic we’re getting from mobile users. The amount of feedback we’re getting for people who use our web app on the opposite side ironically.

They’re like, “Hey, I’ve got a 27-inch display. Why can’t I get a bit more information on
there?” or everyone in between, from Tablet users. A lot of Windows phone users or service users where we were getting feedback from, “Hey, when are you guys going to have some sort of a really good first-class, first parking experience for Pocket?”

It came together especially late last year is when it really started gelling together technically
wise and then it took us through a lot of the gain part of this year and then we launched a few months ago. There were a lot hard work from a lot of people on this, on our team.

Justin Avery: Awesome. Prior to that, where you … when someone would hit the sites just redirecting them to please log in or please download the iOS app or the Android app?

Nick Schaden: You’re saying like if you were a mobile user, correct?

Justin Avery: Yeah.

Nick Schaden: Well, not to overhype the company here but we do have a lot of really great experiences on our native applications as well. We have a really, really gifted iOS and Android developer and designers behind all that. We have
really good … What we think are really good experiences for that.

If you came to, as you said, getpocket.com and you logged in, you would effectively hit
a page which should be like download the app kind of a thing. That was the before and then now with the web app, we just take you directly in.

We do a bit of device sniffing in this case to, of course, if we think you are on a native
device and you’re a new user, we do give you a bit of a nag just once to say, “Hey, by the way, we do have native apps as well,” and then go from there.

Justin Avery: Nice. I just went through it and I figure out I’d logged in before so I need to log out and check that out and see how it goes through. Before you would have been … you got into the web in 2007 and then to
Gucci. You said you re-launched the gucci.com site while you where there, the new e-commerce stuff.

Now, that would have been about the time that Ethan was pinning his article about responsive
design. Was it something that hit while you were at Gucci or?

Nick Schaden: I remember distinctly reading, so our launch process was basically leads. It was most of 2010. When it really comes down to it, if I think of the entire logistics from day 1 kick off to launch day, it was a little bit short
of a year actually because one thing about a company of that size is you’re involving … There’s a lot of people being involved both design and development wise.

There’s quite a few steps to go through to make sure that everything is working from
back to front. I’m just thinking here, so 2010, I’m trying to remember when you can pin that article on a list of part but I do remember reading it. We had heard of it. I mean obviously when we were on a development standpoint, when we’re putting the site together we were not really
factoring this thing at all.

I mean, if anything, I would say from a responsive angle that really approached us late,
was actually the iPad interestingly enough. In particular, when we really figured out and worked together as a team on the design and developments, we were considering basically 100% desktops.

The notion of even saying developing something that would work well on a phone was too significantly
different from the core design at the time to focus on. At least given our team size or budget and our goal, but one thing that kind of almost fell out of the air was once Steve Jobs announced the iPad and then put it out there.

I remember very distinctly that day that we were hearing all the rumors on Mac rumors like
here’s the official width and height of the web ports on the iPad and we’re like, “Oh my God, well, this might actually work for a website,” kind of thing. It’s the kind of thing where it was myself and other developer and a really good designer.

We really didn’t know what we were doing but we were kind of like you’re doing
things like hacking in really weird CSS media query requests and then kind of like, “You know what, I think they’re going to be using their thumb here so let’s make the hit target like triple the size and then just see what happens.”

You’re writing your own like really web 1.0 swipe event listeners. You’re like
I don’t know. I think if I do touch start until end 400 pixels, they’ll be good. It was a bit of a crapshoot. It was functional, and I think there’s a lot of pressure up top like, “Oh, we want to get this,” say this works on the iPad. That was about the extent of responsive web
design in 2010 for me.

Justin Avery: When you moved to Animoto, Animoto?

Nick Schaden: Animoto, yeah.

Justin Avery: What were you doing? What was your responsibilities at that company?

Nick Schaden: I was part of a … I believe a usually oscillating number between 4 to 6-man web team. Actually, it was really interesting because almost every company I’d been in has been even a different experience from a
team standpoint. Gucci, it was I’d say about 6 people and then we had an aim where we fluctuated between 2 to 4 developers and designers on the frontend team.

That was very much the dynamic of mostly very senior print designers and then working with
them moving to a more digital environment. Animoto was almost the opposite where it’s a very engineering focused culture. These are people that are dyed-in-the-wool, hardcore technical people, they’re video people.

I work with some very, very smart people especially on the backend, for things like algorithms,
video compression, speed, performance. At Animoto it was a 5-man team. They’re all actually, frankly pretty senior in our role. There was maybe 1 or 2 junior people. What we did is I think it was really interesting experience because we were all hired for primarily different specialties.

For example, my coworker there also by the name of Justin, he was a guy who came from meet-up,
genius on the backend and on speed and performance. He was the smartest guy I’ve probably have still ever worked with on that. The main reason I was hired is where I tend to have focus lately, which I was known for especially at Gucci, was much more on the bleeding front end architecture.

Again, by the time I dropped into Animoto, the notion of responsive web design was becoming
a really big deal because one of the reasons … I don’t want to say one of the reasons I was hired but a big task that I was hired with early on was Animoto did not have much of a responsive … It had a very cursory responsive design especially its external side.

Much as I said with Pocket, the numbers of mobile users were effectively doubling, I believe,
at least from what I recall almost every year. In terms of what I worked on, it was a mix. Animoto is actually also a video-based HTML app as well. I did work quite a bit on that, just doing various, especially, mostly frontend UX, UI related activities.

[focusing on] what’s called the first user experience like, “Hey, I’ve never heard of Animoto.” You type in the web address or you go and inbound link. What’s the experience like both on the design side and especially on the development side?

Also a big part of what I did was again, much like with Gucci was taking, especially what’s
called the first user experience like, “Hey, I’ve never heard of Animoto.” You type in the web address or you go and inbound link. What’s the experience like both on the design side and especially on the development side?

A big part of my role was trying to architect as much as I could of Animoto especially the
external phasing pages that were popular and making them very friendly on mobile and very responsive from an architectural standpoint.

Justin Avery: Animoto itself because it was all about the video, and like you said people who are producing video, they’re all about the speed and the compression, do they bring that ethos to the website? You said this other fantastically
name, Justin, was big on performances stuff as well. Was it a culture at Animoto that was all about the performance?

Nick Schaden: I’d say it came from … Again, that’s why I say the yin and yang experience that I had between the 2 companies. You take a company like Gucci which is incredibly smart especially like a visual or aesthetic
standpoint. They have very, very gifted especially print designers. They don’t come at least from my group.

They don’t come from as much of a traditional software development or engineering
culture. Animoto was very much the opposite. I came in and everyone is holding. We have a very much scramble like system. We have stand ups every day. We have a roll-out. We believe in continuous deployment. Performance is key.

I’m sure we all have in our career, it was very much a learning experience for me
especially. We definitely focus on Gucci but I learn so much when I was at Animoto about trying to make a faster, more usable experience especially for first time users.

Justin Avery: You were saying the Animoto app, I know you’re not there anymore and I don’t know how [inaudible 00:16:58]. The app was a HTML wrapper, a web view within?

Nick Schaden: It was 2-part. In the context of mobile, we never … At least from the time when I was there, we never fully got around, for example, focusing on a responsive version of the web for mobile specifically. The reason
why was I think much like you alluded to earlier, in terms of performance for on demand video.

I mean if we’ll talk about the whole native versus web to dates sort of thing but
one thing I will say about that is hey, I’m a big believer in the proponent of the web. Frankly, there are certain applications which I think especially when performance is key, things like streaming video, things like video editing.

I mean on a new iPhone or iPad, I mean there’s just going to be a more demonstrably
better experience with the native application in that context right given the tools out there. Given that as a priority, most of the mobile stuff was handled by our native developers and designers. If you were on a desktop though, the focus was not a native like it wasn’t, say a slack-like experience.

As you said, as you’re alluding to the native markup with a wrapper around a web page,
it was just the web page. You use that for basically creating these … I mean, again, what Animoto … To back up for a minute, Animoto really specializes and are effectively, you upload a series of photos. It makes this almost like music video, greeting card or whatever you would send to
other people.

A lot of families use it, photographers, things like that. It’s not like, say, you’re
doing a final cut on the webpage. It’s definitely nothing like that. It’s meant to be a very user-friendly, novice-like experience where you almost you’re rearranging. Think of them as a keynote experience, rearranging slides but they’re pictures. Then pressing a button and then
previewing that on the web.

Justin Avery: Do you think the web will inherently always lack the ability to compete on that level of things or are there certain elements of the web that … and browsers, I suppose more to the point that they need to come up
and bridge the gap a little bit like what’s missing from making that experience perfect just in the web instead of having to go native?

Nick Schaden: That’s a great question. I wonder about that a lot. I think that if we step back from it, I’m just trying to think of like where I’m excited about some of the innovation on the web. I think that in many
ways a lot of it at least especially where … I don’t want to say mine especially but a lot of my focus again, things like UX and layouts and interfaces.

You look at little things like Flexbox. Small thing but has made a world of difference here
at Pocket and at other companies I’ve worked at or done work for. I think of things even things like web components and things of that. It’s the kind of thing that I feel like I’m trying to reflect in your question a little bit in terms of view.

I guess the short answer is, there are … I don’t want to just say, blatantly
like “Oh, if you’re doing a game or hey, man. If you’re doing a video app, don’t waste your time with the web. It’s horrible for that.” I mean, you don’t want to be too dismissive. I look the overall as the web’s advantage is that kind of umbrella, it’s
that accessibility to all people.

I think that if we focus more on that and focus on the UI side in making that as fast as
possible and as successful as possible, that’s the number 1 goal. I think that if we try to emulate … I mean I’m sorry to go off on a small tangent here but in terms of … Look at the controversy that I think embroiled Flipboard recently with their …

Justin Avery: With the canvass approach.

Nick Schaden: Exactly, the canvass approach. Now, again, I don’t want to necessarily say one way or the other of is that good, is that bad, is that emulating the web, are we throwing away markup for the wrong reasons, da, da, da.
Go ahead.

Justin Avery: Do you that in your mind but for the listeners that weren’t aware …

Nick Schaden: Sorry about that.

Justin Avery: No. That’s why I always do this. I just go off in a tangent and forget to explain thinking everyone is completely across it. What Flipboard were looking at, they wanted these nice, beautiful, quick, slick animations
that you would normally get native but what concerns that the web wouldn’t be able to keep up to the 60 frames a second which is the point which you or I can tell that something is a little bit not quite smooth.

Because of that, they decided to create their interface within the canvass element because
they were able to hit the performance target and the UI and the gestures they were after. It mean that they were just putting out a canvass body, an angular art, just body tags and then that’s it. There’s no full back for that at all. It’s that the gist of it?

Nick Schaden: I agree.

Justin Avery: Yeah?

Nick Schaden: Yeah, I think that’s very well put there. I guess what I thought about during the debate either pro or con whether that was a good approach, it just struck me that the debate … I felt like the debate was maybe
a little bit on slightly the wrong subject in the sense of that the obsession was on the 60 frames per second and about hitting that number.

I know some very prominent bloggers, especially those that are extremely pro-native, I guess
you could say were like if you don’t hit 60 frames a second, it’s over. User experience is over. You won’t waste your time there. I just thought that well, I think it’s a nice achievement in many ways.

It’s at the same time not necessarily priority one depending where you’re going
with that. I think it’s a fair goal but I guess back to your original question of native versus web, I feel like the goal for web shouldn’t be to necessarily chase native. We’re saying if it’s a head-to-head comparison against a native app, we have to beat them 100% in time exactly
what a native app does.

I think that part of, again, the advantage of the web is it’s reach, is it’s
cross platform compatibility, is how fast it is to get things out. Again, like if we focus so much on the 60 frames per second for the animation which again, I think is important for a general, hey, you want to have fast animations, right?

Well, I guess the side question is if we focus so much on that question, are we answering
the question of how long does it take for your page to load? Again, I go back to that question, what is the first user experience like? If you have a wonderful framework that is crazy fast animations but it takes your site an extra 2 or 3 seconds to load, what decisions are we making for the user then?

It’s not necessarily right or wrong but don’t focus on just that one answer
of the 60 frames a second. There’s a more complex or holistic answer I think around it.

Justin Avery: Absolutely. Not just how long does it take to load and stuff but the benefit that apps have as well. There’s a colleague I worked with yesterday asked me he uses a windows tablet and he said to me with your iPad,
do you have a lot of junk data files just kicking around.

Will Apple hide that with the iOS? You can’t really tell unless you go in and have
a look at the application usage. He was saying on his windows tablet there was just hundreds. He cleared it out. He got back about 4.7 GB worth of data files.

I just think the leisure that native apps sometimes have is that they can load in all of
these additional data storage on the device whereas the web, we have a lot more limited capabilities of that. Also we didn’t want to do that. You don’t want to use someone’s data plan out there and just store all these strenuous stuff in cash just in case you need it one day.

Nick Schaden: I think it was a recent discussion on the ShopTalk show. Not to mention or broadcast it here.

Justin Avery: Great podcast. Go to shoptalkshow.com. Go and listen.

Nick Schaden: Css-tricks.com, it’s a wonderful resource, I will say too. Recent discussion with I believe a representative there from … I forgot his name but he was from … He worked on the Chrome team, from Google
of course.

Justin Avery: Paul Kinlan?

Nick Schaden: It might have been Paul Kinlan. It might have been, yes. I think that rings a bell. He was talking about how recently I believe in one of the most recent Chrome releases. They pushed out effectively mobile notifications
at least on Native Android devices, right?

I think what he touched on as you said the storage issue that does ring up this thing where,
I mean, that is the traditional weakness of websites too. You’re literally incased in the browser. You can’t go outside of it. You can’t use a lot of the native hardware that of course the native app can use.

To me I thought that was a really smart step in the right direction like for something like
notifications where it’s again, just small step. It’s simple to understand from an API standpoint. If you’re a developer in the web, if you look at again the way that Chrome has done it, I think it’s pretty shrewd in terms of its implementation.

It’s also though it’s very necessary. I mean, I talked to many people who they’ve
worked with their companies and like, “You know what, Nick, we love it. It’s a really simple thing, but on the ends, we need something on a home screen and it had to have notifications so we couldn’t do a web version?

Everything else was great but that was the one thing we couldn’t do. I thought, oh
man. Again, there’s a few things like notifications that I think can really what’s called level the playing fields architecturally for websites versus the traditional native experience.

Justin Avery: The home screen is another big one as well. I think in that episode, he talked about that as well where they haven’t the API app to allow you to just offer adding to the home screen but if someone visits the website,
several times over a period of time. They know what the algorithm is. Then they will offer it the same way.

You’ve been using this a bit, would you like to drop this down. The web workers for
the notifications and offline stuff it’s all very exciting. Actually do you do much work with offline?

Nick Schaden: We do a little bit. I’ve done quite a few side products with it in anticipation, mostly on the side little websites here and there. I used it for this little weather web app that I did. I think it still might be on
the website. I’m not sure if you go ahead to my homepage.

Justin Avery: Send it through [crosstalk 00:27:46].

Nick Schaden: I’ll send it through, sure. I mean, it is something that … I mean, it’s kind of unveil the curtain. It’s definitely the next big frontier that I would love to look at in terms of Pocket’s
web app experience. It definitely wasn’t the first priority I would say. The notion being well, the average web users is still probably on desktop and probably connected to the internet.

One of the things that Pocket very strongly believes and I think it’s a great thing
is that you should have access to your Pocket list or save for later list, really anywhere, in any condition. Obviously, especially if we’re purporting this as something as effectively great first run experience for users.

We want to make sure that if you’re on, let’s say you log in to a Windows phone
or whatever, maybe we don’t have quite a native app for you, you go in the subway, we want to be able to basically catch the experience. It’s definitely something that happened that worked in as much now but is probably on the top of my list to grow my skills in.

Justin Avery: It would be a good thing because I know … I’ve recently took a trip back to Australia and I was queuing up my Pocket reading list for the plane. I admit, I had to do a quick search to see if you actually do
videos because there are a couple of videos I wanted to watch but that would take up the storage. It’s actually not possible is it?

Nick Schaden: No. I think, I believe, no. Just think offhand, we do not save entire of it. Part of it is stored. We keep it really mean to means, basically it’s links, it’s parsed articles. Also, I think frankly there’s
a bit of a … It might be a bit of a copyright issue too if you’re like hey, save this YouTube video.

Justin Avery: Don’t worry about the ads that they put through there, the pre-rolls, absolutely. While I was doing that, when I was on the plain, I opened up my laptop to do some work on a local server, on a WordPress site and I
was like I had a Pocket article which I wanted to reference and I had it on the iPad. I was like it would be cool if I could just call this up and it would be there and ready.

Nick Schaden: I think as you pointed out too, it’s not just for offline. There’s performance implication too, as we talked about before. Every day when I look at that, at the web app that we have at Pocket … Not every
day, it’s a little bit obsessive. Let’s say, every week or every other week. I’m thinking like how can we make that load faster? If you cut off half a second for a new user, possibilities are just wide open if they find it faster.

Justin Avery: On that point, what other things that you’re doing with the web app to improve performance and to get the most out of it. It is one thing that comes up quite a bit and people send through emails and tweets and stuff.
It’s just they want a faster performing website. They can send and they want to know the latest tips and techniques and tricks and what other people are doing.

Nick Schaden: One thing that we have done is … Of course, one of the first things we try to do was just prune … When I first came there, we know a lot of the things before we even moved to more of a responsive base was
just cleaning a lot of just CSS and JavaScript we didn’t even use. I know it sounds like a very simple non-technical answer to start with but doing that I think in just recalling here, the first time I got here, we cut down our entire load weight of the JavaScript and the CSS by, I’d say
anywhere from 30 to 40%.

It’s the kind of thing where you work on it and you’re in a small company. You
always have the pressure to add. You never had the pressure to subtract. We all are there. I think I had a period where my boss was fortunate enough to be like, “Hey, man. Here’s a week. Why don’t you just go and start cleaning this stuff up.”

It was a huge saver there. That footprint was big. I’d say the other 2 things just
thinking off hand is that from where we started and where we are now is we’ve leaned very heavily on task runners which have made a really demonstrative difference too. I started with more of a Grunt fan.

Now, we’re pretty heavily invested in gold at Pocket. It’s the kind of things
where it’s step 1 was like. Obviously when you automated these things, instead of the one-offs of like I’m adding a JavaScript file and I forgot to minify this, it’s all there. It’s attributably added. In terms of general packaged performance for the user, everyone is in the same
page whether it’s me or someone else working on the code base. That’s step 1.

You had things like image compression algorithms, step 2. Just things that can be little
things where you wouldn’t think of it where we’re busy, we have a new landing page that went up. Someone from production knocked out a file. They accidentally saved it as a 100% resolution JPEG. The next thing you know we’re in trouble, right?

Little things like that, that a Gulp runner can really make a difference. I would say, 3rd
and potentially most significantly is at least for the web app and we actually are in the process of doing this too for the website. It’s going to be coming hopefully in the near future. We’ve moved the entire code base from the web app from traditional Vanilla CSS to a Sass base.

Let’s not get too wonky here but we do use LibSass via Gulp, just ran that Gulp, SASS
to pick that out regularly via build script. It’s great. It’s the kind of thing where the thing I almost regret not doing it earlier with a web app because it’s not just the consistency argument or the many other benefits of using any preprocessor, Sass, LESS, whatever.

We actually, ironically save a lot of space because you’re using a mix and you realize
how many times before you might have written that bond or whatever. I think we honestly say 20% of our CSS base which is pretty big for the web app just from that conversion which was awesome.

Justin Avery: Have you delved into any of the outside of the building process? I want to go back to the build process and the article that you recently wrote as well but the actual implementation itself, so the scripts in the header,
JavaScript, lazy loading of things.

I recently caught Scott Jehl in Dusseldorf, Beyond Tellerrand conference which is an amazing
conference if anyone gets a chance to go there in Berlin in November, a huge plug for that. He was talking about that whole critical CSS learning the fun stuff afterwards. Do you take any of that into consideration when you’re building?

Nick Schaden: Certainly. I mean, I think regarding that, we do use, for example, we use Modernizr. We use a simple YepNope for a few … This is just, I will say phase 1. Right now, the number goal is getting everything minified
using best practices for when it loads, just a step 1 in 1 big file.

Step 2, where we are live on the web app and the website is a bit of a hybrid approach.
We have I’d say about 3 or 4 especially large JavaScript in CSS files. They are located basically using YepNope via Modernizr. They are differed and only loaded for select users. The case of the web app there, the touch users, things like touch libraries, extra changes for them.

We are starting down that path but per that point, I mean, yes, I would love to explore.
The 2 biggest hits we get especially on the web app from a performance standpoint are the obviously the initial load with all the Chrome. As you mentioned, Scott Jehl, in terms of … Obviously he’s Filament Group, right?

Justin Avery: Yeah.

Nick Schaden: We’re a huge fan. I mean, I’m a huge fan in his work. His work of course with responsive imagery and Picturefill has been life changing for even us at Pocket. I mean that’s going again on a switching subject
here but the before approach when we were trying to think of “clean way” to handle responsive imagery and then the after end using that design library.

I know we’d spend updates, got even better. It’s been amazing. It’s the
difference between either designing you’re going to pass on responsive imagery temporarily and then just being like hey, we have confidence in this. Let’s do this. Let’s do this for some critical assets.

Justin Avery: Before you go back, it’s really interesting. I was speaking to someone who launched a web app the other day which was a portfolio application so artists can go on there, kind of a square space but really dedicated
to artists’ portfolio, because it’s very heavily image based. I had a look and they had … It was like query strings in the URL to produce a certain size image and that’s fine.

They were just image pegs and I questioned and said is there any reason you’re not
going for a responsive image solution? The reply was that the technical director wanted to wait until it was embedded in every single browser and accepted before they would include it into the product.

I thought it was just really bizarre but interesting. I can see why you wouldn’t approach
it but also it’s the web and why not just polyfill it and most people do support it.

Nick Schaden: I want to almost apologize for that laugh there because I was going to say that the funny thing is I think when you ever enter any organization, also it’s just as dangerous. You want to move forward. Everyone probably
listening for the most part believes in notions of progressive enhancement and not every site has looked the same in every browser, yadi, yada.

At the same time, I think you have to come into every organization to be a bit humble without
knowing your user first. I think it’s something that I learned both good and the hard way starting my career web wise. You go and you’re like, Hey, man. Learn this new technique, let’s kick it out there.

Look at your user analytics, who are your users. Even at Pocket, Pocket versus Gucci. Gucci,
we’re supporting corporate clients during lunch, browsing the website to buy expensive handbags on IE6. At pocket we have a lot on the flipside very cutting edge users who have the newest browsers, the latest stuff.

There’s no 1 right answer. You have to take it from there but then going back to your
point about responsive imagery. I’ve spoken to a few when I teach a bit at this company general assembly here in the Flatiron District, here in New York. I talk to a lot of student … both students and a lot of them are in the workforce.

They’re much like you were pointing out there, people that are part startups that
have big web components of their companies. I get questions on imagery a lot and it’s much like you said, it’s the notion of well, it feels really junky and experimental. I don’t want to take that stuff forward.

The first thing I always tell them is like aside from the whole picture on it, the fact
that you won’t even include was SourceSet. SourceSet, I always don’t know how to pronounce it.

Justin Avery: SourceSet is good.

Nick Schaden: SourceSet, cool. Something like that … and again, every company is different. Everyone has different involvement but especially if you’re handwriting an image tech and you’re not thinking of including
SourceSet in just doing the 1X, 2X base flow for your users. It’s like come on, man. Was it Firefox, Chrome, I could pull, can I use? I mean, it’s getting there.

It’s going to spread everywhere. I feel like there’s … I don’t
want to say no excuse but you should be any sort of especially redesign or a new site, you should be thinking that from day 1.

Justin Avery: What always gets that far is to say there is no excuse because I mean, what happens if the browser doesn’t support it. HTML is so forgiving. It just ignores. It’s like I don’t understand that.

Nick Schaden: Exactly.

Justin Avery: I’m just going to put the image in there like you said other than what this source that you’ve made a mistake here. I wanted to break the page and start rendering. I’m just going to keep going. I’m
with you. The only thing I ever had a problem with has in the Picturefill.

I don’t know if it’s been fixed now but if you ran Picturefill and you also had your
image tagged there, it would download the source. If the browser didn’t support SourceSet, the Picturefill would fill that and download the SourceSet image as well, so you’d get this double download.

Nick Schaden: I believe in their release nodes, if you look on GitHub, for Picturefill. I think they had mention that. There are definitely … Hey, we even saw that when we implemented it. We have it with Pocket. There were a few
cases where by using the SourceSet attribute in a context of a picture, we would see that problem.

We ran to it. You’re right. There are those risks especially with the polyfill. I
don’t know want to say have a blanket rule but I feel like people can, at least as you pointed out at least wait into the waters and not just say, “Oh, I don’t have to worry about this yet,” or worst of all just say, “Let’s load a 2X image for everybody.”

Justin Avery: That was the full back for these. It’s just like well, it’s a portfolio so let’s just load the biggest image because we want it to be beautiful which I can see that it’s interesting. You were talking
about the general assembly stuff that you were teaching. Are there any other things that you noticed students or people are new to responsive design that they struggle with. You mentioned the images, are there other things which they started to grasp?

Nick Schaden: Well, imagery is an interesting topic. I mean, staying on that for a minute. I mean, usually I teach and it’s a 1 day workshop class. It’s really meant for pretty much complete beginners, mainly people that
you have to have some basic HTML CSS but it’s not all meant to be technical of a class even we do have a code.

When we talk about imagery, it’s almost like I usually save it for the end. I should
actually change this now because I still find it on the parts, let’s call it the responsive world. I feel imagery is still the one that’s changing. When even look right at the, what is it? SourceSet with sizes recently changed. Slightly its speck a little bit. They have both to …

Justin Avery: You had to declare. I think originally, Eric Porter said, you could leave off the last 100 viewport because it was just default to it and now you should specify it.

Nick Schaden: Part of it is waving through those wires. I’d say to answer your question more directly on the imagery, honestly, the biggest thing I get feedback on is the surprise of how it involves everyone else. I want to say
we’re deep in the weeds. We’ve got some technical talks which is good but on a completely non-technical side, they’re so surprised on how much they’re flow changes as a company.

I’ll get a designer and they’ll be like, “Oh, okay, wait, so there’s
more than just like this one bit of code we have to put in here? Wait, we have to like oh …” You know what I mean? Again, I’m not trying to imply some naivety here but part of it is just learning a new process and that it’s touching multiple people.

Business people have to think about QA, has to approach it differently and it’s not
just a bit of code. I think it’s a very transformative experience for a lot of companies. I think that’s in many ways the eye opening experience that a lot of my students have. That’s it. It’s like this is involving more than just me here.

Justin Avery: How do you go about that? I imagine you would have a close to perfect process. For the sake of being recorded, it is a perfect process at Pocket. What would be whether it is the process that you have inside at Pocket or
what would your ideal workflow be for building a responsive site?

Nick Schaden: The collaboration I think is the keyword? You can do down the road of agile and Scrum and Holacracy and there’s a lot of other buzz words you could use for that. I think champion some ways the spirit of that. I think
one of the biggest issues that I see on both good and bad for companies is specifically the relationship between designers and developers, and the communication between them.

My personal flow, like again, when I … As you mentioned back, say the Gucci days
were like we had a fixed website. You definitely need a lot of interaction and I think always having tight communication is always a benefit between both parties. Especially for a responsive website, if you don’t communicate often and early, you can really get into trouble.

I think even what we’ve both touched on earlier, little things like image formats,
little things like I have Explorer 2X version 2. Then things like wait, we’re using a responsive grid column. How does that work again? I thought if I’m on the iPhone, I can move this thing over here. Again, anything that’s technically possible but if you want to make things faster,
it’s just really breaking down barriers between both sides.

Justin Avery: That’s good advice. On the fast thing, you were talking about the build tools that you were using and Gulp specifically. I’ve recently seen people incorporating performance budgets, say, Tim Kadlec, fantastic
person. He’s just taken up a job with [inaudible 00:46:11] perhaps or was for the performance stuff.

Now, he wrote at a Grunt plug-in which was based on a performance budget where you could
include some performance metrics that would then output as an error while it was doing a build script. I’ve also seen people do similar things but then also push out to something like SpeedCurve or site, speed.io.

You can monitor your performance, your frontend performance specifically overtime with your
continuous integration and stuff. Have you looked in to that at all or have any thoughts around the approach?

Nick Schaden: We definitely have explored it. I actually have a side branch. Probably if I looked back in my pin board archive, I could find or Pocket archive, I could find exactly where that came up. There was definitely, I think in
my case it was a Gulp script that pings it was a YSLow or web page test to go write and gave you the basic performance.

It was the kind of thing where I definitely had a side branch in that because I mean you
do bring up the continuous deployment. It’s definitely something that we’re striving always for at Pocket. Especially, honestly as we grow as a company. We’re small now but invariably I think we’re going to grow in terms of hiring people. We’re actually going to hire now,
just a small plug thrown out there.

Justin Avery: Where can people find this?

Nick Schaden: If you go to getpocket.com/jobs. In fact I’m going to double check that just to make sure. I’m pretty certain that’s it. Let me just make sure here. Exactly, getpocket.com/jobs, we actually have quite
a few positions that we’re looking for.

Justin Avery: Nice. Remotes as well?

Nick Schaden: It depends on the position. Some positions are looking for San Francisco based and some are not. [Inaudible 00:48:10] but I’m working with some really great people and really smart people, really, really great developers,
designers and a really good team. Then back to your earlier question, it’s definitely a factor.

It’s the kind of thing where if we talked about our Gulp process in general, I think
at first we did the basics of just minification, library load, sizing. We’ve now integrated recently sprites. We still use slightly old school 1X, 2X PNGs for a lot of our iconography via sprite. We got that.

Justin Avery: With the big guide, SVG and all?

Nick Schaden: Yes, definitely. I have this somebody list of always like hey, I’m the focused user. I have this huge list of here’s what I like to do. One thing I’m experimenting with is things like PhantomJS and doing
snap shots. It’s minor and again, it’s very limited. I don’t want to say we‘re one of the shops that can just basically have a dashboard where you can get an alert on slackers or something if something goes down.

We’re getting there. We’re such a small team. The more we can automate, the
better the process. I’m sorry, I feel like I’m drifting too much away from your original question which was on a performance side will you not use it now. We are definitely looking more into that for the future.

It’s the kind of thing where it’s, honestly, it’s frankly a little bit
too informal now. It’s the kind of thing where it’s like me going, “Hey, wait a minute. I think we’re adding up. We got 5 fonts here on site. I mean, we should cut down a little bit.

Justin Avery: I just shot, nicked something through on the Skype call which the BBC came up with just when you mentioned a PhantomJS taking snapshots. They came up with a thing called Wraith, W-R-A-I-T-H. It’s on GitHub and basically
it takes a snapshot when you’re making changes.

It takes snapshot and it compares it against the old version. It does a diff on it basically
which is quite cool. They open sourced that so if you’re looking at it, check that out. That will be in the show next as well. 

Nick Schaden: I will look at it. The more we can do for automated visual testing, the better. I think that’s something even … It’s like when I talked about earlier the notion of even developer-designer relations. Part
of it is buy-ins. It’s opening the cloak up and I think the first time, again I did it a bit and then we had some other works frankly pushed to the side.

Regarding on that screenshot capture it’s really open people’s eyes. It’s
been little things like internationalization like, “Hey, we prepped this new page. How does it look on every browser?” It’s like boom, you press 1 button. It’s loose, it’s not perfect but then even just setting that little thing off to the designers, everyone is like that’s
cool. That’s something that I would love to look into in the future.

Justin Avery: That is so awesome. It is pretty awesome. We’re getting towards the end of the hour. I could keep going for ages but I’ve got a couple other questions. What should we dip around to? I always like this one. I
used to do an interview series but it was a written interview series a while ago.

I had this set bunch of questions which I was going to try and bring in to the podcast but
I end up just losing my place as we go off into different tangents and stuff but the 2 that I always did like to ask, especially for frontend people, what are the 2 responsive design framework or plug-ins or shims that you would recommend or you couldn’t live without?

Nick Schaden: Responsive plug-ins that I couldn’t live without. This can go in any context?

Justin Avery: Any context.

Nick Schaden: Wow. This is tough. Well, the first one that does come to mind when I think of shims or polyfills, it has to be probably Picturefill. I think it’s a great resource. Again, it was the turning point for me as even a
developer saying, “Hey, you know what, I think this is worth the time.” That’s one. Two, what would be a second plug-in on how I feel. I mean, honestly I’m still a huge fan of … Wait, this is a question specific to responsive, right?

Justin Avery: I mean, it’s your front end stuff. It could be responsive but also like always when I started asking these questions, it was 3 years ago and so plug-ins and shims you needed them because there wasn’t much around,
but nowadays we use things like Flexbox, we’ve got the box-sizing, border-box thing there. I couldn’t live without that these days. It’s open a little bit.

Nick Schaden: I would say the number 2 is I still love Modernizr. Every so often, I hear some more negative pains about that. I think it is a very good point that you can’t just use it loosely. I think there’s too many people
that just do something like download the HTML5 Boilerplate. They’re like, “Hey, man. I got the test version. Let’s throw this up there because there’s definitely performance implications if you don’t use it and use an optimized version of it.

Just as you said the way we detect 4 things like Flexbox is all via Modernizr today. It’s
less of a responsive thing but just let’s call it a progressive enhancement utility that we can use at Pocket or we use to have that actually at Animoto. Even at Gucci, I think in its infancy. It’s really a great resource.

Justin Avery: It’s almost like cutting the mustard, right?

Nick Schaden: Exactly.

Justin Avery: The other question which I always had in there is what is one thing with responsive design that you would like to see improved? Again, these questions are odd. When I came up with them, like I said, it was 3 years ago.
It’s not just responsive is a new thing, it’s how we build websites. What’s one thing that you want to see improved on the web in terms of tooling you have access to?

Nick Schaden: That’s is a great question and it’s a good question that is a bit open-ended but in a good way because I’m sure 3 years ago they were like I just want to work at all.

Justin Avery: Most people answered I want a responsive image solution.

Nick Schaden: That’s true. We come a really long way. You know what, I would actually say … I was about to say a really good grid format but then nowadays … I know … Susie has moved to I think the LibSaas over
there. There’s something we’re very interested in. We‘ve grown our own grid here at Pocket.

It’s a bit based a little bit on foundation, a little bit on bootstrap, a little bit
customary, but I guess, you know what I want, I want more string, open ended, less opinionated grid systems. How’s that for an answer?

Justin Avery: That’s good.

Nick Schaden: Even when I’m switching briefly to the class head, so often when we’re teaching someone completely new, they might be even knew to just technically to web design. We stick to basis of like, “Hey, there’s
this thing called responsive grids and there’s poppers ones like bootstrap or foundation or da, da, da.”

They tend to have a bit of croft and done and they tend to be … I mean actually they
were great. I don’t want to knock them for that but they’re very uniformed, they’re very simple. One of the things when I think about where the web is going and I think we’ve seen a lot of criticism in the news, that sameness of what design that they all look kind of these full-bleed
imagery and centered Helvetica on a photo.

I think though it’s exciting to guys. It’s almost because of responsiveness
we’re at the infancy of the next step of web design. I think grids are still very important in some ways for the responsive world just for simplicity, for building for access. The more people move towards custom grids, I think we’re going to see a lot more exciting designs out there.

Now, I think that’s great and it’s ironic because at Pocket we have a pretty
uniformed grid. Actually for the web app, it’s completely just done by ourselves. We’re a different use case at least especially for our applications because we want a sense of very clean, conformity between items in our case. For something that’s really funky, really out there, something
that really impress people visually, I don’t know. I’m really excited about that. 

Justin Avery: Have you looked in to the CSS grid spec at all?

Nick Schaden: I’ve heard of it. I’ve looked a little bit into it. Not too in depth but …

Justin Avery: Just brain exploding.

Nick Schaden: Yeah.

Justin Avery: It is. Just regions …

Nick Schaden: It’s like the first time I saw Flexbox. I thought it was a colon or something. I’m like what?

Justin Avery: Is it April 1st. What’s going? This is ridiculous. Just a quick tangent, do you guys put your grid up on GitHub or do you run a style guide or anything, a public facing style guide I should say?

Nick Schaden: No. I mean when you touch on style guides, I’m sure that if any of our extremely talented designers, Nikki or Maggie or Diego listen to this, they’re going to be like, “Nick always brings up the style
guide thing. Come on guys, we need the style guide.” We’re getting there. We’re a growing company. Style guides was a big proponent.

We had actually a very much a living style guide. I’m not sure if it was open sourced
at Animoto and I love it. I would love to do it at Pocket for consistency reasons but we’re getting there. It’s one step at a time, pretty busy now but I would love to explore that in the future but no, the short answer is we don’t have anything open sourced or public for now.

Justin Avery: That’s good. The final question, so each week, I ask you, the guest to ask a question of next week’s guest. I will get you to ask a question after I ask you this one. It can be about anything preferably responsive’ish
or [inaudible 00:58:51] web design. We’ve had like what’s your favorite Star Wars movie?

You an dwell on that for a little bit while I ask this one. Last week Nathan Ford and I
explained to him that this exact same thing and then I failed to ask him what his question was. This question is actually coming from a friend of mine called Chris Burnell.

I don’t know how much you’re familiar with HTTP/2 specification and what’s coming
bit his question is, HTTP/2 is around the corner and it’s certainly going to make strides in web performance in a way which we can serve our assets. Do you think it will have an effect in responsive design and if so, how to you imagine it being leveraged in a way that’s not possible or widely
supported at the moment? Thanks, Chris. Have you come across the HTTP/2 spec at all?

Nick Schaden: I have heard of it. I have not honestly investigated it too much, no. I’ve heard of it and I’ve heard of it, bleakly.

Justin Avery: That tough question to answer then if you …

Nick Schaden: It is a tough question. I mean, I can take … I guess I could answer it’s maybe a side step but I can answer the question more around web performance in the way we serve our assets because I think that is the
heart of the matter. That basically we can improve that experience what effect it would have. I don’t know, is that cheating or do you want me …

Justin Avery: No, that’s good. I’ll run through some of the changes with HTTP/2 specs or sharing information but until that arrives, what are you doing?

Nick Schaden: I think the next great frontier in general for responsive design in terms of … I already said that for grids. I’m cheating. I’m sorry. If we talked about the issue of web performance the way we serve
our assets, I think server to client side integration is one of the next great frontiers.

We have your traditional NVC, JavaScript based frameworks, from Angular, Ember and all but
aside from that, aside from those whole hog, let’s call them scenarios where you’re going all down that road. A lot of the attention right now is very, very frontend and very, very frontend focused with things like everything from media craze to grids, to those kinds of issues.

On a recent article that I read recently, I wasn’t a huge fan of the article but it
did touch a nerve with me was the notion of I think it was marketing page that was like hey, you know what, if you do a landing page, don’t make it responsive. That’s not the way to go. Make it like an M-Dot or an adaptive website.

I think was necessarily maybe the wrong the conclusion but I think the reasons they have
were very interesting. In particular they brought the point that our colleagues, we’ve seen these people make these responsive sites and they still end up serving especially server site. The same croft that mobile that mobile never sees for desktop users.

I think that’s a really interesting point. Again, when I think about that, I think
of look at the recent New York Times … Well, it’s not that recent now but the New York Times redesign. It’s also true with The Guardian, the BBC as well. It’s like a combination of both very smartly done design and frontend shops for the architecture.

Then also a very smart decisions have been made about server delivery and about what asked
are given based on issues like viewport or the other kind of traditional responsive elements. I’m worried there’s not enough attention drawn on that. I don’t want to say we’re debating phase 1.

I mean we have to. Things like responsive imagery, we still have to … I don’t
want to say figure things out but we still maybe have a bit of little room where we’re going. I hope that we move attention to that kind of more early stage earlier in that discussion because I think it actually is a very important appendix to the main game around the bread and butter of media
queries and grids and things like that.

Justin Avery: That’s very true. If anyone that wants some more information around that the stuff The Guardian was doing, there’s an early episode with Patrick Hamaan and he was fantastic. Their whole process if trying to
serve the news in under a 100 milliseconds and the lengths t hat they went to, things like you were saying like they try to limit their … Do you use WordPress?

Nick Schaden: I do on my personal side. I run with WordPress.

Justin Avery: WordPress made a request to the database and the request is for the current post but then a whole bunch of other stuff, they’re related, metadata and related post and a whole bunch of stuff. There’s always request
that go hit the database and it comes back with a chunk of HTML.

The approach of The Guardian is again, like you were saying to take a focus on that service
side of things, is this is one request for the article to bring it back and then all of the other … Because that’s what the user wants. They’re there to read that one article when you land on an article page.

If only 1 request works and that’s the one that you want. Then everything else that’s
done in the navigation, the sidebars, the comments, the polls, they’re all done subsequently and depending on the device you’re on. They do a mastered cut to find out what capabilities your browser has. Then they just lazy load things in.

Nick Schaden: I mean, I think it’s only smart. I mean, I’m a huge fan of The Guardian. I think coincidentally, when I first started my workshop on responsive web design, I think I was using their very site as a test case
to illustrate responsive imagery in terms of hey, here’s an article, here’s it on different devices, let’s use this as a starting point for talking about this. They’re very impressive in terms of what they do.

Justin Avery: It’s also one of the only places where I think you can get away with it because they’ve done it in a … They thought it through is that it loads content using JavaScript. It usually will like, I don’t
know, it must be progressive but they do it in a way where you do get the article you’re after and just load up the stuff as you need it. That’s interestingly good.

Back on that HTTP/2, really good specification, I did a solo podcast a long time ago but
it gets past all of the approaches that we’ve had so far to improve the performance of our websites. Things like concatenating files, putting all the JavaScript into a single file, putting all the CSS into a single file, dropping the JavaScript at the ends so that it’s a non-blocking request
or putting it in a sync or a differ attribute on sprite images.

All these things that we’ve done to hack around the gist. When you make a request
for a page, it goes against the HTML page and brings it back. When the browser passes it, it then finds all the other things it needs and then it goes back and request those but to request it, each individually.

It’s a HTTP request every single time. Then there’s only a certain number of
HTTP request that you can make it any one time. Then we started doing things more to a single domain. We started hosting things on dub, dub, dub dot one, dub, dub, dub dot two, dub, dub, dub dot three.

Then there was a limit to a number of those that you could request so that we … We’ve
done all these things together around the limitation of that protocol. That protocol is what’s changing. It would do a push. It’ll do things small. It’ll keep your connection open.

It’ll send multiple things back so you get the HTML file and you can declare that
there’s a few things that are needed. It sends them all back at once. It just gets past all the hacks we’ve done. Now, it would be interesting I think to see whether or not we continue with the hacks and still have less requests of whether we fallback to let’s keep everything separate
because we can now.

In the same way because the pipes have got bigger on our internet connections, we’ve
got, let’s just put that 2,000 pixel image up because the pipes can handle it. I think it’s an interesting timing anyway.

Nick Schaden: I mean, with that last point you mention, the pipes will handle it, it’s very dangerous. Again, I think that’s something that I think it’s part of just doing what we all do. Whether you’re in web
design or development. Part of it is just being humble in realizing that … I mean, I’m guilty of doing this too is that you’re so focused on what you have in terms of your bandwidth, in terms of, for example your display.

Almost every design, especially design right now, they’re on right on displays. They’re
on high end architecture, latest web browsers. Are we considering for people who maybe are quite on the same level that way. I think that’s just really important. I mean, again, we haven’t touched on at all but I think that some of the discussion around Facebook and the instant articles debate.

I think that part of the argument of, “Hey, I have a 2,000 thing. You know what, so
what? It’s only another half a second.” Everyone has got a fast enough connection for this. I think that, I don’t want to say has led to the point where we are. I think there’s a lot more than just speed that’s going on with a lot more even politically frankly with Facebook
in regarding instant articles.

What I would say is it is drawing attention in a right way. I’m not the first to point
this out. There’s a lot of smarter people out there than I am on this but it is that … It’s drawing attention to performance in a good way. It’s saying there are so many websites out there. They may have great contents but frankly, specially on the mobile web experience is slow.

As you point out in terms of choosing what to load first with say The Guardian or say of
HTTP/2, is like how are you choosing to load that. Are you forcing the user to slow down an extra second or two with a full screen ad? It’s dangerous.

Justin Avery: Totally. I’ve read the other Facebook article thing in the last episode. I think it’s a very interesting time around that and I agree. It’s racing. It’s good that it’s come up because it is
pointing the finger back at a slow web. It’s not slow inherently. We’ve just made it that way. It’s a great subject.

I shot you a quick Skype message which is what does my site cost.com, something that Tim
Kadlec put together and you basically put your IRL into the site and it would do a web page test and then it has a whole set of different countries and the cost of the most cheap data plan giving you an allowance of 500 megabytes for 30 days.

It gives you a breakdown of what your size. Again, Pocket weighs in 1.14 megabytes and it
gives you a breakdown of countries starting with the most expensive and working its way down. In Germany it needs to load that homepage, it cost 14 cents. In Japan it costs 13 cents. In Ireland, it’s 11 cents. In United States, it’s 8 cents.

It’s a really great site because it takes a megabyte. If no one understands what a
megabyte is, but people understand what money is. They’ve incorporated this web page test now so you can see the little dollar signs next to it, any test that you run and you could really see how much your costing people. I’d love to run that older ugly site back through this.

Nick Schaden: I know what you’re talking about.

Justin Avery: It’s actually 4 megabytes or something which is a lovely, beautiful site and they did fix it when they got called on it. That was a couple of bucks just to visit, have a look at it. It’s crazy. Do you have a
question? Have you thought of a question for our next guest before we wrap things up?

Nick Schaden: I think so. It’s probably less technical but I think it’s still relevant which is I would ask the next guest, so I’m assuming which obviously is involved with responsive web design or the probably won’t
be talking with you. The question would, how has responsive web design changed the workflow in your company?

That’s a very open ended question. I mean you could say it within your technical team,
within your design team. Again, this could be approached from a business aspect, QA, design, what have you. I love to hear those stories because I always find there’s a lot more that’s changing than just again, just code or just how, “Hey, will you sketch more a lot aggressively than
Photoshop,” or something like that. There’s more to it. There’s a lot more to it, I think.

Justin Avery: Absolutely. That is a good question. I’ll look forward to hearing how people … I might use that for a couple of guests the next time so I won’t forget. That is a good question. Well, thank you very much
for taking the time out and joining us on the podcast. Are you doing any talks? Have you got any launches coming up? How can people read, follow you on Twitter, your websites?

Nick Schaden: Sure. I have my website is at nickschaden.com. I’m on Twitter @nschaden. I post the occasional link post on my website and I tweet occasionally sometimes about development but sometimes about completely other random
things like electronic music or film or games or whatever. I’m on that.

In terms of upcoming talks or events, the only that I would mention that’s coming
up soon is I’m actually working with Invision specifically. I think a bit of a cross promotion with both Invision and Pocket. We’re going to be having a webinar I believe the date is going to be June 9th which is a Tuesday. Let me just check on my calendar here. Yes, I believe it’s
June 9th.

We haven’t set along the exact time yet but if you go to invisionapp.com or if you
just follow then on Twitter in the next probably … I’m guessing in the next few days, there will probably be a landing page for this. It’s going to be a free webinar that I’m going to be giving, probably it will last about 30 to 45 minutes on that day.

The topic is called building responsive teams. It might sound mildly pretentious but it’s
basely just a little bit of a talk on multi device flow, why it’s important and potentially just small strategies that could implement regardless of your team size or dynamic to try to make a bit more of cohesive units, both development and design wise. That’s about the only plug I have on
my side.

Justin Avery: Awesome. All right, June 9th. I’ll put the link up in the show. If you shoot that through to me [crosstalk 01:14:23].

Nick Schaden: I will. My understanding is they’re still … I think as we speak today, they’re actually putting the quick landing page to sign up for that. Again, as far as I know, it’s completely free but I’ll
definitely shoot you that once it’s locked up.

Justin Avery: Is it a responsive landing page or is it a mobile?

Nick Schaden: That’s a good question. If it’s not responsive, I’m just not sure enough with those guys. I’m kidding. They totally have their work. I’m a big fan of Invision on a side anyway. Especially their
blog, it’s totally responsive.

Justin Avery: I really like Invision stuff. They’re really running some really good articles as well. They’re dominating it at the moment.

Nick Schaden: Right.

Justin Avery: Excellent. Again, thank you very much for coming on. All those links will be on the show next on the website. Once again, thank you for all the listeners for tuning in and listening. If you live to watch Nick had to say
ago and check out his blog, he’s got some really great articles on there. There’s one about approaching whereas I’ve got here bridging the designer-developer gap on responsive web projects. It’s an excellent rate. We’ll be in the newsletter this week as well.

Rate us up on iTunes, give us a 5 stars and if you would like to join me if you have something
to share on the podcast, be sure to get in touch. You head over to responsivedesign.is. There’s a contact form there and for the other podcast, go to responsivedesign.is/podcast. Thanks again for everyone tuning in and thank you again, Nick.

Nick Schaden: Thank you very much.

Justin Avery: Cheers, bye.

Nick Schaden: Cheers, bye.