Podcasting

Responsive Web Design Podcast Feed

Justin Avery

ResponsiveDesign.is the knowledge hub for planning, designing, developing, and implementing responsive design.

Episodes

RWD Podcast 65 : Public speaking, Hololens, NBC Redesign
20:55
2017-09-22 13:53:31 UTC 20:55
RWD Podcast 65 : Public speaking, Hololens, NBC Redesign

Show Notes

RWD Podcast 64
15:45
2017-09-22 13:53:31 UTC 15:45
RWD Podcast 64

I’m just back from a few weeks in Australia visiting family and getting the podcast back up and running again. This week we go through the best links for the weekly newsletter.

RWD Podcast 63
11:07
2017-09-22 13:53:31 UTC 11:07
RWD Podcast #62
23:33
2017-09-22 13:53:31 UTC 23:33
RWD Podcast #62

RWD Podcast #61
58:00
2017-09-22 13:53:31 UTC 58:00
RWD Podcast #61

RWD Podcast 60
40:22
2017-09-22 13:53:31 UTC 40:22
RWD Podcast 60

Hey everyone and welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly newsletter, a weekly newsletter all about responsive design and other front-end cool stuff. This week I’ve got a small guest but it’s not until the end and I’ve got a piece that I’ll add at the end of the podcast, and the reason why I say it’s a small guest is because they’re small in stature it’s my little boy Noah and he decided that he wanted to do some recording over the weekend so we did a little short podcast together. If you don’t like the opinions of a three year old then feel free just to skip over it. So that’s why I’m not including it until the end. He probably has some better opinions than me a lot of times but, you know, he’s a little childish. Takes after his dad.

But this week to start with I’ve got a lot to offer everyone, so I’m going to get to that first. We’ve got a couple of sponsors this week which is fantastic and they’re giving everything back to us which is great. Or you, the listener. So, conferences, we’ve got a bunch on. We’ve got three conferences coming up. One in the states, one in the UK, and one that is global that you can view anywhere and the first one is the global one.

So this is the SVG online summit and anyone can join it, it’s global, it’s an online thing. There’s a tonne of talks during the day. Actually, let’s go through it properly. A better-prepared person would have all this here. So SVG Summit, if you go to svgsummit.com then you can go check it out. If you use the discount “RWDWEEKLY“, all capital letters, that’s good for 20% off. Now it’s coming up on the 15th of February so it’s not too far away. Starts 10:00am Eastern Standard Time, 9:00am Central Time, and it has six speakers throughout the day. Chris Coyier, Sarah Drasner, Amelia Bellamy-Royds, Dudley Storey, Clark Wimberly, and Kevin Ball and they’re all talking about SVG and different ways to use it online. It’s going to be super cool.

And the great thing about these online conferences is you don’t have to spend any money flying there, you don’t have spend money on accommodation. I love flying to places but it gets expensive when you add everything up, and the time you’ve got to take off. So this just pop it on your computer at work, put your headphones on, and just learn lots. They’re really cool conferences. I’m fortunate I’ve been to a couple where I’ve partaken in a couple, watched on the computer, and I presented at one as well. It’s just so much fun. Really good, the guys do a good job there.

The second conference we’ve got is for the awwwards, so this is for folks in the UK or Europe and it’s coming up fast. It’s the awards conference so A.W.W., see what they did with the name? That’s coming up on the 2nd and 3rd of February so I’m going to be going along there and I’m going to be hanging out with some friends from the Adobe XD Team who I caught up with late last year and I actually want to speak to them a little bit more too because I think the XD stuff is really interesting in terms of like rapid prototyping and being able to get interactions and things on the screen that clients can see. So I kind of want to try a couple of screen-casts and see how it might work out to improve our responsive workflows and stuff.

So if you want to go to that you can go to conference.awwwards.com/london2017. Do a search for “awards conference in London” and that will come up there, and if you use the discount code “responsivedesignldn“, it’s like responsive design London, that’s good for 10% of the ticket as well. They’re also going to be doing a live stream of the conference out as well and Vitaly from Smashing Mag is going to be there to kind of host that as well, so that should be really cool. I want to catch up with him as well because Smashing Mag are doing this huge redesign. They’ve had people like Sarah Souiden working on it, I think Dan Mall had done the original designs perhaps as well. It looks really good. It kind of looks a lot like the Responsive Design redesign as well so I’m happy that the design that I’ve gone with, with the guys from No Divide, that they’re going in a direction similar to Smashing and I think that’s a good direction.

But as part of this, Smashing Magazine and Vitaly, they’re looking at different ways of generating an income for a publisher. So it’ll be really interesting to see with all the ad blockers in now, they don’t make as much money through ad revenue, so you need other ways to supplement the income to continue the business. And Smashing Magazine is a big business so it will be really interesting to see what he’s doing to try and tap in with that. I think he’s going along a little bit of subscription model which I think is cool. I’d be happy to subscribe to a magazine like that, they put out a lot of good stuff. I feel like I should be paying them for doing that as well because they pay all of their writers and I really like it.

And then the last one is for people in the states most likely, or the Americas, and that is called “ImageCon” so it’s imagecon.com and if you use the code “RWDWEEKLY” it’s good for 50% off your ticket which is really cool.

Now I wrote a piece earlier in the week about how to approach typical problems when uploading large numbers of images and it’s actually what I’m going to be talking about after this and running through with you today. If you want to head along to the conference that will let you understand and deal with bigger problems than just how to get images optimised properly and rolled out on your screen or near different sites. They’re going into a lot of detail like the different problems that we have with images at the moment, and it’s on the 1st of March. So 1st of March in San Francisco and it’s got some amazing speakers like Jason Grigsby, they’ve got Allison McKnight from Etsy, Vitaly as well, we just talked about Vitaly from Smashing, Steve Souders like the performance person getting around so he’s at SpeedCurve these days. So all these great people talking about images and it should be a really good conference. That’s imagecon.com and use “RWDWEEKLY” for 50% off your ticket.

That’s all the discount stuff at the top of the show so you can save 20%, 10%, 50%. Great stuff.

So for this week I wanted to talk about watching your weight. And I’m not talking about like the post-Christmas holiday weight and “Oh my goodness, I’m going to put a New Years Resolution to never eat unhealthy again, and I’m never going to drink again.” We’re talking about image weight on your websites. And the reason why I wanted to talk about it this week is because, like I said a bit earlier I wrote an article this week is because I came across a tweet from Andy Clarke. Now Andy Clarke has published this awesome article on his site called “Designing Inspired Style Guides” and it was a talk that he delivered, and he doesn’t think he’ll be able to deliver the talk again, but it got a really good reception and so he thought, “Rather than waste all of this great content, why don’t I turn all of this great content into a super long blog post? Then more people can enjoy it.” Which is like, kudos. It’s a really good, long detailed article about style guides. So kudos to Andy for doing that.

Now in the second paragraph of the article he even says, “This page contains a lot of images.” And he says, “This page contains 35 MB of images, I’ve optimised them as much as I can but you probably don’t want to load this page on your mobile data plan.” So that’s great that he gave people the heads, there’s just the issue that by the time I’ve read that, a lot of the images which are on that page are already starting to download. Now I suppose thing in this is that there were so many images on the page, so there’s like 150 images, there’s so many there that it won’t have downloaded that many because of the number of connection that it has. Or it needs to make the number of HTTP requests. So by the time I read that I could hit stop and then save my data plan a little bit if I was reading it on my phone or even my desktop I had time to stop it.

So I want to get this super clear up front, Andy did as much as he could do with knowledge that he had on providing an awesome resource to everyone and giving them a heads up. Like that’s awesome. Not many people would do that. And I thought, “I wonder if there was anything that could be done to perhaps make that experience a little bit better for users. Let’s see how this goes.”

What I did was first I opened up Chrome Dev Tools and I opened up the Network Panel. There’s an option in the Network Panel where you can set a throttle, so you can say rather than run off your regular connexion to the internet you can set it to run at 2G or 3G or good 3G or 4G or GPRS so you can test different network conditions. So I tested a mobile network condition at regular 3G, ticked “Disable cache” because I’d used the page before, and then refreshed the page and started watching it. And once it had finished loading I noticed it was slow because it was on 3G but all of the files that were being served were PNGs, that was one thing that I noted. And immediately there come a thought, “That must have been the default export option for the presentation he did, Keynote or PowerPoint.” I also noticed that all of the images were being loaded regardless of whether or not I had scrolled down the page to view them, and the last thing I noticed was that every single image required it’s own HTTP request.

So with 150 images that’s 150 round trips between your browser and the server and going through network connexions. With that information I thought, “Right. Let me address those images and see if I can improve upon the load time for that particular page and the great resource.” First I saved down the page locally, so if you ever want to grab a webpage from someone’s site and put it locally so you can work on it and check stuff out, it’s File > Save Page As > Webpage Complete. And that downloads the HTML as a HTML document and then it also downloads a folder and within that folder it has all the assets, so all the images, all the JavaScript, all the CSS, everything that goes to make up that page. So if you’re offline, locally you can double-click on that HTML document and it’ll open up and you’ll see the entire page. So that’s a good start.

I saved it to my desktop and then I moved on, and I mentioned that the first thing I noticed was that PNGs were being used for everything. Now as a general rule you can either have PNGs or you can have JPEGs. It used be GIFs and JPEGs and I know there’s PNG-8 and PNG-24, I won’t go into that but let’s just start with it’s PNG or JPEG. So if you want to choose a PNG, you should choose a PNG when the image is more of block colours. So think vector kind of things like logos, icons, they’re kind of just full block colours. Also if you want to have a transparent background then you might choose a PNG as well, and we’ll go back to the logo and PNG transparency thing in a sec too. You should choose JPEG if the image is more of a rasterized image, like a photo. They’re the general two choices.

Now back at the logos and icons, technically these days we probably would want to go for an SVG rather than a PNG purely because it’s a scalable vector graphic. So it will scale from small viewports to large viewports, so rather than have many different types of your PNGs depending on what size you need to render them as, you have one SVG and it scales magically. Hooray!

And then on the transparency side of things as well, there’s a file type called WebP and it’s supporting in Chrome and I think Opera as well but I do know that Safari were looking at implementing it as well or they were checking it, and they never check stuff out like this so that’s really positive. WebP is a lot more performance so you can compress it a lot more and get still really, crisp, clear JPEGs effectively at much smaller file sizes and it provides transparency as well which is really cool.

So looking through all those images I thought most of them were more suited to JPEGs than PNGs, and if you PNG something that should be a JPEG the file size becomes incredibly larger than what it should be. Whereas if you JPEG a PNG you can really small PNGs for quite large pictures because it’s mostly block colours and you can get incredibly large PNGs for small pictures if it’s more suited to a JPEG. And just out of interest if you’re going to export your files or your slides from something like Keynote or PowerPoint there is an option, definitely in Keynote you can select JPEG high quality, small file size, PNG or TIFs. So just think about what most of your images are going to be and export to suit.

So now that I had them all downloaded, all of the images, or downloaded the webpage, then I wanted to change them all from PNG to JPEG. Now normally with my Mac I can right-click and say “PNG to JPEG” because I’ve set some automation up because I take a lot of screenshots and I just want to switch it through the PNG to JPEG because traditionally JPEGs are better for the screenshots that I take, so I’ve got like this right-click shortcut. But because it’s 150 images in this case I have Photoshop on my machine so I was able to use something from Photoshop, so in these cases where you’ve got large scale, you want to batch-process things. So if you go into Photoshop and you go File > Scripts > Image Processor then it gives you a few options, you select the folder of the images you want to change, you select a folder for where you want your images to end up and then you pick what file [size 16:26] you want it, in this case it was JPEG, and the quality that you want it as well. I chose a four which is about 30% quality because I wanted them small.

Then I hit “Save” and then bam, we got a whole bunch of JPEG images and that changed the file size so it wasn’t 35 MB it was now down to 10.4 MB. So we’ve already reduced it down to a third of what it was just through changing the image file type and optimising the images a little bit. Then when I had all of that the next step is a little bit further optimisation using a tool called ImageOptim. It’s a free tool and the wonderful thing about that is that it provides lossless compression which means that image isn’t as big but it is just as beautiful as it once was, so it doesn’t affect the quality of the image at all, it just reduces the size of it which is exactly what we want. To do that it removes like … I actually don’t really know what it does, it’s like magic I think. But what I do know is it removes a whole bunch of metadata about the image which isn’t needed for people to view it on the web so just get rid of it. So yay ImageOptim. Free, you should totally get it.

So I dragged all the images onto Image Optim and then within like 30 seconds or a minute it had processed all those images and that had taken it from 10.4 MB down to 6.1 MB so now we’re talking about going from like 35 MB all the way down to 6.1 MB which is amazing. From there it’s a simple … I always say simple matter, it’s not always simple. From there you need to get the images back onto your server so I used an FTP client and you put all of the images back into the folder that you had all you PNGs, it won’t override them because now they’re all JPEGs so it won’t overwrite a PNG because they’re different file names. And once they’re all back in there you have to update the reference in the post, so at the moment all the image tags are referencing .png you need to reference JPEGs and it’s Control-F like a find and replace. So you want to find anything that says “.png” and replace it with “.jpg” then you publish and voila. You’ve gone from 35 MB per page for every visitor down to just 6.1 MB for every visitor.

Not only is that really good for the users so they get the content faster, they don’t have to wait around, their browser doesn’t slow down, they don’t lose all their data. The other great thing is Andy is a popular guy, he writes a lot, he does some cool stuff. Now he would have like, I’m guessing 10,000 people would go and view that article that he wrote, it was re-tweeted by a lot of really popular people in the web community as well. So 10,000 people at 30 MB, that’s 300 GB of data that he’s now saved and he doesn’t have to pay in bandwidth. It’s just fantastic, it’s a win-win for everyone I think.

So at the top of the show we talked about there’s three things, so there’s the file size which we’ve now corrected to a certain extent, a pretty good extent I would say. The other thing is that all the images are being loaded regardless of whether or not anyone was going to see them. To fix that essentially you’ve got 150 pictures you might not scroll through all of them so why should you be downloading the ones that you’re not going to view. So you can use a tool, it’s a JavaScript plugin called “lazySizes” and what that does is it Lazy Loads the images into the page. What that means is that when you first load the page it will load the images that you can see that are within your current viewport and then as you scroll through the site as the other images get close to the viewport then it will say, “Hey, you’re about to be viewed by the user. I think you should start downloading now so that you can be there for when they arrive.” And then as you scroll through the images slowly start being loaded in.

If you stop scrolling then the images stop being loaded from below the viewport and it’s just great because it means that only the images that you’re likely to see are going to be loaded. So you’re only paying in bandwidth and time and even the hosts, so Andy is only paying in his bandwidth for the images that you’re going to see as well. Now to do that, like I said “lazySizes” if you do a search we’ve got it in the resources section on the Responsive Design site as well and it’ll be in the show notes. It’s a small JavaScript file, you can load it asynchronously so it’s not a blocking script, it won’t affect the load of your page. And for any image that you want to Lazy Load you need to change the source to “data-source” so it’s a data attribute instead and add a class of Lazy Load to that image.

Now the reason you have to do that data-source thing is because browsers are super smart these days and as soon as they detect an image tag, like even before all the HTML has passed, it will start downloading all of those images and that’s to make it seem as though web pages are faster. They do that for the users benefit for performance side of things. What that means is that all the images start downloading before any JavaScript can run and stop it from downloading so that’s why you need to change it from “source” to “data-source” and then as you scroll through lazySizes checks to see whether the image is approaching the viewport, as it gets close to it like within 200 pixels or so, then it changes the “data-source” to “source” and the browser will download the image. So it’s super, super cool.

I’ve used it for a few sites, I did it for the Adobe Mac site, I rebuilt their conference site from like a better approach for a responsive, responsible design and performance is a big thing. I added lazySizes to it and it’s shaved like several seconds, we’re talking five or six seconds off the load time of the site by just implementing the lazySizes. Very good for image heavy sites, especially for ones that are below “the fold”, so definitely implement that if you can.

We also talked about I said there’s lot of requests for the images as well, so if you were able to run on HTTPS and your server supports HTTP/2 then instead of having one request for each of the 150 images and there’s latency on every single request, with HTTP/2 you don’t have that latency. It can just request all of them at once and they can all download and of course if you’re using lazySizes then you trip yourself up because you don’t want them to all download at once. But that connexion will stay open so you don’t have to make it look up every time, which is fantastic.

And the final thing, there’s one more thing that we can do. For those in podcast room, can anyone just raise your hand and say … Like, are you thinking of one other way that you haven’t mentioned, the key way to have better images for this page? Anyone? You in the back, Mr. Eric Portis? Yes, you were right. It’s using responsive images is the other thing we could do. This requires a little bit more work. What we had for these images is they’re all slides, so they’ve all been exported about 1024 pixels wide. Now if I’m viewing that on my iPhone 5 which has a width of 320 pixels and it’s a retina one, I think they’re all retina, 320 you might double that and arguably say it’s 640, but that’s still like half the screen area of what I need from what the image is being loaded. It’s 1024 only you really need 640. So we can include something like SourceSet for the images so that we can give the browser several different sizes of image to chose from and then it would download the image that best suited the viewport to render that image.

And that great thing about that lazySizes that we talked about before is that it works with responsive image syntax as well so it works with SourceSet and it works with picture as well. So that would be a cool bonus addition there and the reason I … Eric didn’t really put his hand up, but Eric Portis wrote this really awesome article about responsive images and again I’ll link to that in the show notes and it’s linked in the article as well.

So that’s it, so this is how we can turn like … and I encourage everyone, we’ve got this problem at the moment with large web pages, they’re bulking, they’re oversized, they’re overweight. And most of the weight is due to images. We always complain about, “Let’s not include that JavaScript library in there it weighs 30 KB.” And yet we’ll chuck on 35 MB of images onto a page. I see this all the time and it doesn’t have to be 35 MB it could be 5 MB of images, the point is that’s too often, that’s too much. But if you can approach it in a systematic way like, “Am I loading the right images? Are they properly optimised? Have I put them in a responsive image container so that only the right sized image gets served up? We’ve got a tonne of images, are they loading below the fold? Are my users likely to scroll down there and if so will they scroll all the way or should I just be serving up a couple that they’re definitely going to be seeing?”

This is the other reason why this image conference is on at the moment too because it is a real problem, but I think we make the problem worse for ourselves by including these things. And I realise that most projects are done in a rush, unfortunately, it’s just the nature of the way we do things. These kind of things tend to be, “We’ll look at that later, let’s just get it up and going.” And I think that’s a bad approach. We should really just focus on trying to make it a little bit lighter, try and work those images as well as we can and see how we go.

So that’s it. Thank you for listening, thank you for tuning in and downloading. If you want to talk about something, if you want me to cover something in particular, feel free to write in. You can hit me up on email, you can reach me on Twitter @ResWebDes, you can subscribe to the newsletter at responsivedesignweekly.com and please rate this show up in whatever podcasting listening tool you’re listening to at the moment. Rate it up that would be super awesome.

Coming up next is my little interview with Noah so if you want to check out what a three year old has to say about the web and what’s better, what’s the newest thing coming out and what’s the best thing to watch The Minions on, then you are in for a treat. Until next week, I will see you soon. Cheers. Bye.

RWD Podcast 59
10:00
2017-09-22 13:53:31 UTC 10:00
RWD Podcast 59

Hey everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly Podcast, and the newsletter, a weekly newsletter all about Responsive Design and front end funky stuff. Now this week as you will notice, my throat hasn’t cleared up at all, the kids have kept my cold going and my cough has just got worse. So we’re going to keep this super quick because you don’t want me to be coughing in your ears on your journey to work or while you’re chilling out. So we’re just going to cover one thing this week, and again there’s no guest this week but next week I have two people to chat to which I’m very, very excited about. Yeah, it’s going to be awesome.

So this week, the feature side, the feature article for this week is we’re looking a little bit at an article which Scott Jehl has written from The Filament Group. Scott Jehl for those of you that haven’t heard of Scott, he has been doing wonderful work over the last couple of years on the web and he’s always about practical performance. In fact he wrote a book on just that topic as well. If you go to “A Book Apart”, I’ll type that in and it’s great radio. Here we go with the coughs. So yes, we know of the Responsive Design right? So “A Book Apart” Ethan Marcott wrote his first article on [inaudible 00:01:48] and then he wrote a book called, “Responsive Design” and then it was followed up with “Responsible Responsive Design” from Scott Jehl, and it’s just talking about the responsible ways in which we can approach the booting of websites. Now because Filament Groups stay on top of this stuff, the site is usually pretty darn fast and this latest article though we’re featuring is about them stepping it up, so the title is, “Modernising Our Progressive Enhancement Delivery” and it’s all about taking advantage of some of the newer tools that are available to us today, not across the world, but available to a lot of people.

And namely that is around HTTP/2 and so we can look at the browser support for HTTP/2 and it’s running on IE 11 partially but it’s limited to Windows 10 for IE 11, but Edge runs so 14 and 15 for IE or now Edge. Firefox supports it as of version 36 I think and we’re up to version 50 at the moment. Chrome has supported it since 41 and we’re at 55. Safari? Come on Safari. Safari offered partial support. Safari. Opera supports, iOS Safari does support it, Opera mini does not, but Android browsers and Chrome for Android both support it as well. So that’s from the Browser point of view. So if you send an HTTP/2 across to a Browser that doesn’t support it, it just falls back to HTTP/1.1 in the way that the web works. We always fall back, which is great, and that’s why the web is so awesome.

So the thing with HTTP/2, one of the coolest things, I think I’ve talked about this a little bit in the past as well, it’s just a lot faster. The communication between the server and the browser is done with 1’s and 0’s now, instead of text, so it’s a lot quicker. The compression on the chats is a lot better as well. But the main thing is that there’s no blocking requests. So previously if we requested an HTML page, and that HTML page had CSS and images and JavaScript and the like, it would wait, generally we would have that waterfall, network diagram. So it would request an image and then it wouldn’t request the next image until that image had downloaded and then it would go off and request the other one and the bring that back.

So each time we needed a new HTTP request, which was expensive and made things slower. With HTTP/2 you won’t even need to make a single request, and when the HTML comes back to the Browser, it then looks through it and goes, hey I need all of these files, go and get them. And they all come back at once, which means we don’t need to concatenate files together so much anymore because we’re not using the extra HTTP requests, it’s just all coming back. So instead of seeing this hierarchical, as like waterfall thing, it’s one request, bang everything else comes back. So that’s great.

The other thing that we’ve been doing is critical CSS. So the idea is that we want the first fourteen kilobytes that comes back from the server, we want to render as much of the page as possible within that first fourteen kilobytes because that’s the first trip back. And to do that we need to have all of the CSS that is required to render the visible part of the page within that first fourteen kilobytes. So we used to inline that CSS, called critical CSS. With HTTP/2 now, we’ve got this option of a server push, so that when the request goes out for the webpage, so when you request the Filament Groups homepage, as the server send the HTML back to the browser, you need to wait for the HTML to arrive in the browser, look through the HTML, find the images and the CSS and JavaScript, then request them, and even then they’re going to come back in one whole hit, and it’s one request, there’s still a bit of latency involved with that.

Instead because you know what file is going to be sent back, you can instruct the server to say, hey if someone requests this page, push along that HTML we’re sending back, push all these files because I know that these files are going to be required on that page. So that’s really, really awesome. It means that you don’t have to do that second request and then you don’t actually have to inline your styles anymore, you can just push them down.

Now I can imagine you’re thinking, but hey what if we already have those files, what if we’ve already visited that page once before? Fortunately, Scott has thought of that as well, and they’re using a cookie to check that. So even though the push happens, the browser can actually cancel that at any point. Now there is a couple of occasions where those files will come down and you will get the extra burden on your data plan because you’ve downloaded files that you already had. But for the most part once that cookie is set, then you no longer have to push those files down anymore, which is great. So I highly recommend, check the newsletter out, check the website out on redesign.responsivedesign.is.

Well you’re probably there at the moment, check the show notes of this as well, we’ve got a link to that article, but definitely check it out, browser support is great like we said. HTTP/2 you need to do a little bit of configuration on your server depending on what server you’re running, that will also need to support HTTP/2, but if you’re using something like CloudFlair, which I highly recommend, that actually has HTTP/2 out of the box. Another bonus about it as well is that you have to be on HTTPS, so you have to be serving your site securely to take advantage of HTTP/2. Another good reason to use it because you get all of these benefits along with it.

So that’s it for this very short episode, I’m really hoping that this cough sorts itself by the time we get a guest on. But fortunately, they will be doing more speaking then what I will, hopefully. Either that or I’ll just sit with a bottle of cough medicine and just swig it for every time I’m going to ask a question, another swig and see how we go.

So that’s it for this week, if you’re not already subscribed, head over to responsivedesignweekly.com and subscribe to the weekly newsletter. Check out the new stories going up on redesign.responsivedesign.is every day, and we tweet about them, so you can follow us on Twitter @ResWebDes. See you next week.

RWD Podcast 58
19:35
2017-09-22 13:53:31 UTC 19:35
RWD Podcast 58

Show notes

Transcription

Hey, everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery, and I am your host and the curator of the Responsive Design Weekly news letter. A weekly news letter all about front end development and back end stuff and performance stuff and frameworks and tools. A whole bunch of stuff. This podcast is like a … I was going to say  a sidekick. It’s not a sidekick. It’s like a spin off of the news letter as well, so I bring you some cool stuff on the podcast as well I hope. This is edition number 58 which is kind of cool, and the fist time that I’ve gone back to back editions week to week for a while actually. It’s the first time in 2017, but it’s only been two weeks in 2017, but it’s actually the first time for quite a while including 2016, so yay.

Thank you for downloading and tuning in again. This week I’ve got like this tickle in my throat thanks to my little boy. Thanks to him going back to school, so he’s bringing back a whole swathe of new germs that can do the run around in the family as well, so I’m going to try this thing where I click on the mute button if I feel a cough coming, so there will be like tonnes of tiny little pauses through the show. Super professional, I know.

This week no guest, but I did on Tuesday night I went to the London web performance meet up, and I saw a wonderful talk from Ada Rose Edwards. You can see her site at Ada.is. She was fantastic. She talked all about web VR. Now, I looked into web VR a couple of months ago because a client was asking what they could do with it, and they wanted to keep on top of things, and when I had a look I came across this framework called A frame. Aframe.io, and it’s a framework produced by the Mozilla company. Here we go. We’re going to try to cough quickly. I hope that worked.

I believe it’s developed by Mozilla. Anyway, it’s a wonderful thing. It’s like a framework. You drop in a bit of Java script, and instead of programming really, really difficult like web GL stuff and things that I have no idea or understand, have any comprehension of how to do at all. You drop this code in so the reference to a Java script file, and then you can just pretty much write HTML. The HTML, like you write HTML but with particular components, but it then turns it into a wonderful web VR experience. Then all you need is, all you need, you then need a phone. Some description. Something that supports web VR, so I mean I’ve got an iPhone five here. I’ve got an iPhone six from work. Both of those support it, and then like a headset which could be Google cardboard, or it could just be you pushing the phone really hard up against your face.

Google cardboards come pretty cheap. Fortunately there was a Google representative that gave away 100 Google cardboards at this meet up, so we all got to try it out. I forgot to hit the mute then. It was a wonderful meet up, and it was really, really good. Ada talked. No slides, just demos which makes it even better. Web VR it’s really a thing. It’s like it’s here, and it’s ready to go. I’m not going to lie, it looks a little bit like the designs that were coming out in the mid 90s or late 90s, so they’ve got a very 80s, 90s feel about the designs, but that’s because the web VR stuff is still, I mean the pixel perfection we expect retina quality stuff now with our screens and our phones, but the resolution on web VR just isn’t up to that scratch, but man it is immersive, and it is cool, all right?

One of the wonderful things I think is that you can jump straight into it. Now, A frame has a whole bunch of examples to allow you to get involved with it straight away, and there’s this wonderful component that you can add in called a sky box, all right? It’s almost literally … Let me just fire up. I built a call thing. Well, I didn’t build a call thing. I built a thing. Not necessarily going to say it’s cool. Yeah, it’s called a sky, so you know how I’ve dissed [amp alone 00:05:12]. I’ve questioned the usefulness of amp and the ideas behind it, so this has a very similar idea, so you’re loading in Java script at the top of the page. May as well.  We have locking script.  Pretty sure it is. Then instead of using regular HTML tags you’re using kind of like components I suppose, so everything in amp is predefined or prefixed with amp-image or amp-iframe.

Everything in here with the components is prefixed with an A for A frame, so you can build a box which is A-sky. Give it an ID. Give it a radius. Give it a source, and then it will effectively build a sky for you which is well cool. Now, the cool thing that I did with this if you go on to aframe.io and we can try it out. There’s an example which is a 3-D 360 image. This is how simple it was. It was lunch time yesterday, and I thought look I just want to try this out. I want to see how quickly I could build something that might be somewhat helpful. I jumped on and we have at work some clients, and as you would hope, and the clients are really keen on making sure that new employees get a really good feel for what it’s going to be like to work at the place.

All right, and that’s great, so you can have tours of your office which is fine, or you can show pictures, or you can show a video of the office and stuff, but sometimes things like if you’re working in construction, so we have like for a couple of construction companies, you can’t take people onto construction sites and show them because you’ve got it go through a whole bunch of safety rigmarole things, so it’s not really going to fly. Some places are super secure, so you’re not allowed to let people in, so even though you could show them the office, and there’s nothing super secure on desks or anything you’re not actually allowed to let them into the building to begin with.

Sometimes people just won’t travel, right? If you’re doing an international placement, or if you’re moving from one side of the country to the other, and you want to get a feel for what it’s like then, I mean, it’s a long way to go just to get a feel. I thought well it would be cool if you could kind of get an immersive experience of what it’s like in an office. I downloaded … For this you need a 360 degree picture, and so I didn’t have the camera. You can get a camera, and what Ada recommended there’s a Samsung Gear 360. It takes some pretty sweet shots. Like, it looks beautiful. It does video I believe, or maybe it’s just … Could be just … I’ll check that. It may not do video, but it definitely does some beautiful pictures. It’s 349 quid, so not cheap. Not something that I’m just going to drop 350 quid on to try out, but I probably will now that I’ve seen how cool it is.

I’m not going to tell you to go and do that, but if you do have a phone which I’m sure most of you do there is I think available for the iPhone anyway which is what I had. An app called 360 panorama, and it’s by Occipital. It was a pound 50, so 350 pounds verse a pound 50. I went with the cheaper pound 50 for a change, and essentially it lets you kind of do a panorama like you can do with your iPhone now, but it sets like this globe grid behind it to begin with, and then as you hold you phone over a particular area it records that part of the image and then adds it to this grid, and you basically do a circle and then you look up and then you look down, and you’re done. You have this amazing 360 … You have this amazing … I just muted my headphones instead of the microphone, sorry. You have this amazing 360 view. This is great.

Now, from that you just download it and put it into an images folder like you normally would a regular image and then you’ve got this picture which you can then paint on the sky box, all right? This is amazing, so you can get started with this just having a 360 image, and I think it’s like about 30 lines of code, but for me it was like a copy and paste and update one image reference. It was really cool. What I did is I downloaded this thing and then I took a look around, and I did a 360 view at my desk. Then I went into our kitchen, and I did a 360 view of our kitchen as well. Then once I was finished doing that I downloaded the picture and then I chose the gallery option, so the gallery option is like the 360 image, but it allows you to have multiple images.

What this does is it just gives you the ability to put like just two boxes like a thumb nail to say I want to view that one, and with web VR because you don’t have a mouse or a pointer or a clicker you can write into it that you want a little dot which is kind of life your reference point, or it’s like a pointer. Then if you move that dot onto a square that you’ve designated as a link and you stare at it for a little bit it activates that as if you were clicking on it which is super cool, right? Then the click is you can just control the click event like you do with Java script for normal click events. I’ve got these two boxes now which one says office, one says kitchen, and you look at the kitchen box, and it sets the sky box. The A-sky to use the 360 picture of the kitchen, and then if you look at the office box then it runs Java script and that sets it as the office one.

Now I’ve got this 360 immersive experience with … I mean, I’m going to say it’s not the best picture in the world, but it gives you an idea of what the office is like. Yeah, so now we’ve got this thing, so if I was to say hey you should come and work for us. This is what our offices look like. This is what our kitchen looks like. This is … Maybe not toilets, but you know just showcase some of the different areas. If you’re in a building construction site you can showcase those different areas there. If you’re selling houses why not showcase the different rooms the house has?

One of the things I want to do with it is I’m Australian. I live in the UK. I have a lot of family back in Australia, family and friends, and they’ve never been over to visit. They don’t know I I live. They don’t know what our house looks like. They can’t picture like what a garage is like or a backyard or anything, so I’m going to go … Especially my dad who’s technically not there I would say to be nice. Sorry, dad.  You’re not the most cynical person. The most practical person in the world. He can build. He’s build a barge. He builds some cool stuff, but computers he’s not a fan. I can now do these pictures in rooms and set this up, and my brother who lives over there with him still can give him this phone. He can put on this cheap Google cardboard headset, and he can be immersed. He can see pictures of the kids. He can be involved in it.

It’s really cool, so anything you can do with Java script you can do. You can import objects. You can, if you’ve done a bit of SVG work and sort of moving SVGs around and animations and stuff this is all possible with this A frame. I highly, highly recommend it. We talked about responsive design. We talked about how we’re going to make our information and make our content respond to the different devices that we’re consuming it from. Well, we’ve been looking at screens. We’ve been looking at windows, so I remember someone describing a screen as amazing, but it’s kind of like if you take a picture and then you put it in a frame. That’s kind of … That’s what you get. You can look at it, but you can’t experience it. You can take a video of something which is better, but it’s still a picture, and it’s still a frame, and you’re looking at it through a 16 by nine window. What you want to do is you want to put your head through that window and be there and experience it.

If we can create content which allows people … We are creating content, but we want to be able to create content that allows people to experience it in that way, and at the moment the web can now do it, so with this web VR we’re able to start doing it. Now, a couple of things which I’ve learned over the last couple of days and from the talk is text in web VR is not a great idea. I still want to wrap my head around that a little bit more, but I just have really advised against using huge amounts of text. That causes a bit of an issue if we’re creating loads of content on our web sites, and we want people to consume it, and then we said we can’t use text then we need to find other ways for people to be able to do that. I need to wrap my head around that a little bit more. If anyone has experience on web VR and large amounts of text or being able to consume content, text content, in that way, I’d love to hear from you and learn a bit more about that.  I’ll be updating anyway.

I kind of want to do a responsive, so I’m doing the redesign of the responsive design that is coming along nicely. I kind of want to add a web VR version of it as well, and see how that just might look. I think that would be quite cool. Text, not so great. The other thing is you need the camera, but like I said we’ve got this fall back. You can use an app to do that instead. There’s a whole bunch of different cameras that you can get a hold of, but apparently that one is the best one. The Samsung 360 VR. We also at work we did this project with an energy company, and we built this 3-D model of this island in a futuristic city, and the 3-D modellers, we only got a 2-D picture of it because we were putting it up on a website, and we kind of made it float like an island because it was a transparent PNG, but what we really wanted to do is make it so that people could experience it. They could turn it around. They could zoom into it like a web VR process.

I’m going to get that file back.  I’m going to trial it out and see what it’s like. Now, when you’re working with 3-D objects, I asked Ada and she said, “What you want to do is you want to keep the polycount under 100,000 in total.” I don’t know what that means, but just that’s a tip, right, so someone says because that was a question the 3-D artist asked me. They said, “What polycount should it be?” I don’t know. What is a polycount? Under 100,000 is what you want. The other thing that the 3-D artist asked for was what file type did you need it in? For that, again, I have no idea, but you can work with objects so .obj or .gltf. Again, I have no idea what that means, but if you’re going to grab 3-D objects then use those ones as well.

That’s it for this week. Yeah, like I said, highly recommend. Go check out Ada.is and read about what Ada is talking about. Go use Aframe.io  and just trial something. It’s pretty cool. People will be pretty impressed, and if you want to have a look at the little gallery that I built you can go to vr.Simplethin.gs/gallery.html.  I’ll put links up in the show notes, and you can check that out. See where I work. That would be kind of cool, but that’s it for this week.

Next week I think … Is it next week? We’ve got a guest coming up which is super cool and very awesome. If it’s not next week it is the week after. Definitely the week after we have Una Kravets which is going to be super cool. She runs a podcast called Web Tools with another guest, and I’ve promised her that if she does a song at the beginning of theirs about what she’s going to talk about, so I’ve said that I will sing a song for Una when she comes on which will be an interesting way of going about it. I’m looking forward to that.

Yeah, until then let’s go for a streak of three, and I will see you next week. Until then stay responsive.

Cheers. Bye now.

RWD Podcast 57
23:02
2017-09-22 13:53:31 UTC 23:02
RWD Podcast 57

RWD Podcast 56
33:51
2017-09-22 13:53:31 UTC 33:51
RWD Podcast 56

Show Notes 

ESPN Senior Front End Developer

An awesome opportunity to join a wonderful team and push the boundaries of what is considered story telling on the web. Apply Now.

@supports will change your life

View article

Charlotte Jackson shows just why @supports can be so valuable for the sites that we build.

RWD Survey

Take it now. It’ll take 60 seconds TOPS.

RWD Podcast 55
18:10
2017-09-22 13:53:31 UTC 18:10
RWD Podcast 55

RWD Podcast #54
25:41
2017-09-22 13:53:31 UTC 25:41
RWD Podcast #54

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


RWD Podcast #53
16:20
2017-09-22 13:53:31 UTC 16:20
RWD Podcast #53

Show Notes

Browsersync

I can not believe this is something I haven’t shared with you all, yet here we are. It’s unusual for a tool to make it to the headline but this is such an important tool in the web workflow that it needed to be prominent…. and y’know it’s totally free and awesome.

BrowserSync essentially allows you to test your local dev copy of your site (or live site) across a network of devices, and what you do on one device is immediately visible on the others. Your scroll, click, refresh and form actions are mirrored between browsers while you test. AH-MAZE-ING

New <video> Policies for iOS

When we wanted to share videos on the web we would convert them to animated gifs, and now that animated gif’s are a big thing on the web we are taking those gifs and converting them to videos in process of becoming more performant (a mp4 video of a gif of a video is smaller than the gif). Now safari
are allowing for <video>
elements to auto play IF there is no audio track or if the track is muted. Check out the list of policies Webkit are including to ensure this isn’t abused or annoying for the user.

Offline Google Analytics Made Easy

If you’re jumping onto the Progressive Web App (PWA) bandwagon, and well you should, then you probably want to track analytics when your users are offline as well as online. Now with this library shared by Google you can stored the users actions in IndexDB and send them once the users is online
again. Is there anything Service Workers can’t do???? (rhetorical… I know there’s things they can’t do).

RWD Podcast #52
23:02
2017-09-22 13:53:31 UTC 23:02
RWD Podcast #52

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


Show Notes

Hey everyone and welcome to another edition of RWD Weekly.

In the show this week I discuss both Beacons and HTTPS along with

  • When you might use them
  • How you can implement them
  • What you and your customers get out of it

Physical Web & Beacons

This week I found out that you can enter the physical web world without the use of one of the beacons.
– First beacon from the TheWeb.is
– Used it to locate my keys.
– Idea is that it just broadcasts a URL. Great for discoverability.

from the article:

Not convinced this is the future? Well think about this: what if you were giving a presentation, and could bring along a beacon that sent out a link to download the slides for your presentation? Or what if you owned a sandwich shop and wanted customers to easily access a link to the mobile app for online ordering you spent so much time building? Or wanted to push an updated agenda link to conference attendees as they walked in the door? The possibilities are endless.

There always seems to be a catch. Luckily this one isn’t too bad: just note that you can only send secure web pages (HTTPS), and the URL is limited to 17 characters because of Bluetooth packet size limitations.

If your URLs are too long then use a URL shortening service.

Everyone in the audience to turn their Bluetooth and Location on and for iOS users to add Chrome to their notification center (I’ll explain why they have to do this later), then I ask to raise hand if they got the URL on their phones.

– android users automatically get notifications when a Physical Web is within range

– iOS users first need to add Chrome to the Today section in their Notification Center. There is a great step-by-step tutorial for that on the Physical Web website.

HTTPS

The other great story this week is that the web has now doubled in the number of HTTPS websites being served in the past year.

This is amazing and I think it’s down to a couple of reasons.

  1. it’s a lot cheaper to go https now.
    1. Lets Encrypt provide free SSL certificates
      – with that a lot of other providers have driven their prices down
      (there was never a reason to set the price so high, it was just something we did).
  2. Large services are serving them by default
    1. GitHub Pages
    2. WordPress
  3. Services such as Cloudflare make it super simple and free.
  4. Carrots — Not the ones that rabbits and reindeer eat, but ones that compliment the stick.
    If you want to take advantage of things like Geo Location, the speed of HTTP2, the amazing-ness of Service Workers and progressive web apps… even serving your sites on physical web beacons… then they need to be on HTTPS…

RWD Podcast #51
22:27
2017-09-22 13:53:31 UTC 22:27
RWD Podcast #51

I talk about using a combination of your own CMS, RSS feed and something like IFTTT to post it for you. I use IFTTT for posting articles to Surf the Dream, saving images from Facebook, posting news articles to Facebook… although now I’m trialling Zapier.

Speaking of WordPress, I also delve into some issues that I recently came across with a clients site.

  • changing URLs – why that can be bad
  • Links don’t work
  • no natively support 301 redirects
  • Page templates failing

RWD Podcast #50
15:49
2017-09-22 13:53:31 UTC 15:49
RWD Podcast #50

RWD Podcast #48
33:53
2017-09-22 13:53:31 UTC 33:53
RWD Podcast #48

This week we take a quick preview of the up coming RWD Summit and offer up a discount code for 20% off (but you have to listen to get it, of course). While on the conference band wagon we also talk about the CSS Dev Conference opening up for proposals… get your talk in now.

Google release their new RWD resizrvery similar to another tool we’ve seen.

Finally we talk about content modelling (with Jekyll) and how it makes it a lot easier to roll out things like Apple News feeds or AMP pages if you decide you want to push your content out there as well. Speaking of AMP pages, I also talk through how you set up an AMP page properly and the bits you need to include (but are not told about).

RWD Podcast Episode #47
68:52
2017-09-22 13:53:31 UTC 68:52
RWD Podcast Episode 46
30:26
2017-09-22 13:53:31 UTC 30:26
RWD Podcast Episode 46

RWD Podcast Episode 45
26:42
2017-09-22 13:53:31 UTC 26:42
RWD Podcast Episode 45

RWD Podcast Episode 44
35:36
2017-09-22 13:53:31 UTC 35:36
RWD Podcast Episode 44

Hey, everyone, and welcome to Responsive Design Weekly Podcast, episode number 44. My name is Justin Avery. I am your host and the curator of the Responsive Design Weekly Newsletter, a weekly newsletter all about responsive design. A whole lot of cool stuff has been happening since the last time I ran one of these. This is episode 44. The last 2 episodes were all about the presentation that I gave over in Germany, in Berlin, and since then, there&rsquo;s just been so much happening, tons, and I just wanted to share a couple of those things with you as well.

This week, we don&rsquo;t have a sponsor, but what I will shout out is that we&rsquo;re finally getting the Responsive Design notebooks printed up, so just in time for Christmas. Although, it was supposed to be at the beginning of this year. I&rsquo;m doing a set of 3 notebooks that you can get a hold of, so the 3 notebooks will be covering the 3 tenants of responsible design or responsive design, so we&rsquo;ll have our fluid grids, our flexible media, and our media queries as well.

Each of them have 36 pages inside and a little quote in the back from some of the leading thought people, our thought leaders, so there&rsquo;s a little bit in there from Brad, a little bit in there from Ethan, and also a little bit from the man who I think started this on this path a long time ago which is Mr. John Allsopp with his “Dao of Web Design.&rdquo; Yeah, so that&rsquo;s coming up. If you go to backpocket.co, backpocket.C-O, you can put your email address in there and be one of the first to find out when they come available. There&rsquo;ll be a limited edition of 200 available in the sets, [00:02:00] so be quick, be very quick, and grab it. Yeah, more about that in the weeks to come.

Recently, I was lucky enough. I head over to the States for the Adobe Max Conference. It was a 3-day conference. I was there for a couple days either side. It was just amazing. It was really cool. They put on a huge massive big event. The party that they had there, it had donuts. They had a doughnut wall, which I&rsquo;ll put a picture up in the show notes. It was crazy. They had some really great keynote speakers, and some of the things that they were sharing about where they&rsquo;re heading with the products was great. They had some really good product demonstrations.

I think they&rsquo;re doing &hellip; Adobe are actually doing a pretty good. Given where they were for a little while, they&rsquo;re doing a really good job in listening to what you and I as web designers and web developers, what we need and what we&rsquo;re missing in our day-to-day workflow like the web is continually changing, so is the way that we&rsquo;re building, and we need our tools to change along with us as well, and it&rsquo;s just becoming &hellip; I think their focus has been a lot more around collaboration, but they&rsquo;ve also had some pretty cool stuff improved as well, and there&rsquo;s a new product coming out, which is a project called “Comet,&rdquo; which I might talk about in a little bit as well.

Yeah, like all great conferences have &hellip; It&rsquo;s not so much about everything that you see and you&rsquo;re presented, but it&rsquo;s about the people as well. This one, the Adobe Conference was no change from that, so there were some amazing people there. I got to actually meet the people from Comet and who are working on it. I might as well talk about it now. [00:04:00] Comet is a new kind of prototyping tool that Adobe are coming out with. It gives you the ability to mock up designs quite quickly and allows you to reuse patterns, so if you have a particular pattern.

Just think we&rsquo;re doing a &hellip; we&rsquo;re building Pinterest, for example, and we want to mock up how that might look, so you might have card view or you might have a multi-card view. You can build out 1 card, and then option-click and create a second card, but then you can turn that into like a module. As you click and drag the &hellip; if you were to make it larger, so wider or taller, instead of it stretching the width of the card itself, what it would do is it will turn into like a repeater, so it will repeat it to the right, and it will repeat it low down as well.

The other cool thing is that we usually design these things with Lorem Ipsum. You can put dummy data in there, so if you type a name into a name field and then something into a description field, it can randomize stuff, so it knows that you&rsquo;re putting in name, so it will put in random names. If you have a first name and second name, it will put in random first names and second names, so you can get the feel of like, “Is it going to go over 2 lines? How is the design going to look if someone&rsquo;s name is really, really long?&rdquo; They even extend it further past that where you can drag &hellip; you can have a whole bunch of images sitting in your library, and it will automatically pull those images into the little pins as well, so you can see how real images will look.

The great thing though about that is when you extend it further and you can go &hellip; so if we were redesigning Pinterest in this example, we could go to pinterest.com, and we could have a look at a board, and I could &hellip; from Comet, I could like &hellip; I can&rsquo;t remember what the command was, but just say it&rsquo;s like a right-click on the title, and then you go over, so you&rsquo;ve got a page in your design [00:06:00] full of these cards. Right-click on one of the titles, go to pinterest.com, and select the title of a range of cards in a view as well, and it&rsquo;s smart enough to look through all the HTML, find out what elements that title is, and then pull back all of the content, and populate your design with the content on the website. If you were redesigning a website, you can redesign it with real data as well, which I thought was super cool, but that&rsquo;s just like one of the small things.

There&rsquo;s another guy who I hang out with quite a bit too, Jay [Messing 00:06:38]. He&rsquo;s over based in Germany. He&rsquo;s the guy who came up with the Open Device Lab or one of the guys that came up with the Open Device Lab. The whole concept of the Open Device Lab, we want to test on as many devices as possible, right? We build these websites, they&rsquo;re responsive. We need them to work. We build them, so that they work across a variety of devices, but then most of us, a lot of us will just test inside of Chrome or Safari, and open up DevTools, and move things back and forth, but you really need to get on to devices to check out how they actually feel and how they interact with the site. It doesn&rsquo;t make sense. Is it comfortable?

Now, buying devices is really, really expensive. Really expensive, so this Open Device Lab allows you to go and look at a world map. You go to opendevicelab.com, and you get to see a world map, and you can see where there are device labs near where you live. You can go to that device lab, and you can book some time, and go in, and test your websites on someone else&rsquo;s devices. It&rsquo;s an open device lab. You don&rsquo;t have to pay for any of these.

Equally, if you&rsquo;re a company who is fortunate enough to be able to afford all these devices and you want to share that with the community, you&rsquo;re not using them all the time, then you can register yourself on [00:08:00] Open Device Lab. Register the devices that you have, and then other people can come, and book time with you, and sit down, and test their websites using your devices, so a really, really cool idea.

Who else was there? I caught up with Brad Frost. He was there, and he introduced me to one of his friends , Dan Rose. Dan Rose is &hellip; he was a really cool guy. We hung out a bit. We went to the Kings&rsquo; hockey game. I&rsquo;m from Australia, so I don&rsquo;t actually think what ice hockey is like and about, and so I went in a t-shirt, and it was really cold. I didn&rsquo;t think that perhaps the stadium needs to be chilly to keep the ice from melting, so I froze for most of the game, but he&rsquo;s really cool, Dan.

He runs a website called “Photoshop Etiquette,&rdquo; so photoshopetiquette.com, and you should all go and check that out. If you are a designer and you work in Photoshop, go and check this site out. It tells you how not to be a pain in the butt when you hand your designs to a developer. It gives you tips on how you should be adding layers, how you should set things up, how you might be able to set your workspaces up or your outboards. If you&rsquo;re a developer, go and check it out. See how the designers will and can lay their Photoshop files out to make your lives a lot easier as well. Yeah, definitely go check it out.

He&rsquo;s done a lot of really cool work around Photoshop and workflows, wrote a book for Adobe called “Responsive Design with Photoshop.&rdquo; He does not advise you to design responsively inside Photoshop. You can&rsquo;t design for every single device and every single break-point unless you&rsquo;ve got a hell of a lot of time, but the book goes through and explains when [00:10:00] &hellip; what you should be doing in Photoshop, and where you should be jumping at, and trying to get in the browser, and get into the code as quickly as possible, so a lot of experience around that sort of area as well.

Now, I&rsquo;m going to try and get Dan &hellip; or Dan, he&rsquo;s going to come on the podcast in the next few weeks, and we&rsquo;re going to talk about that. We&rsquo;re going to talk about a responsive workflow, and he&rsquo;s going to talk through Photoshop and share his experiences of how he designs and how he works with developers and other designers who have more &hellip; so other designers that might have a lot of dev skills like a lot of HTML and CSS skills, and also, how he works with people that have limited dev skills who have never used HTML and how he works with them in different ways as well. He is primarily a Photoshop guy. A designer, but he does have his like responsive badge coding up site, so it should be a really good episode. I&rsquo;m really looking forward to that as well.

There&rsquo;s another guy there called “David Blatner&rdquo; as well, and he&rsquo;s more of an Illustrator and InDesign guy. He runs a couple of different conferences, and I think even like InDesign magazine or something. I&rsquo;m not a designer. I&rsquo;ve never heard of that magazine before, but he was really a nice guy, and we were talking about &hellip; because he was into InDesign and stuff like books can be written through InDesign, all these design and laid out type set, and we&rsquo;re talking about bringing books into the browser to make the content universally available across the world or universally.

It really struck a chord with me like this conversation because I&rsquo;ve been working on a side project of taking a PDF version of an old book, a science-y book, a universe-based book, and I&rsquo;m trying to put it across to HTML and CSS to make it more accessible [00:12:00] for everyone to be able to access it. It&rsquo;s an unsolicited side project, but I&rsquo;ve really enjoyed working on it. I want to make it offline and available for everyone.

I started doing a bit more research around it and seeing some other books as well, and there&rsquo;s a whole bunch of really great examples where authors publish books. They&rsquo;re for sale. You can download the PDF. You can download the EPUB version, but &hellip; and they might still be in print as well, so you can get a hard copy, but they also provide all of the content online for free. If you want to find out about it, then you can go and learn about it, but if you want to buy and you want to contribute to them, then you can buy it.

This one is learnpythonthehardway.org. Aaron Gustafson is &hellip; just released a second or is in the process of releasing a second edition of the “Adaptive Web Design&rdquo; book, but if you go to adaptivewebdesign.info, you can either pre-order the second edition, or you can read the entire first edition on the web as well. Brad Frost is writing a book, “Atomic Design in the Open.&rdquo; As he writes each chapter, it gets added to his site. That&rsquo;s at atomicdesign.bradfrost.com. Mark Boulton as well, he wrote &hellip; Jeez, I can&rsquo;t remember the name of his book. “The 5 Simple Steps: Web Design.&rdquo; I&rsquo;ll put it on the show notes, but that is another one (ed: it was actually Designing for the Web).

Lara Hogan with “Designing for Performance&rdquo; so designingforperformance.com. Again, there&rsquo;s a button there to buy it, but otherwise, you can read the whole thing online as well. Also, there was one I was speaking to, a former podcast guest, Stephen Hay. He really gets into this sort of stuff in terms of manipulating Markdown. [00:14:00] He uses a tool called “Dexy&rdquo; to work with his content, and he mentioned one called “practicaltypography.com.&rdquo; That&rsquo;s something that I&rsquo;m looking at, at the moment, so this concept of writing content in one place like in a Markdown sort of way.

I should point out that people are &hellip; that like Aaron, Brad, Lara Hogan, they all used Jekyll, I suppose. Like a static site generator, they created their content in Markdown, and then they ran it through a static site generator, which punched out a website at the end of it, which they then went through and hand-coded all the stuff that they want to, but the whole idea of like writing once and publishing everywhere is like the idea that we have with responsive design as well. We have to have it in 1 centralized location.

Anyway, this “Practical Typography&rdquo; book is just that. It&rsquo;s written, and then it&rsquo;s using a thing called “Pollen&rdquo; which is able to push it to EPUB. It&rsquo;s able to push it to PDF. It&rsquo;s able to push it to .MOBI. It&rsquo;s able to create a book as well. I&rsquo;m going to look into that, and try and get something, which we&rsquo;ll be at a &hellip; republish this, this thing. I&rsquo;m only really concerned about doing the HTML version because the other versions have already been created and are being sold. Yeah, it&rsquo;s really, really interesting, and that&rsquo;s the side project that I&rsquo;ll be working on over the next couple of months anyway, so that&rsquo;s excellent.

One of the things I&rsquo;m trying to do is mostly make these, the books, available offline. When I was going to fly over, I wanted to do some work on this side project, and it involves a little bit of jQuery because I&rsquo;m a little bit terrible with JavaScript. I can get by with jQuery, but I often have to refer to the documentation, and that&rsquo;s hard to do at 30,000 feet.

Now, [00:16:00] I haven&rsquo;t used &hellip; I didn&rsquo;t have Dash installed, which is apparently the go-to tool and what I should have, but I went to a site called “devdocs.io,&rdquo; and that allowed you to save different development documents offline, so when you went back to that URL, all of those docs would be available to you to check out like I had problems with my jQuery I couldn&rsquo;t work out, and so I went back to devdocs.io on the browser in the plane at 40,000 feet, 50 &hellip; whatever. However high you fly. I typed in the URL, and then bam, I had all the information that I needed.

I really love that idea of not just every device, we&rsquo;re creating content for every device in every scenario, but also, every data connection. If you&rsquo;re not connected to the network, is your content going to be available anyway? That is something that I think is the next thing that we&rsquo;re all working towards. The other thing that I&rsquo;m working towards is like making things more performant. Recently, the last couple weeks anyway, they had the release of AMP, so the Accelerated Mobile Pages. This is the new thing that Google kicked out there, and the whole idea is that it makes things faster.

When love when things are fast and when things load fast, but I had a carpool of problems in understanding what they&rsquo;re actually trying to do. For one, the A-M-P Project or the AMP Project requires you to create a new template layout for your site. It forces you, and I do mean force, so you to include this. You have to include the AMP JavaScript in the header of the document. If the AMP JavaScript doesn&rsquo;t load, then your page doesn&rsquo;t load. For me, that&rsquo;s against the [00:18:00] natural way that we try and get people to build things like, “You should build them progressively, you should make your content available, and then you should lay things upon it.&rdquo; To come up with a solution to a faster &hellip; to making faster websites and then forcing this JavaScript in there, it goes against the grind a little bit.

The other thing that it requires you to do is you need to use only a subset of HTML elements, and a lot of those elements then get renamed. For instance, if you want to include an image within your AMP document, then you need to not use the image tag. You need to use “AMP-image&rdquo; as the tag instead, and then there&rsquo;s a bunch of HTML tags that you are not allowed to use. I can&rsquo;t recall all of them. I&rsquo;m going to say things like you can&rsquo;t include things like iFrames. Basically, they&rsquo;re trying to make it as performant as possible, so they&rsquo;re stripping out things that might counteract to that performance.

Now, for me, it &hellip; this approach is like going back to an MDOT site. All right? In the past, we used to have desktop sites and mobile sites, and the mobile would have an entirely different structure around it. It would have different content in it, and it would only be available for mobile phones. This feels like the same thing. It feels like I need to create a new document to house new content within that just to take advantage of this AMP process.

Now, you can use &hellip; you can do it though like the focus I think shouldn&rsquo;t be about, “Let&rsquo;s get on to AMP, and let&rsquo;s start booting our pages there, and then that will solve our performance problems. Then, we can make our other site really, really big and have loads of images, [00:20:00] and it doesn&rsquo;t matter.&rdquo; That&rsquo;s not the approach like I would focus upon making your site as bleeding fast like bleedingly quick as possible. Once you&rsquo;ve done that, then you can look at your AMP stuff because effectively, AMP is just a way of making the web faster, so if you just made your website faster, you wouldn&rsquo;t actually need to use it.

Now, the good thing is it&rsquo;s not that difficult to set up, so &hellip; and complain a little bit about it, but effectively, if you already run an RSS feed, this is essentially what you&rsquo;re doing. All right? RSS takes the content of your page, and then repurposes it within an XML structure effectively, and then you can customize what you want in there. AMP does the same thing, so I created a new template. I created a new layout for the content area. The CMS that I use has like a template as a wrapper, which would be the header, a HTML head, body tag, and then closing body tag, and closing HTML, and then a layout wrapper, which then just lays out how the page structure would normally look.

For me, it took me an hour to set up. I didn&rsquo;t include any styles within it because I didn&rsquo;t want to copy and paste styles, and spend time. It was just to get it going, and I didn&rsquo;t mock around with the images at all. I included 1 image at the top of the page, which was like the article feature image. Imagine that like as a thumbnail kind of image, so I used the AMP image for that, but otherwise, I didn&rsquo;t worry about converting image tags within the body of the content itself into AMP image tags, so I don&rsquo;t know how that&rsquo;s going to break.

Like I said, it&rsquo;s like using RSS. If you&rsquo;ve already got that, it&rsquo;s not too much of a step. [00:22:00] The only other thing you need to do, you need to put a meta tag in the head of your document, so of the original document on your website. You put in a meta tag, and I think you do a “rel,&rdquo; a “rel AMP.&rdquo; I&rsquo;ll put it in the show notes to relate it, and then you give the URL of the AMP version of the page. Then, on the AMP version of the page, you point back to the canonical version of the article as well, so it&rsquo;s cool.

Again, I&rsquo;m not really sure it&rsquo;s the greatest thing in the world, but for an hour&rsquo;s work, at least it&rsquo;s up there. You can check it out. I don&rsquo;t think I&rsquo;ve set it up on the podcast page, but if you do go to one of the articles page, if you go to “Articles&rdquo; in the menu, and then check out one of the articles, then you&rsquo;ll be able to see the link to the page, and then you&rsquo;ll be able to grab the link for the AMP page, and then open that up, and check that out as well. How you register it with Google, I just assume they&rsquo;re going to index my pages, and then find that canonical link, and then go and index the AMP pages, but I&rsquo;m not actually sure. If anyone does now how that might happen, do let me know.

Google, Google do some cool things. This is one of them. I know they&rsquo;re trying to make the web faster. One thing that they did to make the web faster was they removed that 300-millisecond tap. If you had a mobile, a touch device on a webpage, it would delay 300 milliseconds on a touch to ensure that it wasn&rsquo;t going to be like a touch scroll. You put your thumb on the screen, and then you just push it up, and that&rsquo;s a scrolling action. If every time you did that and you were hovering over a link or a button, you don&rsquo;t want to fire that, and then just go to a different page every time you&rsquo;re going to scroll. That would be super frustrating.

The browser vendors put in [00:24:00] this delay to see if you like touched like down and up, and then it would do the link after 300 millisecond. Whereas if you left your finger there and moved it, then it would know it was a scroll event, and then it would scroll the page for you. On any device or any website on a Chrome browser on Android, that has &hellip; or the viewpoint meta tag set to width equals device width, then it removes that 300-millisecond delay when clicking and still avoids the incident of accidentally clicking through to links when you&rsquo;re scrolling as well.

Now, WebKit have just announced that they&rsquo;re doing the same, which means Safari users like us &hellip; yay, or us. I say “us&rdquo; because I&rsquo;m an Apple person. We&rsquo;re going to get that on the iPhones, which is awesome, but one of the problems is it&rsquo;s been released now, so they say, “Yes, we&rsquo;re going to do it now,&rdquo; but the release cycle for Safari is just diabolical. They release it once a year when they release the update to the operating system, so we&rsquo;re not actually going to get it until like September of 2016. Thank you for that, Apple. You guys rock in the most sarcastic way possible. It is super like frustrating to have this sort of things. This sort of thing is like so close, but then not able to actually take proper advantage of them.

Fortunately though, our great friends at the FT, the Financial Times labs, they&rsquo;ve come up with a lovely little script which allows you to bypass the whole 300-millisecond delay, so if you go to GitHub &hellip; GitHub. Is there a website called “GitHub?&rdquo; I wonder. If you go to github.com/ftlabs/fastclick, [00:26:00] it will remove that 300-millisecond, 350-millisecond delay from clicks and make your websites just feel so much more responsive. Definitely, go and check that out. It requires JavaScript to work, but hey, so does AMP, so sometimes. If it doesn&rsquo;t load, then you&rsquo;re just going to get the same use case, the same experiences as not loading it and you&rsquo;re not losing out on anything.

Now, that is designed to make it feel faster, make the web feel faster, and when we say “feel faster,&rdquo; we&rsquo;re always equating this to, “How does a native feel? Like how much faster does a native app feel?&rdquo; It feels native. It&rsquo;s smooth. It&rsquo;s 60 frames per second. I was having a long conversation/argument with a really good friend of mine on the way home from the football the other day. He is brilliant. He helps me with my hosting. He gets my website running super fast. He&rsquo;s been a massive help over the last couple of years, but we&rsquo;re talking about this new app that was coming out and how it didn&rsquo;t have a mobile side. It was native only.

We know that Instagram went this way for a little while, but I&rsquo;m sure even from the get-go, Instagram still allowed you to view pages. You just couldn&rsquo;t do anything, so if I took a picture of something, I could share it with someone. If they didn&rsquo;t have Instagram, they still got the web version, and they could see the image. Now, I want to say if they didn&rsquo;t have that maybe at the very beginning, it was a real pain in the butt because someone would send a link or post a link to their Instagram image, and then you&rsquo;d go there, and it&rsquo;d be like, “Bop bow, you need to install [00:28:00] Instagram,&rdquo; and that&rsquo;s super frustrating like really, really frustrating.

Anyway, so we&rsquo;re having this chat, and we&rsquo;re talking about this new app, and it&rsquo;s only native, and they&rsquo;re not going web because they don&rsquo;t feel as though web provides a good enough experience for people and that the web is dead. Now, not his words. He&rsquo;s recycling the words, but yeah, like the web is dead, and that native apps were the future, and the web will die this death.

Now, I remember seeing a presentation recently where they put up all the wide articles that mentioned that the web was dead all the way from like &rsquo;98, &rsquo;99, 2001, 2003, 2005, 2007, 2009, 2011 like it just keep coming up, “The web is dead. The web is &hellip;&rdquo; this time, definitely dead that native is going to kill it. Whenever I hear it, I just giggle to myself and like, “Yeah. Okay. Fair enough. The web is going to die. Sure. Native is the future.&rdquo;

I can see their point. It&rsquo;s just going &hellip; it&rsquo;s a bad user experience. They want to build their brand on a fast, sleek experience, but I think the experience of clicking and receiving a notification about something, and not being able to access it unless you have a specific phone or a specific operating system, or if you have enough space on your phone to be able to download the app, if you have a good enough connectivity to warrant downloading 50 megs, if you have a good enough connection. Not just like the speed of the connection, but how&rsquo;s your data plan?

I don&rsquo;t know how big this app was, but I&rsquo;m talking about like 50 or 100 meg. That seems a lot to me to be able to just view some content and a few pictures, but you have to download it like you [00:30:00] still have to download it. There are no times ever when you receive something that you have to download the internet. You never have to download the web. All right? Every device comes with a browser. If it doesn&rsquo;t have a browser, it probably doesn&rsquo;t connect to the internet, and you probably want to be able to get your native experience on that device as well.

For me, he was like dangling a massive red flag in front of my eyes that&rsquo;s like waving in front of me just waiting for me to charge, and charge I did. I stuck up for the web, and the way of building things responsively, and also that it doesn&rsquo;t need to be slow. We have things like this FT click thing. Now, I agree, it will be &hellip; things will be sleeker on native because you have &hellip; you&rsquo;re closer. You&rsquo;re like 1 layer of obstruction, closer to the operating system. You can tap into &hellip; just things will work faster that&rsquo;s naturally. It&rsquo;s a natural thing.

In the talk that I did at the MOBX Conference, I don&rsquo;t understand why you would have one over the other, right? I can understand why you would have a website over native apps because it&rsquo;s universal and not everyone is going to download the native app, but I don&rsquo;t understand why you have a native app without a website. There&rsquo;s no reasoning around it. You&rsquo;re just cutting off your nose despite your face by saying, “This has to be special. Only special people can access this particular content. I don&rsquo;t really want to access the universal audience that I have at my fingertips if I had a web version of this.&rdquo;

Anyway, we spoke lots about it. We argued quite a bit, and then we [00:32:00] just bowed and agreed to disagree. It turns out that on further conversations, and when we looked into it a little bit further, and spoke to a few other people we know, it is on this company&rsquo;s roadmap, and they are heading in that direction now, whether it was always that plan or they come to the realization, but it&rsquo;s something which I totally agree. Native apps are great. You do need them for some things to be super fast like I use Slack. It&rsquo;s great. I have it on my tablet and my phone, but I also have it in the browser. All right? It&rsquo;s just a good experience. If I were only able to access it in the browser, I would be absolutely fine with that because it does what I need.

That&rsquo;s my week. That&rsquo;s what&rsquo;s been happening. Yeah, we&rsquo;re going to &hellip; I&rsquo;m putting a couple of these links that I&rsquo;ve talked about so far into the newsletter this week. If you&rsquo;re not subscribed to the newsletter, make sure you head over to responsivedesignweekly.com and drop your email address in there. You&rsquo;ll get a newsletter once a week talking about all this kind of stuff with links that you can go off and check things out yourself.

Next week, we&rsquo;re going to be talking to &hellip; I say “we.&rdquo; I&rsquo;m going to be talking to the team from ZURB. ZURB are the guys that build Foundation. It&rsquo;s like Foundation and Bootstrap have been going head to head for the last couple of years. ZURB are actually about to release Foundation Version 6, and they&rsquo;ve cut their code by 50%.&nbsp;

They&rsquo;ve made things faster. They&rsquo;ve made them smarter.

What we&rsquo;ll be doing is we&rsquo;ll be catching up with some of the developers who have been putting this stuff together and talking about why they changed it, what has changed on the web for them to warrant changing the [00:34:00] framework in this way. Also, if you are running something like Foundation, how people be able to go and do updates properly. Can they just drop it in there, or is there like a few steps that they need to go? Also, where they&rsquo;re looking at next like what they think the next big problem is to squish out.

I also mentioned we&rsquo;re going to be talking to Dan Rose. It&rsquo;s coming up, so that&rsquo;s going to be all about workflow, and working with Photoshop, and the responsive design workflow in teams which will be really cool and really interesting. Then, also, Rachel Andrew who has agreed and said she&rsquo;d be happy to come on the show as well. Rachel is going to be talking about her thoughts and knowledge on the grid layout specification, which is really exciting. It&rsquo;s bed down a little bit now. It doesn&rsquo;t change as much as it was, so she&rsquo;s been able to create some really awesome examples and build up a little bit of a talk around. I think in the moment, she&rsquo;s in the States talking at an event, but &hellip; so it will be really good to get her on and chat through that stuff as well.

Yes, we&rsquo;ve got some really great guests and talking about some really great topics on the way over the next couple of weeks. Yeah. Thank you for tuning in and listening. Please go ahead and rate the show up 5 stars. Leave a comment. That&rsquo;s how people find out about it. Tell your friends. Tell your friends to subscribe. If you have a topic that you want me to cover, or if you would like to join me and talk about some of the things that you&rsquo;ve been doing at work, or some of the things that you&rsquo;ve been working on, or some of your own thoughts and ideas, then do reach out. You can reach me the contact form link in the footer, but until next week, stay responsive, and I will see you then. Cheers, everyone. Bye.

RWD Podcast Episode 43
46:40
2017-09-22 13:53:31 UTC 46:40
RWD Podcast Episode 43

Presentation Slides 

RWD Podcast Episode 42
22:29
2017-09-22 13:53:31 UTC 22:29
RWD Podcast Episode 42

RWD Podcast 65 : Public speaking, Hololens, NBC Redesign
20:55
2017-09-23 00:10:05 UTC 20:55
RWD Podcast 65 : Public speaking, Hololens, NBC Redesign

Show Notes

RWD Podcast 64
15:45
2017-09-23 00:10:05 UTC 15:45
RWD Podcast 64

I’m just back from a few weeks in Australia visiting family and getting the podcast back up and running again. This week we go through the best links for the weekly newsletter.

RWD Podcast 63
11:07
2017-09-23 00:10:05 UTC 11:07
RWD Podcast #62
23:33
2017-09-23 00:10:05 UTC 23:33
RWD Podcast #62

RWD Podcast #61
58:00
2017-09-23 00:10:05 UTC 58:00
RWD Podcast #61

RWD Podcast 60
40:22
2017-09-23 00:10:05 UTC 40:22
RWD Podcast 60

Hey everyone and welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly newsletter, a weekly newsletter all about responsive design and other front-end cool stuff. This week I’ve got a small guest but it’s not until the end and I’ve got a piece that I’ll add at the end of the podcast, and the reason why I say it’s a small guest is because they’re small in stature it’s my little boy Noah and he decided that he wanted to do some recording over the weekend so we did a little short podcast together. If you don’t like the opinions of a three year old then feel free just to skip over it. So that’s why I’m not including it until the end. He probably has some better opinions than me a lot of times but, you know, he’s a little childish. Takes after his dad.

But this week to start with I’ve got a lot to offer everyone, so I’m going to get to that first. We’ve got a couple of sponsors this week which is fantastic and they’re giving everything back to us which is great. Or you, the listener. So, conferences, we’ve got a bunch on. We’ve got three conferences coming up. One in the states, one in the UK, and one that is global that you can view anywhere and the first one is the global one.

So this is the SVG online summit and anyone can join it, it’s global, it’s an online thing. There’s a tonne of talks during the day. Actually, let’s go through it properly. A better-prepared person would have all this here. So SVG Summit, if you go to svgsummit.com then you can go check it out. If you use the discount “RWDWEEKLY“, all capital letters, that’s good for 20% off. Now it’s coming up on the 15th of February so it’s not too far away. Starts 10:00am Eastern Standard Time, 9:00am Central Time, and it has six speakers throughout the day. Chris Coyier, Sarah Drasner, Amelia Bellamy-Royds, Dudley Storey, Clark Wimberly, and Kevin Ball and they’re all talking about SVG and different ways to use it online. It’s going to be super cool.

And the great thing about these online conferences is you don’t have to spend any money flying there, you don’t have spend money on accommodation. I love flying to places but it gets expensive when you add everything up, and the time you’ve got to take off. So this just pop it on your computer at work, put your headphones on, and just learn lots. They’re really cool conferences. I’m fortunate I’ve been to a couple where I’ve partaken in a couple, watched on the computer, and I presented at one as well. It’s just so much fun. Really good, the guys do a good job there.

The second conference we’ve got is for the awwwards, so this is for folks in the UK or Europe and it’s coming up fast. It’s the awards conference so A.W.W., see what they did with the name? That’s coming up on the 2nd and 3rd of February so I’m going to be going along there and I’m going to be hanging out with some friends from the Adobe XD Team who I caught up with late last year and I actually want to speak to them a little bit more too because I think the XD stuff is really interesting in terms of like rapid prototyping and being able to get interactions and things on the screen that clients can see. So I kind of want to try a couple of screen-casts and see how it might work out to improve our responsive workflows and stuff.

So if you want to go to that you can go to conference.awwwards.com/london2017. Do a search for “awards conference in London” and that will come up there, and if you use the discount code “responsivedesignldn“, it’s like responsive design London, that’s good for 10% of the ticket as well. They’re also going to be doing a live stream of the conference out as well and Vitaly from Smashing Mag is going to be there to kind of host that as well, so that should be really cool. I want to catch up with him as well because Smashing Mag are doing this huge redesign. They’ve had people like Sarah Souiden working on it, I think Dan Mall had done the original designs perhaps as well. It looks really good. It kind of looks a lot like the Responsive Design redesign as well so I’m happy that the design that I’ve gone with, with the guys from No Divide, that they’re going in a direction similar to Smashing and I think that’s a good direction.

But as part of this, Smashing Magazine and Vitaly, they’re looking at different ways of generating an income for a publisher. So it’ll be really interesting to see with all the ad blockers in now, they don’t make as much money through ad revenue, so you need other ways to supplement the income to continue the business. And Smashing Magazine is a big business so it will be really interesting to see what he’s doing to try and tap in with that. I think he’s going along a little bit of subscription model which I think is cool. I’d be happy to subscribe to a magazine like that, they put out a lot of good stuff. I feel like I should be paying them for doing that as well because they pay all of their writers and I really like it.

And then the last one is for people in the states most likely, or the Americas, and that is called “ImageCon” so it’s imagecon.com and if you use the code “RWDWEEKLY” it’s good for 50% off your ticket which is really cool.

Now I wrote a piece earlier in the week about how to approach typical problems when uploading large numbers of images and it’s actually what I’m going to be talking about after this and running through with you today. If you want to head along to the conference that will let you understand and deal with bigger problems than just how to get images optimised properly and rolled out on your screen or near different sites. They’re going into a lot of detail like the different problems that we have with images at the moment, and it’s on the 1st of March. So 1st of March in San Francisco and it’s got some amazing speakers like Jason Grigsby, they’ve got Allison McKnight from Etsy, Vitaly as well, we just talked about Vitaly from Smashing, Steve Souders like the performance person getting around so he’s at SpeedCurve these days. So all these great people talking about images and it should be a really good conference. That’s imagecon.com and use “RWDWEEKLY” for 50% off your ticket.

That’s all the discount stuff at the top of the show so you can save 20%, 10%, 50%. Great stuff.

So for this week I wanted to talk about watching your weight. And I’m not talking about like the post-Christmas holiday weight and “Oh my goodness, I’m going to put a New Years Resolution to never eat unhealthy again, and I’m never going to drink again.” We’re talking about image weight on your websites. And the reason why I wanted to talk about it this week is because, like I said a bit earlier I wrote an article this week is because I came across a tweet from Andy Clarke. Now Andy Clarke has published this awesome article on his site called “Designing Inspired Style Guides” and it was a talk that he delivered, and he doesn’t think he’ll be able to deliver the talk again, but it got a really good reception and so he thought, “Rather than waste all of this great content, why don’t I turn all of this great content into a super long blog post? Then more people can enjoy it.” Which is like, kudos. It’s a really good, long detailed article about style guides. So kudos to Andy for doing that.

Now in the second paragraph of the article he even says, “This page contains a lot of images.” And he says, “This page contains 35 MB of images, I’ve optimised them as much as I can but you probably don’t want to load this page on your mobile data plan.” So that’s great that he gave people the heads, there’s just the issue that by the time I’ve read that, a lot of the images which are on that page are already starting to download. Now I suppose thing in this is that there were so many images on the page, so there’s like 150 images, there’s so many there that it won’t have downloaded that many because of the number of connection that it has. Or it needs to make the number of HTTP requests. So by the time I read that I could hit stop and then save my data plan a little bit if I was reading it on my phone or even my desktop I had time to stop it.

So I want to get this super clear up front, Andy did as much as he could do with knowledge that he had on providing an awesome resource to everyone and giving them a heads up. Like that’s awesome. Not many people would do that. And I thought, “I wonder if there was anything that could be done to perhaps make that experience a little bit better for users. Let’s see how this goes.”

What I did was first I opened up Chrome Dev Tools and I opened up the Network Panel. There’s an option in the Network Panel where you can set a throttle, so you can say rather than run off your regular connexion to the internet you can set it to run at 2G or 3G or good 3G or 4G or GPRS so you can test different network conditions. So I tested a mobile network condition at regular 3G, ticked “Disable cache” because I’d used the page before, and then refreshed the page and started watching it. And once it had finished loading I noticed it was slow because it was on 3G but all of the files that were being served were PNGs, that was one thing that I noted. And immediately there come a thought, “That must have been the default export option for the presentation he did, Keynote or PowerPoint.” I also noticed that all of the images were being loaded regardless of whether or not I had scrolled down the page to view them, and the last thing I noticed was that every single image required it’s own HTTP request.

So with 150 images that’s 150 round trips between your browser and the server and going through network connexions. With that information I thought, “Right. Let me address those images and see if I can improve upon the load time for that particular page and the great resource.” First I saved down the page locally, so if you ever want to grab a webpage from someone’s site and put it locally so you can work on it and check stuff out, it’s File > Save Page As > Webpage Complete. And that downloads the HTML as a HTML document and then it also downloads a folder and within that folder it has all the assets, so all the images, all the JavaScript, all the CSS, everything that goes to make up that page. So if you’re offline, locally you can double-click on that HTML document and it’ll open up and you’ll see the entire page. So that’s a good start.

I saved it to my desktop and then I moved on, and I mentioned that the first thing I noticed was that PNGs were being used for everything. Now as a general rule you can either have PNGs or you can have JPEGs. It used be GIFs and JPEGs and I know there’s PNG-8 and PNG-24, I won’t go into that but let’s just start with it’s PNG or JPEG. So if you want to choose a PNG, you should choose a PNG when the image is more of block colours. So think vector kind of things like logos, icons, they’re kind of just full block colours. Also if you want to have a transparent background then you might choose a PNG as well, and we’ll go back to the logo and PNG transparency thing in a sec too. You should choose JPEG if the image is more of a rasterized image, like a photo. They’re the general two choices.

Now back at the logos and icons, technically these days we probably would want to go for an SVG rather than a PNG purely because it’s a scalable vector graphic. So it will scale from small viewports to large viewports, so rather than have many different types of your PNGs depending on what size you need to render them as, you have one SVG and it scales magically. Hooray!

And then on the transparency side of things as well, there’s a file type called WebP and it’s supporting in Chrome and I think Opera as well but I do know that Safari were looking at implementing it as well or they were checking it, and they never check stuff out like this so that’s really positive. WebP is a lot more performance so you can compress it a lot more and get still really, crisp, clear JPEGs effectively at much smaller file sizes and it provides transparency as well which is really cool.

So looking through all those images I thought most of them were more suited to JPEGs than PNGs, and if you PNG something that should be a JPEG the file size becomes incredibly larger than what it should be. Whereas if you JPEG a PNG you can really small PNGs for quite large pictures because it’s mostly block colours and you can get incredibly large PNGs for small pictures if it’s more suited to a JPEG. And just out of interest if you’re going to export your files or your slides from something like Keynote or PowerPoint there is an option, definitely in Keynote you can select JPEG high quality, small file size, PNG or TIFs. So just think about what most of your images are going to be and export to suit.

So now that I had them all downloaded, all of the images, or downloaded the webpage, then I wanted to change them all from PNG to JPEG. Now normally with my Mac I can right-click and say “PNG to JPEG” because I’ve set some automation up because I take a lot of screenshots and I just want to switch it through the PNG to JPEG because traditionally JPEGs are better for the screenshots that I take, so I’ve got like this right-click shortcut. But because it’s 150 images in this case I have Photoshop on my machine so I was able to use something from Photoshop, so in these cases where you’ve got large scale, you want to batch-process things. So if you go into Photoshop and you go File > Scripts > Image Processor then it gives you a few options, you select the folder of the images you want to change, you select a folder for where you want your images to end up and then you pick what file [size 16:26] you want it, in this case it was JPEG, and the quality that you want it as well. I chose a four which is about 30% quality because I wanted them small.

Then I hit “Save” and then bam, we got a whole bunch of JPEG images and that changed the file size so it wasn’t 35 MB it was now down to 10.4 MB. So we’ve already reduced it down to a third of what it was just through changing the image file type and optimising the images a little bit. Then when I had all of that the next step is a little bit further optimisation using a tool called ImageOptim. It’s a free tool and the wonderful thing about that is that it provides lossless compression which means that image isn’t as big but it is just as beautiful as it once was, so it doesn’t affect the quality of the image at all, it just reduces the size of it which is exactly what we want. To do that it removes like … I actually don’t really know what it does, it’s like magic I think. But what I do know is it removes a whole bunch of metadata about the image which isn’t needed for people to view it on the web so just get rid of it. So yay ImageOptim. Free, you should totally get it.

So I dragged all the images onto Image Optim and then within like 30 seconds or a minute it had processed all those images and that had taken it from 10.4 MB down to 6.1 MB so now we’re talking about going from like 35 MB all the way down to 6.1 MB which is amazing. From there it’s a simple … I always say simple matter, it’s not always simple. From there you need to get the images back onto your server so I used an FTP client and you put all of the images back into the folder that you had all you PNGs, it won’t override them because now they’re all JPEGs so it won’t overwrite a PNG because they’re different file names. And once they’re all back in there you have to update the reference in the post, so at the moment all the image tags are referencing .png you need to reference JPEGs and it’s Control-F like a find and replace. So you want to find anything that says “.png” and replace it with “.jpg” then you publish and voila. You’ve gone from 35 MB per page for every visitor down to just 6.1 MB for every visitor.

Not only is that really good for the users so they get the content faster, they don’t have to wait around, their browser doesn’t slow down, they don’t lose all their data. The other great thing is Andy is a popular guy, he writes a lot, he does some cool stuff. Now he would have like, I’m guessing 10,000 people would go and view that article that he wrote, it was re-tweeted by a lot of really popular people in the web community as well. So 10,000 people at 30 MB, that’s 300 GB of data that he’s now saved and he doesn’t have to pay in bandwidth. It’s just fantastic, it’s a win-win for everyone I think.

So at the top of the show we talked about there’s three things, so there’s the file size which we’ve now corrected to a certain extent, a pretty good extent I would say. The other thing is that all the images are being loaded regardless of whether or not anyone was going to see them. To fix that essentially you’ve got 150 pictures you might not scroll through all of them so why should you be downloading the ones that you’re not going to view. So you can use a tool, it’s a JavaScript plugin called “lazySizes” and what that does is it Lazy Loads the images into the page. What that means is that when you first load the page it will load the images that you can see that are within your current viewport and then as you scroll through the site as the other images get close to the viewport then it will say, “Hey, you’re about to be viewed by the user. I think you should start downloading now so that you can be there for when they arrive.” And then as you scroll through the images slowly start being loaded in.

If you stop scrolling then the images stop being loaded from below the viewport and it’s just great because it means that only the images that you’re likely to see are going to be loaded. So you’re only paying in bandwidth and time and even the hosts, so Andy is only paying in his bandwidth for the images that you’re going to see as well. Now to do that, like I said “lazySizes” if you do a search we’ve got it in the resources section on the Responsive Design site as well and it’ll be in the show notes. It’s a small JavaScript file, you can load it asynchronously so it’s not a blocking script, it won’t affect the load of your page. And for any image that you want to Lazy Load you need to change the source to “data-source” so it’s a data attribute instead and add a class of Lazy Load to that image.

Now the reason you have to do that data-source thing is because browsers are super smart these days and as soon as they detect an image tag, like even before all the HTML has passed, it will start downloading all of those images and that’s to make it seem as though web pages are faster. They do that for the users benefit for performance side of things. What that means is that all the images start downloading before any JavaScript can run and stop it from downloading so that’s why you need to change it from “source” to “data-source” and then as you scroll through lazySizes checks to see whether the image is approaching the viewport, as it gets close to it like within 200 pixels or so, then it changes the “data-source” to “source” and the browser will download the image. So it’s super, super cool.

I’ve used it for a few sites, I did it for the Adobe Mac site, I rebuilt their conference site from like a better approach for a responsive, responsible design and performance is a big thing. I added lazySizes to it and it’s shaved like several seconds, we’re talking five or six seconds off the load time of the site by just implementing the lazySizes. Very good for image heavy sites, especially for ones that are below “the fold”, so definitely implement that if you can.

We also talked about I said there’s lot of requests for the images as well, so if you were able to run on HTTPS and your server supports HTTP/2 then instead of having one request for each of the 150 images and there’s latency on every single request, with HTTP/2 you don’t have that latency. It can just request all of them at once and they can all download and of course if you’re using lazySizes then you trip yourself up because you don’t want them to all download at once. But that connexion will stay open so you don’t have to make it look up every time, which is fantastic.

And the final thing, there’s one more thing that we can do. For those in podcast room, can anyone just raise your hand and say … Like, are you thinking of one other way that you haven’t mentioned, the key way to have better images for this page? Anyone? You in the back, Mr. Eric Portis? Yes, you were right. It’s using responsive images is the other thing we could do. This requires a little bit more work. What we had for these images is they’re all slides, so they’ve all been exported about 1024 pixels wide. Now if I’m viewing that on my iPhone 5 which has a width of 320 pixels and it’s a retina one, I think they’re all retina, 320 you might double that and arguably say it’s 640, but that’s still like half the screen area of what I need from what the image is being loaded. It’s 1024 only you really need 640. So we can include something like SourceSet for the images so that we can give the browser several different sizes of image to chose from and then it would download the image that best suited the viewport to render that image.

And that great thing about that lazySizes that we talked about before is that it works with responsive image syntax as well so it works with SourceSet and it works with picture as well. So that would be a cool bonus addition there and the reason I … Eric didn’t really put his hand up, but Eric Portis wrote this really awesome article about responsive images and again I’ll link to that in the show notes and it’s linked in the article as well.

So that’s it, so this is how we can turn like … and I encourage everyone, we’ve got this problem at the moment with large web pages, they’re bulking, they’re oversized, they’re overweight. And most of the weight is due to images. We always complain about, “Let’s not include that JavaScript library in there it weighs 30 KB.” And yet we’ll chuck on 35 MB of images onto a page. I see this all the time and it doesn’t have to be 35 MB it could be 5 MB of images, the point is that’s too often, that’s too much. But if you can approach it in a systematic way like, “Am I loading the right images? Are they properly optimised? Have I put them in a responsive image container so that only the right sized image gets served up? We’ve got a tonne of images, are they loading below the fold? Are my users likely to scroll down there and if so will they scroll all the way or should I just be serving up a couple that they’re definitely going to be seeing?”

This is the other reason why this image conference is on at the moment too because it is a real problem, but I think we make the problem worse for ourselves by including these things. And I realise that most projects are done in a rush, unfortunately, it’s just the nature of the way we do things. These kind of things tend to be, “We’ll look at that later, let’s just get it up and going.” And I think that’s a bad approach. We should really just focus on trying to make it a little bit lighter, try and work those images as well as we can and see how we go.

So that’s it. Thank you for listening, thank you for tuning in and downloading. If you want to talk about something, if you want me to cover something in particular, feel free to write in. You can hit me up on email, you can reach me on Twitter @ResWebDes, you can subscribe to the newsletter at responsivedesignweekly.com and please rate this show up in whatever podcasting listening tool you’re listening to at the moment. Rate it up that would be super awesome.

Coming up next is my little interview with Noah so if you want to check out what a three year old has to say about the web and what’s better, what’s the newest thing coming out and what’s the best thing to watch The Minions on, then you are in for a treat. Until next week, I will see you soon. Cheers. Bye.

RWD Podcast 59
10:00
2017-09-23 00:10:05 UTC 10:00
RWD Podcast 59

Hey everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly Podcast, and the newsletter, a weekly newsletter all about Responsive Design and front end funky stuff. Now this week as you will notice, my throat hasn’t cleared up at all, the kids have kept my cold going and my cough has just got worse. So we’re going to keep this super quick because you don’t want me to be coughing in your ears on your journey to work or while you’re chilling out. So we’re just going to cover one thing this week, and again there’s no guest this week but next week I have two people to chat to which I’m very, very excited about. Yeah, it’s going to be awesome.

So this week, the feature side, the feature article for this week is we’re looking a little bit at an article which Scott Jehl has written from The Filament Group. Scott Jehl for those of you that haven’t heard of Scott, he has been doing wonderful work over the last couple of years on the web and he’s always about practical performance. In fact he wrote a book on just that topic as well. If you go to “A Book Apart”, I’ll type that in and it’s great radio. Here we go with the coughs. So yes, we know of the Responsive Design right? So “A Book Apart” Ethan Marcott wrote his first article on [inaudible 00:01:48] and then he wrote a book called, “Responsive Design” and then it was followed up with “Responsible Responsive Design” from Scott Jehl, and it’s just talking about the responsible ways in which we can approach the booting of websites. Now because Filament Groups stay on top of this stuff, the site is usually pretty darn fast and this latest article though we’re featuring is about them stepping it up, so the title is, “Modernising Our Progressive Enhancement Delivery” and it’s all about taking advantage of some of the newer tools that are available to us today, not across the world, but available to a lot of people.

And namely that is around HTTP/2 and so we can look at the browser support for HTTP/2 and it’s running on IE 11 partially but it’s limited to Windows 10 for IE 11, but Edge runs so 14 and 15 for IE or now Edge. Firefox supports it as of version 36 I think and we’re up to version 50 at the moment. Chrome has supported it since 41 and we’re at 55. Safari? Come on Safari. Safari offered partial support. Safari. Opera supports, iOS Safari does support it, Opera mini does not, but Android browsers and Chrome for Android both support it as well. So that’s from the Browser point of view. So if you send an HTTP/2 across to a Browser that doesn’t support it, it just falls back to HTTP/1.1 in the way that the web works. We always fall back, which is great, and that’s why the web is so awesome.

So the thing with HTTP/2, one of the coolest things, I think I’ve talked about this a little bit in the past as well, it’s just a lot faster. The communication between the server and the browser is done with 1’s and 0’s now, instead of text, so it’s a lot quicker. The compression on the chats is a lot better as well. But the main thing is that there’s no blocking requests. So previously if we requested an HTML page, and that HTML page had CSS and images and JavaScript and the like, it would wait, generally we would have that waterfall, network diagram. So it would request an image and then it wouldn’t request the next image until that image had downloaded and then it would go off and request the other one and the bring that back.

So each time we needed a new HTTP request, which was expensive and made things slower. With HTTP/2 you won’t even need to make a single request, and when the HTML comes back to the Browser, it then looks through it and goes, hey I need all of these files, go and get them. And they all come back at once, which means we don’t need to concatenate files together so much anymore because we’re not using the extra HTTP requests, it’s just all coming back. So instead of seeing this hierarchical, as like waterfall thing, it’s one request, bang everything else comes back. So that’s great.

The other thing that we’ve been doing is critical CSS. So the idea is that we want the first fourteen kilobytes that comes back from the server, we want to render as much of the page as possible within that first fourteen kilobytes because that’s the first trip back. And to do that we need to have all of the CSS that is required to render the visible part of the page within that first fourteen kilobytes. So we used to inline that CSS, called critical CSS. With HTTP/2 now, we’ve got this option of a server push, so that when the request goes out for the webpage, so when you request the Filament Groups homepage, as the server send the HTML back to the browser, you need to wait for the HTML to arrive in the browser, look through the HTML, find the images and the CSS and JavaScript, then request them, and even then they’re going to come back in one whole hit, and it’s one request, there’s still a bit of latency involved with that.

Instead because you know what file is going to be sent back, you can instruct the server to say, hey if someone requests this page, push along that HTML we’re sending back, push all these files because I know that these files are going to be required on that page. So that’s really, really awesome. It means that you don’t have to do that second request and then you don’t actually have to inline your styles anymore, you can just push them down.

Now I can imagine you’re thinking, but hey what if we already have those files, what if we’ve already visited that page once before? Fortunately, Scott has thought of that as well, and they’re using a cookie to check that. So even though the push happens, the browser can actually cancel that at any point. Now there is a couple of occasions where those files will come down and you will get the extra burden on your data plan because you’ve downloaded files that you already had. But for the most part once that cookie is set, then you no longer have to push those files down anymore, which is great. So I highly recommend, check the newsletter out, check the website out on redesign.responsivedesign.is.

Well you’re probably there at the moment, check the show notes of this as well, we’ve got a link to that article, but definitely check it out, browser support is great like we said. HTTP/2 you need to do a little bit of configuration on your server depending on what server you’re running, that will also need to support HTTP/2, but if you’re using something like CloudFlair, which I highly recommend, that actually has HTTP/2 out of the box. Another bonus about it as well is that you have to be on HTTPS, so you have to be serving your site securely to take advantage of HTTP/2. Another good reason to use it because you get all of these benefits along with it.

So that’s it for this very short episode, I’m really hoping that this cough sorts itself by the time we get a guest on. But fortunately, they will be doing more speaking then what I will, hopefully. Either that or I’ll just sit with a bottle of cough medicine and just swig it for every time I’m going to ask a question, another swig and see how we go.

So that’s it for this week, if you’re not already subscribed, head over to responsivedesignweekly.com and subscribe to the weekly newsletter. Check out the new stories going up on redesign.responsivedesign.is every day, and we tweet about them, so you can follow us on Twitter @ResWebDes. See you next week.

RWD Podcast 58
19:35
2017-09-23 00:10:05 UTC 19:35
RWD Podcast 58

Show notes

Transcription

Hey, everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery, and I am your host and the curator of the Responsive Design Weekly news letter. A weekly news letter all about front end development and back end stuff and performance stuff and frameworks and tools. A whole bunch of stuff. This podcast is like a … I was going to say  a sidekick. It’s not a sidekick. It’s like a spin off of the news letter as well, so I bring you some cool stuff on the podcast as well I hope. This is edition number 58 which is kind of cool, and the fist time that I’ve gone back to back editions week to week for a while actually. It’s the first time in 2017, but it’s only been two weeks in 2017, but it’s actually the first time for quite a while including 2016, so yay.

Thank you for downloading and tuning in again. This week I’ve got like this tickle in my throat thanks to my little boy. Thanks to him going back to school, so he’s bringing back a whole swathe of new germs that can do the run around in the family as well, so I’m going to try this thing where I click on the mute button if I feel a cough coming, so there will be like tonnes of tiny little pauses through the show. Super professional, I know.

This week no guest, but I did on Tuesday night I went to the London web performance meet up, and I saw a wonderful talk from Ada Rose Edwards. You can see her site at Ada.is. She was fantastic. She talked all about web VR. Now, I looked into web VR a couple of months ago because a client was asking what they could do with it, and they wanted to keep on top of things, and when I had a look I came across this framework called A frame. Aframe.io, and it’s a framework produced by the Mozilla company. Here we go. We’re going to try to cough quickly. I hope that worked.

I believe it’s developed by Mozilla. Anyway, it’s a wonderful thing. It’s like a framework. You drop in a bit of Java script, and instead of programming really, really difficult like web GL stuff and things that I have no idea or understand, have any comprehension of how to do at all. You drop this code in so the reference to a Java script file, and then you can just pretty much write HTML. The HTML, like you write HTML but with particular components, but it then turns it into a wonderful web VR experience. Then all you need is, all you need, you then need a phone. Some description. Something that supports web VR, so I mean I’ve got an iPhone five here. I’ve got an iPhone six from work. Both of those support it, and then like a headset which could be Google cardboard, or it could just be you pushing the phone really hard up against your face.

Google cardboards come pretty cheap. Fortunately there was a Google representative that gave away 100 Google cardboards at this meet up, so we all got to try it out. I forgot to hit the mute then. It was a wonderful meet up, and it was really, really good. Ada talked. No slides, just demos which makes it even better. Web VR it’s really a thing. It’s like it’s here, and it’s ready to go. I’m not going to lie, it looks a little bit like the designs that were coming out in the mid 90s or late 90s, so they’ve got a very 80s, 90s feel about the designs, but that’s because the web VR stuff is still, I mean the pixel perfection we expect retina quality stuff now with our screens and our phones, but the resolution on web VR just isn’t up to that scratch, but man it is immersive, and it is cool, all right?

One of the wonderful things I think is that you can jump straight into it. Now, A frame has a whole bunch of examples to allow you to get involved with it straight away, and there’s this wonderful component that you can add in called a sky box, all right? It’s almost literally … Let me just fire up. I built a call thing. Well, I didn’t build a call thing. I built a thing. Not necessarily going to say it’s cool. Yeah, it’s called a sky, so you know how I’ve dissed [amp alone 00:05:12]. I’ve questioned the usefulness of amp and the ideas behind it, so this has a very similar idea, so you’re loading in Java script at the top of the page. May as well.  We have locking script.  Pretty sure it is. Then instead of using regular HTML tags you’re using kind of like components I suppose, so everything in amp is predefined or prefixed with amp-image or amp-iframe.

Everything in here with the components is prefixed with an A for A frame, so you can build a box which is A-sky. Give it an ID. Give it a radius. Give it a source, and then it will effectively build a sky for you which is well cool. Now, the cool thing that I did with this if you go on to aframe.io and we can try it out. There’s an example which is a 3-D 360 image. This is how simple it was. It was lunch time yesterday, and I thought look I just want to try this out. I want to see how quickly I could build something that might be somewhat helpful. I jumped on and we have at work some clients, and as you would hope, and the clients are really keen on making sure that new employees get a really good feel for what it’s going to be like to work at the place.

All right, and that’s great, so you can have tours of your office which is fine, or you can show pictures, or you can show a video of the office and stuff, but sometimes things like if you’re working in construction, so we have like for a couple of construction companies, you can’t take people onto construction sites and show them because you’ve got it go through a whole bunch of safety rigmarole things, so it’s not really going to fly. Some places are super secure, so you’re not allowed to let people in, so even though you could show them the office, and there’s nothing super secure on desks or anything you’re not actually allowed to let them into the building to begin with.

Sometimes people just won’t travel, right? If you’re doing an international placement, or if you’re moving from one side of the country to the other, and you want to get a feel for what it’s like then, I mean, it’s a long way to go just to get a feel. I thought well it would be cool if you could kind of get an immersive experience of what it’s like in an office. I downloaded … For this you need a 360 degree picture, and so I didn’t have the camera. You can get a camera, and what Ada recommended there’s a Samsung Gear 360. It takes some pretty sweet shots. Like, it looks beautiful. It does video I believe, or maybe it’s just … Could be just … I’ll check that. It may not do video, but it definitely does some beautiful pictures. It’s 349 quid, so not cheap. Not something that I’m just going to drop 350 quid on to try out, but I probably will now that I’ve seen how cool it is.

I’m not going to tell you to go and do that, but if you do have a phone which I’m sure most of you do there is I think available for the iPhone anyway which is what I had. An app called 360 panorama, and it’s by Occipital. It was a pound 50, so 350 pounds verse a pound 50. I went with the cheaper pound 50 for a change, and essentially it lets you kind of do a panorama like you can do with your iPhone now, but it sets like this globe grid behind it to begin with, and then as you hold you phone over a particular area it records that part of the image and then adds it to this grid, and you basically do a circle and then you look up and then you look down, and you’re done. You have this amazing 360 … You have this amazing … I just muted my headphones instead of the microphone, sorry. You have this amazing 360 view. This is great.

Now, from that you just download it and put it into an images folder like you normally would a regular image and then you’ve got this picture which you can then paint on the sky box, all right? This is amazing, so you can get started with this just having a 360 image, and I think it’s like about 30 lines of code, but for me it was like a copy and paste and update one image reference. It was really cool. What I did is I downloaded this thing and then I took a look around, and I did a 360 view at my desk. Then I went into our kitchen, and I did a 360 view of our kitchen as well. Then once I was finished doing that I downloaded the picture and then I chose the gallery option, so the gallery option is like the 360 image, but it allows you to have multiple images.

What this does is it just gives you the ability to put like just two boxes like a thumb nail to say I want to view that one, and with web VR because you don’t have a mouse or a pointer or a clicker you can write into it that you want a little dot which is kind of life your reference point, or it’s like a pointer. Then if you move that dot onto a square that you’ve designated as a link and you stare at it for a little bit it activates that as if you were clicking on it which is super cool, right? Then the click is you can just control the click event like you do with Java script for normal click events. I’ve got these two boxes now which one says office, one says kitchen, and you look at the kitchen box, and it sets the sky box. The A-sky to use the 360 picture of the kitchen, and then if you look at the office box then it runs Java script and that sets it as the office one.

Now I’ve got this 360 immersive experience with … I mean, I’m going to say it’s not the best picture in the world, but it gives you an idea of what the office is like. Yeah, so now we’ve got this thing, so if I was to say hey you should come and work for us. This is what our offices look like. This is what our kitchen looks like. This is … Maybe not toilets, but you know just showcase some of the different areas. If you’re in a building construction site you can showcase those different areas there. If you’re selling houses why not showcase the different rooms the house has?

One of the things I want to do with it is I’m Australian. I live in the UK. I have a lot of family back in Australia, family and friends, and they’ve never been over to visit. They don’t know I I live. They don’t know what our house looks like. They can’t picture like what a garage is like or a backyard or anything, so I’m going to go … Especially my dad who’s technically not there I would say to be nice. Sorry, dad.  You’re not the most cynical person. The most practical person in the world. He can build. He’s build a barge. He builds some cool stuff, but computers he’s not a fan. I can now do these pictures in rooms and set this up, and my brother who lives over there with him still can give him this phone. He can put on this cheap Google cardboard headset, and he can be immersed. He can see pictures of the kids. He can be involved in it.

It’s really cool, so anything you can do with Java script you can do. You can import objects. You can, if you’ve done a bit of SVG work and sort of moving SVGs around and animations and stuff this is all possible with this A frame. I highly, highly recommend it. We talked about responsive design. We talked about how we’re going to make our information and make our content respond to the different devices that we’re consuming it from. Well, we’ve been looking at screens. We’ve been looking at windows, so I remember someone describing a screen as amazing, but it’s kind of like if you take a picture and then you put it in a frame. That’s kind of … That’s what you get. You can look at it, but you can’t experience it. You can take a video of something which is better, but it’s still a picture, and it’s still a frame, and you’re looking at it through a 16 by nine window. What you want to do is you want to put your head through that window and be there and experience it.

If we can create content which allows people … We are creating content, but we want to be able to create content that allows people to experience it in that way, and at the moment the web can now do it, so with this web VR we’re able to start doing it. Now, a couple of things which I’ve learned over the last couple of days and from the talk is text in web VR is not a great idea. I still want to wrap my head around that a little bit more, but I just have really advised against using huge amounts of text. That causes a bit of an issue if we’re creating loads of content on our web sites, and we want people to consume it, and then we said we can’t use text then we need to find other ways for people to be able to do that. I need to wrap my head around that a little bit more. If anyone has experience on web VR and large amounts of text or being able to consume content, text content, in that way, I’d love to hear from you and learn a bit more about that.  I’ll be updating anyway.

I kind of want to do a responsive, so I’m doing the redesign of the responsive design that is coming along nicely. I kind of want to add a web VR version of it as well, and see how that just might look. I think that would be quite cool. Text, not so great. The other thing is you need the camera, but like I said we’ve got this fall back. You can use an app to do that instead. There’s a whole bunch of different cameras that you can get a hold of, but apparently that one is the best one. The Samsung 360 VR. We also at work we did this project with an energy company, and we built this 3-D model of this island in a futuristic city, and the 3-D modellers, we only got a 2-D picture of it because we were putting it up on a website, and we kind of made it float like an island because it was a transparent PNG, but what we really wanted to do is make it so that people could experience it. They could turn it around. They could zoom into it like a web VR process.

I’m going to get that file back.  I’m going to trial it out and see what it’s like. Now, when you’re working with 3-D objects, I asked Ada and she said, “What you want to do is you want to keep the polycount under 100,000 in total.” I don’t know what that means, but just that’s a tip, right, so someone says because that was a question the 3-D artist asked me. They said, “What polycount should it be?” I don’t know. What is a polycount? Under 100,000 is what you want. The other thing that the 3-D artist asked for was what file type did you need it in? For that, again, I have no idea, but you can work with objects so .obj or .gltf. Again, I have no idea what that means, but if you’re going to grab 3-D objects then use those ones as well.

That’s it for this week. Yeah, like I said, highly recommend. Go check out Ada.is and read about what Ada is talking about. Go use Aframe.io  and just trial something. It’s pretty cool. People will be pretty impressed, and if you want to have a look at the little gallery that I built you can go to vr.Simplethin.gs/gallery.html.  I’ll put links up in the show notes, and you can check that out. See where I work. That would be kind of cool, but that’s it for this week.

Next week I think … Is it next week? We’ve got a guest coming up which is super cool and very awesome. If it’s not next week it is the week after. Definitely the week after we have Una Kravets which is going to be super cool. She runs a podcast called Web Tools with another guest, and I’ve promised her that if she does a song at the beginning of theirs about what she’s going to talk about, so I’ve said that I will sing a song for Una when she comes on which will be an interesting way of going about it. I’m looking forward to that.

Yeah, until then let’s go for a streak of three, and I will see you next week. Until then stay responsive.

Cheers. Bye now.

RWD Podcast 57
23:02
2017-09-23 00:10:05 UTC 23:02
RWD Podcast 57

RWD Podcast 56
33:51
2017-09-23 00:10:05 UTC 33:51
RWD Podcast 56

Show Notes 

ESPN Senior Front End Developer

An awesome opportunity to join a wonderful team and push the boundaries of what is considered story telling on the web. Apply Now.

@supports will change your life

View article

Charlotte Jackson shows just why @supports can be so valuable for the sites that we build.

RWD Survey

Take it now. It’ll take 60 seconds TOPS.

RWD Podcast 55
18:10
2017-09-23 00:10:05 UTC 18:10
RWD Podcast 55

RWD Podcast #54
25:41
2017-09-23 00:10:05 UTC 25:41
RWD Podcast #54

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


RWD Podcast #53
16:20
2017-09-23 00:10:05 UTC 16:20
RWD Podcast #53

Show Notes

Browsersync

I can not believe this is something I haven’t shared with you all, yet here we are. It’s unusual for a tool to make it to the headline but this is such an important tool in the web workflow that it needed to be prominent…. and y’know it’s totally free and awesome.

BrowserSync essentially allows you to test your local dev copy of your site (or live site) across a network of devices, and what you do on one device is immediately visible on the others. Your scroll, click, refresh and form actions are mirrored between browsers while you test. AH-MAZE-ING

New <video> Policies for iOS

When we wanted to share videos on the web we would convert them to animated gifs, and now that animated gif’s are a big thing on the web we are taking those gifs and converting them to videos in process of becoming more performant (a mp4 video of a gif of a video is smaller than the gif). Now safari
are allowing for <video>
elements to auto play IF there is no audio track or if the track is muted. Check out the list of policies Webkit are including to ensure this isn’t abused or annoying for the user.

Offline Google Analytics Made Easy

If you’re jumping onto the Progressive Web App (PWA) bandwagon, and well you should, then you probably want to track analytics when your users are offline as well as online. Now with this library shared by Google you can stored the users actions in IndexDB and send them once the users is online
again. Is there anything Service Workers can’t do???? (rhetorical… I know there’s things they can’t do).

RWD Podcast #52
23:02
2017-09-23 00:10:05 UTC 23:02
RWD Podcast #52

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


Show Notes

Hey everyone and welcome to another edition of RWD Weekly.

In the show this week I discuss both Beacons and HTTPS along with

  • When you might use them
  • How you can implement them
  • What you and your customers get out of it

Physical Web & Beacons

This week I found out that you can enter the physical web world without the use of one of the beacons.
– First beacon from the TheWeb.is
– Used it to locate my keys.
– Idea is that it just broadcasts a URL. Great for discoverability.

from the article:

Not convinced this is the future? Well think about this: what if you were giving a presentation, and could bring along a beacon that sent out a link to download the slides for your presentation? Or what if you owned a sandwich shop and wanted customers to easily access a link to the mobile app for online ordering you spent so much time building? Or wanted to push an updated agenda link to conference attendees as they walked in the door? The possibilities are endless.

There always seems to be a catch. Luckily this one isn’t too bad: just note that you can only send secure web pages (HTTPS), and the URL is limited to 17 characters because of Bluetooth packet size limitations.

If your URLs are too long then use a URL shortening service.

Everyone in the audience to turn their Bluetooth and Location on and for iOS users to add Chrome to their notification center (I’ll explain why they have to do this later), then I ask to raise hand if they got the URL on their phones.

– android users automatically get notifications when a Physical Web is within range

– iOS users first need to add Chrome to the Today section in their Notification Center. There is a great step-by-step tutorial for that on the Physical Web website.

HTTPS

The other great story this week is that the web has now doubled in the number of HTTPS websites being served in the past year.

This is amazing and I think it’s down to a couple of reasons.

  1. it’s a lot cheaper to go https now.
    1. Lets Encrypt provide free SSL certificates
      – with that a lot of other providers have driven their prices down
      (there was never a reason to set the price so high, it was just something we did).
  2. Large services are serving them by default
    1. GitHub Pages
    2. WordPress
  3. Services such as Cloudflare make it super simple and free.
  4. Carrots — Not the ones that rabbits and reindeer eat, but ones that compliment the stick.
    If you want to take advantage of things like Geo Location, the speed of HTTP2, the amazing-ness of Service Workers and progressive web apps… even serving your sites on physical web beacons… then they need to be on HTTPS…

RWD Podcast #51
22:27
2017-09-23 00:10:05 UTC 22:27
RWD Podcast #51

I talk about using a combination of your own CMS, RSS feed and something like IFTTT to post it for you. I use IFTTT for posting articles to Surf the Dream, saving images from Facebook, posting news articles to Facebook… although now I’m trialling Zapier.

Speaking of WordPress, I also delve into some issues that I recently came across with a clients site.

  • changing URLs – why that can be bad
  • Links don’t work
  • no natively support 301 redirects
  • Page templates failing

RWD Podcast #50
15:49
2017-09-23 00:10:05 UTC 15:49
RWD Podcast #50

RWD Podcast #48
33:53
2017-09-23 00:10:05 UTC 33:53
RWD Podcast #48

This week we take a quick preview of the up coming RWD Summit and offer up a discount code for 20% off (but you have to listen to get it, of course). While on the conference band wagon we also talk about the CSS Dev Conference opening up for proposals… get your talk in now.

Google release their new RWD resizrvery similar to another tool we’ve seen.

Finally we talk about content modelling (with Jekyll) and how it makes it a lot easier to roll out things like Apple News feeds or AMP pages if you decide you want to push your content out there as well. Speaking of AMP pages, I also talk through how you set up an AMP page properly and the bits you need to include (but are not told about).

RWD Podcast Episode #47
68:52
2017-09-23 00:10:05 UTC 68:52
RWD Podcast Episode 46
30:26
2017-09-23 00:10:05 UTC 30:26
RWD Podcast Episode 46

RWD Podcast Episode 45
26:42
2017-09-23 00:10:05 UTC 26:42
RWD Podcast Episode 45

RWD Podcast Episode 44
35:36
2017-09-23 00:10:05 UTC 35:36
RWD Podcast Episode 44

Hey, everyone, and welcome to Responsive Design Weekly Podcast, episode number 44. My name is Justin Avery. I am your host and the curator of the Responsive Design Weekly Newsletter, a weekly newsletter all about responsive design. A whole lot of cool stuff has been happening since the last time I ran one of these. This is episode 44. The last 2 episodes were all about the presentation that I gave over in Germany, in Berlin, and since then, there&rsquo;s just been so much happening, tons, and I just wanted to share a couple of those things with you as well.

This week, we don&rsquo;t have a sponsor, but what I will shout out is that we&rsquo;re finally getting the Responsive Design notebooks printed up, so just in time for Christmas. Although, it was supposed to be at the beginning of this year. I&rsquo;m doing a set of 3 notebooks that you can get a hold of, so the 3 notebooks will be covering the 3 tenants of responsible design or responsive design, so we&rsquo;ll have our fluid grids, our flexible media, and our media queries as well.

Each of them have 36 pages inside and a little quote in the back from some of the leading thought people, our thought leaders, so there&rsquo;s a little bit in there from Brad, a little bit in there from Ethan, and also a little bit from the man who I think started this on this path a long time ago which is Mr. John Allsopp with his “Dao of Web Design.&rdquo; Yeah, so that&rsquo;s coming up. If you go to backpocket.co, backpocket.C-O, you can put your email address in there and be one of the first to find out when they come available. There&rsquo;ll be a limited edition of 200 available in the sets, [00:02:00] so be quick, be very quick, and grab it. Yeah, more about that in the weeks to come.

Recently, I was lucky enough. I head over to the States for the Adobe Max Conference. It was a 3-day conference. I was there for a couple days either side. It was just amazing. It was really cool. They put on a huge massive big event. The party that they had there, it had donuts. They had a doughnut wall, which I&rsquo;ll put a picture up in the show notes. It was crazy. They had some really great keynote speakers, and some of the things that they were sharing about where they&rsquo;re heading with the products was great. They had some really good product demonstrations.

I think they&rsquo;re doing &hellip; Adobe are actually doing a pretty good. Given where they were for a little while, they&rsquo;re doing a really good job in listening to what you and I as web designers and web developers, what we need and what we&rsquo;re missing in our day-to-day workflow like the web is continually changing, so is the way that we&rsquo;re building, and we need our tools to change along with us as well, and it&rsquo;s just becoming &hellip; I think their focus has been a lot more around collaboration, but they&rsquo;ve also had some pretty cool stuff improved as well, and there&rsquo;s a new product coming out, which is a project called “Comet,&rdquo; which I might talk about in a little bit as well.

Yeah, like all great conferences have &hellip; It&rsquo;s not so much about everything that you see and you&rsquo;re presented, but it&rsquo;s about the people as well. This one, the Adobe Conference was no change from that, so there were some amazing people there. I got to actually meet the people from Comet and who are working on it. I might as well talk about it now. [00:04:00] Comet is a new kind of prototyping tool that Adobe are coming out with. It gives you the ability to mock up designs quite quickly and allows you to reuse patterns, so if you have a particular pattern.

Just think we&rsquo;re doing a &hellip; we&rsquo;re building Pinterest, for example, and we want to mock up how that might look, so you might have card view or you might have a multi-card view. You can build out 1 card, and then option-click and create a second card, but then you can turn that into like a module. As you click and drag the &hellip; if you were to make it larger, so wider or taller, instead of it stretching the width of the card itself, what it would do is it will turn into like a repeater, so it will repeat it to the right, and it will repeat it low down as well.

The other cool thing is that we usually design these things with Lorem Ipsum. You can put dummy data in there, so if you type a name into a name field and then something into a description field, it can randomize stuff, so it knows that you&rsquo;re putting in name, so it will put in random names. If you have a first name and second name, it will put in random first names and second names, so you can get the feel of like, “Is it going to go over 2 lines? How is the design going to look if someone&rsquo;s name is really, really long?&rdquo; They even extend it further past that where you can drag &hellip; you can have a whole bunch of images sitting in your library, and it will automatically pull those images into the little pins as well, so you can see how real images will look.

The great thing though about that is when you extend it further and you can go &hellip; so if we were redesigning Pinterest in this example, we could go to pinterest.com, and we could have a look at a board, and I could &hellip; from Comet, I could like &hellip; I can&rsquo;t remember what the command was, but just say it&rsquo;s like a right-click on the title, and then you go over, so you&rsquo;ve got a page in your design [00:06:00] full of these cards. Right-click on one of the titles, go to pinterest.com, and select the title of a range of cards in a view as well, and it&rsquo;s smart enough to look through all the HTML, find out what elements that title is, and then pull back all of the content, and populate your design with the content on the website. If you were redesigning a website, you can redesign it with real data as well, which I thought was super cool, but that&rsquo;s just like one of the small things.

There&rsquo;s another guy who I hang out with quite a bit too, Jay [Messing 00:06:38]. He&rsquo;s over based in Germany. He&rsquo;s the guy who came up with the Open Device Lab or one of the guys that came up with the Open Device Lab. The whole concept of the Open Device Lab, we want to test on as many devices as possible, right? We build these websites, they&rsquo;re responsive. We need them to work. We build them, so that they work across a variety of devices, but then most of us, a lot of us will just test inside of Chrome or Safari, and open up DevTools, and move things back and forth, but you really need to get on to devices to check out how they actually feel and how they interact with the site. It doesn&rsquo;t make sense. Is it comfortable?

Now, buying devices is really, really expensive. Really expensive, so this Open Device Lab allows you to go and look at a world map. You go to opendevicelab.com, and you get to see a world map, and you can see where there are device labs near where you live. You can go to that device lab, and you can book some time, and go in, and test your websites on someone else&rsquo;s devices. It&rsquo;s an open device lab. You don&rsquo;t have to pay for any of these.

Equally, if you&rsquo;re a company who is fortunate enough to be able to afford all these devices and you want to share that with the community, you&rsquo;re not using them all the time, then you can register yourself on [00:08:00] Open Device Lab. Register the devices that you have, and then other people can come, and book time with you, and sit down, and test their websites using your devices, so a really, really cool idea.

Who else was there? I caught up with Brad Frost. He was there, and he introduced me to one of his friends , Dan Rose. Dan Rose is &hellip; he was a really cool guy. We hung out a bit. We went to the Kings&rsquo; hockey game. I&rsquo;m from Australia, so I don&rsquo;t actually think what ice hockey is like and about, and so I went in a t-shirt, and it was really cold. I didn&rsquo;t think that perhaps the stadium needs to be chilly to keep the ice from melting, so I froze for most of the game, but he&rsquo;s really cool, Dan.

He runs a website called “Photoshop Etiquette,&rdquo; so photoshopetiquette.com, and you should all go and check that out. If you are a designer and you work in Photoshop, go and check this site out. It tells you how not to be a pain in the butt when you hand your designs to a developer. It gives you tips on how you should be adding layers, how you should set things up, how you might be able to set your workspaces up or your outboards. If you&rsquo;re a developer, go and check it out. See how the designers will and can lay their Photoshop files out to make your lives a lot easier as well. Yeah, definitely go check it out.

He&rsquo;s done a lot of really cool work around Photoshop and workflows, wrote a book for Adobe called “Responsive Design with Photoshop.&rdquo; He does not advise you to design responsively inside Photoshop. You can&rsquo;t design for every single device and every single break-point unless you&rsquo;ve got a hell of a lot of time, but the book goes through and explains when [00:10:00] &hellip; what you should be doing in Photoshop, and where you should be jumping at, and trying to get in the browser, and get into the code as quickly as possible, so a lot of experience around that sort of area as well.

Now, I&rsquo;m going to try and get Dan &hellip; or Dan, he&rsquo;s going to come on the podcast in the next few weeks, and we&rsquo;re going to talk about that. We&rsquo;re going to talk about a responsive workflow, and he&rsquo;s going to talk through Photoshop and share his experiences of how he designs and how he works with developers and other designers who have more &hellip; so other designers that might have a lot of dev skills like a lot of HTML and CSS skills, and also, how he works with people that have limited dev skills who have never used HTML and how he works with them in different ways as well. He is primarily a Photoshop guy. A designer, but he does have his like responsive badge coding up site, so it should be a really good episode. I&rsquo;m really looking forward to that as well.

There&rsquo;s another guy there called “David Blatner&rdquo; as well, and he&rsquo;s more of an Illustrator and InDesign guy. He runs a couple of different conferences, and I think even like InDesign magazine or something. I&rsquo;m not a designer. I&rsquo;ve never heard of that magazine before, but he was really a nice guy, and we were talking about &hellip; because he was into InDesign and stuff like books can be written through InDesign, all these design and laid out type set, and we&rsquo;re talking about bringing books into the browser to make the content universally available across the world or universally.

It really struck a chord with me like this conversation because I&rsquo;ve been working on a side project of taking a PDF version of an old book, a science-y book, a universe-based book, and I&rsquo;m trying to put it across to HTML and CSS to make it more accessible [00:12:00] for everyone to be able to access it. It&rsquo;s an unsolicited side project, but I&rsquo;ve really enjoyed working on it. I want to make it offline and available for everyone.

I started doing a bit more research around it and seeing some other books as well, and there&rsquo;s a whole bunch of really great examples where authors publish books. They&rsquo;re for sale. You can download the PDF. You can download the EPUB version, but &hellip; and they might still be in print as well, so you can get a hard copy, but they also provide all of the content online for free. If you want to find out about it, then you can go and learn about it, but if you want to buy and you want to contribute to them, then you can buy it.

This one is learnpythonthehardway.org. Aaron Gustafson is &hellip; just released a second or is in the process of releasing a second edition of the “Adaptive Web Design&rdquo; book, but if you go to adaptivewebdesign.info, you can either pre-order the second edition, or you can read the entire first edition on the web as well. Brad Frost is writing a book, “Atomic Design in the Open.&rdquo; As he writes each chapter, it gets added to his site. That&rsquo;s at atomicdesign.bradfrost.com. Mark Boulton as well, he wrote &hellip; Jeez, I can&rsquo;t remember the name of his book. “The 5 Simple Steps: Web Design.&rdquo; I&rsquo;ll put it on the show notes, but that is another one (ed: it was actually Designing for the Web).

Lara Hogan with “Designing for Performance&rdquo; so designingforperformance.com. Again, there&rsquo;s a button there to buy it, but otherwise, you can read the whole thing online as well. Also, there was one I was speaking to, a former podcast guest, Stephen Hay. He really gets into this sort of stuff in terms of manipulating Markdown. [00:14:00] He uses a tool called “Dexy&rdquo; to work with his content, and he mentioned one called “practicaltypography.com.&rdquo; That&rsquo;s something that I&rsquo;m looking at, at the moment, so this concept of writing content in one place like in a Markdown sort of way.

I should point out that people are &hellip; that like Aaron, Brad, Lara Hogan, they all used Jekyll, I suppose. Like a static site generator, they created their content in Markdown, and then they ran it through a static site generator, which punched out a website at the end of it, which they then went through and hand-coded all the stuff that they want to, but the whole idea of like writing once and publishing everywhere is like the idea that we have with responsive design as well. We have to have it in 1 centralized location.

Anyway, this “Practical Typography&rdquo; book is just that. It&rsquo;s written, and then it&rsquo;s using a thing called “Pollen&rdquo; which is able to push it to EPUB. It&rsquo;s able to push it to PDF. It&rsquo;s able to push it to .MOBI. It&rsquo;s able to create a book as well. I&rsquo;m going to look into that, and try and get something, which we&rsquo;ll be at a &hellip; republish this, this thing. I&rsquo;m only really concerned about doing the HTML version because the other versions have already been created and are being sold. Yeah, it&rsquo;s really, really interesting, and that&rsquo;s the side project that I&rsquo;ll be working on over the next couple of months anyway, so that&rsquo;s excellent.

One of the things I&rsquo;m trying to do is mostly make these, the books, available offline. When I was going to fly over, I wanted to do some work on this side project, and it involves a little bit of jQuery because I&rsquo;m a little bit terrible with JavaScript. I can get by with jQuery, but I often have to refer to the documentation, and that&rsquo;s hard to do at 30,000 feet.

Now, [00:16:00] I haven&rsquo;t used &hellip; I didn&rsquo;t have Dash installed, which is apparently the go-to tool and what I should have, but I went to a site called “devdocs.io,&rdquo; and that allowed you to save different development documents offline, so when you went back to that URL, all of those docs would be available to you to check out like I had problems with my jQuery I couldn&rsquo;t work out, and so I went back to devdocs.io on the browser in the plane at 40,000 feet, 50 &hellip; whatever. However high you fly. I typed in the URL, and then bam, I had all the information that I needed.

I really love that idea of not just every device, we&rsquo;re creating content for every device in every scenario, but also, every data connection. If you&rsquo;re not connected to the network, is your content going to be available anyway? That is something that I think is the next thing that we&rsquo;re all working towards. The other thing that I&rsquo;m working towards is like making things more performant. Recently, the last couple weeks anyway, they had the release of AMP, so the Accelerated Mobile Pages. This is the new thing that Google kicked out there, and the whole idea is that it makes things faster.

When love when things are fast and when things load fast, but I had a carpool of problems in understanding what they&rsquo;re actually trying to do. For one, the A-M-P Project or the AMP Project requires you to create a new template layout for your site. It forces you, and I do mean force, so you to include this. You have to include the AMP JavaScript in the header of the document. If the AMP JavaScript doesn&rsquo;t load, then your page doesn&rsquo;t load. For me, that&rsquo;s against the [00:18:00] natural way that we try and get people to build things like, “You should build them progressively, you should make your content available, and then you should lay things upon it.&rdquo; To come up with a solution to a faster &hellip; to making faster websites and then forcing this JavaScript in there, it goes against the grind a little bit.

The other thing that it requires you to do is you need to use only a subset of HTML elements, and a lot of those elements then get renamed. For instance, if you want to include an image within your AMP document, then you need to not use the image tag. You need to use “AMP-image&rdquo; as the tag instead, and then there&rsquo;s a bunch of HTML tags that you are not allowed to use. I can&rsquo;t recall all of them. I&rsquo;m going to say things like you can&rsquo;t include things like iFrames. Basically, they&rsquo;re trying to make it as performant as possible, so they&rsquo;re stripping out things that might counteract to that performance.

Now, for me, it &hellip; this approach is like going back to an MDOT site. All right? In the past, we used to have desktop sites and mobile sites, and the mobile would have an entirely different structure around it. It would have different content in it, and it would only be available for mobile phones. This feels like the same thing. It feels like I need to create a new document to house new content within that just to take advantage of this AMP process.

Now, you can use &hellip; you can do it though like the focus I think shouldn&rsquo;t be about, “Let&rsquo;s get on to AMP, and let&rsquo;s start booting our pages there, and then that will solve our performance problems. Then, we can make our other site really, really big and have loads of images, [00:20:00] and it doesn&rsquo;t matter.&rdquo; That&rsquo;s not the approach like I would focus upon making your site as bleeding fast like bleedingly quick as possible. Once you&rsquo;ve done that, then you can look at your AMP stuff because effectively, AMP is just a way of making the web faster, so if you just made your website faster, you wouldn&rsquo;t actually need to use it.

Now, the good thing is it&rsquo;s not that difficult to set up, so &hellip; and complain a little bit about it, but effectively, if you already run an RSS feed, this is essentially what you&rsquo;re doing. All right? RSS takes the content of your page, and then repurposes it within an XML structure effectively, and then you can customize what you want in there. AMP does the same thing, so I created a new template. I created a new layout for the content area. The CMS that I use has like a template as a wrapper, which would be the header, a HTML head, body tag, and then closing body tag, and closing HTML, and then a layout wrapper, which then just lays out how the page structure would normally look.

For me, it took me an hour to set up. I didn&rsquo;t include any styles within it because I didn&rsquo;t want to copy and paste styles, and spend time. It was just to get it going, and I didn&rsquo;t mock around with the images at all. I included 1 image at the top of the page, which was like the article feature image. Imagine that like as a thumbnail kind of image, so I used the AMP image for that, but otherwise, I didn&rsquo;t worry about converting image tags within the body of the content itself into AMP image tags, so I don&rsquo;t know how that&rsquo;s going to break.

Like I said, it&rsquo;s like using RSS. If you&rsquo;ve already got that, it&rsquo;s not too much of a step. [00:22:00] The only other thing you need to do, you need to put a meta tag in the head of your document, so of the original document on your website. You put in a meta tag, and I think you do a “rel,&rdquo; a “rel AMP.&rdquo; I&rsquo;ll put it in the show notes to relate it, and then you give the URL of the AMP version of the page. Then, on the AMP version of the page, you point back to the canonical version of the article as well, so it&rsquo;s cool.

Again, I&rsquo;m not really sure it&rsquo;s the greatest thing in the world, but for an hour&rsquo;s work, at least it&rsquo;s up there. You can check it out. I don&rsquo;t think I&rsquo;ve set it up on the podcast page, but if you do go to one of the articles page, if you go to “Articles&rdquo; in the menu, and then check out one of the articles, then you&rsquo;ll be able to see the link to the page, and then you&rsquo;ll be able to grab the link for the AMP page, and then open that up, and check that out as well. How you register it with Google, I just assume they&rsquo;re going to index my pages, and then find that canonical link, and then go and index the AMP pages, but I&rsquo;m not actually sure. If anyone does now how that might happen, do let me know.

Google, Google do some cool things. This is one of them. I know they&rsquo;re trying to make the web faster. One thing that they did to make the web faster was they removed that 300-millisecond tap. If you had a mobile, a touch device on a webpage, it would delay 300 milliseconds on a touch to ensure that it wasn&rsquo;t going to be like a touch scroll. You put your thumb on the screen, and then you just push it up, and that&rsquo;s a scrolling action. If every time you did that and you were hovering over a link or a button, you don&rsquo;t want to fire that, and then just go to a different page every time you&rsquo;re going to scroll. That would be super frustrating.

The browser vendors put in [00:24:00] this delay to see if you like touched like down and up, and then it would do the link after 300 millisecond. Whereas if you left your finger there and moved it, then it would know it was a scroll event, and then it would scroll the page for you. On any device or any website on a Chrome browser on Android, that has &hellip; or the viewpoint meta tag set to width equals device width, then it removes that 300-millisecond delay when clicking and still avoids the incident of accidentally clicking through to links when you&rsquo;re scrolling as well.

Now, WebKit have just announced that they&rsquo;re doing the same, which means Safari users like us &hellip; yay, or us. I say “us&rdquo; because I&rsquo;m an Apple person. We&rsquo;re going to get that on the iPhones, which is awesome, but one of the problems is it&rsquo;s been released now, so they say, “Yes, we&rsquo;re going to do it now,&rdquo; but the release cycle for Safari is just diabolical. They release it once a year when they release the update to the operating system, so we&rsquo;re not actually going to get it until like September of 2016. Thank you for that, Apple. You guys rock in the most sarcastic way possible. It is super like frustrating to have this sort of things. This sort of thing is like so close, but then not able to actually take proper advantage of them.

Fortunately though, our great friends at the FT, the Financial Times labs, they&rsquo;ve come up with a lovely little script which allows you to bypass the whole 300-millisecond delay, so if you go to GitHub &hellip; GitHub. Is there a website called “GitHub?&rdquo; I wonder. If you go to github.com/ftlabs/fastclick, [00:26:00] it will remove that 300-millisecond, 350-millisecond delay from clicks and make your websites just feel so much more responsive. Definitely, go and check that out. It requires JavaScript to work, but hey, so does AMP, so sometimes. If it doesn&rsquo;t load, then you&rsquo;re just going to get the same use case, the same experiences as not loading it and you&rsquo;re not losing out on anything.

Now, that is designed to make it feel faster, make the web feel faster, and when we say “feel faster,&rdquo; we&rsquo;re always equating this to, “How does a native feel? Like how much faster does a native app feel?&rdquo; It feels native. It&rsquo;s smooth. It&rsquo;s 60 frames per second. I was having a long conversation/argument with a really good friend of mine on the way home from the football the other day. He is brilliant. He helps me with my hosting. He gets my website running super fast. He&rsquo;s been a massive help over the last couple of years, but we&rsquo;re talking about this new app that was coming out and how it didn&rsquo;t have a mobile side. It was native only.

We know that Instagram went this way for a little while, but I&rsquo;m sure even from the get-go, Instagram still allowed you to view pages. You just couldn&rsquo;t do anything, so if I took a picture of something, I could share it with someone. If they didn&rsquo;t have Instagram, they still got the web version, and they could see the image. Now, I want to say if they didn&rsquo;t have that maybe at the very beginning, it was a real pain in the butt because someone would send a link or post a link to their Instagram image, and then you&rsquo;d go there, and it&rsquo;d be like, “Bop bow, you need to install [00:28:00] Instagram,&rdquo; and that&rsquo;s super frustrating like really, really frustrating.

Anyway, so we&rsquo;re having this chat, and we&rsquo;re talking about this new app, and it&rsquo;s only native, and they&rsquo;re not going web because they don&rsquo;t feel as though web provides a good enough experience for people and that the web is dead. Now, not his words. He&rsquo;s recycling the words, but yeah, like the web is dead, and that native apps were the future, and the web will die this death.

Now, I remember seeing a presentation recently where they put up all the wide articles that mentioned that the web was dead all the way from like &rsquo;98, &rsquo;99, 2001, 2003, 2005, 2007, 2009, 2011 like it just keep coming up, “The web is dead. The web is &hellip;&rdquo; this time, definitely dead that native is going to kill it. Whenever I hear it, I just giggle to myself and like, “Yeah. Okay. Fair enough. The web is going to die. Sure. Native is the future.&rdquo;

I can see their point. It&rsquo;s just going &hellip; it&rsquo;s a bad user experience. They want to build their brand on a fast, sleek experience, but I think the experience of clicking and receiving a notification about something, and not being able to access it unless you have a specific phone or a specific operating system, or if you have enough space on your phone to be able to download the app, if you have a good enough connectivity to warrant downloading 50 megs, if you have a good enough connection. Not just like the speed of the connection, but how&rsquo;s your data plan?

I don&rsquo;t know how big this app was, but I&rsquo;m talking about like 50 or 100 meg. That seems a lot to me to be able to just view some content and a few pictures, but you have to download it like you [00:30:00] still have to download it. There are no times ever when you receive something that you have to download the internet. You never have to download the web. All right? Every device comes with a browser. If it doesn&rsquo;t have a browser, it probably doesn&rsquo;t connect to the internet, and you probably want to be able to get your native experience on that device as well.

For me, he was like dangling a massive red flag in front of my eyes that&rsquo;s like waving in front of me just waiting for me to charge, and charge I did. I stuck up for the web, and the way of building things responsively, and also that it doesn&rsquo;t need to be slow. We have things like this FT click thing. Now, I agree, it will be &hellip; things will be sleeker on native because you have &hellip; you&rsquo;re closer. You&rsquo;re like 1 layer of obstruction, closer to the operating system. You can tap into &hellip; just things will work faster that&rsquo;s naturally. It&rsquo;s a natural thing.

In the talk that I did at the MOBX Conference, I don&rsquo;t understand why you would have one over the other, right? I can understand why you would have a website over native apps because it&rsquo;s universal and not everyone is going to download the native app, but I don&rsquo;t understand why you have a native app without a website. There&rsquo;s no reasoning around it. You&rsquo;re just cutting off your nose despite your face by saying, “This has to be special. Only special people can access this particular content. I don&rsquo;t really want to access the universal audience that I have at my fingertips if I had a web version of this.&rdquo;

Anyway, we spoke lots about it. We argued quite a bit, and then we [00:32:00] just bowed and agreed to disagree. It turns out that on further conversations, and when we looked into it a little bit further, and spoke to a few other people we know, it is on this company&rsquo;s roadmap, and they are heading in that direction now, whether it was always that plan or they come to the realization, but it&rsquo;s something which I totally agree. Native apps are great. You do need them for some things to be super fast like I use Slack. It&rsquo;s great. I have it on my tablet and my phone, but I also have it in the browser. All right? It&rsquo;s just a good experience. If I were only able to access it in the browser, I would be absolutely fine with that because it does what I need.

That&rsquo;s my week. That&rsquo;s what&rsquo;s been happening. Yeah, we&rsquo;re going to &hellip; I&rsquo;m putting a couple of these links that I&rsquo;ve talked about so far into the newsletter this week. If you&rsquo;re not subscribed to the newsletter, make sure you head over to responsivedesignweekly.com and drop your email address in there. You&rsquo;ll get a newsletter once a week talking about all this kind of stuff with links that you can go off and check things out yourself.

Next week, we&rsquo;re going to be talking to &hellip; I say “we.&rdquo; I&rsquo;m going to be talking to the team from ZURB. ZURB are the guys that build Foundation. It&rsquo;s like Foundation and Bootstrap have been going head to head for the last couple of years. ZURB are actually about to release Foundation Version 6, and they&rsquo;ve cut their code by 50%.&nbsp;

They&rsquo;ve made things faster. They&rsquo;ve made them smarter.

What we&rsquo;ll be doing is we&rsquo;ll be catching up with some of the developers who have been putting this stuff together and talking about why they changed it, what has changed on the web for them to warrant changing the [00:34:00] framework in this way. Also, if you are running something like Foundation, how people be able to go and do updates properly. Can they just drop it in there, or is there like a few steps that they need to go? Also, where they&rsquo;re looking at next like what they think the next big problem is to squish out.

I also mentioned we&rsquo;re going to be talking to Dan Rose. It&rsquo;s coming up, so that&rsquo;s going to be all about workflow, and working with Photoshop, and the responsive design workflow in teams which will be really cool and really interesting. Then, also, Rachel Andrew who has agreed and said she&rsquo;d be happy to come on the show as well. Rachel is going to be talking about her thoughts and knowledge on the grid layout specification, which is really exciting. It&rsquo;s bed down a little bit now. It doesn&rsquo;t change as much as it was, so she&rsquo;s been able to create some really awesome examples and build up a little bit of a talk around. I think in the moment, she&rsquo;s in the States talking at an event, but &hellip; so it will be really good to get her on and chat through that stuff as well.

Yes, we&rsquo;ve got some really great guests and talking about some really great topics on the way over the next couple of weeks. Yeah. Thank you for tuning in and listening. Please go ahead and rate the show up 5 stars. Leave a comment. That&rsquo;s how people find out about it. Tell your friends. Tell your friends to subscribe. If you have a topic that you want me to cover, or if you would like to join me and talk about some of the things that you&rsquo;ve been doing at work, or some of the things that you&rsquo;ve been working on, or some of your own thoughts and ideas, then do reach out. You can reach me the contact form link in the footer, but until next week, stay responsive, and I will see you then. Cheers, everyone. Bye.

RWD Podcast Episode 43
46:40
2017-09-23 00:10:05 UTC 46:40
RWD Podcast Episode 43

Presentation Slides 

RWD Podcast Episode 42
22:29
2017-09-23 00:10:05 UTC 22:29
RWD Podcast Episode 42

RWD Podcast #66 : Grid Layout, Ecommerce Performance, and IphoneX
17:14
2017-12-22 20:56:41 UTC 17:14
RWD Podcast #66 : Grid Layout, Ecommerce Performance, and IphoneX

This week I get back into podcasting the hard way — by recording a 20 minute episode without actually pressing the record button.

Fortunately it was a good rehearsal to know about the types of things I wanted to cover in this first podcast for far too long.

The podcast was an overview of this weeks RWD Weekly Newsletter but once I’m able to string 3 weeks in a row together I’ll be back with some guests.

RWD Podcast 65 : Public speaking, Hololens, NBC Redesign
20:55
2017-12-22 20:56:41 UTC 20:55
RWD Podcast 65 : Public speaking, Hololens, NBC Redesign

Show Notes

RWD Podcast 64
15:45
2017-12-22 20:56:41 UTC 15:45
RWD Podcast 64

I’m just back from a few weeks in Australia visiting family and getting the podcast back up and running again. This week we go through the best links for the weekly newsletter.

RWD Podcast 63
11:07
2017-12-22 20:56:41 UTC 11:07
RWD Podcast #62
23:33
2017-12-22 20:56:41 UTC 23:33
RWD Podcast #62

RWD Podcast #61
58:00
2017-12-22 20:56:41 UTC 58:00
RWD Podcast #61

RWD Podcast 60
40:22
2017-12-22 20:56:41 UTC 40:22
RWD Podcast 60

Hey everyone and welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly newsletter, a weekly newsletter all about responsive design and other front-end cool stuff. This week I’ve got a small guest but it’s not until the end and I’ve got a piece that I’ll add at the end of the podcast, and the reason why I say it’s a small guest is because they’re small in stature it’s my little boy Noah and he decided that he wanted to do some recording over the weekend so we did a little short podcast together. If you don’t like the opinions of a three year old then feel free just to skip over it. So that’s why I’m not including it until the end. He probably has some better opinions than me a lot of times but, you know, he’s a little childish. Takes after his dad.

But this week to start with I’ve got a lot to offer everyone, so I’m going to get to that first. We’ve got a couple of sponsors this week which is fantastic and they’re giving everything back to us which is great. Or you, the listener. So, conferences, we’ve got a bunch on. We’ve got three conferences coming up. One in the states, one in the UK, and one that is global that you can view anywhere and the first one is the global one.

So this is the SVG online summit and anyone can join it, it’s global, it’s an online thing. There’s a tonne of talks during the day. Actually, let’s go through it properly. A better-prepared person would have all this here. So SVG Summit, if you go to svgsummit.com then you can go check it out. If you use the discount “RWDWEEKLY“, all capital letters, that’s good for 20% off. Now it’s coming up on the 15th of February so it’s not too far away. Starts 10:00am Eastern Standard Time, 9:00am Central Time, and it has six speakers throughout the day. Chris Coyier, Sarah Drasner, Amelia Bellamy-Royds, Dudley Storey, Clark Wimberly, and Kevin Ball and they’re all talking about SVG and different ways to use it online. It’s going to be super cool.

And the great thing about these online conferences is you don’t have to spend any money flying there, you don’t have spend money on accommodation. I love flying to places but it gets expensive when you add everything up, and the time you’ve got to take off. So this just pop it on your computer at work, put your headphones on, and just learn lots. They’re really cool conferences. I’m fortunate I’ve been to a couple where I’ve partaken in a couple, watched on the computer, and I presented at one as well. It’s just so much fun. Really good, the guys do a good job there.

The second conference we’ve got is for the awwwards, so this is for folks in the UK or Europe and it’s coming up fast. It’s the awards conference so A.W.W., see what they did with the name? That’s coming up on the 2nd and 3rd of February so I’m going to be going along there and I’m going to be hanging out with some friends from the Adobe XD Team who I caught up with late last year and I actually want to speak to them a little bit more too because I think the XD stuff is really interesting in terms of like rapid prototyping and being able to get interactions and things on the screen that clients can see. So I kind of want to try a couple of screen-casts and see how it might work out to improve our responsive workflows and stuff.

So if you want to go to that you can go to conference.awwwards.com/london2017. Do a search for “awards conference in London” and that will come up there, and if you use the discount code “responsivedesignldn“, it’s like responsive design London, that’s good for 10% of the ticket as well. They’re also going to be doing a live stream of the conference out as well and Vitaly from Smashing Mag is going to be there to kind of host that as well, so that should be really cool. I want to catch up with him as well because Smashing Mag are doing this huge redesign. They’ve had people like Sarah Souiden working on it, I think Dan Mall had done the original designs perhaps as well. It looks really good. It kind of looks a lot like the Responsive Design redesign as well so I’m happy that the design that I’ve gone with, with the guys from No Divide, that they’re going in a direction similar to Smashing and I think that’s a good direction.

But as part of this, Smashing Magazine and Vitaly, they’re looking at different ways of generating an income for a publisher. So it’ll be really interesting to see with all the ad blockers in now, they don’t make as much money through ad revenue, so you need other ways to supplement the income to continue the business. And Smashing Magazine is a big business so it will be really interesting to see what he’s doing to try and tap in with that. I think he’s going along a little bit of subscription model which I think is cool. I’d be happy to subscribe to a magazine like that, they put out a lot of good stuff. I feel like I should be paying them for doing that as well because they pay all of their writers and I really like it.

And then the last one is for people in the states most likely, or the Americas, and that is called “ImageCon” so it’s imagecon.com and if you use the code “RWDWEEKLY” it’s good for 50% off your ticket which is really cool.

Now I wrote a piece earlier in the week about how to approach typical problems when uploading large numbers of images and it’s actually what I’m going to be talking about after this and running through with you today. If you want to head along to the conference that will let you understand and deal with bigger problems than just how to get images optimised properly and rolled out on your screen or near different sites. They’re going into a lot of detail like the different problems that we have with images at the moment, and it’s on the 1st of March. So 1st of March in San Francisco and it’s got some amazing speakers like Jason Grigsby, they’ve got Allison McKnight from Etsy, Vitaly as well, we just talked about Vitaly from Smashing, Steve Souders like the performance person getting around so he’s at SpeedCurve these days. So all these great people talking about images and it should be a really good conference. That’s imagecon.com and use “RWDWEEKLY” for 50% off your ticket.

That’s all the discount stuff at the top of the show so you can save 20%, 10%, 50%. Great stuff.

So for this week I wanted to talk about watching your weight. And I’m not talking about like the post-Christmas holiday weight and “Oh my goodness, I’m going to put a New Years Resolution to never eat unhealthy again, and I’m never going to drink again.” We’re talking about image weight on your websites. And the reason why I wanted to talk about it this week is because, like I said a bit earlier I wrote an article this week is because I came across a tweet from Andy Clarke. Now Andy Clarke has published this awesome article on his site called “Designing Inspired Style Guides” and it was a talk that he delivered, and he doesn’t think he’ll be able to deliver the talk again, but it got a really good reception and so he thought, “Rather than waste all of this great content, why don’t I turn all of this great content into a super long blog post? Then more people can enjoy it.” Which is like, kudos. It’s a really good, long detailed article about style guides. So kudos to Andy for doing that.

Now in the second paragraph of the article he even says, “This page contains a lot of images.” And he says, “This page contains 35 MB of images, I’ve optimised them as much as I can but you probably don’t want to load this page on your mobile data plan.” So that’s great that he gave people the heads, there’s just the issue that by the time I’ve read that, a lot of the images which are on that page are already starting to download. Now I suppose thing in this is that there were so many images on the page, so there’s like 150 images, there’s so many there that it won’t have downloaded that many because of the number of connection that it has. Or it needs to make the number of HTTP requests. So by the time I read that I could hit stop and then save my data plan a little bit if I was reading it on my phone or even my desktop I had time to stop it.

So I want to get this super clear up front, Andy did as much as he could do with knowledge that he had on providing an awesome resource to everyone and giving them a heads up. Like that’s awesome. Not many people would do that. And I thought, “I wonder if there was anything that could be done to perhaps make that experience a little bit better for users. Let’s see how this goes.”

What I did was first I opened up Chrome Dev Tools and I opened up the Network Panel. There’s an option in the Network Panel where you can set a throttle, so you can say rather than run off your regular connexion to the internet you can set it to run at 2G or 3G or good 3G or 4G or GPRS so you can test different network conditions. So I tested a mobile network condition at regular 3G, ticked “Disable cache” because I’d used the page before, and then refreshed the page and started watching it. And once it had finished loading I noticed it was slow because it was on 3G but all of the files that were being served were PNGs, that was one thing that I noted. And immediately there come a thought, “That must have been the default export option for the presentation he did, Keynote or PowerPoint.” I also noticed that all of the images were being loaded regardless of whether or not I had scrolled down the page to view them, and the last thing I noticed was that every single image required it’s own HTTP request.

So with 150 images that’s 150 round trips between your browser and the server and going through network connexions. With that information I thought, “Right. Let me address those images and see if I can improve upon the load time for that particular page and the great resource.” First I saved down the page locally, so if you ever want to grab a webpage from someone’s site and put it locally so you can work on it and check stuff out, it’s File > Save Page As > Webpage Complete. And that downloads the HTML as a HTML document and then it also downloads a folder and within that folder it has all the assets, so all the images, all the JavaScript, all the CSS, everything that goes to make up that page. So if you’re offline, locally you can double-click on that HTML document and it’ll open up and you’ll see the entire page. So that’s a good start.

I saved it to my desktop and then I moved on, and I mentioned that the first thing I noticed was that PNGs were being used for everything. Now as a general rule you can either have PNGs or you can have JPEGs. It used be GIFs and JPEGs and I know there’s PNG-8 and PNG-24, I won’t go into that but let’s just start with it’s PNG or JPEG. So if you want to choose a PNG, you should choose a PNG when the image is more of block colours. So think vector kind of things like logos, icons, they’re kind of just full block colours. Also if you want to have a transparent background then you might choose a PNG as well, and we’ll go back to the logo and PNG transparency thing in a sec too. You should choose JPEG if the image is more of a rasterized image, like a photo. They’re the general two choices.

Now back at the logos and icons, technically these days we probably would want to go for an SVG rather than a PNG purely because it’s a scalable vector graphic. So it will scale from small viewports to large viewports, so rather than have many different types of your PNGs depending on what size you need to render them as, you have one SVG and it scales magically. Hooray!

And then on the transparency side of things as well, there’s a file type called WebP and it’s supporting in Chrome and I think Opera as well but I do know that Safari were looking at implementing it as well or they were checking it, and they never check stuff out like this so that’s really positive. WebP is a lot more performance so you can compress it a lot more and get still really, crisp, clear JPEGs effectively at much smaller file sizes and it provides transparency as well which is really cool.

So looking through all those images I thought most of them were more suited to JPEGs than PNGs, and if you PNG something that should be a JPEG the file size becomes incredibly larger than what it should be. Whereas if you JPEG a PNG you can really small PNGs for quite large pictures because it’s mostly block colours and you can get incredibly large PNGs for small pictures if it’s more suited to a JPEG. And just out of interest if you’re going to export your files or your slides from something like Keynote or PowerPoint there is an option, definitely in Keynote you can select JPEG high quality, small file size, PNG or TIFs. So just think about what most of your images are going to be and export to suit.

So now that I had them all downloaded, all of the images, or downloaded the webpage, then I wanted to change them all from PNG to JPEG. Now normally with my Mac I can right-click and say “PNG to JPEG” because I’ve set some automation up because I take a lot of screenshots and I just want to switch it through the PNG to JPEG because traditionally JPEGs are better for the screenshots that I take, so I’ve got like this right-click shortcut. But because it’s 150 images in this case I have Photoshop on my machine so I was able to use something from Photoshop, so in these cases where you’ve got large scale, you want to batch-process things. So if you go into Photoshop and you go File > Scripts > Image Processor then it gives you a few options, you select the folder of the images you want to change, you select a folder for where you want your images to end up and then you pick what file [size 16:26] you want it, in this case it was JPEG, and the quality that you want it as well. I chose a four which is about 30% quality because I wanted them small.

Then I hit “Save” and then bam, we got a whole bunch of JPEG images and that changed the file size so it wasn’t 35 MB it was now down to 10.4 MB. So we’ve already reduced it down to a third of what it was just through changing the image file type and optimising the images a little bit. Then when I had all of that the next step is a little bit further optimisation using a tool called ImageOptim. It’s a free tool and the wonderful thing about that is that it provides lossless compression which means that image isn’t as big but it is just as beautiful as it once was, so it doesn’t affect the quality of the image at all, it just reduces the size of it which is exactly what we want. To do that it removes like … I actually don’t really know what it does, it’s like magic I think. But what I do know is it removes a whole bunch of metadata about the image which isn’t needed for people to view it on the web so just get rid of it. So yay ImageOptim. Free, you should totally get it.

So I dragged all the images onto Image Optim and then within like 30 seconds or a minute it had processed all those images and that had taken it from 10.4 MB down to 6.1 MB so now we’re talking about going from like 35 MB all the way down to 6.1 MB which is amazing. From there it’s a simple … I always say simple matter, it’s not always simple. From there you need to get the images back onto your server so I used an FTP client and you put all of the images back into the folder that you had all you PNGs, it won’t override them because now they’re all JPEGs so it won’t overwrite a PNG because they’re different file names. And once they’re all back in there you have to update the reference in the post, so at the moment all the image tags are referencing .png you need to reference JPEGs and it’s Control-F like a find and replace. So you want to find anything that says “.png” and replace it with “.jpg” then you publish and voila. You’ve gone from 35 MB per page for every visitor down to just 6.1 MB for every visitor.

Not only is that really good for the users so they get the content faster, they don’t have to wait around, their browser doesn’t slow down, they don’t lose all their data. The other great thing is Andy is a popular guy, he writes a lot, he does some cool stuff. Now he would have like, I’m guessing 10,000 people would go and view that article that he wrote, it was re-tweeted by a lot of really popular people in the web community as well. So 10,000 people at 30 MB, that’s 300 GB of data that he’s now saved and he doesn’t have to pay in bandwidth. It’s just fantastic, it’s a win-win for everyone I think.

So at the top of the show we talked about there’s three things, so there’s the file size which we’ve now corrected to a certain extent, a pretty good extent I would say. The other thing is that all the images are being loaded regardless of whether or not anyone was going to see them. To fix that essentially you’ve got 150 pictures you might not scroll through all of them so why should you be downloading the ones that you’re not going to view. So you can use a tool, it’s a JavaScript plugin called “lazySizes” and what that does is it Lazy Loads the images into the page. What that means is that when you first load the page it will load the images that you can see that are within your current viewport and then as you scroll through the site as the other images get close to the viewport then it will say, “Hey, you’re about to be viewed by the user. I think you should start downloading now so that you can be there for when they arrive.” And then as you scroll through the images slowly start being loaded in.

If you stop scrolling then the images stop being loaded from below the viewport and it’s just great because it means that only the images that you’re likely to see are going to be loaded. So you’re only paying in bandwidth and time and even the hosts, so Andy is only paying in his bandwidth for the images that you’re going to see as well. Now to do that, like I said “lazySizes” if you do a search we’ve got it in the resources section on the Responsive Design site as well and it’ll be in the show notes. It’s a small JavaScript file, you can load it asynchronously so it’s not a blocking script, it won’t affect the load of your page. And for any image that you want to Lazy Load you need to change the source to “data-source” so it’s a data attribute instead and add a class of Lazy Load to that image.

Now the reason you have to do that data-source thing is because browsers are super smart these days and as soon as they detect an image tag, like even before all the HTML has passed, it will start downloading all of those images and that’s to make it seem as though web pages are faster. They do that for the users benefit for performance side of things. What that means is that all the images start downloading before any JavaScript can run and stop it from downloading so that’s why you need to change it from “source” to “data-source” and then as you scroll through lazySizes checks to see whether the image is approaching the viewport, as it gets close to it like within 200 pixels or so, then it changes the “data-source” to “source” and the browser will download the image. So it’s super, super cool.

I’ve used it for a few sites, I did it for the Adobe Mac site, I rebuilt their conference site from like a better approach for a responsive, responsible design and performance is a big thing. I added lazySizes to it and it’s shaved like several seconds, we’re talking five or six seconds off the load time of the site by just implementing the lazySizes. Very good for image heavy sites, especially for ones that are below “the fold”, so definitely implement that if you can.

We also talked about I said there’s lot of requests for the images as well, so if you were able to run on HTTPS and your server supports HTTP/2 then instead of having one request for each of the 150 images and there’s latency on every single request, with HTTP/2 you don’t have that latency. It can just request all of them at once and they can all download and of course if you’re using lazySizes then you trip yourself up because you don’t want them to all download at once. But that connexion will stay open so you don’t have to make it look up every time, which is fantastic.

And the final thing, there’s one more thing that we can do. For those in podcast room, can anyone just raise your hand and say … Like, are you thinking of one other way that you haven’t mentioned, the key way to have better images for this page? Anyone? You in the back, Mr. Eric Portis? Yes, you were right. It’s using responsive images is the other thing we could do. This requires a little bit more work. What we had for these images is they’re all slides, so they’ve all been exported about 1024 pixels wide. Now if I’m viewing that on my iPhone 5 which has a width of 320 pixels and it’s a retina one, I think they’re all retina, 320 you might double that and arguably say it’s 640, but that’s still like half the screen area of what I need from what the image is being loaded. It’s 1024 only you really need 640. So we can include something like SourceSet for the images so that we can give the browser several different sizes of image to chose from and then it would download the image that best suited the viewport to render that image.

And that great thing about that lazySizes that we talked about before is that it works with responsive image syntax as well so it works with SourceSet and it works with picture as well. So that would be a cool bonus addition there and the reason I … Eric didn’t really put his hand up, but Eric Portis wrote this really awesome article about responsive images and again I’ll link to that in the show notes and it’s linked in the article as well.

So that’s it, so this is how we can turn like … and I encourage everyone, we’ve got this problem at the moment with large web pages, they’re bulking, they’re oversized, they’re overweight. And most of the weight is due to images. We always complain about, “Let’s not include that JavaScript library in there it weighs 30 KB.” And yet we’ll chuck on 35 MB of images onto a page. I see this all the time and it doesn’t have to be 35 MB it could be 5 MB of images, the point is that’s too often, that’s too much. But if you can approach it in a systematic way like, “Am I loading the right images? Are they properly optimised? Have I put them in a responsive image container so that only the right sized image gets served up? We’ve got a tonne of images, are they loading below the fold? Are my users likely to scroll down there and if so will they scroll all the way or should I just be serving up a couple that they’re definitely going to be seeing?”

This is the other reason why this image conference is on at the moment too because it is a real problem, but I think we make the problem worse for ourselves by including these things. And I realise that most projects are done in a rush, unfortunately, it’s just the nature of the way we do things. These kind of things tend to be, “We’ll look at that later, let’s just get it up and going.” And I think that’s a bad approach. We should really just focus on trying to make it a little bit lighter, try and work those images as well as we can and see how we go.

So that’s it. Thank you for listening, thank you for tuning in and downloading. If you want to talk about something, if you want me to cover something in particular, feel free to write in. You can hit me up on email, you can reach me on Twitter @ResWebDes, you can subscribe to the newsletter at responsivedesignweekly.com and please rate this show up in whatever podcasting listening tool you’re listening to at the moment. Rate it up that would be super awesome.

Coming up next is my little interview with Noah so if you want to check out what a three year old has to say about the web and what’s better, what’s the newest thing coming out and what’s the best thing to watch The Minions on, then you are in for a treat. Until next week, I will see you soon. Cheers. Bye.

RWD Podcast 59
10:00
2017-12-22 20:56:41 UTC 10:00
RWD Podcast 59

Hey everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery and I am your host and curator of the Responsive Design Weekly Podcast, and the newsletter, a weekly newsletter all about Responsive Design and front end funky stuff. Now this week as you will notice, my throat hasn’t cleared up at all, the kids have kept my cold going and my cough has just got worse. So we’re going to keep this super quick because you don’t want me to be coughing in your ears on your journey to work or while you’re chilling out. So we’re just going to cover one thing this week, and again there’s no guest this week but next week I have two people to chat to which I’m very, very excited about. Yeah, it’s going to be awesome.

So this week, the feature side, the feature article for this week is we’re looking a little bit at an article which Scott Jehl has written from The Filament Group. Scott Jehl for those of you that haven’t heard of Scott, he has been doing wonderful work over the last couple of years on the web and he’s always about practical performance. In fact he wrote a book on just that topic as well. If you go to “A Book Apart”, I’ll type that in and it’s great radio. Here we go with the coughs. So yes, we know of the Responsive Design right? So “A Book Apart” Ethan Marcott wrote his first article on [inaudible 00:01:48] and then he wrote a book called, “Responsive Design” and then it was followed up with “Responsible Responsive Design” from Scott Jehl, and it’s just talking about the responsible ways in which we can approach the booting of websites. Now because Filament Groups stay on top of this stuff, the site is usually pretty darn fast and this latest article though we’re featuring is about them stepping it up, so the title is, “Modernising Our Progressive Enhancement Delivery” and it’s all about taking advantage of some of the newer tools that are available to us today, not across the world, but available to a lot of people.

And namely that is around HTTP/2 and so we can look at the browser support for HTTP/2 and it’s running on IE 11 partially but it’s limited to Windows 10 for IE 11, but Edge runs so 14 and 15 for IE or now Edge. Firefox supports it as of version 36 I think and we’re up to version 50 at the moment. Chrome has supported it since 41 and we’re at 55. Safari? Come on Safari. Safari offered partial support. Safari. Opera supports, iOS Safari does support it, Opera mini does not, but Android browsers and Chrome for Android both support it as well. So that’s from the Browser point of view. So if you send an HTTP/2 across to a Browser that doesn’t support it, it just falls back to HTTP/1.1 in the way that the web works. We always fall back, which is great, and that’s why the web is so awesome.

So the thing with HTTP/2, one of the coolest things, I think I’ve talked about this a little bit in the past as well, it’s just a lot faster. The communication between the server and the browser is done with 1’s and 0’s now, instead of text, so it’s a lot quicker. The compression on the chats is a lot better as well. But the main thing is that there’s no blocking requests. So previously if we requested an HTML page, and that HTML page had CSS and images and JavaScript and the like, it would wait, generally we would have that waterfall, network diagram. So it would request an image and then it wouldn’t request the next image until that image had downloaded and then it would go off and request the other one and the bring that back.

So each time we needed a new HTTP request, which was expensive and made things slower. With HTTP/2 you won’t even need to make a single request, and when the HTML comes back to the Browser, it then looks through it and goes, hey I need all of these files, go and get them. And they all come back at once, which means we don’t need to concatenate files together so much anymore because we’re not using the extra HTTP requests, it’s just all coming back. So instead of seeing this hierarchical, as like waterfall thing, it’s one request, bang everything else comes back. So that’s great.

The other thing that we’ve been doing is critical CSS. So the idea is that we want the first fourteen kilobytes that comes back from the server, we want to render as much of the page as possible within that first fourteen kilobytes because that’s the first trip back. And to do that we need to have all of the CSS that is required to render the visible part of the page within that first fourteen kilobytes. So we used to inline that CSS, called critical CSS. With HTTP/2 now, we’ve got this option of a server push, so that when the request goes out for the webpage, so when you request the Filament Groups homepage, as the server send the HTML back to the browser, you need to wait for the HTML to arrive in the browser, look through the HTML, find the images and the CSS and JavaScript, then request them, and even then they’re going to come back in one whole hit, and it’s one request, there’s still a bit of latency involved with that.

Instead because you know what file is going to be sent back, you can instruct the server to say, hey if someone requests this page, push along that HTML we’re sending back, push all these files because I know that these files are going to be required on that page. So that’s really, really awesome. It means that you don’t have to do that second request and then you don’t actually have to inline your styles anymore, you can just push them down.

Now I can imagine you’re thinking, but hey what if we already have those files, what if we’ve already visited that page once before? Fortunately, Scott has thought of that as well, and they’re using a cookie to check that. So even though the push happens, the browser can actually cancel that at any point. Now there is a couple of occasions where those files will come down and you will get the extra burden on your data plan because you’ve downloaded files that you already had. But for the most part once that cookie is set, then you no longer have to push those files down anymore, which is great. So I highly recommend, check the newsletter out, check the website out on redesign.responsivedesign.is.

Well you’re probably there at the moment, check the show notes of this as well, we’ve got a link to that article, but definitely check it out, browser support is great like we said. HTTP/2 you need to do a little bit of configuration on your server depending on what server you’re running, that will also need to support HTTP/2, but if you’re using something like CloudFlair, which I highly recommend, that actually has HTTP/2 out of the box. Another bonus about it as well is that you have to be on HTTPS, so you have to be serving your site securely to take advantage of HTTP/2. Another good reason to use it because you get all of these benefits along with it.

So that’s it for this very short episode, I’m really hoping that this cough sorts itself by the time we get a guest on. But fortunately, they will be doing more speaking then what I will, hopefully. Either that or I’ll just sit with a bottle of cough medicine and just swig it for every time I’m going to ask a question, another swig and see how we go.

So that’s it for this week, if you’re not already subscribed, head over to responsivedesignweekly.com and subscribe to the weekly newsletter. Check out the new stories going up on redesign.responsivedesign.is every day, and we tweet about them, so you can follow us on Twitter @ResWebDes. See you next week.

RWD Podcast 58
19:35
2017-12-22 20:56:41 UTC 19:35
RWD Podcast 58

Show notes

Transcription

Hey, everyone, and welcome to another edition of Responsive Design Weekly. My name is Justin Avery, and I am your host and the curator of the Responsive Design Weekly news letter. A weekly news letter all about front end development and back end stuff and performance stuff and frameworks and tools. A whole bunch of stuff. This podcast is like a … I was going to say  a sidekick. It’s not a sidekick. It’s like a spin off of the news letter as well, so I bring you some cool stuff on the podcast as well I hope. This is edition number 58 which is kind of cool, and the fist time that I’ve gone back to back editions week to week for a while actually. It’s the first time in 2017, but it’s only been two weeks in 2017, but it’s actually the first time for quite a while including 2016, so yay.

Thank you for downloading and tuning in again. This week I’ve got like this tickle in my throat thanks to my little boy. Thanks to him going back to school, so he’s bringing back a whole swathe of new germs that can do the run around in the family as well, so I’m going to try this thing where I click on the mute button if I feel a cough coming, so there will be like tonnes of tiny little pauses through the show. Super professional, I know.

This week no guest, but I did on Tuesday night I went to the London web performance meet up, and I saw a wonderful talk from Ada Rose Edwards. You can see her site at Ada.is. She was fantastic. She talked all about web VR. Now, I looked into web VR a couple of months ago because a client was asking what they could do with it, and they wanted to keep on top of things, and when I had a look I came across this framework called A frame. Aframe.io, and it’s a framework produced by the Mozilla company. Here we go. We’re going to try to cough quickly. I hope that worked.

I believe it’s developed by Mozilla. Anyway, it’s a wonderful thing. It’s like a framework. You drop in a bit of Java script, and instead of programming really, really difficult like web GL stuff and things that I have no idea or understand, have any comprehension of how to do at all. You drop this code in so the reference to a Java script file, and then you can just pretty much write HTML. The HTML, like you write HTML but with particular components, but it then turns it into a wonderful web VR experience. Then all you need is, all you need, you then need a phone. Some description. Something that supports web VR, so I mean I’ve got an iPhone five here. I’ve got an iPhone six from work. Both of those support it, and then like a headset which could be Google cardboard, or it could just be you pushing the phone really hard up against your face.

Google cardboards come pretty cheap. Fortunately there was a Google representative that gave away 100 Google cardboards at this meet up, so we all got to try it out. I forgot to hit the mute then. It was a wonderful meet up, and it was really, really good. Ada talked. No slides, just demos which makes it even better. Web VR it’s really a thing. It’s like it’s here, and it’s ready to go. I’m not going to lie, it looks a little bit like the designs that were coming out in the mid 90s or late 90s, so they’ve got a very 80s, 90s feel about the designs, but that’s because the web VR stuff is still, I mean the pixel perfection we expect retina quality stuff now with our screens and our phones, but the resolution on web VR just isn’t up to that scratch, but man it is immersive, and it is cool, all right?

One of the wonderful things I think is that you can jump straight into it. Now, A frame has a whole bunch of examples to allow you to get involved with it straight away, and there’s this wonderful component that you can add in called a sky box, all right? It’s almost literally … Let me just fire up. I built a call thing. Well, I didn’t build a call thing. I built a thing. Not necessarily going to say it’s cool. Yeah, it’s called a sky, so you know how I’ve dissed [amp alone 00:05:12]. I’ve questioned the usefulness of amp and the ideas behind it, so this has a very similar idea, so you’re loading in Java script at the top of the page. May as well.  We have locking script.  Pretty sure it is. Then instead of using regular HTML tags you’re using kind of like components I suppose, so everything in amp is predefined or prefixed with amp-image or amp-iframe.

Everything in here with the components is prefixed with an A for A frame, so you can build a box which is A-sky. Give it an ID. Give it a radius. Give it a source, and then it will effectively build a sky for you which is well cool. Now, the cool thing that I did with this if you go on to aframe.io and we can try it out. There’s an example which is a 3-D 360 image. This is how simple it was. It was lunch time yesterday, and I thought look I just want to try this out. I want to see how quickly I could build something that might be somewhat helpful. I jumped on and we have at work some clients, and as you would hope, and the clients are really keen on making sure that new employees get a really good feel for what it’s going to be like to work at the place.

All right, and that’s great, so you can have tours of your office which is fine, or you can show pictures, or you can show a video of the office and stuff, but sometimes things like if you’re working in construction, so we have like for a couple of construction companies, you can’t take people onto construction sites and show them because you’ve got it go through a whole bunch of safety rigmarole things, so it’s not really going to fly. Some places are super secure, so you’re not allowed to let people in, so even though you could show them the office, and there’s nothing super secure on desks or anything you’re not actually allowed to let them into the building to begin with.

Sometimes people just won’t travel, right? If you’re doing an international placement, or if you’re moving from one side of the country to the other, and you want to get a feel for what it’s like then, I mean, it’s a long way to go just to get a feel. I thought well it would be cool if you could kind of get an immersive experience of what it’s like in an office. I downloaded … For this you need a 360 degree picture, and so I didn’t have the camera. You can get a camera, and what Ada recommended there’s a Samsung Gear 360. It takes some pretty sweet shots. Like, it looks beautiful. It does video I believe, or maybe it’s just … Could be just … I’ll check that. It may not do video, but it definitely does some beautiful pictures. It’s 349 quid, so not cheap. Not something that I’m just going to drop 350 quid on to try out, but I probably will now that I’ve seen how cool it is.

I’m not going to tell you to go and do that, but if you do have a phone which I’m sure most of you do there is I think available for the iPhone anyway which is what I had. An app called 360 panorama, and it’s by Occipital. It was a pound 50, so 350 pounds verse a pound 50. I went with the cheaper pound 50 for a change, and essentially it lets you kind of do a panorama like you can do with your iPhone now, but it sets like this globe grid behind it to begin with, and then as you hold you phone over a particular area it records that part of the image and then adds it to this grid, and you basically do a circle and then you look up and then you look down, and you’re done. You have this amazing 360 … You have this amazing … I just muted my headphones instead of the microphone, sorry. You have this amazing 360 view. This is great.

Now, from that you just download it and put it into an images folder like you normally would a regular image and then you’ve got this picture which you can then paint on the sky box, all right? This is amazing, so you can get started with this just having a 360 image, and I think it’s like about 30 lines of code, but for me it was like a copy and paste and update one image reference. It was really cool. What I did is I downloaded this thing and then I took a look around, and I did a 360 view at my desk. Then I went into our kitchen, and I did a 360 view of our kitchen as well. Then once I was finished doing that I downloaded the picture and then I chose the gallery option, so the gallery option is like the 360 image, but it allows you to have multiple images.

What this does is it just gives you the ability to put like just two boxes like a thumb nail to say I want to view that one, and with web VR because you don’t have a mouse or a pointer or a clicker you can write into it that you want a little dot which is kind of life your reference point, or it’s like a pointer. Then if you move that dot onto a square that you’ve designated as a link and you stare at it for a little bit it activates that as if you were clicking on it which is super cool, right? Then the click is you can just control the click event like you do with Java script for normal click events. I’ve got these two boxes now which one says office, one says kitchen, and you look at the kitchen box, and it sets the sky box. The A-sky to use the 360 picture of the kitchen, and then if you look at the office box then it runs Java script and that sets it as the office one.

Now I’ve got this 360 immersive experience with … I mean, I’m going to say it’s not the best picture in the world, but it gives you an idea of what the office is like. Yeah, so now we’ve got this thing, so if I was to say hey you should come and work for us. This is what our offices look like. This is what our kitchen looks like. This is … Maybe not toilets, but you know just showcase some of the different areas. If you’re in a building construction site you can showcase those different areas there. If you’re selling houses why not showcase the different rooms the house has?

One of the things I want to do with it is I’m Australian. I live in the UK. I have a lot of family back in Australia, family and friends, and they’ve never been over to visit. They don’t know I I live. They don’t know what our house looks like. They can’t picture like what a garage is like or a backyard or anything, so I’m going to go … Especially my dad who’s technically not there I would say to be nice. Sorry, dad.  You’re not the most cynical person. The most practical person in the world. He can build. He’s build a barge. He builds some cool stuff, but computers he’s not a fan. I can now do these pictures in rooms and set this up, and my brother who lives over there with him still can give him this phone. He can put on this cheap Google cardboard headset, and he can be immersed. He can see pictures of the kids. He can be involved in it.

It’s really cool, so anything you can do with Java script you can do. You can import objects. You can, if you’ve done a bit of SVG work and sort of moving SVGs around and animations and stuff this is all possible with this A frame. I highly, highly recommend it. We talked about responsive design. We talked about how we’re going to make our information and make our content respond to the different devices that we’re consuming it from. Well, we’ve been looking at screens. We’ve been looking at windows, so I remember someone describing a screen as amazing, but it’s kind of like if you take a picture and then you put it in a frame. That’s kind of … That’s what you get. You can look at it, but you can’t experience it. You can take a video of something which is better, but it’s still a picture, and it’s still a frame, and you’re looking at it through a 16 by nine window. What you want to do is you want to put your head through that window and be there and experience it.

If we can create content which allows people … We are creating content, but we want to be able to create content that allows people to experience it in that way, and at the moment the web can now do it, so with this web VR we’re able to start doing it. Now, a couple of things which I’ve learned over the last couple of days and from the talk is text in web VR is not a great idea. I still want to wrap my head around that a little bit more, but I just have really advised against using huge amounts of text. That causes a bit of an issue if we’re creating loads of content on our web sites, and we want people to consume it, and then we said we can’t use text then we need to find other ways for people to be able to do that. I need to wrap my head around that a little bit more. If anyone has experience on web VR and large amounts of text or being able to consume content, text content, in that way, I’d love to hear from you and learn a bit more about that.  I’ll be updating anyway.

I kind of want to do a responsive, so I’m doing the redesign of the responsive design that is coming along nicely. I kind of want to add a web VR version of it as well, and see how that just might look. I think that would be quite cool. Text, not so great. The other thing is you need the camera, but like I said we’ve got this fall back. You can use an app to do that instead. There’s a whole bunch of different cameras that you can get a hold of, but apparently that one is the best one. The Samsung 360 VR. We also at work we did this project with an energy company, and we built this 3-D model of this island in a futuristic city, and the 3-D modellers, we only got a 2-D picture of it because we were putting it up on a website, and we kind of made it float like an island because it was a transparent PNG, but what we really wanted to do is make it so that people could experience it. They could turn it around. They could zoom into it like a web VR process.

I’m going to get that file back.  I’m going to trial it out and see what it’s like. Now, when you’re working with 3-D objects, I asked Ada and she said, “What you want to do is you want to keep the polycount under 100,000 in total.” I don’t know what that means, but just that’s a tip, right, so someone says because that was a question the 3-D artist asked me. They said, “What polycount should it be?” I don’t know. What is a polycount? Under 100,000 is what you want. The other thing that the 3-D artist asked for was what file type did you need it in? For that, again, I have no idea, but you can work with objects so .obj or .gltf. Again, I have no idea what that means, but if you’re going to grab 3-D objects then use those ones as well.

That’s it for this week. Yeah, like I said, highly recommend. Go check out Ada.is and read about what Ada is talking about. Go use Aframe.io  and just trial something. It’s pretty cool. People will be pretty impressed, and if you want to have a look at the little gallery that I built you can go to vr.Simplethin.gs/gallery.html.  I’ll put links up in the show notes, and you can check that out. See where I work. That would be kind of cool, but that’s it for this week.

Next week I think … Is it next week? We’ve got a guest coming up which is super cool and very awesome. If it’s not next week it is the week after. Definitely the week after we have Una Kravets which is going to be super cool. She runs a podcast called Web Tools with another guest, and I’ve promised her that if she does a song at the beginning of theirs about what she’s going to talk about, so I’ve said that I will sing a song for Una when she comes on which will be an interesting way of going about it. I’m looking forward to that.

Yeah, until then let’s go for a streak of three, and I will see you next week. Until then stay responsive.

Cheers. Bye now.

RWD Podcast 57
23:02
2017-12-22 20:56:41 UTC 23:02
RWD Podcast 57

RWD Podcast 56
33:51
2017-12-22 20:56:41 UTC 33:51
RWD Podcast 56

Show Notes 

ESPN Senior Front End Developer

An awesome opportunity to join a wonderful team and push the boundaries of what is considered story telling on the web. Apply Now.

@supports will change your life

View article

Charlotte Jackson shows just why @supports can be so valuable for the sites that we build.

RWD Survey

Take it now. It’ll take 60 seconds TOPS.

RWD Podcast 55
18:10
2017-12-22 20:56:41 UTC 18:10
RWD Podcast 55

RWD Podcast #54
25:41
2017-12-22 20:56:41 UTC 25:41
RWD Podcast #54

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


RWD Podcast #53
16:20
2017-12-22 20:56:41 UTC 16:20
RWD Podcast #53

Show Notes

Browsersync

I can not believe this is something I haven’t shared with you all, yet here we are. It’s unusual for a tool to make it to the headline but this is such an important tool in the web workflow that it needed to be prominent…. and y’know it’s totally free and awesome.

BrowserSync essentially allows you to test your local dev copy of your site (or live site) across a network of devices, and what you do on one device is immediately visible on the others. Your scroll, click, refresh and form actions are mirrored between browsers while you test. AH-MAZE-ING

New <video> Policies for iOS

When we wanted to share videos on the web we would convert them to animated gifs, and now that animated gif’s are a big thing on the web we are taking those gifs and converting them to videos in process of becoming more performant (a mp4 video of a gif of a video is smaller than the gif). Now safari
are allowing for <video>
elements to auto play IF there is no audio track or if the track is muted. Check out the list of policies Webkit are including to ensure this isn’t abused or annoying for the user.

Offline Google Analytics Made Easy

If you’re jumping onto the Progressive Web App (PWA) bandwagon, and well you should, then you probably want to track analytics when your users are offline as well as online. Now with this library shared by Google you can stored the users actions in IndexDB and send them once the users is online
again. Is there anything Service Workers can’t do???? (rhetorical… I know there’s things they can’t do).

RWD Podcast #52
23:02
2017-12-22 20:56:41 UTC 23:02
RWD Podcast #52

Sponsor

  • URL: http://mobxcon.com
  • Conference day: September 9, 2016. A Friday.
  • Location: Berlin, Kino International (the same old cinema we were in in 2015)
  • Speakers: Kim Goodwin, Andy Budd, C Todd Lombardo, James Archer and several more.
  • Topics at MOBX 2016: Real world RWD projects, conversational interface, chatbots, IoT and the vision of Zero UI. Design Leadership, Designing with Scenarios and more…
  • Promotion code for your listeners, followers, readers: rwdpodcast  (that’s a 60 euro discount per ticket)

Did everyone see that? USE PROMOTION CODE ‘rwdpodcast‘ for a €60 discount per ticket.


Show Notes

Hey everyone and welcome to another edition of RWD Weekly.

In the show this week I discuss both Beacons and HTTPS along with

  • When you might use them
  • How you can implement them
  • What you and your customers get out of it

Physical Web & Beacons

This week I found out that you can enter the physical web world without the use of one of the beacons.
– First beacon from the TheWeb.is
– Used it to locate my keys.
– Idea is that it just broadcasts a URL. Great for discoverability.

from the article:

Not convinced this is the future? Well think about this: what if you were giving a presentation, and could bring along a beacon that sent out a link to download the slides for your presentation? Or what if you owned a sandwich shop and wanted customers to easily access a link to the mobile app for online ordering you spent so much time building? Or wanted to push an updated agenda link to conference attendees as they walked in the door? The possibilities are endless.

There always seems to be a catch. Luckily this one isn’t too bad: just note that you can only send secure web pages (HTTPS), and the URL is limited to 17 characters because of Bluetooth packet size limitations.

If your URLs are too long then use a URL shortening service.

Everyone in the audience to turn their Bluetooth and Location on and for iOS users to add Chrome to their notification center (I’ll explain why they have to do this later), then I ask to raise hand if they got the URL on their phones.

– android users automatically get notifications when a Physical Web is within range

– iOS users first need to add Chrome to the Today section in their Notification Center. There is a great step-by-step tutorial for that on the Physical Web website.

HTTPS

The other great story this week is that the web has now doubled in the number of HTTPS websites being served in the past year.

This is amazing and I think it’s down to a couple of reasons.

  1. it’s a lot cheaper to go https now.
    1. Lets Encrypt provide free SSL certificates
      – with that a lot of other providers have driven their prices down
      (there was never a reason to set the price so high, it was just something we did).
  2. Large services are serving them by default
    1. GitHub Pages
    2. WordPress
  3. Services such as Cloudflare make it super simple and free.
  4. Carrots — Not the ones that rabbits and reindeer eat, but ones that compliment the stick.
    If you want to take advantage of things like Geo Location, the speed of HTTP2, the amazing-ness of Service Workers and progressive web apps… even serving your sites on physical web beacons… then they need to be on HTTPS…

RWD Podcast #51
22:27
2017-12-22 20:56:41 UTC 22:27
RWD Podcast #51

I talk about using a combination of your own CMS, RSS feed and something like IFTTT to post it for you. I use IFTTT for posting articles to Surf the Dream, saving images from Facebook, posting news articles to Facebook… although now I’m trialling Zapier.

Speaking of WordPress, I also delve into some issues that I recently came across with a clients site.

  • changing URLs – why that can be bad
  • Links don’t work
  • no natively support 301 redirects
  • Page templates failing

RWD Podcast #50
15:49
2017-12-22 20:56:41 UTC 15:49
RWD Podcast #50

RWD Podcast #48
33:53
2017-12-22 20:56:41 UTC 33:53
RWD Podcast #48

This week we take a quick preview of the up coming RWD Summit and offer up a discount code for 20% off (but you have to listen to get it, of course). While on the conference band wagon we also talk about the CSS Dev Conference opening up for proposals… get your talk in now.

Google release their new RWD resizrvery similar to another tool we’ve seen.

Finally we talk about content modelling (with Jekyll) and how it makes it a lot easier to roll out things like Apple News feeds or AMP pages if you decide you want to push your content out there as well. Speaking of AMP pages, I also talk through how you set up an AMP page properly and the bits you need to include (but are not told about).

RWD Podcast Episode #47
68:52
2017-12-22 20:56:41 UTC 68:52
RWD Podcast Episode 46
30:26
2017-12-22 20:56:41 UTC 30:26
RWD Podcast Episode 46

RWD Podcast Episode 45
26:42
2017-12-22 20:56:41 UTC 26:42
RWD Podcast Episode 45

RWD Podcast Episode 44
35:36
2017-12-22 20:56:41 UTC 35:36
RWD Podcast Episode 44

Hey, everyone, and welcome to Responsive Design Weekly Podcast, episode number 44. My name is Justin Avery. I am your host and the curator of the Responsive Design Weekly Newsletter, a weekly newsletter all about responsive design. A whole lot of cool stuff has been happening since the last time I ran one of these. This is episode 44. The last 2 episodes were all about the presentation that I gave over in Germany, in Berlin, and since then, there&rsquo;s just been so much happening, tons, and I just wanted to share a couple of those things with you as well.

This week, we don&rsquo;t have a sponsor, but what I will shout out is that we&rsquo;re finally getting the Responsive Design notebooks printed up, so just in time for Christmas. Although, it was supposed to be at the beginning of this year. I&rsquo;m doing a set of 3 notebooks that you can get a hold of, so the 3 notebooks will be covering the 3 tenants of responsible design or responsive design, so we&rsquo;ll have our fluid grids, our flexible media, and our media queries as well.

Each of them have 36 pages inside and a little quote in the back from some of the leading thought people, our thought leaders, so there&rsquo;s a little bit in there from Brad, a little bit in there from Ethan, and also a little bit from the man who I think started this on this path a long time ago which is Mr. John Allsopp with his “Dao of Web Design.&rdquo; Yeah, so that&rsquo;s coming up. If you go to backpocket.co, backpocket.C-O, you can put your email address in there and be one of the first to find out when they come available. There&rsquo;ll be a limited edition of 200 available in the sets, [00:02:00] so be quick, be very quick, and grab it. Yeah, more about that in the weeks to come.

Recently, I was lucky enough. I head over to the States for the Adobe Max Conference. It was a 3-day conference. I was there for a couple days either side. It was just amazing. It was really cool. They put on a huge massive big event. The party that they had there, it had donuts. They had a doughnut wall, which I&rsquo;ll put a picture up in the show notes. It was crazy. They had some really great keynote speakers, and some of the things that they were sharing about where they&rsquo;re heading with the products was great. They had some really good product demonstrations.

I think they&rsquo;re doing &hellip; Adobe are actually doing a pretty good. Given where they were for a little while, they&rsquo;re doing a really good job in listening to what you and I as web designers and web developers, what we need and what we&rsquo;re missing in our day-to-day workflow like the web is continually changing, so is the way that we&rsquo;re building, and we need our tools to change along with us as well, and it&rsquo;s just becoming &hellip; I think their focus has been a lot more around collaboration, but they&rsquo;ve also had some pretty cool stuff improved as well, and there&rsquo;s a new product coming out, which is a project called “Comet,&rdquo; which I might talk about in a little bit as well.

Yeah, like all great conferences have &hellip; It&rsquo;s not so much about everything that you see and you&rsquo;re presented, but it&rsquo;s about the people as well. This one, the Adobe Conference was no change from that, so there were some amazing people there. I got to actually meet the people from Comet and who are working on it. I might as well talk about it now. [00:04:00] Comet is a new kind of prototyping tool that Adobe are coming out with. It gives you the ability to mock up designs quite quickly and allows you to reuse patterns, so if you have a particular pattern.

Just think we&rsquo;re doing a &hellip; we&rsquo;re building Pinterest, for example, and we want to mock up how that might look, so you might have card view or you might have a multi-card view. You can build out 1 card, and then option-click and create a second card, but then you can turn that into like a module. As you click and drag the &hellip; if you were to make it larger, so wider or taller, instead of it stretching the width of the card itself, what it would do is it will turn into like a repeater, so it will repeat it to the right, and it will repeat it low down as well.

The other cool thing is that we usually design these things with Lorem Ipsum. You can put dummy data in there, so if you type a name into a name field and then something into a description field, it can randomize stuff, so it knows that you&rsquo;re putting in name, so it will put in random names. If you have a first name and second name, it will put in random first names and second names, so you can get the feel of like, “Is it going to go over 2 lines? How is the design going to look if someone&rsquo;s name is really, really long?&rdquo; They even extend it further past that where you can drag &hellip; you can have a whole bunch of images sitting in your library, and it will automatically pull those images into the little pins as well, so you can see how real images will look.

The great thing though about that is when you extend it further and you can go &hellip; so if we were redesigning Pinterest in this example, we could go to pinterest.com, and we could have a look at a board, and I could &hellip; from Comet, I could like &hellip; I can&rsquo;t remember what the command was, but just say it&rsquo;s like a right-click on the title, and then you go over, so you&rsquo;ve got a page in your design [00:06:00] full of these cards. Right-click on one of the titles, go to pinterest.com, and select the title of a range of cards in a view as well, and it&rsquo;s smart enough to look through all the HTML, find out what elements that title is, and then pull back all of the content, and populate your design with the content on the website. If you were redesigning a website, you can redesign it with real data as well, which I thought was super cool, but that&rsquo;s just like one of the small things.

There&rsquo;s another guy who I hang out with quite a bit too, Jay [Messing 00:06:38]. He&rsquo;s over based in Germany. He&rsquo;s the guy who came up with the Open Device Lab or one of the guys that came up with the Open Device Lab. The whole concept of the Open Device Lab, we want to test on as many devices as possible, right? We build these websites, they&rsquo;re responsive. We need them to work. We build them, so that they work across a variety of devices, but then most of us, a lot of us will just test inside of Chrome or Safari, and open up DevTools, and move things back and forth, but you really need to get on to devices to check out how they actually feel and how they interact with the site. It doesn&rsquo;t make sense. Is it comfortable?

Now, buying devices is really, really expensive. Really expensive, so this Open Device Lab allows you to go and look at a world map. You go to opendevicelab.com, and you get to see a world map, and you can see where there are device labs near where you live. You can go to that device lab, and you can book some time, and go in, and test your websites on someone else&rsquo;s devices. It&rsquo;s an open device lab. You don&rsquo;t have to pay for any of these.

Equally, if you&rsquo;re a company who is fortunate enough to be able to afford all these devices and you want to share that with the community, you&rsquo;re not using them all the time, then you can register yourself on [00:08:00] Open Device Lab. Register the devices that you have, and then other people can come, and book time with you, and sit down, and test their websites using your devices, so a really, really cool idea.

Who else was there? I caught up with Brad Frost. He was there, and he introduced me to one of his friends , Dan Rose. Dan Rose is &hellip; he was a really cool guy. We hung out a bit. We went to the Kings&rsquo; hockey game. I&rsquo;m from Australia, so I don&rsquo;t actually think what ice hockey is like and about, and so I went in a t-shirt, and it was really cold. I didn&rsquo;t think that perhaps the stadium needs to be chilly to keep the ice from melting, so I froze for most of the game, but he&rsquo;s really cool, Dan.

He runs a website called “Photoshop Etiquette,&rdquo; so photoshopetiquette.com, and you should all go and check that out. If you are a designer and you work in Photoshop, go and check this site out. It tells you how not to be a pain in the butt when you hand your designs to a developer. It gives you tips on how you should be adding layers, how you should set things up, how you might be able to set your workspaces up or your outboards. If you&rsquo;re a developer, go and check it out. See how the designers will and can lay their Photoshop files out to make your lives a lot easier as well. Yeah, definitely go check it out.

He&rsquo;s done a lot of really cool work around Photoshop and workflows, wrote a book for Adobe called “Responsive Design with Photoshop.&rdquo; He does not advise you to design responsively inside Photoshop. You can&rsquo;t design for every single device and every single break-point unless you&rsquo;ve got a hell of a lot of time, but the book goes through and explains when [00:10:00] &hellip; what you should be doing in Photoshop, and where you should be jumping at, and trying to get in the browser, and get into the code as quickly as possible, so a lot of experience around that sort of area as well.

Now, I&rsquo;m going to try and get Dan &hellip; or Dan, he&rsquo;s going to come on the podcast in the next few weeks, and we&rsquo;re going to talk about that. We&rsquo;re going to talk about a responsive workflow, and he&rsquo;s going to talk through Photoshop and share his experiences of how he designs and how he works with developers and other designers who have more &hellip; so other designers that might have a lot of dev skills like a lot of HTML and CSS skills, and also, how he works with people that have limited dev skills who have never used HTML and how he works with them in different ways as well. He is primarily a Photoshop guy. A designer, but he does have his like responsive badge coding up site, so it should be a really good episode. I&rsquo;m really looking forward to that as well.

There&rsquo;s another guy there called “David Blatner&rdquo; as well, and he&rsquo;s more of an Illustrator and InDesign guy. He runs a couple of different conferences, and I think even like InDesign magazine or something. I&rsquo;m not a designer. I&rsquo;ve never heard of that magazine before, but he was really a nice guy, and we were talking about &hellip; because he was into InDesign and stuff like books can be written through InDesign, all these design and laid out type set, and we&rsquo;re talking about bringing books into the browser to make the content universally available across the world or universally.

It really struck a chord with me like this conversation because I&rsquo;ve been working on a side project of taking a PDF version of an old book, a science-y book, a universe-based book, and I&rsquo;m trying to put it across to HTML and CSS to make it more accessible [00:12:00] for everyone to be able to access it. It&rsquo;s an unsolicited side project, but I&rsquo;ve really enjoyed working on it. I want to make it offline and available for everyone.

I started doing a bit more research around it and seeing some other books as well, and there&rsquo;s a whole bunch of really great examples where authors publish books. They&rsquo;re for sale. You can download the PDF. You can download the EPUB version, but &hellip; and they might still be in print as well, so you can get a hard copy, but they also provide all of the content online for free. If you want to find out about it, then you can go and learn about it, but if you want to buy and you want to contribute to them, then you can buy it.

This one is learnpythonthehardway.org. Aaron Gustafson is &hellip; just released a second or is in the process of releasing a second edition of the “Adaptive Web Design&rdquo; book, but if you go to adaptivewebdesign.info, you can either pre-order the second edition, or you can read the entire first edition on the web as well. Brad Frost is writing a book, “Atomic Design in the Open.&rdquo; As he writes each chapter, it gets added to his site. That&rsquo;s at atomicdesign.bradfrost.com. Mark Boulton as well, he wrote &hellip; Jeez, I can&rsquo;t remember the name of his book. “The 5 Simple Steps: Web Design.&rdquo; I&rsquo;ll put it on the show notes, but that is another one (ed: it was actually Designing for the Web).

Lara Hogan with “Designing for Performance&rdquo; so designingforperformance.com. Again, there&rsquo;s a button there to buy it, but otherwise, you can read the whole thing online as well. Also, there was one I was speaking to, a former podcast guest, Stephen Hay. He really gets into this sort of stuff in terms of manipulating Markdown. [00:14:00] He uses a tool called “Dexy&rdquo; to work with his content, and he mentioned one called “practicaltypography.com.&rdquo; That&rsquo;s something that I&rsquo;m looking at, at the moment, so this concept of writing content in one place like in a Markdown sort of way.

I should point out that people are &hellip; that like Aaron, Brad, Lara Hogan, they all used Jekyll, I suppose. Like a static site generator, they created their content in Markdown, and then they ran it through a static site generator, which punched out a website at the end of it, which they then went through and hand-coded all the stuff that they want to, but the whole idea of like writing once and publishing everywhere is like the idea that we have with responsive design as well. We have to have it in 1 centralized location.

Anyway, this “Practical Typography&rdquo; book is just that. It&rsquo;s written, and then it&rsquo;s using a thing called “Pollen&rdquo; which is able to push it to EPUB. It&rsquo;s able to push it to PDF. It&rsquo;s able to push it to .MOBI. It&rsquo;s able to create a book as well. I&rsquo;m going to look into that, and try and get something, which we&rsquo;ll be at a &hellip; republish this, this thing. I&rsquo;m only really concerned about doing the HTML version because the other versions have already been created and are being sold. Yeah, it&rsquo;s really, really interesting, and that&rsquo;s the side project that I&rsquo;ll be working on over the next couple of months anyway, so that&rsquo;s excellent.

One of the things I&rsquo;m trying to do is mostly make these, the books, available offline. When I was going to fly over, I wanted to do some work on this side project, and it involves a little bit of jQuery because I&rsquo;m a little bit terrible with JavaScript. I can get by with jQuery, but I often have to refer to the documentation, and that&rsquo;s hard to do at 30,000 feet.

Now, [00:16:00] I haven&rsquo;t used &hellip; I didn&rsquo;t have Dash installed, which is apparently the go-to tool and what I should have, but I went to a site called “devdocs.io,&rdquo; and that allowed you to save different development documents offline, so when you went back to that URL, all of those docs would be available to you to check out like I had problems with my jQuery I couldn&rsquo;t work out, and so I went back to devdocs.io on the browser in the plane at 40,000 feet, 50 &hellip; whatever. However high you fly. I typed in the URL, and then bam, I had all the information that I needed.

I really love that idea of not just every device, we&rsquo;re creating content for every device in every scenario, but also, every data connection. If you&rsquo;re not connected to the network, is your content going to be available anyway? That is something that I think is the next thing that we&rsquo;re all working towards. The other thing that I&rsquo;m working towards is like making things more performant. Recently, the last couple weeks anyway, they had the release of AMP, so the Accelerated Mobile Pages. This is the new thing that Google kicked out there, and the whole idea is that it makes things faster.

When love when things are fast and when things load fast, but I had a carpool of problems in understanding what they&rsquo;re actually trying to do. For one, the A-M-P Project or the AMP Project requires you to create a new template layout for your site. It forces you, and I do mean force, so you to include this. You have to include the AMP JavaScript in the header of the document. If the AMP JavaScript doesn&rsquo;t load, then your page doesn&rsquo;t load. For me, that&rsquo;s against the [00:18:00] natural way that we try and get people to build things like, “You should build them progressively, you should make your content available, and then you should lay things upon it.&rdquo; To come up with a solution to a faster &hellip; to making faster websites and then forcing this JavaScript in there, it goes against the grind a little bit.

The other thing that it requires you to do is you need to use only a subset of HTML elements, and a lot of those elements then get renamed. For instance, if you want to include an image within your AMP document, then you need to not use the image tag. You need to use “AMP-image&rdquo; as the tag instead, and then there&rsquo;s a bunch of HTML tags that you are not allowed to use. I can&rsquo;t recall all of them. I&rsquo;m going to say things like you can&rsquo;t include things like iFrames. Basically, they&rsquo;re trying to make it as performant as possible, so they&rsquo;re stripping out things that might counteract to that performance.

Now, for me, it &hellip; this approach is like going back to an MDOT site. All right? In the past, we used to have desktop sites and mobile sites, and the mobile would have an entirely different structure around it. It would have different content in it, and it would only be available for mobile phones. This feels like the same thing. It feels like I need to create a new document to house new content within that just to take advantage of this AMP process.

Now, you can use &hellip; you can do it though like the focus I think shouldn&rsquo;t be about, “Let&rsquo;s get on to AMP, and let&rsquo;s start booting our pages there, and then that will solve our performance problems. Then, we can make our other site really, really big and have loads of images, [00:20:00] and it doesn&rsquo;t matter.&rdquo; That&rsquo;s not the approach like I would focus upon making your site as bleeding fast like bleedingly quick as possible. Once you&rsquo;ve done that, then you can look at your AMP stuff because effectively, AMP is just a way of making the web faster, so if you just made your website faster, you wouldn&rsquo;t actually need to use it.

Now, the good thing is it&rsquo;s not that difficult to set up, so &hellip; and complain a little bit about it, but effectively, if you already run an RSS feed, this is essentially what you&rsquo;re doing. All right? RSS takes the content of your page, and then repurposes it within an XML structure effectively, and then you can customize what you want in there. AMP does the same thing, so I created a new template. I created a new layout for the content area. The CMS that I use has like a template as a wrapper, which would be the header, a HTML head, body tag, and then closing body tag, and closing HTML, and then a layout wrapper, which then just lays out how the page structure would normally look.

For me, it took me an hour to set up. I didn&rsquo;t include any styles within it because I didn&rsquo;t want to copy and paste styles, and spend time. It was just to get it going, and I didn&rsquo;t mock around with the images at all. I included 1 image at the top of the page, which was like the article feature image. Imagine that like as a thumbnail kind of image, so I used the AMP image for that, but otherwise, I didn&rsquo;t worry about converting image tags within the body of the content itself into AMP image tags, so I don&rsquo;t know how that&rsquo;s going to break.

Like I said, it&rsquo;s like using RSS. If you&rsquo;ve already got that, it&rsquo;s not too much of a step. [00:22:00] The only other thing you need to do, you need to put a meta tag in the head of your document, so of the original document on your website. You put in a meta tag, and I think you do a “rel,&rdquo; a “rel AMP.&rdquo; I&rsquo;ll put it in the show notes to relate it, and then you give the URL of the AMP version of the page. Then, on the AMP version of the page, you point back to the canonical version of the article as well, so it&rsquo;s cool.

Again, I&rsquo;m not really sure it&rsquo;s the greatest thing in the world, but for an hour&rsquo;s work, at least it&rsquo;s up there. You can check it out. I don&rsquo;t think I&rsquo;ve set it up on the podcast page, but if you do go to one of the articles page, if you go to “Articles&rdquo; in the menu, and then check out one of the articles, then you&rsquo;ll be able to see the link to the page, and then you&rsquo;ll be able to grab the link for the AMP page, and then open that up, and check that out as well. How you register it with Google, I just assume they&rsquo;re going to index my pages, and then find that canonical link, and then go and index the AMP pages, but I&rsquo;m not actually sure. If anyone does now how that might happen, do let me know.

Google, Google do some cool things. This is one of them. I know they&rsquo;re trying to make the web faster. One thing that they did to make the web faster was they removed that 300-millisecond tap. If you had a mobile, a touch device on a webpage, it would delay 300 milliseconds on a touch to ensure that it wasn&rsquo;t going to be like a touch scroll. You put your thumb on the screen, and then you just push it up, and that&rsquo;s a scrolling action. If every time you did that and you were hovering over a link or a button, you don&rsquo;t want to fire that, and then just go to a different page every time you&rsquo;re going to scroll. That would be super frustrating.

The browser vendors put in [00:24:00] this delay to see if you like touched like down and up, and then it would do the link after 300 millisecond. Whereas if you left your finger there and moved it, then it would know it was a scroll event, and then it would scroll the page for you. On any device or any website on a Chrome browser on Android, that has &hellip; or the viewpoint meta tag set to width equals device width, then it removes that 300-millisecond delay when clicking and still avoids the incident of accidentally clicking through to links when you&rsquo;re scrolling as well.

Now, WebKit have just announced that they&rsquo;re doing the same, which means Safari users like us &hellip; yay, or us. I say “us&rdquo; because I&rsquo;m an Apple person. We&rsquo;re going to get that on the iPhones, which is awesome, but one of the problems is it&rsquo;s been released now, so they say, “Yes, we&rsquo;re going to do it now,&rdquo; but the release cycle for Safari is just diabolical. They release it once a year when they release the update to the operating system, so we&rsquo;re not actually going to get it until like September of 2016. Thank you for that, Apple. You guys rock in the most sarcastic way possible. It is super like frustrating to have this sort of things. This sort of thing is like so close, but then not able to actually take proper advantage of them.

Fortunately though, our great friends at the FT, the Financial Times labs, they&rsquo;ve come up with a lovely little script which allows you to bypass the whole 300-millisecond delay, so if you go to GitHub &hellip; GitHub. Is there a website called “GitHub?&rdquo; I wonder. If you go to github.com/ftlabs/fastclick, [00:26:00] it will remove that 300-millisecond, 350-millisecond delay from clicks and make your websites just feel so much more responsive. Definitely, go and check that out. It requires JavaScript to work, but hey, so does AMP, so sometimes. If it doesn&rsquo;t load, then you&rsquo;re just going to get the same use case, the same experiences as not loading it and you&rsquo;re not losing out on anything.

Now, that is designed to make it feel faster, make the web feel faster, and when we say “feel faster,&rdquo; we&rsquo;re always equating this to, “How does a native feel? Like how much faster does a native app feel?&rdquo; It feels native. It&rsquo;s smooth. It&rsquo;s 60 frames per second. I was having a long conversation/argument with a really good friend of mine on the way home from the football the other day. He is brilliant. He helps me with my hosting. He gets my website running super fast. He&rsquo;s been a massive help over the last couple of years, but we&rsquo;re talking about this new app that was coming out and how it didn&rsquo;t have a mobile side. It was native only.

We know that Instagram went this way for a little while, but I&rsquo;m sure even from the get-go, Instagram still allowed you to view pages. You just couldn&rsquo;t do anything, so if I took a picture of something, I could share it with someone. If they didn&rsquo;t have Instagram, they still got the web version, and they could see the image. Now, I want to say if they didn&rsquo;t have that maybe at the very beginning, it was a real pain in the butt because someone would send a link or post a link to their Instagram image, and then you&rsquo;d go there, and it&rsquo;d be like, “Bop bow, you need to install [00:28:00] Instagram,&rdquo; and that&rsquo;s super frustrating like really, really frustrating.

Anyway, so we&rsquo;re having this chat, and we&rsquo;re talking about this new app, and it&rsquo;s only native, and they&rsquo;re not going web because they don&rsquo;t feel as though web provides a good enough experience for people and that the web is dead. Now, not his words. He&rsquo;s recycling the words, but yeah, like the web is dead, and that native apps were the future, and the web will die this death.

Now, I remember seeing a presentation recently where they put up all the wide articles that mentioned that the web was dead all the way from like &rsquo;98, &rsquo;99, 2001, 2003, 2005, 2007, 2009, 2011 like it just keep coming up, “The web is dead. The web is &hellip;&rdquo; this time, definitely dead that native is going to kill it. Whenever I hear it, I just giggle to myself and like, “Yeah. Okay. Fair enough. The web is going to die. Sure. Native is the future.&rdquo;

I can see their point. It&rsquo;s just going &hellip; it&rsquo;s a bad user experience. They want to build their brand on a fast, sleek experience, but I think the experience of clicking and receiving a notification about something, and not being able to access it unless you have a specific phone or a specific operating system, or if you have enough space on your phone to be able to download the app, if you have a good enough connectivity to warrant downloading 50 megs, if you have a good enough connection. Not just like the speed of the connection, but how&rsquo;s your data plan?

I don&rsquo;t know how big this app was, but I&rsquo;m talking about like 50 or 100 meg. That seems a lot to me to be able to just view some content and a few pictures, but you have to download it like you [00:30:00] still have to download it. There are no times ever when you receive something that you have to download the internet. You never have to download the web. All right? Every device comes with a browser. If it doesn&rsquo;t have a browser, it probably doesn&rsquo;t connect to the internet, and you probably want to be able to get your native experience on that device as well.

For me, he was like dangling a massive red flag in front of my eyes that&rsquo;s like waving in front of me just waiting for me to charge, and charge I did. I stuck up for the web, and the way of building things responsively, and also that it doesn&rsquo;t need to be slow. We have things like this FT click thing. Now, I agree, it will be &hellip; things will be sleeker on native because you have &hellip; you&rsquo;re closer. You&rsquo;re like 1 layer of obstruction, closer to the operating system. You can tap into &hellip; just things will work faster that&rsquo;s naturally. It&rsquo;s a natural thing.

In the talk that I did at the MOBX Conference, I don&rsquo;t understand why you would have one over the other, right? I can understand why you would have a website over native apps because it&rsquo;s universal and not everyone is going to download the native app, but I don&rsquo;t understand why you have a native app without a website. There&rsquo;s no reasoning around it. You&rsquo;re just cutting off your nose despite your face by saying, “This has to be special. Only special people can access this particular content. I don&rsquo;t really want to access the universal audience that I have at my fingertips if I had a web version of this.&rdquo;

Anyway, we spoke lots about it. We argued quite a bit, and then we [00:32:00] just bowed and agreed to disagree. It turns out that on further conversations, and when we looked into it a little bit further, and spoke to a few other people we know, it is on this company&rsquo;s roadmap, and they are heading in that direction now, whether it was always that plan or they come to the realization, but it&rsquo;s something which I totally agree. Native apps are great. You do need them for some things to be super fast like I use Slack. It&rsquo;s great. I have it on my tablet and my phone, but I also have it in the browser. All right? It&rsquo;s just a good experience. If I were only able to access it in the browser, I would be absolutely fine with that because it does what I need.

That&rsquo;s my week. That&rsquo;s what&rsquo;s been happening. Yeah, we&rsquo;re going to &hellip; I&rsquo;m putting a couple of these links that I&rsquo;ve talked about so far into the newsletter this week. If you&rsquo;re not subscribed to the newsletter, make sure you head over to responsivedesignweekly.com and drop your email address in there. You&rsquo;ll get a newsletter once a week talking about all this kind of stuff with links that you can go off and check things out yourself.

Next week, we&rsquo;re going to be talking to &hellip; I say “we.&rdquo; I&rsquo;m going to be talking to the team from ZURB. ZURB are the guys that build Foundation. It&rsquo;s like Foundation and Bootstrap have been going head to head for the last couple of years. ZURB are actually about to release Foundation Version 6, and they&rsquo;ve cut their code by 50%.&nbsp;

They&rsquo;ve made things faster. They&rsquo;ve made them smarter.

What we&rsquo;ll be doing is we&rsquo;ll be catching up with some of the developers who have been putting this stuff together and talking about why they changed it, what has changed on the web for them to warrant changing the [00:34:00] framework in this way. Also, if you are running something like Foundation, how people be able to go and do updates properly. Can they just drop it in there, or is there like a few steps that they need to go? Also, where they&rsquo;re looking at next like what they think the next big problem is to squish out.

I also mentioned we&rsquo;re going to be talking to Dan Rose. It&rsquo;s coming up, so that&rsquo;s going to be all about workflow, and working with Photoshop, and the responsive design workflow in teams which will be really cool and really interesting. Then, also, Rachel Andrew who has agreed and said she&rsquo;d be happy to come on the show as well. Rachel is going to be talking about her thoughts and knowledge on the grid layout specification, which is really exciting. It&rsquo;s bed down a little bit now. It doesn&rsquo;t change as much as it was, so she&rsquo;s been able to create some really awesome examples and build up a little bit of a talk around. I think in the moment, she&rsquo;s in the States talking at an event, but &hellip; so it will be really good to get her on and chat through that stuff as well.

Yes, we&rsquo;ve got some really great guests and talking about some really great topics on the way over the next couple of weeks. Yeah. Thank you for tuning in and listening. Please go ahead and rate the show up 5 stars. Leave a comment. That&rsquo;s how people find out about it. Tell your friends. Tell your friends to subscribe. If you have a topic that you want me to cover, or if you would like to join me and talk about some of the things that you&rsquo;ve been doing at work, or some of the things that you&rsquo;ve been working on, or some of your own thoughts and ideas, then do reach out. You can reach me the contact form link in the footer, but until next week, stay responsive, and I will see you then. Cheers, everyone. Bye.

RWD Podcast Episode 43
46:40
2017-12-22 20:56:41 UTC 46:40
RWD Podcast Episode 43

Presentation Slides 

RWD Podcast Episode 42
22:29
2017-12-22 20:56:41 UTC 22:29
RWD Podcast Episode 42

RWD Podcast Episode 41 : Peter-Paul Koch
71:51
2017-12-22 20:56:41 UTC 71:51
RWD Podcast Episode 41 : Peter-Paul Koch

PODCAST SPONSOR

A huge thanks to MobX&nbsp;for their support of this weeks podcast.

MOBX is a Mobile User Experience Conference. It’s running in Berlin this year on the
11th of September, 2015 and you can head over to 2015.MOBXcon.com. It’s all about mobile interactions, designing for small screens, designing for smart devices and dumb phones as well. It’s mainly targeted around user experience and user interface design but anyone would find it useful to attend.

Show Notes&nbsp;

Transcript

Justin Avery: Hey everyone, and welcome to Episode 41 of the Responsive Design Podcast. My name is Justin Avery. I’m your host and the curator of the Responsive Design Weekly Newsletter, a newsletter all about responsive design and things happening in the web. This
week we’re sponsored by Mob X Conference, which is a mobile user experience conference. It is running on the 11th of September this year and it is in Berlin. If you go along to 2015.mobxcon.com, the link will be in the show tonight so you can go and check out the… It’s a really cool conference. They’ve
got all the videos up from the past years so you can see what they were like.

They’ve got some really good speakers this year and also some kind of randoms. I, myself, are a random speaker, but I’m very, very honored to be making my way to Berlin, it’s my first time there. And speaking in front of the audience. The venue looks absolutely amazing. And they’ve got
a really cool line-up. The, I’m fortunate that I’m actually making it on stage before two of my, I’ll say heroes, my web heroes, which is Brad Frost coming on after me. He is an awesome speaker. He’ll be talking all about atomic design and he’s just released a new website called death to bull crap,
but crap is the more swear-y version of it, but I won’t swear on this podcast, cause then I have to write it as a nasty podcast.

Also, Stephen Hay is speaking as well. I’ve seen Stephen speak a couple of times and he’s absolutely magnificent. I’m really looking forward to seeing those two speak, and the other speakers and to catch up with them again. Thank you to Mob X for sponsoring this week’s podcast. Speaking
of Stephen Haye as well, he runs his own conference and he actually does it in conjunction with this week’s guest, so let’s welcome along PPK, welcome.

Peter Paul Koch Hello, thank you.

Justin Avery: How are you doing today?

Peter Paul Koch I’m doing fine, I’m doing fine. I’m just sitting in my office, you know, staring at the screen at your photograph. We’re going to talk about cool web-y stuff, so that’s nice.

Justin Avery: That’s good. I’m glad I got to put a photograph up and we’re not doing the video thing. I like putting up early photographs, it masks the age.

Peter Paul Koch Yeah, yeah. I’m still using a photograph of four or five years ago.

Justin Avery: It’s the stress lines of the web that are starting to imprint themselves as the number of browsers

Peter Paul Koch Yeah, I’ve got the same problem.

Justin Avery: I just said Stephen is going to be speaking and we’re looking forward to seeing him do it again. But, you guys run a conference yourselves, right?

Peter Paul Koch Yes we do, yes we do. We run several conferences in fact. We used to do a conference called Mobil ism, but we stopped this year. But, what’s coming up in November, 13th of November is Design Day, which is all about graphic and inter directional design for the web or
[inaudible 00:03:03] as we call it nowadays. Stephen is actually two speakers there. Last year he did a terrific job, so I’m very glad he’s going to do it again. It’s going to be in Amsterdam, it’s going to be a one day conference on 13th of November. You can find all of the information on, Design Day
is spelled wrong, D-S-G-N-D-A-Y.NL. I hope you’ll put it in the show (notes).

Justin Avery: We’ll put it in the show (notes). Basically, design, short of vowels.

Peter Paul Koch That’s a complicated back story, but I’m not going to read it.

Justin Avery: That’s awesome. There’s a few things happening in Amsterdam at the moment. It seems to be a hub of a lot of web activity. I know booking.com is basing a lot of their user and interaction design out of there as well.

Peter Paul Koch Well it’s an Amsterdam company originally, it was started by a guy from here. In fact I think actually that their very first office was in a street where my great grandfather had his house in Amsterdam.

Justin Avery: Wow.

Peter Paul Koch I’ve never really become totally sure of that place. No, actually it has been an Amsterdam company for ages and they’re trying to get people that around here, yeah sure. There’s plenty of things going on here. You know that’s always the problem when you compare Europe
to the U. S. in terms of start ups and stuff and cool companies. You’re a bit also scattered. There’s lots going on, in London of course, and Berlin, and Amsterdam, and Stockholm, and Paris, and Dusseldorf in Germany and a few other cities. But, you know, in the U. S. It’s much more concentrated in San
Francisco, of course, and the Silicon Valley and, to a lesser extent I believe, in New York. I’m always wondering if that’s not the better model for start ups and stuff like that.

Justin Avery: Put everyone into one place.

Peter Paul Koch Yeah. Because you know then all of the people are together in the same city and they can help each other out and so on. It’s more difficult in Europe I find sometimes.

Justin Avery: Provided, as long as people are helping each other out. I think the industry itself, like I would, ourselves, we’re very quick to share and help people out. I wonder when you take the step up to the people who actually own the companies or the start ups
themselves whether or not they’re a little bit more cards to the chest, do you think? Or, do you think they’re equally open?

Peter Paul Koch To be honest, I don’t know. I’ve never [inaudible 00:05:35] myself. Their business lines and stuff like that, they are, those are of course secrets. In terms of technology, not so much unless of course it’s totally vital and they make major innovation. It’s just web
people. It’s fine, it’s fine, they share, that’s not a problem.

Justin Avery: Even people like Facebook, I haven’t read it, I’ve got it open and I’ll put it in the newsletter this week, but they’re sharing all of the information about how to cache better with&nbsp; the HP and how to just improve your caching rate.

Peter Paul Koch Well, exactly. So, we’ll do it and that’s what makes the web so interesting.

Justin Avery: Indeed, indeed. Speaking of the web, how did you get involved with the web?

Peter Paul Koch It was a long time ago. I became aware, not of the web, but of the internet back in 1988. I didn’t really understand it back then. But was, back then I had a room mate who was into computers, which was still special at that time. One day he took me to the faculty of
technology here at the University in Amsterdam because they had a special room there. In that room you could connect to the internet. That was something really, really special in those days. We used to play multi player games over the internet basically. I had to type in something like,
telnet to a certain IP address, I had no clue what an IP address was. Then I came into this wonderful world where there was stuff and it could kill monsters and things like that. That was the internet. Later on, I studied history and especially the later Roman Empire, so if you have any questions on
that I’ll be happy to take them.

I couldn’t find a job as a history teacher. Then at a certain point, it was in 1997, then I could go on a course that would make me an internet advisor. I still don’t know what that is, but it seemed kind of cool back then.

Justin Avery: It’s a good one for the business card, surely.

Peter Paul Koch Yeah, yeah, oh absolutely, absolutely. Nobody could tell us what an internet advisor was. In any case, I decided to go into front end development because on the 3rd or 4th day of the course, I found out that things look slightly different in different browsers. Then
I thought, hey, what shall I do about that? One thing led to the other and I started doing front end work and I started to study browsers.

Justin Avery: What year was that you were looking at getting into the front end, I suppose if it was I.E. and Netscape…

Peter Paul Koch It was I.E. 3 and Netscape 3, I think. Netscape 4 had just come out, so probably 1997 definitely. Then, in ’98 I got an internship and in ’99 I started to work at a website creation company.

Justin Avery: Did you continue to follow down just the technical side of the CSS and HTML rather than dipping into the design area of things?

Peter Paul Koch Yes, I was a technical guy. I’m not a designer at all. I never, I mean if I want a design, I hire a competent web designer and go out of his way and just let him do the graphic design. No, I’m totally a tech-y.

Justin Avery: Over the years and more recently, probably, definitely within the last 4 or 5 years, I became more and more aware of QuirksMode, which is the website that you run, the QuirksMode.org. How did that start? When did you kick off that? When did you realize that
was something that was really being paid attention to and anything written there was a big talking point?

Peter Paul Koch It appeared gradually, you know. I did my first real serious compatibility table back in 2000, I think. It was about a W3C Dom which back then was pretty new and you had all kinds of browsers that make all kinds of mistakes. I just thought, now I’m going to sit down
and I’m just going to test everything, and I’m going to write down what I find and then put it online. Well, that’s cool. I had a few hundred readers and they would like it. Then gradually that started to snowball and there came more and more links to my sites and I did more and more research and, to
be honest, there was never a strategy or anything. Just me doing stuff and other people liking it. Of course I was one of the earlier ones.

Back in those days it was much easier to get noticed because there were just fewer people around doing this kind of stuff. It was a bit of luck as well. I find that I still have something interesting to say, so I will continue. I don’t know until when, but for the moment I will definitely
continue.

Justin Avery: That’s good to hear. As your readership grew, did you start second guessing yourself? Were you worried about what you were going to put up there, or anything like that? The reason I ask is that I do get a few listeners and readers of the newsletter that
are always a bit down on themselves to say, well I don’t want to write that because what if I’m wrong? Or, I don’t want to write that because someone else has already said it.

Peter Paul Koch Yeah, I’m always terrified of being wrong. I mean, when you do technical research especially in topics I haven’t really been researched yet, then there’s a good chance that you are going to be wrong. Fortunately, I’ve so far, I’ve only been wrong in fairly small things,
more like details from the big overview. I’m, I mean, if you think you could be wrong, that means that you are doing your work right. I mean it’s actually the person who thinks that he’s absolutely right that is the real danger. I mean it’s more like, if you think you could be wrong, you have a healthy
sense of perspective and you do your utmost to make sure that your research is correct.

That makes it more reliable. Actually I think that it’s a good thing that I’m afraid of being wrong. The second thing you asked, I forget.

Justin Avery: No, it was just about, if someone’s already covered the same topic.

Peter Paul Koch Oh yeah, yeah, yeah, that’s something else. Back in the day I was always fairly certain that nobody had because I followed all the web-y blogs and stuff, but nowadays it’s impossible to know. I mean, it could be that I present a conclusion and then I find out that some
library author has found out the same 3 years ago and has already written a library and basically solved the problem already, that happens, yes it does. But you know that’s too something that is inevitable. You just have to try. At least I want to try and I advise all people who hear this to also try
because if you don’t try anything, you will never get anywhere.

Justin Avery: That’s very, very good advice. I also like the fact that if I were to have written something, let’s just say if you wrote something cause the chances are you’d write it before me, but if you were to write something and I was to write something on the same
topic, we’re going to have different opinions, I will focus on something slightly different. I’ll probably have a different idea or a different take on a problem and therefore the people reading it will then have 2 different points of view from which they can draw their own conclusions.

I never think it’s really, people aren’t really doubling up on stuff. They’re just providing a different view. This also would never happen, but if I write something and you re-wrote it, the chances are your explanation is going to be a bit better.

Peter Paul Koch Yeah, that’s how we practice. I’ve been expecting things a lot of things in the past. What is it, 15 years or so. But, I mean, what you say is correct except that when it comes to purely technical matters does x support feature y, it’s not so much of an opinion, it’s
more of a fact. If you just repeat somebody else’s research, I do that, by the way. From time to time I find some research and I think, okay this is kind of cool. But they didn’t think of this and I disagree with this slant the research is taking, so I do my own anyway. Besides, that’s what I’m used
to. I mean, by now I don’t, I trust very few people when they say that browser x does this or that. I always want to see for myself. But that’s just me because I’ve been used to browsers for such a long time.

Justin Avery: That’s fair enough, that’s fair enough. You’ve, you also aside from writing on QuirkMode, you write, you’ve contributed to a few books and then also written one. The most recent would be, was it the “Mobile Web Handbook“?

Peter Paul Koch It was the “Mobile Web Handbook” by Smashing Magazine Publishing. Yeah, I like that because it basically, it closed off a chapter for me. I started with the mobile web in early 2009 when somebody at Photo Foam invited me to come to Dusseldorf in Germany because they
were working with mobile browsers. And hey, what do you know, they found there are differences between browsers. They thought, okay, we will have a specialist. I went there and they had 2 cupboards full of mobile phones. They said to me, okay you can test them all as far as we’re concerned. I didn’t
actually do that. But, it gave me a leg up in the whole mobile web business.

Especially since, I think it was about a year in advance of the rest of the air web developments. I have no clue how I got on this tangent.

Justin Avery: We were talking about the mobile web book. You’re saying it closed a chapter in your life.

Peter Paul Koch Absolutely. Basically I started studying and pretty soon I found out that there were 2 areas where the mobile web is really different from the desk top web. One is the events on the mobile web, touch events and certain events like mouse over a mouse don’t work because
we don’t have a mouse on the touch screen. The other topic was the view boards. Basically a mobile screen is much smaller than a desk top screen and nowadays, of course, we have [inaudible 00:16:21] to take care of that. Back in the day when this all started there were no mobile [inaudible 00:16:27]
sites yet. But still, mobile browsers had to do something with desk top websites and make them somehow readable on a tiny mobile device.

Those were the two main areas I focused on almost from the beginning. The mobile web handbook gave me an opportunity to, not quite close off those chapters, but to write down my conclusions. To say, okay, I think it’s like this and like that. These are the technical details you need to
know, and these are more like the philosophical questions you have to ask yourself. Such as, do we really need separate events for touch and for mouse, or can we, as Microsoft is doing, say okay we should merge those into pointer events. Quite apart from technical details, this is also a big philosophical
question that we have to ask ourselves.

The Mobile Web Handbook allowed me to wrap up all the stuff and basically draw conclusions. I liked writing that book a lot although, of course, it was hard work. Writing a book is very hard work. Especially if somebody is listening now and is thinking of writing a book or maybe has tried
to write a book, the first chapter you produce will always be crap. I mean, you’re just trying out okay, so which voice am I going to use? What kind of technical detail am I going to give? And how to build up the whole book, and there’s this chapter and you will make mistakes. Especially in the early
parts. I mean, I wrote the chapter on view boards first for the Mobile Web Handbook,&nbsp; basically because I promised somebody else to do the research and also because it was the most complicated subject. I wrote that and I put it away. I continued with the rest of the book.

At the end, when I had written all of the chapters, I went back to the view board chapters and I thought, oh my God, did I write this? This is awful. I had to completely re-write it from scratch. But, that’s okay. That’s part of an experience of writing a book. In small part, that’s also
part of the experience of writing a blog post because it’s been often, especially in my major blog post, I just start writing and at that point in time my whole concern is to get everything I want to say in to one single text file.

Then I like to leave it for a couple of days, do something completely different, re-read it and completely re-write it. I think that’s pretty normal for writers. I mean I’m not really a writer. I’m written 2 books and a bunch of blog posts, that’s all. But, again, if anyone thinks, oh
should I write this down, it may not be so interesting, and I can’t write anyway, re-write.

Justin Avery: Definitely write it. And also the other thing I always find is that write enough. Don’t just write a sentence. Write a few sentences, a paragraph if you don’t have time, or a couple of paragraphs. Just write enough for the reason you’re writing it, the possible
solution you’ve got or your philosophical idea. When you re-read it, one sentence makes no sense.

Peter Paul Koch True, true, true. Sometimes I make notes. Sometimes I make one sentence notes. Then, a month later I come back and say, what? I have no clue what I’m talking about. Yes, that’s very true.

Justin Avery: No context.

Peter Paul Koch That’s why I always try to write an article. Even though I know that the order of it is wrong and I will probably be some details that I will leave out and some other details that I will have to get in, etc., etc, but try to write a full article and then leave it for
a couple of days or a week. Then, just re-write the entire thing. Don’t think you’re going to edit it. You’re not going to edit it. You’re going to re-write and that’s absolutely[inaudible 00:20:20]

Justin Avery: What was I going to say next? I’ve got a couple of questions on it. Looking at this whole, cause you wrote about the mobile web, and then there’s also the mobile native area as well. There’s always the argument of native versus website. Today I was sitting
in the kitchen where I work and I could over hear a project manager talking to an account manager, saying it’s only a conference website. People are only going to view it at the conference, so they’ll only be on mobile and we want them to be able to download it, so you should build a native app for it.

I was just swearing under my breath. Just walked out and re-addressed the situation later. But there is a whole native versus web kind of thing. What’s your outlook on that whole argument or debate?

Peter Paul Koch Yeah, this is tricky. I mean I’m currently thinking a lot about the web and how I think it has gone wrong in response to native. We used to have, back 4 or 5 years ago, you used to have a native versus web debate as if, okay we want to build product x, do we go native
or do we go web? Back then it was simplistic and saying, okay native can do this and web can do that. I mean it’s all true, it’s not as if it’s wrong or anything. But I think, I think it’s misleading the issue in some kind of sense. Unfortunately because I’m not yet done thinking, I can’t exactly put
my finger on what’ wrong here.

But the interesting thing you saw is that you have this native versus web discussion and it died out. Nobody was interested anymore. In the last, I don’t know, 3 or 4 months or so, you see a resurgence of that question. Everybody is talking about it and what we should consider as web developers
is that native is just something different from the web. I don’t just mean technically different, but maybe, maybe even philosophically different. I mean what we have in here, it’s not a simple question of should we use a native or should we use a website? It’s more, it’s very hard to explain.

Because I don’t know what I’m talking about myself. It’s, I think it’s the wrong question. And not because native and web are one, because they’re not, they’re different. But, because we shouldn’t ask ourselves that question. I’m hoping that in the not too distant future, we can once we
conceive a project, we immediately understand whether to go to a native app or to a website. The thing that’s fueling native versus web right now is the web’s attempt to emulate native, as far as I’m concerned. What I think I’ve seen is, that back in the days when native started, web developers and the
browser makers and everybody else in the web Eco system said, yeah we can do that too.

I mean I was exactly the same. I said exactly the same. And I said, okay, we as web developers can definitely make a web app, website, or if you want to call it, that’s as good as native. I don’t believe that anymore. I do not believe that in terms of smooth user experience, the web will
ever be able to compete with native. But of course, not every single project needs a smooth user experience. If it’s just a survey, why make a native app just create a website. In the case of your conference thing, I mean, I should definitely say it should be a website because, you know, people will
have to buy tickets, for instance to the conference with their mobile device.

Justin Avery: Yes, absolutely. People are going to want to look at the conference before from work. They’re probably on a lap top. I take a lap top to every conference I attend and I spend time writing on it and I check the schedule. It’s a big no brainer on that side
of things.

Peter Paul Koch I think that the native versus web debate currently is being fueled by the desire of web developers to emulate native and to keep the narrative in being that the web can be as good as native. I don’t believe that anymore.

Justin Avery: Part of the Mobile Web Book, by the way, if anyone hasn’t got it, go to the Smashing Bookshop, or Shop.smashing, go pick up a… I’ve got a physical copy, I love it. It’s very well hard bound. It’s beautifully done. But it’s also an excellent read, so thank
you for writing that. In it you talk a lot about different browsers on different phones as well. I was lucky to see you in Dusseldorf at Mark’s BT Conf, The Beyond Tellerrand, which is a fantastic conference. You spoke about Chromia and Chromium like the different flavors of chrome and why the appear
on different devices. One of the reasons behind it, I think you mentioned in the book, and I’m not sure if you mentioned during the talk, was around the money that you could get for adding your search engine as the default search engine for that browser.

Is that, I’m sure, I just want to make sure I didn’t take it out of context. I think whether the, I was speaking to a friend of mine who works for a company who builds native apps. They build gaming apps. When we discuss different business ideas as you do, just lazing around at the pub
over a beer, this would be a good idea, that would be a good idea. I’m always like, oh we should build it on a website and he always is like, it’s too hard to monetize that way. The discoverabililty and the monetization of native apps is far easier to make money through. It’s interesting whether or not
more effort goes into the native side of things, or you have more of these start ups that are creating things that slide down the native side of things because it is easier to monetize.

Peter Paul Koch It’s easier, but it’s not easy. At least, I must admit that I haven’t studied native monetization for awhile. But back when I did, I found out that, basically, it was not possible for somebody whose apps are downloaded in average time to actually make a living out of
creating native apps. I mean, this is the real thing, do you play games?

Justin Avery: On occasion. More before I became a dad, but a little bit.

Peter Paul Koch I mean, did you ever spend say 30, 40, 50 pounds on a computer game?

Justin Avery: Yes. A long, a very long time ago.

Peter Paul Koch Sure, but you did.

Justin Avery: Yes, absolutely.

Peter Paul Koch That was normal, wasn’t it?

Justin Avery: Yes.[crosstalk 00:28:04]

Peter Paul Koch Okay, did you ever spend so much money on a board game, a physical board game?

Justin Avery: Yeah, probably not as much. Probably half the price, like a Trivial Pursuit would have been half the price.

Peter Paul Koch Yes, something like that. Now, if we start looking at native apps, did you ever spend 20, 30 pounds for a native app?

Justin Avery: Yeah, I, the most expensive, I’ve bought 2 apps which have been quite expensive. One is the Tom Tom app and the other is the Omni Focus app. Both of which I was bitter about spending, I think 19.95, so 20 pounds on. They’re the only ones I’ve ever spent
more than 2 pounds on.

Peter Paul Koch Yeah, exactly. And that is the problem with native monetization as far as I can see. I asked these questions at a conference before in private talks and it was just like, okay, yeah, everybody likes gaming. I’m talking specifically about games because games exist on
a lot of platforms, if you know what I mean. Basically, yeah, 30, 40 pounds for a computer game, yeah I’ve done that and a board game, yeah, I’ve done that. But an I-Pad game, no way. Way too expensive. While, if you think about it, I mean I’m a board gamer myself and I buy quite a few board games, but
I tend to, purely in terms of time, I play more games on the I-pads. That’s, I also hesitate in shelling out even 5 or 6 Euros or whatever.

I mean our whole idea of much something should cost, both on the web and on native, is completely strange. I mean, my current theory, but I have absolutely no data to back this up, but my current theory is back when web started, one of the promises of web was that stuff was going to be
free because somebody would publish something because he liked it. I mean I’ve done that myself, right? With the whole QuirksMode thing. I just published and published and published for free. Everybody got to read it. They would, you know they would get interested in me. I would get some, some work through QuirksMode. I would be invited to conferences, etc, etc.

That kind of paid for itself. But still, the expectation was the website is free. Now on native at the start, let’s just start with the I-phone, things were not quite free, but it was still cheap. I mean back in the day when the I-phone started you could have 99 cents for an app. 1.99,
2.99, that’s a bit steep maybe. For some reason people expect native apps to be cheap. That, in turn, means that it’s going to be almost impossible to make money as an independent native developer. Just creating your own apps, putting them in the app store and making money out of that. A few people have
succeeded. One of the successful like Andrew Berge or something, that’s another story.

Justin Avery: They’re few and far between.

Peter Paul Koch Exactly, exactly. Just the other day I read in the paper that [inaudible 00:31:29] is now going to fire 260 people. Why? Because they couldn’t do it again. Because they didn’t have a second hit. Monetization is definitely easier on native, but I don’t think it’s easy.

Justin Avery: Yeah.

Peter Paul Koch I don’t think anybody has really figured out how to do monetization in an easy way on either native or the web. I mean what’s, even back with desk top applications. Back in the day if you bought Microsoft Office, I don’t know how much it cost, 50, 60?

Justin Avery: It was a lot of money.

Peter Paul Koch And, people thought that was normal. Because, I mean computer, if you buy a Windows or Mac application, you’re willing to spend that much money because it’s normal. A native, it’s not normal and that’s a big problem with monetization.

Justin Avery: It’s interesting. I don’t know how much testing of it you’ve done, or if you’ve been able to do any. I saw an article that someone emailed me today which was around IOS9 and their content blocking coming up. They’re looking at any third party ads or third
party content [crosstalk 00:32:44]

Peter Paul Koch They’re going to do an ad blocker, yeah, that’s really interesting.

Justin Avery: Yeah, have you had a chance to look at that at all cause that could really…

Peter Paul Koch Not from the technical side, but I have been thinking about it, from the monetization side. I mean the whole ad model is broken. It has never really worked on the web. But, now with the ad blockers it’s clear that it’s completely broken, and why would anyone want to
see ads on their websites or in their native apps for that matter? Marketing people will have to come up with something better.

Justin Avery: Better ways, but it’s going to cost, people like I quite like, Net Magazine and a lot of people that use advertising on their sites. Chris Coy for example. CSS Tricks is mainly funded from the advertising that runs on there. I think if you strip that away,
I think he does it in a very good way where it’s not obtrusive. It’s there, you know it’s there, but it doesn’t get in the way of the content itself.

Peter Paul Koch [crosstalk 00:33:49]I’ve never seen Chris’ site. Really weird because I usually tend to read just newspaper sites on my desk top computer. The other day I just quickly took a look on the I-pad because I wanted to read something. Then, I suddenly saw all of those ads.
I had basically forgotten they were there. I mean, once you’re used to an ad free web it’s impossible to go back. I think Apple is making a good move here because it has to happen. Something has to be done. I mean…

Justin Avery: Do you think it’s a bit sneakier then there, they’re clearing the ads out from the web, and they’re also introducing this capability where you can run an ISS feed which you point to their news, news to Apple I think it is, and then they provide an ISS feed
within their news app, which they will then, you can buy advertising to advertise through their news app.

Peter Paul Koch Okay, so they have a clever plan The question is will anybody actually use that?

Justin Avery: Use that, no.

Peter Paul Koch I mean Apple is not very good in advertising. Remember I-ad?

Justin Avery: This is what it’s using, it’s using I-ads through this news feeder.

Peter Paul Koch Okay so they’re desperate to put an I-ad somewhere because they spent, I don’t know millions on developing something that nobody really wanted. I mean, this is a fundamental problem, but I don’t have an easy solution. The only thing I know right now is that (a) the current
solutions don’t work, and (b) from the start of the web and native there has been an expectation that it would be free or cheap. That expectation is extremely hard to change.

Justin Avery: Yeah, I know, that’s a good point. I don’t mind paying for content either. There’s a excellent, oh I can’t even think, Web Platform Daily, is an excellent news letter which gets sent out and if you visit the page on the day, you get all the links. But, if
you go there the day after, then you can look through the history of it, but all the links are missing. You can see the sort of snippet of what was there, but it’s missing. But if you pay 6 pounds or 6 dollars a month I think it is, you have access to this history. I think that approach is fine. I’m
more than happy to pay 6 dollars a month for someone to deliver me all of the things that are happening.

Peter Paul Koch Sure. I mean, I don’t know about the U. K., but here in Holland we’ve had a very successful initiative with a couple of journalists who just came together and said okay, now we’re going to do journalism on the web. Right, we’re going to have a website. We’re going to
do journalism. And, we are going to ask people to subscribe and give us, I don’t know, 6 Euros a year or something. And they announced it a year and a half ago and, within, I don’t know 5, 6, 7 weeks, they had happened to get a million viewers. There was no site, there was nothing except for a plan.
Well, there were a few well known journalists here in Holland. I think that is much more like the future of journalism online than the whole ad based thing, because it’s not going to work. This might actually work.

Justin Avery: Is that sort of a [inaudible 00:37:20] based thing, where it’s going to sit hidden?

Peter Paul Koch To be honest, it’s not quite [inaudible 00:37:25]. You do get access to some things only if you’re a subscriber, but I think you’re allowed, if somebody links to an article on Twitter or Facebook, I think they let the traffic go through, even if you’re not a paying member,
something like that.

Justin Avery: That’s excellent. That’s a really good idea.

Peter Paul Koch Yeah. The point is not so much that they erect a [inaudible 00:37:50] but rather that they say okay, guys, if we don’t do this we won’t have any journalism left in 20 years, at least that was my conclusion. They didn’t actually say that in those words, but that was my
conclusion.

Justin Avery: I think that’s a good idea. If you can, we’ll check on the show tonight if you remember the Url of that, we’ll put that in there for sure. Well, moving a bit away from the philosophical side of things which I quite enjoy anyway. Now that we’ve got responsive
design, you were talking before that sometimes we have, before the responsive design thing we had mobile specific sites and desk top specific sites and stuff. Now that we’ve got this solution, which is a one size fits all, where, what do you think is next? Where do we need to move to next?

Peter Paul Koch An excellent question. I don’t know. I mean when I started with the mobile, I was totally obsessed with mobile for 2 years and then everybody else started to come into mobile. I thought, okay, I should stay ahead of the curve, so what’s going to happen next? What will
basically be the next device category that’s going to enter the web market? And I was asked at a panel in 2011 or 2012, and I, all the panelists agreed it was going to be t v. Meanwhile I don’t believe that anymore. Who wants the web on their t v?

I don’t know. If you want, just want to do some nice web surfing, are you going to use your t v? I don’t think so. Are you going to use your refrigerator? I don’t think so. Your car? I don’t think so. Basically the question is, what is going to go next in terms of devices. Those devices
will bring in technical issues, like the small screen on mobile phones. And, we will have to solve those issues. But, I can’t see any device actually coming right now, to be honest. I have absolutely no clue. Responsive design has basically solved the issue of screen size forever, I think. I think it
will stick around forever.

What we have still is the question I referred to earlier about [inaudible 00:40:02] events, do we need different events for touch and mouse? And maybe, if you have a t v remote, do we need different events again in some kind of connect way you try to read out how to use a wiggling remote
or something like that. In a car we will eventually have to have some kind of voice control. I mean, you do not want the driver to touch the screen while he’s driving.

Justin Avery: Hopefully not.

Peter Paul Koch Those kind of questions are going to be interesting, but there’s not an easy one size fits all solution like responsive design was for all screen sizes. It’s an interesting question, but I haven’t found the answer yet. Cause it all depends on where is the web going to
go next and I simply don’t know.

Justin Avery: If we have, like you mentioned, there’s going to be, and there is, I think, what’s his name, can’t think of his name but I’m sure you remember, Luke, Luke Ribolsky. He often speaks about not only have we increased the number of devices for screen sizes and
view ports, but also the number of inputs that we have for them. From a technical point of view, have we got enough with the web and browsers and the way that they are, we’re not talking native stuff, this is sort of web, to take advantage of all of the things that we need to do to control our websites
and have those interactions?

Peter Paul Koch No, we don’t. But, the new stuff will come in very gradually. I don’t, right now I don’t see one big revelation, such as responsive design was. I more see like, a good example is the whole pressure thing. I think Apple is going to introduce IOS9 or something that you
can detect the pressure…

Justin Avery: Oh, how hard you’re pressing on the screen?

Peter Paul Koch Yeah, something like that. I can’t remember the details, but it only takes, this has been talked about for ages, because even back in 2009 it was clear to me that that was going to be an interesting new input mode. Because I used to have, I used to test an old Blackberry
and there you had, you could swipe across a screen and you had a mouse like thing and you had to actually depress the screen in order to click something. That set me thinking. That taught me at least that pressure was going to be an interesting new feature. But it all depends on hardware.

You have to have hardware that’s going to actually detect the pressure. That leads me to conclude that the new I-phone will probably be able to do that. That’s an interesting thing. Years ago I heard an interesting talk by somebody from the BBC. He was talking about t v and the web. He
basically said, okay, so suppose you were watching a tennis match, they even just click on one of the players and get his vital statistics and things like that.

Again, that’s a big technical issue because you have to actually map the t v screen and figure out, okay if you user clicks there, he really wants to click on a player or maybe even on an ad you can see besides the tennis court and stuff like that. There’s a technical issue to be solved
there, but it sounds interesting and I think it will be more like gradual evolution from now on. Of course, I could be completely wrong and in 2 months we may find out that there is something revolutionary new that is going to happen that’s going to change.

Justin Avery: That’s it. We never know that, don’t need, what is it if someone, if you asked what the public wanted they would have asked for faster horses instead of a car. You never actually know. We weren’t looking for responsive web design. Ethan just dropped it on
our lap. We’re like, oh yeah, this is totally what we needed. Why didn’t we have this before?

Peter Paul Koch Of course it could happen, but, and if I’m forced, yes I would say that it will be more gradual evolution from now on. Responding to, basically, hardware capabilities.

Justin Avery: Now on gradual evolution, you’ve recently written a couple of articles and it caused a bit of a Twitter stir. Some, a lot negative, well 50/50[crosstalk 00:44:46] It was less of a, and do correct me, cause this is a, for those that haven’t read it, let you
explain it but you were sort of calling for instead of continually progressing the browsers and these particular things is just to take a step back for a little bit and just deal with the stuff that we’ve got at our fingertips before we start looking into the future of what else we’re going to make.
That caused a stir and a few people said well no, we should be redeveloping and this is people, Jake Archibald, I think wrote a very good post. And there was a few others anyway. How does that work in with the gradual thing and…

Peter Paul Koch Good question. I hadn’t considered it yet in those terms. I would say that it would work fine together. Basically my argument right now is that web developers have this almost obsession with emulating native. Which means we have to have, we basically have to have a better
UX for our websites. My argument is that we will never succeed, not because web isn’t pushing forward, but because native is also pushing forward. Suppose that now we get in 2 or 3 years time we get a library that will solve all [inaudible 00:46:15] issues once and for all.

By that time native will also have progressed and will have new features that we will have to copy. We’re playing a catch up race that we cannot win. Also, because we’re trying to copy native features, we have a, we have 2 distinct problems. One, that browsers are adding too many features
right now. That’s why I asked basically for a stop for about a year. Just stop, don’t add anything new. You can think about it. You can discuss new interesting features, but don’t implement them yet. Just wait for a little while for what the average web developers to catch up. That’s one issue. The other
issue is that because everything has grown too complicated, and because we want to emulate native, even in our little websites, our little web apps, without us understanding really how to do that and what native is doing different.

We have this insane proliferation of tools. I mean how many libraries are there nowadays? I think we should also call for a stop on new libraries for awhile or something like that. I haven’t posted that yet, and I need to think about it.

Justin Avery: So is this like stopping development of things like J Query, or stopping things like coming up with a library of, what example of?

Peter Paul Koch Basically what everybody is doing right now is re-inventing the wheel in that, okay, they want to write a J Query that’s better or angular life library or react life library whatever, but better. I increasingly think that takes up a lot of energy that could be spent
in a more useful way elsewhere. Also it means that as a beginning web developer you have no clue what to do because you know there are 17 libraries for one specific job. Okay, which one is the best? You don’t know. I don’t know either. I don’t think anybody knows, to be honest. So we basically need less
tools, and we need to get back to actually writing, especially Java script for ourselves, because it will teach you a lot more.

Also, and that’s the fourth part of the equation, because we know have a tool chain, I don’t think it’s a particularly good one and it’s subject to a lot of change, but we have a tool chain. Therefore, back end developers, Java developers I’m thinking about mainly, tend to think of the
web as a new platform that they just have to learn a few tools and then they can write applications for that platform. The problem is, at what [inaudible 00:49:13] what platform? Jeremy Keith calls it a continuum. I tend to say it’s more like an immense amount of platforms.

I mean in a sense you could see every single browser on every single [inaudible 00:49:28] as a new platform, because something might go wrong, right? I mean you may be on an old computer or on a very basic phone that doesn’t support any[inaudible 00:49:37], something like that. I think
that idea of the web as a multitude of platforms is severely underestimated, especially by back end programmers. But on the other hand, the back enders don’t know any better. The front enders are now saying, okay, we’ve got all this nice tools that will solve all of your problems for you. There’s a whole
web of problems centered around us trying to emulate native.

That’s my theory. I am going to write and will wrap up an article that will state all of this. I haven’t, I think, posted this conclusion yet. But, that’s basically what I think. Now to get back to your questions about a gradual, to be honest and I think of this right now, maybe what I’m
saying is we should let the web evolve more gradually, especially at a slightly slower pace, because the pace has been insane for the past 5 years. I guess that’s what I’m saying, yeah. I need to think about that.

Justin Avery: That’s cool. You mentioned that talk about a platform and a continuum, I was, I’ve been considering, I love space, right? I love the universe, I love the whole, just the whole, everything about it. I was very fortunate. My wife got me a ticket to go and
see Professor Bryan Cox, who is one of my idols, speak last night. He was talking, one question was around would they rebuild the large Hadron collider again, all the money that’s gone into it. Was it worth it, just finding this heat explosive&nbsp; and stuff. There were some interesting things. The
amounts of money it costs to build that is, I think it was half the budget of the Manchester University. It was funded by 85 different countries. To be fair, if you wanted to look at, in terms of how much money Cern has&nbsp; made and given back to the world, that’s where the world wide web was invented.

It’s made it’s money pretty, pretty well. I thought it was really interesting. I always think that we always emulate nature. For the very early days and perhaps, in Roman times, here’s a segway question, in Roman times the building of the towers and the columns and stuff, didn’t they base
them upon tree trunks? They slightly tapered around as they went up to make them stronger.

Peter Paul Koch Yeah, that’s true.

Justin Avery: The fact that the web was built out of Cern makes me really believe that the web is like it’s own universe. It’s ever expanding. We have these galaxies.

Peter Paul Koch Based on the large Hadron collider, yeah.

Justin Avery: Based on the large Hadron collider. So [inaudible 00:52:37] came up with it there, very well influenced by the universal thing. That’s what I like to think anyway.

Peter Paul Koch Yeah, I mean, I mean people now all of a sudden it’s fashion again to think that web is doomed. I mean I’ve read a few articles that horrible things are going to happen to the web because big companies get more, more influence, etc, etc, and I tend to poo poo those stories.
I don’t really believe in them. On the other hand it’s something you shouldn’t ignore. I think the web is on a cross road right now. We have to select, we have to basically select our destination right now. I, I am starting to have an idea of what I’d like that destination to be. But now I have to convince
other people. And this is, again, a new thought that I have to think about.

That’s the problem with these kinds of conversations about things you haven’t fully written down yet. You get new ideas all the time and you’re trying to think up ways of integrating that with the whole idea you already had. That’s what I’m doing right now, but it’s interesting.

Justin Avery: Be interesting to see. Well let’s, again we’ll break, we always seem to go back to these philosophical conversations, don’t we?

Peter Paul Koch That’s entirely my fault because it’s most of what I’m doing right now. I haven’t done any actual solid research in months, except for 1 day in July where I got the test results that were so weird and incomprehensible that I just gave up.

Justin Avery: Well if we, speaking of test results and stuff, so these days, I’m hoping that you’ll have an answer to this. These days when we build a site, we’re building it for multiple devices and browsers and different users and different user inputs and things like
that. There are so many that testing becomes very difficult. For people building for a multiple device web and responsive designs, have you got any advice, like technical advice about how to approach testing, test plans, tool kits, things that you would recommend to people looking at?

Peter Paul Koch I just get a lot of devices. That’s the basis of your testing. I mean I, when I do my tests, I test in, I don’t know 20, 25 phones, something like that. If you’re really, really serious about your mobile application, you should do the same. You should especially buy
a lot of Androids. I mean IOS is not so much of a problem. Apple is doing a really great job of, and you know, keeping the whole family together. There are different screen sizes of course, but that’s mostly it. On Android, it’s completely different because most Android devices have a default browser
that’s actually created by the hardware manufacturer.

Samsung has it’s own default browser and ATT does and Sony does. And Lenova does, so they bought Motorola nowadays, etc, etc. They, all of these default browsers are based on Chrome, but all slightly different. They have slightly different features. That is something that you are going
to miss when you test mostly on Nexus devices and think 2 or 3 Androids are enough. They’re not. You have to reserve a serious budget for just buying phones. A high end Samsung, a low end Samsung, ATT, Sony, the Chinese companies are making [inaudible 00:56:15] in the West right now.&nbsp; [inaudible
00:56:18] of course is trying now and [inaudible 00:56:23] which is basically, they tend to think of themselves as the Chinese Apple. They try to emulate Apple all the time with a very small printer, very charismatic guy who goes onstage and talks about how wonderful they are.

They’re actually not bad phones. They are pretty good phones. They all use a slightly different solution to things and, also they want to distinguish themselves from each other. I mean, put yourself in the shoes of Samsung or ATT or whatever. You are using an operating system that everybody
else except for Apple is also using. Why would a consumer care that they buy a Samsung, and not a Sony, or a Chinese one? The answer they came up with was trying to differentiate their phones in matter of hardware, but also in software.

Basically they are making changes to, basically, all the applications, also browsers, to try to convince consumers that they are the better phone. That means that this whole differentiation thing is not going to go away any time soon. Because they still want to do that. I mean Google is
trying exactly the opposite, of course. Google is trying to bring everybody together and make sure that all Android phones perform more or less the same. But on the other hand, if Google just said, okay, and now you’re all going to use Androids in this one specific way, then most of the hardware companies
would start looking for another operating system.

There’s a complicated thing going on between Google on the one hand and all of the Android vendors on the other hand. The practical offshoot for web developers is that browser wise, it is a mess. Also, of course, we have a few browsers that no one has ever heard. For instance, UC, the
UC browser from China, which is making huge inroads to the developing nations, especially India, I believe. If you have anything to do at all with the Indian market, even eventually, you should test the UC browser on Android, and not on one Android phone, but on several Android phones. My most important
advice for serious mobile testing is, get a budget, and get phones.

If you’re targeting a specific market, outside of Europe, get phones from that market. The Chinese phones are different from the European ones. The Japanese are different. The Indian phones are, again, different. I’m not sure what’s going on in Africa, but I wouldn’t be entirely surprised
if they get their own phones in the next few years or so. Because, back there the country is just so different from the developed West. I mean, first of all, consumers have less money, so they can’t afford expensive hardware. Secondly, sometimes, I once read an article about software developing in Ghana.
This was years ago. Basically, there was this guy and he made his fortune by creating a windows application that made sure that windows could react properly to blackouts.

Because, in Africa, you have a blackout every week. All of the electricity is just gone and you can’t continue. And worse, you may lose your work. Basically, he created an application that, I guess it saved the work a way every once in a while and helped people cope with blackouts. That
kind of stuff is also good to have on a mobile. Maybe even more on mobile than on desk top. Because it’s cheaper to start a new mobile company than a new desk top computer company. Besides, you can take Android and make slight changes.

Justin Avery: To develop an operating system.

Peter Paul Koch Yes.

Justin Avery: Actually, talking about, in Africa, I remember seeing a really lovely short, sort of documentary, there was a guy who used to ride to the only computer in the area that had access to the internet. Then he would then ride to each of the different towns around
that area and he would collect questions that people had from a centralized post in the town, like a post board. Then he would come back and do all of the research, write it all down and ride back to all the towns again and pin up all the answers and then collect the next bunch of questions again. So,
sort of share the free ness of the internet with the rest of the people that couldn’t get that access there.

It was lovely. I really loved the story.

Peter Paul Koch No, exactly. I’ve heard the story. I’m not sure if it’s true, about Indian, where very remote villagers would save their money together to buy their mobile phone so that they would be connected to the rest of the world. Problem is, they didn’t have electricity. So there
was a guy whose job it was to bike around the countryside, go from one village to the next, and then basically use his bike to charge their phones. That was his job. When he was done recharging the village mobile phone, he would continue to the next village. I think, and this is also an older story.

&nbsp;&nbsp; I think things are moving very fast in these areas. I mean, I think that in 2 or 3 years time this story will be just ancient history and they will say, no of course we have our own mobile phones. But it shows how very different approaches people have to the whole mobile revolution. Besides
not forget that people in India, people in Africa, people in China, the very first thing they see of the web is on a mobile phone screen. Because they can’t afford a desk top computer, but they can afford a mobile phone.

Justin Avery: So make sure your pages load quickly. Their band width is not great and it costs them a fortune.

Peter Paul Koch [crosstalk 01:02:38] that have to be run once you arrive on the mobile phone and just eat all of the battery life. Years ago there was an interesting research being done. They took an Android phone and they measured how much battery was being used. Then they went to
a Wikipedia page and they were okay, so how much battery juice has been used? Wikipedia, back in that time at least, used J Query, but only for the very simple show and hide thing they have on the mobile Wikipedia site. You know where you can just show and hide parts of the article.

&nbsp;&nbsp; They re-wrote the script, just because you can do that in 5 lines of Java script and they found that that reduced battery drain by about a third.

Justin Avery: Geez.

Peter Paul Koch Just because J Query has to initialize itself and create all of those functions that this specific page does not need. That is one of the problems I have with tools. But, we’ve already talked about tools.

Justin Avery: I think it’s the same problem with things like Bootstrap and Fan Nation and Material Design is that it comes packaged with everything you could possibly need, and a lot of stuff that you don’t.

Peter Paul Koch Yes, and back at our CSA conference in May, in June, John Becket of Godzilla said something very useful. He said, okay module [inaudible 01:04:03] leads to over design. Because if he wants to build something as a module, you also think that it has to be able to function
in basically any kind of situation. That’s why to be honest, I’m starting to question the whole worth of model organization on the web.&nbsp; Because it saves you, as a developer, some time, no doubt about that. But it costs the end user so much in terms of connectivity, in terms of what kind of device
you have to use, in terms of the amount of network data you have to pay for, etc, etc.

Justin Avery: That is interesting then. So is that more around like the, is he referring more to less, like around designing, like an atomic design approach would be designing a modular type fashion. Is he referring more to…

Peter Paul Koch I was specifically talking about java script here.[crosstalk 01:05:01] We have issues with CSS as well, but the issues with java script are just much, much more severe. I’ve, I mean I’ve never used a library in my life. If I want to write, to use a java script, I just
write it. Well not quite from scratch. I mean I’ve got my library of java scripts which I use. But I don’t use a tool for that because I just want the java script to do exactly what I want and only what I need. It’s my theory that we should return to that, because it will solve a lot of problems having
to do with[inaudible 01:05:43] heavy sites basically.

Justin Avery: Getting started though, we’re very short on time so I have 2 kinds of questions after this. But do you think, J Query for people getting started with java script, just to learn, not so much the syntax but how to construct things. Do you think that’s a positive
or a negative, bit of both?

Peter Paul Koch I would say a bit of both. I mean as a beginning java script developer, you need some help. You can’t do it on your own. On the other hand, I mean, a beginning java script developer will have to start with some tools, but to try as soon as possible to write something
without tools. It doesn’t mean they should write everything without tools. But, just to try and not use tools and learn a lot from that. I read that in an article recently. What did I say, okay, reinvent the wheel. Yes it’s good to reinvent the wheel. Not because we get a better wheel, but because it
will teach you so much.

&nbsp;&nbsp; I mean you will learn such a lot from, basically re-writing a part of J Query, you will learn a lot more than from just using J Query, even if your alternative to J Query is not really as good as J Query. That’s not the point. The point is that it will teach you a lot about how browsers
work and about how java script is supposed to be working. I mean, people should still write their own libraries, they just shouldn’t publish them or something. I don’t know what I’m saying. It’s complicated.

Justin Avery: Fair enough. It’s like going through the process is a learning experience, but that sometimes is good enough. Just at being that learning experience. Now, I’ve got one more question before we wrap up and it was from, so each week I ask the guest to ask a
question of next week’s guest. At the end of this question I’ll get you to do the same thing. Last time I had met Matt Griffin on and his question was, “What’s the first moment that you fell in love with the web”?

Peter Paul Koch I think that was when, very in very early days of [inaudible 01:07:58], it wasn’t even called [inaudible 01:08:02] back then. I just got some positive feedback from somebody. It had to do with not using a browser detect, but using feature detects. Nowadays that’s taken
for granted, but back in 1998 it was completely new. I wrote about how we should use feature detects. I got several mails from people who said, hey, you’re right, I’m going to do this from now on. That made me fall in love with the web, not so much because of feature detection, but because they had found
my site and had read it.

&nbsp;&nbsp; I could just publish my thoughts and be read anywhere. That was really a defining moment for me. It’s probably also the reason I’m still continuing QuirksMode even 15 years later.

Justin Avery: That’s awesome. That is lovely. It is nice the first positive feedback you get from something you’ve written from a complete stranger as well. It is nice really.

Peter Paul Koch Of course then you have to get used to the negative feedback.

Justin Avery: I’m sure you have definitely got a lot more thicker skin because of QuirksMode over the last few years.

Peter Paul Koch Absolutely.

Justin Avery: Now have you got our next, have a guest booked in for next week and what would your question to next week’s guest be?

Peter Paul Koch You know, ask him why do you still work on the web?

Justin Avery: Nice. Very good.

Peter Paul Koch And assuming it’s an experienced web person.

Justin Avery: It’s definitely going to be someone that works on the web.

Peter Paul Koch Yeah, why you are doing this, if you know what I mean?

Justin Avery: It is a very good question. PPK, thank you so much for taking time out of your evening, as it is for both of us and jumping on the podcast. So for your site, QuirksMode.org, how do people follow you and find out what you’re doing?

Peter Paul Koch Twitter, PPK, I’m PPK on Twitter.

Justin Avery: Great and the conference coming up…

Peter Paul Koch The conference coming up is Design Day D-S-G-N-D-A-Y.nl.

Justin Avery: That will be in the show notes.

Peter Paul Koch 13th of November, and it will be in the show notes, of course.

Justin Avery: Brilliant. It sounds good. Are you speaking at Design Day?

Peter Paul Koch I’m not, not I’m not a designer. I’m just organizing. Stephen is speaking though.

Justin Avery: Excellent. Have you got any speaking engagements?

Peter Paul Koch Yeah, yeah, yeah, we got a full list on the site and we’ll quickly take a look before I forget anyone. It’s Van Moll, Stephen Haye, Simon Collison, Braun Stein, Susan Robertson, Edat Allen, [inaudible 01:10:34], I must admit I don’t know these ladies and Jerry Cody.

Justin Avery: Edat Allen is awesome. Jerry Code has a magnificent site, which is great. Very, very cool site. That sounds like a really good lineup.

Peter Paul Koch It is, it is.

Justin Avery: I’ll swindle some kind of trip across the pond. I need to come and visit.

Peter Paul Koch From London is essentially zero time. Well, if you go from Amsterdam to London it’s zero time.

Justin Avery: Exactly.

Peter Paul Koch You take off and then they don’t even have time to give you drinks and then you land.

Justin Avery: Exactly, barely time to put the belt on. But thank you very much again. If anyone wants to recommend a guest, or you’d like to speak, do get in touch. You can hear more podcasts and past podcasts at responsivedesign.his/podcasts. You can download an RSS
feed or you can subscribe via I-tunes on your pod catcher, whatever you’re using. If you do feel like rating up this podcast, do so, 5 stars is the best That would be awesome. But that’s about it. Thank you very much for listening, everyone. Thank you again PPK for joining and we will see you all next
week. Cheers.

RWD Podcast : Episode 40
24:13
2017-12-22 20:56:41 UTC 24:13
RWD Podcast : Episode 40

PODCAST SPONSOR

A huge thanks to MobX&nbsp;for their support of this weeks podcast.

MOBX is a Mobile User Experience Conference. It’s running in Berlin this year on the
11th of September, 2015 and you can head over to 2015.MOBXcon.com. It’s all about mobile interactions, designing for small screens, designing for smart devices and dumb phones as well. It’s mainly targeted around user experience and user interface design but anyone would find it useful to attend.

Transcript

Justin Avery:Hey everyone and welcome to another edition of Responsive Design&rsquo;s Weekly Podcast. My name is Justin Avery and I am your host and the curator of the Responsive Design weekly newsletter. A newsletter all about responsive design but it&rsquo;s changing these days so it&rsquo;s not &hellip; Responsive design is I think something which we&rsquo;ve all come to just accept as &hellip; I was going to say gospel but not everyone accepts the gospel.

We just accept it as the best way to build our websites because it kind of is. We still have the whole mobile debate every now and then. It&rsquo;s less about the M dot debate like do you build a mobile specific website and a desktop specific website? I think the debate is now more around do you build
a responsive website or do you have an &hellip; uh, a nap, or do you have an app because it&rsquo;s hard sometimes to build responsive websites and you get tired like I may be now, mispronouncing and mis-saying my words. Do you build a responsive design website as your mobile approach or do you have
a native app otherwise known as naps from here on forth?

It&rsquo;s an interesting debate anyway. It&rsquo;s not &hellip; The newsletter now is sort of forming more around that kind of &hellip; Not that kind of thinking but I think these days with responsive design being so accepted, it&rsquo;s time to start looking into some other things as well. That&rsquo;s
what we&rsquo;re trying to look at. Well, I&rsquo;m trying to look at with our guests that are coming up as well.

Next week we&rsquo;ve got on &hellip; Well, I&rsquo;m doing a couple of recordings next week so we&rsquo;re getting in Jason Grigsby from Cloud Four who is putting on the responsive day &hellip; No, so there was a conference call &hellip; The Responsive Day Out that Jeremy Keith organized and he is
doing a &hellip; Jason Grigsby is doing a Responsive Field Day in the States and he has got some amazing speakers. More about that when I talk to Jason.

I&rsquo;ve also got &hellip; I&rsquo;m really, really excited about this, a chat with PPK. I know I mentioned this last week but both he and myself have been busy and missing each other so we&rsquo;re going to line that up for next week. I&rsquo;m really excited to have a chat to him because he wrote
that whole let&rsquo;s stop pushing the web forward and then Jake Archibald came back with some questions and Bruce Lawson came back with some comments, Aaron Gustafson came back with some comments and he has just posted his reply to those comments from the guys.

It&rsquo;s quite good though. There&rsquo;s a ton of other feedback from other people as well, not just those three. He&rsquo;s come back out again and he&rsquo;s set his point of view a little bit clearer. Some of the things that&rsquo;s &hellip; I was going to say accused but some of the things that
he said last time were perhaps taken out of context. He didn&rsquo;t describe them quite as well as he would have liked and he has done that in this response. I&rsquo;m sure that&rsquo;s going to flare up and have a few more replies to that reply.

It will just be good to get him on and have a chat about. It&rsquo;s always easier just to speak about things rather than try and put them into words because sometimes people can misconstrue your words. They read it the way they want to hear it rather than the way that you are actually trying to convey
it. Anyway, it will be a great chat if not just for that but also, he is a very, very smart man, does a lot of research around browsers. He&rsquo;s really got his finger on the whole mobile thing. It&rsquo;s kind of big these days apparently. It&rsquo;s growing.

This week, we&rsquo;re sponsored by MOBX conference. Thank you to the MOBX conference that is running. It&rsquo;s coming up. If you go to 2015.mobxcon.com, go and check that out. That is a conference &hellip; It&rsquo;s a one-day conference being held in Berlin in Germany on September 11th. There are
some great speakers there and they&rsquo;ve also got me as well, which is awesome. I&rsquo;m really, really excited. I&rsquo;m &hellip; I think I mentioned last week, I&rsquo;m deciding which talk to deliver. I&rsquo;ve got one on building responsively and focusing on performance and how we go about
Y-framing and sort of an end-to-end process.

Then I&rsquo;ve got this other cool one where I&rsquo;m just talking about the universe basically because I love the universe and relating some of the elements that we would see in the universe and how we&rsquo;ve mirrored that in our own internet universe.&nbsp; It&rsquo;s an ever-expanding thing.
I&rsquo;m still deciding which one to run with. The second one, I&rsquo;m kind of nervous about because it&rsquo;s a bit out there and it&rsquo;s a bit abstract and I&rsquo;m much better about just doing sort of a &hellip; I feel more comfortable and say I&rsquo;m better, I feel more comfortable delivering more technical ‘This is how we did this thing and why it&rsquo;s awesome&rsquo; kind of talks but there&rsquo;s better speakers than me coming
out.

Brad Foster&rsquo;s talking there. Stephen Hay is talking there, two guys who I greatly, greatly admire so I&rsquo;m really looking forward to sharing the stage with them. It&rsquo;s all focused around UX and senior UX roles as well but it will cover basically everything web and mobile. If you&rsquo;re
around Berlin, get yourself a ticket. Go to 2015.mobxcon.com and find yourself a ticket there.

Thank you for sponsoring the podcast this week guys. We&rsquo;re just going to have a &hellip; Because there&rsquo;s no guest on this week, I&rsquo;ll have a look at what&rsquo;s happened this week. We already talked about PPK&rsquo;s recent article but there&rsquo;s another one, which I thought was
kind of weird, which was about the transition of everyone moving from HTTP to HTTPS. I know that Google are looking at &hellip; or Chrome is looking at changing the way they display the lock icon. The moment whenever you visit a secure site, if it&rsquo;s completely secure, it will have the green lock
icon.

There&rsquo;s different levels of SSL certificates you can get. Sometimes it has your brand&rsquo;s name in that lock as well, which is really secure. It costs a hell of a lot of money to get those certificates but sometimes you see a lock but it&rsquo;s yellow, which usually it means it&rsquo;s not
as secure as it could be probably because it has some insecure content on that page as well.

We really focus around showing when a page is secure where as if you visited it on a HTTP, we just ignore it. We don&rsquo;t include anything so there&rsquo;s no visual reference for people to understand that they&rsquo;re on an insecure site. It&rsquo;s just taken for granted. I think that they&rsquo;re
looking at perhaps including an icon to show people definitely all the time when they are on an insecure site so that they understand that it&rsquo;s definitely not secure rather than just showing nothing. Out of sight, out of mind, may as well put something there, which is in mind.

Anyway, the article by Troy Hunt is talking about SSL perhaps being, although we want to push people towards it, it still could be considered a bit of a premium service. He goes into a whole lot of detail around why he thinks this. He&rsquo;s been running a blog for years and years and years and is
on Blogger so a Google platform. At the moment, that doesn&rsquo;t offer SSL and so he&rsquo;s looked at different ways to be able to achieve that.

The number of people that are writing on Blogger because it&rsquo;s a free tool, they are not able to go to SSL if they wanted to and so they would have to then export all those posts and put it into a WordPress, pay for WordPress hosting, pay for a certificate and then put it on that so there&rsquo;s
not so much of a free offering. He goes into &hellip; Apparently, he has a wife or a girlfriend I think, writes on a Ghost blog and the Ghost is unable to run on SSL as well, it just it can&rsquo;t do it or at least the hosting platform that Ghost provide don&rsquo;t offer that particular solution.

There&rsquo;s just a series of things where he&rsquo;s tried to move on to SSL but its cost money because you have to host it yourself therefore, pay for it yourself and thinks that is going to be a barrier for people to move into it. The reason it came up &hellip; Well, that came up and then I also
during the week, I tweeted something out. I&rsquo;ve been looking at a bunch of sites that I&rsquo;m doing a gallery &hellip; I&rsquo;m doing a review of a whole bunch of sites that&rsquo;s going to be posted up on the site and one of them is the Polaroid.com website, which is absolutely beautiful, a
lovely responsive site.

When I ran it through a webpage test, the waterfall chart is just out of this world. There&rsquo;s like 500 HTTP requests, it&rsquo;s insane. Strangely though, the performance is quite good. The first render is kind of three seconds and it loads in 10 so that&rsquo;s not great but the page reloads so
the second visit is super fast. It cuts it by &hellip; I don&rsquo;t know, there&rsquo;s only a 10th of the amount of requests coming in for the second so probably even less than that and it&rsquo;s super, super fast.

I said, “Oh, I can&rsquo;t believe how big this waterfall is. This is ridiculous but it&rsquo;s still great. It&rsquo;s kind of performing all right,&rdquo; and someone came back and said, “Look, it&rsquo;s not even going to be a problem if you&rsquo;re using HTTP2.&rdquo; I agree, so I
employ &hellip; I use CloudFlare as a CDN &hellip; Or a CDN, is that the right word? I use CloudFlare basically in front of the ResponsiveDesign.is site to serve my content to you faster. They&rsquo;ve got a whole bunch of servers all around the world. All of my content sits on those servers so it reaches
you as fast as humanly possible &hellip; As fast as digitally possibly.

They offer HTTP2 or SPDY interface as well so that means that if you have a SPDY enabled browser, instead of all these old hacks we used to have to do for HTTP. This HTTP2 doesn&rsquo;t require as many hacks. For example, there are only a certain number of requests that can happen on HTTP1 at a time
and that&rsquo;s why we see these waterfalls and that&rsquo;s why it&rsquo;s called a waterfall chart because it makes one request, it delivers it, it goes back and makes another one, it delivers it, it goes back and forth and back and forth. The more requests you have, the more time it takes to load
the page because these can&rsquo;t be done in parallel. HTTP2 will allow you to do this in parallel. The whole thing around the spreadsheets, you don&rsquo;t need to use it anymore.

Jake&rsquo;s point was that &hellip; This was Jake making this point is that once we switch across to HTTP2 then it doesn&rsquo;t&nbsp; really matter. I was like, “Man, that&rsquo;s going to be ages away. What are you even talking about? No one actually supports it,&rdquo; until I went to the
CanIUse. Before I went back and said, “This is ridiculous. This is ages away,&rdquo; I had a look at CanIUse and SPDY&rsquo;s on just about everything. Its green lights just about all the way across. There&rsquo;s a really old version. Maybe Opera Mini, which doesn&rsquo;t matter anyway because
that&rsquo;s practically an image of the website anyway. It has its own proxy server, IE8 and for some reason, EDGE is listed as not supporting it, which I can&rsquo;t imagine it&rsquo;s true so it&rsquo;s really, really well supported.

If you have a website, you probably do, you&rsquo;re listening to this, put CloudFlare in front of it or talk to your sys admin and see if they can enable SPDY on your engine X or on your Apache server. It will just make things so much faster and everyone wants faster stuff. Google are doing it, Facebook&rsquo;s
doing it, Twitter&rsquo;s doing it. You just may as well do it and for people that have the browsers to support it, which is just about everyone now, then they&rsquo;re going to get an awesome experience. Yeah, definitely, definitely get on the SPDY wagon that&rsquo;s for sure.

There was another article, which I saw, which I really liked. I went to the Web IS conference last year I think it was. Craig Lockwood ran that conference and it was spectacular. It was really awesome. Really great bunch of speakers. I think it was Scott Jensen spoke there who was like a spokesperson
for Google. He&rsquo;s looking at taking the physical web and making something of it. He&rsquo;s kind of like &hellip; I hate to say evangelist but he&rsquo;s going around talking the good talk about these things.

One of the things he gave out to some of the audience members were these beacons. They&rsquo;re a little square thing like a key ring. It&rsquo;s the size of a key ring and it&rsquo;s a &hellip; It&rsquo;s like a size of a &hellip; If you had a matchbox and you made the matchbox to be square instead
of rectangle then that&rsquo;s how big it is if it was a square. Crop it into 300 by 300. That&rsquo;s how big it is.

It&rsquo;s powered by a small battery. It runs a low-powered &hellip; What is it called, Bluetooth emission. What you can do is you can program a URL into it. I would program say ResponsiveDesign.is into this thing. Programming it is really easy. You press a button, you have an app on your phone, you
type the URL into your app, you hit like send or commit or go and then writes it to the beacon.

Then what happens is the beacon just broadcasts that. It has like a five to ten meter radius that it can broadcast this signal and anyone else with this app, this physical web app will be able to see that URL. At the moment, they see it as if it&rsquo;s a Google search result. You have your blue links,
your green URL, your black text and if there&rsquo;s a few of them around then it will list a few of them. Then you can just click on it and it opens up that web page for you.

The whole idea is that these are going to go into vending machines or parking meters so you can pull up next to it, open up your phone, get the URL of that particular meter, click on it, pay your parking or if you&rsquo;ve got a vending machine, walk up to it, click on the URL, go pay for your chocolate
bar or whatever using your phone as the device and then this just spits out your chocolate bar afterwards or you&rsquo;ve covered your parking. It&rsquo;s a really, really good idea.

This article is just about what is going to become a reality like when you are walking through a store, how is it going to look? What are malls going to have? It&rsquo;s really a good review of how we are going to make URLs more discoverable. I was tying that back into a responsive thing. People are
just going to be browsing this stuff on their mobile so if you&rsquo;re not going to have a responsive site then you&rsquo;re in the poop or at least a mobile optimized site.

The other thing is you might look at &hellip; The great argument for the responsive side of things is that you&rsquo;re looking at this website on your mobile. It might be in passing, you&rsquo;ll send it to yourself, you&rsquo;ll save it, you&rsquo;ll share it with someone, who knows what they&rsquo;re
going to be on, they don&rsquo;t want to get an M dot thing. Yeah, it&rsquo;s really good. It&rsquo;s a cool article and if you can pick a beacon up and start playing around with them, they&rsquo;re at $4 or $5 I think it is, two or three quid, three or four quid, definitely, definitely try that and
check that out.

The other one that we&rsquo;ve got is a Lazy Load. I&rsquo;ve spoken about performance quite a bit and hacked on it. Images, one of the problems with this Polaroid site, which was &hellip; The first render was okay but it took so long to download and I tweeted just, just before I came across a conference
site not MOBX and not one that I&rsquo;ve been to before but it was a digital conference. The speakers&rsquo; page had 123 requests. It took 2.6 minutes to load and it was 31.1 megabytes of data transferred.

Now, I didn&rsquo;t scroll past the first frame so I just opened it and let it load. I didn&rsquo;t scroll to the bottom or anything and it still loaded all of that. Now, that&rsquo;s completely pointless. That is ridiculous. This particular plug-in which I&rsquo;m putting into this week&rsquo;s news
[inaudible 00:18:06] is called Lazy Load and they&rsquo;ll be in the show notes but it&rsquo;s a light weight JavaScript plug that&rsquo;s not reliant on jQuery and it will only load in the image when it&rsquo;s about to enter the view port of the scrollable area.

For example, if you&rsquo;ve got a page of 30 speakers and you&rsquo;ve got kind of &hellip; when you first load, you can only see one speaker. Just under the fold, the second speaker will be there. Because it&rsquo;s so close to the fold, I&rsquo;m using my finger quotes. It will load in as well but
the third speaker won&rsquo;t because it&rsquo;s not within the particular range of the viewport. If you start scrolling, you get close to the bottom of the second image then the third image will start loading in.

You will have this nice continuous experience where the image is always there but if you decide to bail on it after three or four speakers, you&rsquo;re not going to be penalized by downloading 30 images that you&rsquo;ll never see and spend 31 meg of your data. Anyway, very cool, very slick.

That&rsquo;s it for this week. Like I said, next week, I&rsquo;m very, very excited to get a couple of guests back on the show. It&rsquo;s going to be very cool. Before we go, there is another conference coming up, which is &hellip; A good friend of mine, Dave Letorey is helping organize this conference
for the London Web Standards Group. He&rsquo;s one of the organizers and event coordinators there. Yeah, we can spot him anywhere because he&rsquo;ll have a big red hat on. When you see him, you&rsquo;ll know what I mean.

He is offering subscribers to the newsletter and listeners as well, a 15 percent discount to attend The State of the Browser. If you go to www.stateofthebrowser.com, you can check that out. Slash speakers, you&rsquo;ll be able to see the speakers that are there. There are some really &hellip; There&rsquo;s
always some great speakers. I really love this conference.

Bruce Lawson is going to be there from Opera. Seb Lee-Delisle, he is one of the best speakers I&rsquo;ve ever seen. He always does something with lasers, usually live coding, which is always very, very cool. Chris Heilmann is going to be there from &hellip; Where does he work these days? I think it&rsquo;s
Microsoft these days but formerly of Mozilla, formerly of Yahoo. He&rsquo;s one of those evangelist folks. Adam Onishi, a great speaker well, Laura Elizabeth who&rsquo;s talking about patterns and pattern libraries, Ada Rose Edwards who&rsquo;s taking about the animation performance on the web, Phil
Nash is speaking, there&rsquo;s a whole bunch of people.

Go and check that out. If you want a cheap ticket, you get a 15 percent discount if you use the code RWD-SOTB5. That&rsquo;s RWD-SOTB5. This is in the show notes so check it out but it&rsquo;s RWD-State of the Browser 5 but yeah, that&rsquo;s it. Thank you very much for listening and downloading this.
Next week, will be a little bit more a two-way conversational instead of me just hounding you for the 15 or 20 minutes that I&rsquo;ve been doing.

Thank you very much for your support. If you want to go and check out some of the latest articles or some of the news items that will be in next week&rsquo;s newsletter you can go to ResponsiveDesign.is and check out the latest news section. There&rsquo;s going to be more examples of sites up there
as well and there&rsquo;s a whole backlog of cool podcasts with some very, very special guests talking about very special things, very intelligent guest. You&rsquo;ve got to check that out as well.

Until next week, enjoy it and have a wonderful weekend. Thanks everyone and see you then, bye.

RWD Podcast Episode #39
21:14
2017-12-22 20:56:41 UTC 21:14
RWD Podcast Episode #39

PODCAST SPONSOR

A huge thanks to MobX&nbsp;for their support of this weeks podcast.

MOBX is a Mobile User Experience Conference. It’s running in Berlin this year on the
11th of September, 2015 and you can head over to 2015.MOBXcon.com. It’s all about mobile interactions, designing for small screens, designing for smart devices and dumb phones as well. It’s mainly targeted around user experience and user interface design but anyone would find it useful to attend.

Transcript

Hey everyone, and welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery, and I am your host and curator of the Responsive Design Weekly newsletter, a weekly newsletter all about Responsive Design, funnily enough. This is episode 39 and I had a late cancellation from
a very, very special guest who will now appear on episode 40. It was an unfortunate cancellation, but we’ll all sort it out for next week.

So next week we’ve got a really cool person coming on … At least I hope it’s going to
be next week, anyway. That’s when we’ve moved it to, but it’s actually Mr. Peter Paul Koch, which is really exciting because he has written some exciting stuff this week which I really wanted to have a bit of a chat to him about.

So for those of you out there that have a question for PPK, for those of you that haven’t
heard of Peter Paul Koch I’m sure you would have come across some of his work. He writes on Quirk’s blog and he writes all about browsers and what’s happening and he keeps kind of all the browser vendors in check. He writes … I think he’s kind of sponsored by all the browsers, but just does a ton of
testing so we don’t have to.

He wrote the mobile web handbook which was published through smashing magazine which is
a fantastic read. I was lucky to see him in Dusseldorf recently … Do a talk all about how chrome really isn’t chrome in all of these many, many places that we find it. So, for instance, on the iphone it’s not really chrome because it’s got the safari rendering engine with IOS web kit running behind
it. So even though it’s got the chrome chrome, the actual rendering engine is still IOS. And then he goes on to explain about the different versions of chrome that appear on Android, whether it be the default browser … Anyway, it’s really great and I won’t do a very good job of explaining it, so that’s
why we have him on the show.

But that’s next week. For this week, before I get into it we’re just going to do a quick
run-over of some of the points that I came across in the newsletter this week and some of the things that I noticed on the web this week as well and strangely on television as well. But before we get into that, I do have a new sponsor this week. It’s not … I wanted to thank Media Temple for all of
their sponsorship over the last quite a few episodes. So thank you very much, Media Temple, for sponsoring the podcast and welcome to the MOBX conference.

So MOBX is a mobile user experience conference. It’s running in Berlin this year on the
11th of September, 2015 and you can head over to 2015.MOBXcon.com. So 2105.MOBXcon.com, and it’s basically all about mobile interactions, designing for small screens, designing for smart devices and dumbphones as well. It’s mainly targeted around user experience and the kind of, kind of the UX, like
more of the scene-y UX roles. I was talking to the organizer the other day and he was really excited about it.

It’s come a very long way in the past couple of years. They’ve got some really great videos
on the site of the previous years as well, and they’ve got some pretty good speakers and some all-right speakers. There’s Jenny Gove who’s a user experience researcher from Google, so you’ll probably notice her stuff … Brad Frost. Amazing. Really great speaker, and also Steven Hay as well. I’ve seen
them both speak before and they’re actually … They’re absolutely fantastic. So I’m actually really, really fortunate I’m going to be sharing a stage with those guys. We’re doing a talk about the responsive workflow and I may, may at the last minute check in a different talk which I’ve been working
on as well but we’ll see how that goes.

But they are sponsoring the podcast for this week so thank you very much MOBX … Go and
check that out if you’re around Europe or the UK or if you’re travelling over, go and check out MOBX. It should be fun! Come and say hello if you’re going to be there. I’d love to catch up and have a chat about the web and the responsive stuff.

So like I said this week we’re just going to have a quick look at some of the points that
are coming up in the newsletter for this week. So the first one is Tim Cadillac is starting a series of posts. He has recently done a whole bunch of research around proxy browsers and rather than sitting on it, he kind of wants to share it in a series of posts. And when I first read proxy browsers, the
immediate thing I thought of wasn’t proxy browsers, so that’s kind of like your Opera mini mobile where you have this browser in the cloud that just serves you … So browser in the cloud that runs off a server, that server goes and gets the content from the website that you’re looking for and then it
serves you the content, but in a much stripped-down form.

We ran a thing recently around what Google were doing with some of the results in Indonesia,
where they were taking the website and compressing the crap out of it. Making the images look terrible, stripping out all the javascript … Basically making the website load super fast and be super small for people in areas where the internet might not be as good and the cost of bandwidth is really
high. So this is kind of what proxy … He does a really good job of explaining it.

But when I first read it, I thought of proxy servers, not proxy browsers. And proxy servers
are things like … Varnish is one, Squid is another … These are like reverse proxies and the way that they work is you have a web server so lets say we have a WordPress site, and WordPress runs the apache, it’s got MySQL on it, and it’s running php and almost every time you request a page from that
server, like just say we request responsivedesignweekly.com, the request goes to the server , it generates the page. So apache gets the request, it’s like “hey, I know this request. I’m going to fire up WordPress, I’m going to go to the database and pull out the content that I need and I’m going to put
these php files together and I’m going to push it back out to the end user.” And it kind of happens every time someone requests a page. That’s just if you’ve got a basic setup.

Now what a proxy browser … sorry, proxy browser. What a proxy server will do or a reverse
proxy server will do is it sits in front of that stack. So where you would have apache, MySQL and php running, it would sit in front of it. So let’s say it’s the squid server, you will request something, it will get to squid and it will say, “right, I want responsive design weekly,” it will check it’s
own cache to see if it already has that page. If it doesn’t, then it will ask the regular stack to build that page and serve it to the proxy or reverse proxy, which is squid, and then it will say, “okay, I will serve this.” But it kind of serves it just as flat html with a CSS and javascript request
that will come through as well. But it just serves it up, it doesn’t serve a dynamic version of it, it just serves the page as if it’s just standard html like a flat site rather than a database powered site.

The exciting thing about that is if there’s additional requests for that same page, and
it’s still in the proxy’s cache, then it won’t bother the server. And the important thing about that is that if you have a really large CMS … Excuse me, if you have a really large CMS … So let’s look at CSS tricks, for example, that database is massive. So Chris has been doing that for so long that
if that database has to fire off for every single request, then it’s quite taxing on the server so he would need a much larger server with a lot more power to serve every single request that comes through. If he had a reverse proxy, then the server has to do much, much less work because it doesn’t have
to start the CMS. It doesn’t have to do these queries, it just has the page already there in cache. So the same way that caching in a browser is great, so it saves additional requests, but you as a user, the reverse proxy is great because it saves all these additional requests to my server.

Now I used to work on a CMS so the the responsive design is CMS, is a CMS called matrix.
And it’s an enterprise-level CMS. It’s way weightier than I need for this particular site … But you know I worked for a company that produced this CMS and I got really good at building things in it so you do what you know. But it’s really expensive to get going because it’s an enterprise level it has
all of these permissions … The way it’s designed, it just takes for an age to get started. So when a request comes in to it, to get it kick-started and for all the moving parts in that CMS to start working, it’s like half a second. And so my time to first bite is absolutely woeful. So what we used
to do is we would but this squid server or varnish reverse proxy in front of the other stack so that we saved on all of these requests.

Now if you use something like Fastly, or if you use the one I use, CloudFlare, they’re great.
That’s kind of what they are. They’re reverse proxies, but they’re also like a content distribution network. They’re like a CDN. They’re reverse proxies all around the world. So not only do you get that benefit of saving a request to your server to get it working, you also can deliver content to people
wherever they’re living. So they work really, really well. But this thing just sort of sits, like this reverse proxy just sits in front your stack. Now the reason why this is important is it makes things more performant. It makes it faster.

Now last week in the newsletter I talked about my cousin coming over from Australia. She
came to stay with us for a couple of days which was great … And we hung out, we watched a bit of TV on the Sunday night, and the television program that came on was a program called “Dragon’s Den.” And for those of you that aren’t aware of what “Dragon’s Den” is, it’s this program where entrepreneurs
come on and they pitch their idea to these four dragons. So we’re not talking like Jon Snow fighting dragons, what is it, “Game of Thrones” dragons, these are just people who have made it in business who have a bunch of cash and they want to invest in startups or entrepreneurs so they can make their
money back. So someone will pitch them and idea and say, ” I would like a half a million dollars or half a million pounds for a 40% stake in my company.” And then if it’s a good idea, people will buy it. Or at least give them money.

Now that’s the premise of the show, and what some people do when they come on is … I just
don’t think they want the money. They just want the coverage. Because this runs on BBC2 on a Sunday night when when they know there’s a lot of people just sitting around their living room watching television, watching really bad television. But they’ll still watch it. And if you hear about a product
on it, the chances are you’re going to be sitting there with your smartphone or your laptop on your lap, or your tablet, and if it’s a good idea, you’ll probably Google them and you’ll go and check it out.

So I saw one a couple of weeks ago which was a property developer and he had a stupid evaluation,
which didn’t make any sense. And he didn’t really want the money, I think he just wanted the coverage. But last week they had a company called Van Girls, who were just an all-woman team, many hired women and they would move people. Basically, you hired them, they would come and move your house or move
something from one place to another. And they were just based in London for now, but they’re growing and they needed money to grow.

Anyway, it was a great pitch and I think it was Emma who did the pitch, she said “my website
is really great.” And so they gave a pitch for her website, which is great. She’s trying to build her company up. I went and had a look at it, because if someone says “this is a really great website,” I’ll go and check it out and try to poke holes in it or just look what a great website is and see if
there’s anything I would have done differently on the site. And I got there and it was just database error connection. The traditional error you get with WordPress when something goes wrong with the database.

So obviously what had happened is that she’s mentioned this on a television show which has
a few hundred thousand viewers, a few of those viewers have decided to … Excuse me, I’ve got a dry throat. A few of those viewers have decided to go and check this website out on their phone or tablet or laptop, and it’s just brought the server crashing down. The same thing happened for another mother/daughter
combination who were pitching for a handbag spa which I didn’t go and check out but my cousin did, and she said she couldn’t get on because it crashed. That one the server had come down, not the database.

But the whole thing is like, this is really simple stuff which all of, like, a lot of your
clients … I know you work on websites, you will have clients who will have websites, you will have websites, so you may be the client, like you may be working for a company and you build their website … And these are really, really basic things. If you’re going to have a spike in traffic, and you
know it’s coming up, it’s not like they recorded this on the Sunday night and they’re like, “oh, man, I totally forgot that we needed the website” … They recorded this weeks if not months in advance. They had time to plan it.

Whoever built them this site, which does look kind of lovely, apart from the fact that they’ve
also built them a mobile-specific site, we’re not judge-y here, but, you know, I’ll judge … They just didn’t build it well. It does look great and she’s very proud of it, but there were 20 CSS files and javascript files from all the different plug-ins that WordPress comes with. So, for one, they should
have all been concatenated into a single file. Caching wasn’t really turned on so requests were going back to the CMS every time a page was requested. They obviously didn’t have a proxy sitting in front of it to help with these requests, so the database was working overtime and all of a sudden a few
thousand people hit their website at once. It just brought it down.

So by doing really basic stuff like adding gzip, concatenating all your files so there’s
less HTTP requests to the server, putting in a proxy or putting CDM like CloudFlare or Fastly in front of your website. CloudFlare offers a free tier; there’s almost no reason not to go with them. They mitigate threats, brute force attacks, especially for WordPress sites that will get rid of, that means
you’ve stopped getting hacked, and if you do, like if you’re lucky enough to have this massive spike in traffic because, I don’t know, Smashing Magazine tweets you or Brad Frost mentions you somewhere or Ethan Marcotte sends a retweet out or someone from A List Apart mentions you or you hit the front
page of Reddit- it happens. Sometimes your site gets really really popular, the last thing you want with all this traffic coming through is for your site to go down because you’re not prepared and it wasn’t built properly in the first place.

So that was super, super annoying. So you should definitely look at your websites and make
sure that stuff doesn’t happen and that you are ready or your clients are ready for that kind of hit. It’s super important, that sort of stuff.

The other thing … if you do need javascript, like different javascripts as well, remember
you can check the async attribute on to the script tag which will mean it won’t be blocking … But just a word, like we were doing some performance improvements at work today on a popular website and I was trying to get them as close as possible to the green 100 [inaudible 00:17:42] Google page insights
and down as close to 1,000 on the speed index for webpage test, and Modernizr was one of the things that they were hanging hooks on to be able to load other things into the site. Modernizr’s a weird one, it does need to run in a head because it needs to be able to put things into the head class so you
are able to hook things on to. So you can’t actually defer that by putting the async in there. That does need to load in the head. But I recently went through and took Modernizr out of a whole bunch of my sites as well.

There was a talk, like a talk that was a discussion on a slack group called Front End London,
by all means go and join it. It’s open and free to join … So if you’re in London, even if you’re not, there are some really great people on there. And it was like, “does anyone use Modernizr anymore?” I was like, “that’s a really good point. It used to be in the HTML5 boilerplate, I think it probably
is, and I think we use that without thinking for a long time, at least I did, and I just include Modernizr on every single project because I was like, “yeah, well, if I need it I can tell if someone’s got Flexbox support or if JS isn’t working or if this or that … But at the end of the day, it was
in the head but I never did the test. I never looked to see if those things were loading or not, I just assumed. So I actually went through and removed it from a ton of projects. Because it’s just an extra javascript file, an extra HTTP request that doesn’t need to be there.

So if you have built something based on the HTML5 boilerplate, if you are using Modernizr,
just go back and check, like are you actually using it or are you just loading it? I commented it out, and it had no bearing on my site whatsoever. So I was super, super impressed with that.

So that’s about it. There were a couple of things that popped into my head while I was going
through the links this week. There’s probably a few more things but my throat is just getting far too dry. This is why I have a guest on, so I don’t talk all the time and get a dry and croaky throat. But thank you for tuning in and downloading this week’s podcast, next week I will be back with a very
special guest. Like I said, we’re getting Peter Paul Koch on, that’s very, very exciting. And also another one coming up is Jonathan Fielding as well. He’s the author of the Simple State Manager, which is kind of like matchMedia on steroids which is very cool. So we’ll talk to him about some of the talks
that he’s giving shortly and some of the work he’s doing around that and why it’s a really cool tool.But like I said, that’s all for me. Thank you very much for MOBX for sponsoring this show, 2015.MOBXcon.com, go and check it out. My name is Justin Avery, you can subscribe to the weekly newsletter at responsivedesignweekly.com and you
can check out all of the responsive design resources. And it’s not just responsive design anymore, there’s a whole bunch of resources and tools and tutorials and podcasts on on the responsivedesign.is website. Thanks for listening, and I’ll see you … Well, I’ll hear you or you’ll hear me next week.
Cheers until then. Bye.

RWD Podcast Episode 38 : Matt Griffin
96:05
2017-12-22 20:56:41 UTC 96:05
RWD Podcast Episode 38 : Matt Griffin

PODCAST SPONSOR

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple’s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That’s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.

&nbsp;


Show notes


Transcript

Justin Avery: Hey, everyone, and welcome to this week’s edition of the Responsive Design podcast. This is episode 38. My name is Justin Avery and I’m your host and curator of the Responsive Design Weekly newsletter. Just right off the top, I just want to thank everyone
of the listeners. Thank you very much for voting. We’re very, very fortunate to make the short list for the Net Awards this year. There are some really great other podcasts in there. Just to be nominated and make that shortlist with those other ones there like Codepen Radio and The Web Ahead show, just
really great stuff. I feel very proud and humbled to be in that crowd. Thank you very much for voting.

This week, I’ve got a super exciting guests joining. I’ve been in touch with this guest for the last couple of years but it’s the first time we’ve actually spoke in real life but before I introduced him, I just wanted to do a sponsor mention at the top of the show. This week’s sponsor is Media Temple.
If you go mediatemple.net, you can check out all they have to offer. They’re a web hosting company and they provide hosting for the Responsive Design Weekly site which is pretty cool.

They’ve got whole bunch of different ranges of levels that you can get it on. If you are just getting started, you can sign up for like a self-hosted, not a self-hosted, but a hosted WordPress hosting facility. It’s super cheap and it takes all of the difficulty away from you. You don’t have to install
Apache or NginX. You don’t have to install WordPress. You don’t have to configure your firewalls. It just looks after everything for you. You just start writing articles and banging in plugins or whatever you want to do in your WordPress site.

They’ve also got other different tiers. I run one which is a dedicated server and so I can run as many different instances and use a host out for friends or for clients and things like that. Wherever you’re coming in, they probably have … Or they do have something for you as well. I can’t recommend
them highly enough. They are very, very good at what they do. Now, if you use the code RD25, you get 25% off your web hosting and also it goes to show that people listen to the show and it will help with future sponsors. You should definitely go and enter RD25 into mediatemple.net and sign up for some
hosting today.

Thank you for sponsoring this show, Media Temple, and let’s get to this week’s guest. Welcome, Mr. Matt Griffin. Hello.

Matt Griffin: Hey, how are you doing today?

Justin Avery: I’m very well. The weather has been a little bit humid and hot in London but otherwise, it has been very well. How are you?

Matt Griffin: Great. We’ve had weird weather in Pittsburgh, not that I’m sure anyone is interested, but it’s been exceptionally rainy and it’s like 65 degrees this morning for the middle of July which is super weird. There is no problem, I’m sure. I’m sure everything is fine.

Justin Avery: It’s [inaudible 00:03:24].

Matt Griffin: Keep burning petroleum. It’s fine.

Justin Avery: Yeah. I’ve got a tire fire around the backyard. It’s cold usually here. I’m from a good place called Darwin in Australia. I don’t know if you’ve ever been to Australia.

Matt Griffin: I have, actually. I spent two months in Australia when I was 16.

Justin Avery: Whereabouts?

Matt Griffin: We went to … My dad is a mechanical engineer and at that time, he was teaching at Carnegie Mellon University. He specializes in turbine jet engine blades and the dynamics of those things like torsional vibrations or the twisting vibrations of turbine engine blades. He
was hired by … Gosh, now, you’re going to hate this, but I can’t remember if it’s Qantas or Ansett. I think it was Qantas. [crosstalk 00:04:08]

Justin Avery: How long ago was it? Because Ansett closed down in the 80’s, I want to say.

Matt Griffin: This would have been early 90’s.

Justin Avery: Maybe they were just around then.

Matt Griffin: Maybe like ’93 or something like that. Probably ’92, ’93. Maybe a little later, maybe ’94, who knows. I don’t know how old I am anymore. But they hired him to go over there and worked on some stuff. Let’s say it’s Qantas just for fun, although I do still remember, because
Qantas had never had a plane crash. Ansett have had one, I think, at that point. The tag line of the people is ‘Chance It With Ansett’ which I thought was pretty great. They had one plane crash, right?

We went over there for this whole summer. We spent two months in Australia and two weeks in New Zealand. We were in … Oh, god, now, I’m going to look like a jerk because I can’t remember city names. It’s been a long time.

Justin Avery: I’m sorry. Melbourne, Sydney?

Matt Griffin: Melbourne. Thank you. We’re mostly in Melbourne. We’re in Sydney for a little bit and we did a little bit of traveling. We went and saw the Great Barrier Reef. Then, we went to New Zealand and went to Auckland and Christchurch and traveled around a bit. It’s actually informative
summer for me. There you go. [crosstalk 00:05:14]. Thanks, Australia.

Justin Avery: Yeah. Well done, Australia. Well, up near the Barrier Reef is an area called Cairns that you might have gone to.

Matt Griffin: Yeah.

Justin Avery: That is kind of, if you went due west from Cairns, you would hit a place called Darwin which is at the top middle of Australia. That’s where I’m from and it’s really hot there all the time, similar to what it would have been like in Cairns. Now, I live in
London. I mean, it’s summer now but jeez, I’m not used to the cold weather, but it’s nice. It’s fun to dress up in these coats in many layers and learn how to not get frostbite.

Matt Griffin: You would love Pittsburgh then.

Justin Avery: Oh really?

Matt Griffin: The wide variation. We’ve got all the fun stuff, like hot summers and freezing winters. It’s wonderful.

Justin Avery: I only ever made the West Coast of the States and only for a short period of time. I do want to get back and [crosstalk 00:06:07] have a look around.

Matt Griffin: I’m all for the warm weather mostly because maybe it’s all men but I think we look bad in shorts, man. Our legs, there’s nothing that you’d want to see there. It’s great when we can just put on pants. I’m all for cold weather.

Justin Avery: Yeah, definitely. I think it’s like, if you’ve got a good tanned leg, it’s fine. [crosstalk 00:06:35].

Matt Griffin: Maybe your legs are okay.

Justin Avery: [crosstalk 00:06:35] If it hasn’t seen the sun for a while, it’s never a pretty sight. When you went to Australia, the internet was around, in ’92 or ’93. Not really, just …

Matt Griffin: Yeah, a little bit.

Justin Avery: What were you doing at school as you were leaving school before you entered these. Did you get in at such an early stage?

Matt Griffin: I really wasn’t … No, that was the ninth grade for me. Well, okay, so high school. This is ’92, ninth grade. I didn’t do much with the web. I do remember one of my friends there, so we had friends in Australia. One of them works for some software company. He’s a little
older. He got me a copy of the XCOM video game that had just come out on floppy disk, like he gave me a tarball copy of that. I spent a lot of time in Australia playing computer games. It’s sad because I could have just done that when I was at home, but 16, that’s what happened.

Justin Avery: Yeah. You just do that at that age, right?

Matt Griffin: Yeah. I got into the web … When did I get into web? I mean, I recall … I was in lots of weird music in high school and college. When I first … I left high school a year early to go to the University of Pittsburgh for a little while which was here as you might imagine
in Pittsburgh. That’s when I really got major exposure to the web and the internet, a little bit before at friend’s houses. I was on BBS’es in middle school and stuff but the web-web, I really got into more, like that year ’96. I remember particularly finding websites for bands that I didn’t think anybody
else was into. It was really exciting. First of all, to see pictures of the bands because they didn’t have pictures in their record covers, their line or notes, but also just to realize that there were people like me who had very weird interests, things I thought that I didn’t figure to share with other
people.

I think that first exposure to the web is really informative for me because it painted the web as this place where the nerds of the world, the people who felt sort of marginalized or different than the people that they’re around in their local region could go and connect with other people and feel
less alone. That early period of the web is really meaningful to me. It wasn’t long after that, that I started getting into teaching myself HTML by looking at view source like most of us did in getting at GeoCities websites and putting animated gifs of flames on. I had music-related websites. Of course,
I was in The Sunset Strip, I don’t know about you.

I remember being so excited about the web at that point because it just seemed wide open. You could do whatever you wanted with it. The things I put on the web seemed just as viable. They had just as much reason to be there as anything anybody else put on the web. That was really, I don’t know. It
opened a lot of doors for me, I think. It wasn’t until much later that I became professionally involved with the web, but for years, I was a musician. I played drums in bands, that I’d be the guy in the band that made the band’s websites. I knew enough to be dangerous and made a bunch of band websites.
It wasn’t until much later … Do you want to hear my weird college origin story? [crosstalk 00:10:05]

Justin Avery: Everyone wants to hear a weird college origin story.

Matt Griffin: Okay. I went to school, Indiana University, at a normalish time for audio recording in music school. I played in bands and I thought the next best thing to go into school for being in a rock band was to learn how to record your band’s albums. I did that for a while and
the university had very good music program. I was learning there and I got a semester short of graduating and then I realized that two things happened. One is I realized that recording music that I didn’t like and trying to make it sound good was my idea of hell. I didn’t want to keep doing that and
inevitably, you’re not going to like most of the bands you have to record if it’s a job. You’re going to record bands all day. You’re going to hate a lot of it.

I didn’t want to do that. I like recording my music but I didn’t want to record anybody else’s particularly. That seemed like a bad thing to complete. Then, my college band got famous in Japan. We got on a record label in Japan. We’re like touring over there and stuff. I was like, “This is it. I’m
just … Forget school. I’m just going to drop out and play, being in a rock band. We’ll be Radiohead or something someday.” It turns out that’s not what happened and that getting on a record label in Japan when you’re 21 does not mean a lifetime legendary music career. In hindsight, that seems obvious,
but at that time, it seemed like a good time than any to drop out of school.

I dropped out of school and I spent the next five years playing on various bands. I lived in Chicago for a little while and moved back to Bloomington, Indiana for a little while where Indiana University is and had a good old time doing it. As I got further into my 20’s and started to feel the pain
of sleeping on floors and sleeping four hours a night and driving to the next town to do a thing, it started to feel like maybe I needed a different career choice that had healthcare, for instance. That might be a good thing.

I decided I was going to look into going back to school. I was still living in Bloomington. I had been there for most of the previous 10 years and this may be 2006 or 2005 or something like that. I’ve been making websites and I thought, “Well, actually, this is pretty creative and interesting. It seems
like there are jobs. I’ll go be a designer.” I looked into going back to school and I checked with registration and as it turns out, because I dropped out of school instead of finishing my degree like my parents really had pushed me to do, I was considered to be re-enrolling if I went back to school
which meant they’re going to backdate me to 1996 rates on the tuition.

Now, I’ve been living in Indiana for 10 years so I was in-state. I actually went back to school in, whatever, 2000 or whatever, for $5,000 a year. Once I figured that out, I was like, “I’m going to go back to school for something.” Design seemed like fun. It seemed like putting together design stuff,
felt like making albums and then you start with the germ of an idea and build it out and then you end up with the thing but someone would actually pay you to do it.

I’m back to school for traditional graphic design and by the time I get out of it, at that time, the web was in the heyday of, I mean, we just finished up tables based layouts and where Flash was going nuts. I hated Flash. It just felt really wrong to me. It didn’t excite me the way that early web
did, so I stayed away from the web and I got really into letterpress, really high into print stuff. That’s where I was trying to go when I came out of school. Then, it turned out that all the work was in web and my boss at my first job convinced me to pursue web stuff.

There was a guy I worked with there who was reading A List Apart and into separation of style and content and using CSS. He started showing me all the stuff and I was like, “This makes sense to me. This is almost more like laying out type on a press bed with letterpress.” It makes sense that you have
content and it’s structured in a way and then you have CSS to make it look a certain way. I could build things like this. This feels more like the web to me. At that point, I got really into the web and then it wasn’t long before I’m doing what I’m doing now, I guess.

Justin Avery: That’s an awesome transition from [part to part 00:14:04].

Matt Griffin: There are a lot of different things in there. I remember telling my boss at the first job that I felt really behind. I think, at that point, I was maybe 30 or 31 and just getting into professional design. All the kids I graduated with, they were also getting entry-level
design jobs were like, whatever 22. I felt like, “Man, I’ve wasted my life on music. I’m so behind now.” I remember telling her, “If I could just drum a website into existence, then I would be great at this.” But I’ve invested in the wrong skills. I don’t know, eventually, I got good at it, I guess.

Justin Avery: You need some kind of like Guitar Hero that builds a website.

Matt Griffin: Great, exactly. To roll down some HTML tags.

Justin Avery: Exactly. You punch in a different combinations of it and then, bam, there’s a header, bam, [crosstalk 00:14:56].

Matt Griffin: Bam, carousel. That’s what the world needs. Bam, carousel.

Justin Avery: Oh, terrible. Because I’m sure there are many people that are moving into the web even today at 31, 35, 40. You think they’re well behind the curve. What advantages do you think you had over those 22-year-olds coming out of design school?

Matt Griffin: A lot. You don’t know anything when you’re 22. You don’t know what you’re doing. Not to make 22-year-olds feel bad, I mean, you know how to do … There are things that you know how to do but your perspective is very limited. I mean, I know when I was 22, god, I had no
idea what the heck I was doing. Your perspective is … I think the biggest thing is your perspective is very different. The more time you get under your belt on this planet, the less specific things bother you because you have the perspective to see that there’s always another thing. I think you learn
how to pace yourself a little bit more, how to focus when you need to, how to pull back perspective when you need to. At least that’s the hope, as you get some sort of wisdom.

I think the life experience that I had, it was less useful when I was a designer at a company. I was at the bottom of the design food chain. I had people telling me what to do all day, but once I started my own thing, when I started Bearded in 2008, it seemed like my only route to get back up the chain
a little bit, instead of being in level with the 22-year-olds is well, I tried to get hired at places that I admired and no one is returning my calls. I thought, “Okay, well, the only way I’m going to make this work is just doing my own thing.” I’m the only one who will give myself a chance.

I should just give it a shot. What have I to lose, right? I hadn’t had a child yet. I felt like now is the time to take risks. I got a teaching gig, an adjunct gig, at Carnegie Mellon at the time doing some production design teaching. I had a little bit of dependable income and started off with a friend
who is a developer and we just started doing stuff. I think all of that time spent playing in bands, was actually really useful.

For a long time, I resented it and I felt angry at myself for wasting all this time playing music. As I did things longer, I realized that I had developed skills were really helpful. For one thing, creating an album is a monumental task that feels a lot like project management juggling. You’ve got
to get from writing and perfecting material to laying tracks down and mixing and editing. I was in recording so I was actually working in Pro Tools. There’s a lot of analogies, I think, between something like Pro Tools and Photoshop, is how you manipulate sound versus how you manipulate. I mean, really,
when you think about music, is just organizing sound into structures that mean something to a person, and design is organizing color and form and type into structures that mean something to a person. They’re very similar.

The other side of it, when you’re running a business is that running a band or being in a band is one of the most stressful and nuanced interpersonal endeavors one can enter into. When you basically have a bunch of creative people that care a hell of a lot about what they’re doing and have different
ideas and may or may not be very good at communicating their thoughts to each other; add to that, that they’re all underpaid and underslept and underfed and you’ve got a recipe for … I mean, there’s a reason bands have horror stories and breakup stories.

If you can learn how to like keep a band together well enough to put out some albums and go on tours and survive and not hate each other, then you can definitely run a design business where people are at least getting paychecks and things happen.

Justin Avery: They have a bed and a roof.

Matt Griffin: Right. They’re being reasonably compensated for what they do. It’s not like their sole reason for doing it isn’t just a pure love for a thing that they may or may not even understand very well.

Justin Avery: How did it go from what you’re doing … You were talking about becoming a sound engineer and recording music for bands and people might not necessarily like the music in putting that on. Have you found similar challenges when working as a designer with
clients, maybe before and after you started Bearded?

Matt Griffin: Yeah. I mean, it’s a different thing in that regard. With music, I feel like, and I think this is maybe the crux that I was getting in before with the band analogy, is with music, you’re doing it … at least with these guys, I was doing indie rock music. No one is expecting
to get paid. Your only motivation is creating something you love. You really, really care if the thing at the end of the day is the thing you personally love or don’t love.

With design, it’s a much more functional thing. You’re trying to create something that is effective at the goals of the thing. If you’re making a poster for an event, then maybe the goal of that poster is to get people to notice the poster and the event and then go to that event. If a poster does that
well, it doesn’t really matter if you like it or not, it’s a good poster objectively. It got people to event, it sold tickets, it’s a good poster. You may think it looks like shit, it doesn’t really matter. It did its job.

I had a teacher in design school, a professor that someone once said something about one of the students in class that said, “It really feels like you have a style with your work, like I see there’s a consistency in the look of the work you’re doing. It’s neat that you have the style.” She interrupted
and she said, “You’re not artists, you’re designers. You don’t have a style. Your style is whatever solves the problem at hand.” I was like, “That’s awesome.” I love it, because that’s true. Who cares if you like it or not.

We flat out tell everyone of our clients. It’s in a document that we hand out at the very beginning of projects and often in proposals. It doesn’t matter if you like the work or not. It doesn’t matter if I like the work or not. That’s irrelevant. Every piece of design everyone produces, somebody’s
going to like it, somebody’s going to not like it. What matters is, does this meet the requirements of the project? Is it effective at its goals? If we decide that it’s going to do these things and we decide that it needs to meet this criteria, is it doing that?

With design, that tends to come down to three things. You have what you’re trying to communicate. You have the audience you’re communicating back to, and then you have the style that you’re going to say it, how effectively you’re saying that. What is the content? Who are we talking to? How do we communicate
that content to those people in a way that they’re best going to receive it from us? What’s the tone, really audience content tone?

Justin Avery: If you’re working with the client, because generally, one of the biggest problems is that you show what you believe is an awesome design and, well, an awesome way of conveying the message and the purpose of the website.

Matt Griffin: Yeah, which is design.

Justin Avery: Yeah, which is design, to the customers that are going to be using the site but when you show it to the client, they are less impressed. They have a particular style that they have in mind. How do go about proving to or helping lead the client down the path
of realizing that what you have produced is in fact better than what they have in their mind?

Matt Griffin: That’s an interesting way of framing it because that’s sort of presupposes that what we have created is good or correct. I tried to go in with an open mind about it being maybe not the correct solution and I want them to do the same thing. When we first sit down to talk
about it, they might say something, the classic, make the logo bigger, make it blue, move them over here, like that’s very prescriptive response. I would say, “Okay, that’s fine. Let’s suggest that,” and keeping in mind that most clients don’t have a formal design education. They don’t know how to talk
about design. They don’t know how to give good feedback. They’re just trying to be helpful. Their goal is to have a good product, so is yours. You’re not immediately at odds.

My first questions tend to be like a therapist, really. It’s, “That’s interesting that you want to make that logo bigger. Why do you think the logo needs to be bigger? Well, that’s neat that you want that to be blue. What is it about the blueness that seems right to you? What’s not right about the
color that it is right now?” We try to steer it back towards things that we set out before we start getting visuals. We don’t just like turn on the screen and just start doing stuff and then hope it’s right. We don’t do stuff until we’re like, “I like it,” and then show it to our client.

We start with a lot of research. One of the things we tried to define in terms of look and feel is what are the qualities that we want to communicate for the brand or for the product. We might have a list of adjectives. It’s like it needs to be like … I mean, the ones you hear all the time were like
friendly and clean and whatever, open.

Justin Avery: Inclusive.

Matt Griffin: Inclusive. That’s a good one. But most of the time, you end up with these tight roadblock things where it’s like, it needs to be high quality but not snobby or high class but not expensive, like these tight roadblock things which is actually reasonable. It’s not contradictory,
it’s explaining to you that there is a balance to be had between two extremes. The real question is like where do you put the fulcrum on that extreme and how far. Are you mostly high ends? Are you like Apple where you’re trying to look really high end? Or not too expensive but maybe a little expensive?
Or are we trying to look cheap, like cheap to buy but still of reasonable quality? Maybe something more like a Fitbit or something like that where it’s this plastic rubber thing. It’s probably not going to fall apart today but it’s $40 or something, whatever. I don’t know what Fitbit costs, I don’t really
know anymore. I probably shouldn’t quote the prices of products in podcasts that I don’t have no idea about.

Anyhow, you get the point. There is an objective set of criteria that we’re trying to make like some products do want to be friendly. Some products don’t want to be friendly. Some products want to be authoritative and that’s a different criteria that you’re going for. When we have those conversations,
we’d go back to those list and we say, “Okay, at the outset of the project we said, we wanted to be these things. Are we achieving that right now, and if we’re not, are we too much something or not enough something else?”

We’re trying to steer them away from the prescriptive results because that’s my job. I’m a designer. I’m supposed to figure out how to solve your design problem, but what I need from you is whether or not I’m solving that problem well with your knowledge of your audience and your business and everything.
If I’m not solving it well, let’s go to the root of how I’m not solving it well. Yeah, I said friendly but this theme is too friendly. It’s almost silly. It’s almost flippant, like that’s too far. We need to pull it back. We need a little more sober than that.

I guess when I said friendly, I didn’t mean playful. I meant inviting. It’s just a little too energetic. It’s not calm enough. We wanted it to be like warm and friendly and reassuring, not like fun and playful and friendly. Oh, okay. Got you. I misunderstood. Then, maybe these colors are a little too
bright, a little too vibrant. Maybe they needed to be warm but a little more like subdued, like maybe like deeper oranges and reds are better than these pinks and purples we’ve got going, whatever it is.

I think if you can tie it back to an objective criteria about something you’re starting to achieve, you can look at almost any aesthetic decision in terms of what it evokes in people. I think color is very clear like that. We all know red, like fire engine red, is going to feel like alert and aggression
and fire and blood all of these. It’s going to get your attention but it may not be positive. Blues are going to be more calming and soothing.

Similarly, with typography, if you’re going to choose something like Garamond, so that’s obviously going to feel more scholarly and bookish than if you’ve picked something very pedestrian and functional like Helvetica. I firmly believe that every choice we make in design has those sorts of components
and you can create good design by looking at the effects that each little choice has on a person and collectively, they make a more nuanced and interesting thing.

Justin Avery: When you’re showing your client these things and presenting to them where they can see whether it’s too playful or whimsical or too bookish in the typography that you’ve chosen, everyone, I think, these days has their own way of approaching a project. Some
people dive straight into design program like Sketch or Photoshop. Other people are wireframing and sketching. Everyone has their own way of approaching it. How do you do it at Bearded, approach it with the client?

Matt Griffin: I’m really in the process. I really like figuring out processes that help us get to solutions that are good, more often than not, but also processes that help us communicate with our client in a most efficient way as possible. If you think of it from a client perspective,
we’ve designed websites all the time. That’s our job. We’re designing websites day in and day out and we know what to expect and we know that at the end of the project, it’s probably going to be pretty okay because it always ends up pretty okay.

From a client side, it’s like what, every four years if they’re lucky that they’re starting a website redesign. Potentially for them, it’s fraught with anxiety and at the very least, unknowns. They don’t know what’s going to happen next. They don’t know what to expect. They don’t know what’s expected
of them and a lot is probably on the line for them. They’ve been tasked probably by a superior to have this website redesign happen and if it tanks, then it’s their job probably.

There are lots of reasons why they’re going to be very anxious during this process potentially. I like to come up with a process that helps out a lot. I think the best thing for both of their sanity and for us to hit the mark on the design and for situations like Responsive Design that are more complex,
it involves breaking down the deliverables into smaller tighter deliverables, that we can do more quickly and discuss more readily.

For instance, when we start, we like to do whiteboard and paper sketches to get in wireframe stuff, to get in information design at layout information architecture. We’ll use those to start talking about things like page layout or even element level layout, a modular layout. We’ll do really quick Photoshop
comps usually for things like Dan Mall [inaudible 00:29:49] element collage or Samantha Warren Style Tiles, that sort of approach to getting look and feel really early. We can spend like 10 or 12 hours hammering out a look and feel direction that doesn’t show a page layout. We’re not going to be arguing
about move the logo over here, I don’t know if this thing should be on top or that thing should be on top. Instead, it’s just, gut level, does this feel right? Does this feel like it’s going towards your website. If not, I was at wrong. Is it too much of this or not enough in that?

We’ll sort of tackle look and feel in this little Photoshop thing and we’ll start tackling information design in Sketches. If we have more complicated user workflows, for instance, we were doing a medical site recently where people had to contact their doctor about something. It could be any number
of things, or making appointment with the doctor’s office. Those can be pretty complex workflows. How do you get through the process of selecting which doctor you want, selecting the location you want to be at, choosing the date and time of your appointment. These actually turned into fairly complex
processes. For that, we might want to use a workflow diagram that a user can do certain steps and make certain choices that diverge their path and we can describe that process through the workflow diagram. That’s the fastest way to get to that.

Unless it’s actually showing aesthetics, we’re less concerned with it being a beautiful object than just the quickest path to communicating the idea. In getting in front of a client as quickly as possible, get their feedback on it and start iterating quickly. For information design also, once we do
this paper sketches, we don’t invest a lot of time in them. It’s just to get the first idea out there. Once we talked to a client about it, instead of revising paper sketches which seems like a pretty stupid thing to do when you’re building a website is we start getting into code, so like, “All right,
we have agreed that this rough sketch is the right direction, let’s take this and the comment you had on it and start writing HTML and start writing CSS and get some very wireframe-looking prototypes together.

Now, we’ve got a thing that’s responsive so it better communicates the layout. We’ve got a thing we can click from link to link and click around the website. You start getting a better sense of workflow in your information architecture so it starts incorporating those user workflow diagrams we might
have worked out earlier. Now, we’ve got the older deliverables fall away and now this prototype is the culmination of deliverables. Eventually, we can bring in look and feel and turn this into fully functional design comps.

What’s really nice too is that because they’re prototypes, because they’re interactive, we can run user testing on them very early. Especially since we use a starter kit, we’ve got this thing called Stubble which is how we start every project ever at Bearded. It’s on GitHub so people can look at it
and use it or just reference it, whatever they want from it, critic it and give us a hard time about it. That’s fine too. Make a pull request if you so wish.

Justin Avery: Or just create loads of issues.

Matt Griffin: Yes, or just make really funny issues. I’m okay with that too. I like the jokes. We’ve got this very quick start to getting wireframing a prototype because all wireframes look the same as far as we’re concerned. It saves us a lot of time getting that up and running. Every
point in that process, the whole goal is to get a thing that more accurately represents the final product and if possible, makes progress towards finishing the final product like if were writing HTML, let’s hope that’s the final production of HTML ultimately once we have refactored [in the launch 00:33:11]
and then get in front of the client and make sure it’s good and then start rolling the revisions into the next iteration of the process.

If they give us feedback on wireframes, we’re going to roll those into design comps which are built on the wireframes. They give us feedback to Sketches. We roll that into the wireframe prototypes. I think that just making things efficient and iterative when you have these big complex problems is the
key.

Justin Avery: Rather than a giant big reveal after a month of …

Matt Griffin: Yes. I think we all know that’s fraught with peril and that’s how we used to do it, like we disappear for a month or two or three and design these elaborate Photoshop comps and then like like print them out, paste them to Boards LOL and then like messenger it to your client
or whatever. That’s what we were all doing early on. It’s really dumb. It wasn’t making the web. It wasn’t making websites. It’s making pictures of websites which aren’t the same thing.

It was a beautiful lie we were telling ourselves when we were designing the web and then trying to recreate that representation of a web in the web afterwards, having to rebuild everything and unbreak it everywhere. Those are really silly way to build things. I think, now, the quicker we can get into
the medium for which we are designing the web and HTML, and CSS, and JavaScript, the better off everybody is.

Justin Avery: You’ve written quite a bit recently … I think it’s funny, you were talking about when you’re working with someone back when you’re just getting started and now, that were reading A List Apart, like, “Oh, what’s that? Oh, separation of content,” and then
you’re writing for&nbsp; A List Apart. How cool is that? [crosstalk 00:34:50] That’s just like a big tick. I made this [crosstalk 00:34:55].

Matt Griffin: That blew my mind, honestly. Several people asked me like, “How did you start writing at A List Apart?” I mean, the honest to god answer is I went on the website and clicked the link for submit and read the guidelines and started submitting stuff. I’ve been writing blog
posts for 1-1/2 years for about the Bearded blog. It was just like a Tumblr we had and then I just thought, “You know, it would be so cool to get published on A List Apart.”

I had one blog post. It was a blog post, it was kind of what I was saying earlier about like pictures of websites. It was the moment we decided, “Okay, Responsive Design means we need to be in code faster. We’re not going to make Photoshop comps anymore. We’re doing everything writing code.” We made
a firm decision. We were only like five or six people so it’s easy to just decide that one and do it.

I wrote this blog post and I was like, “I need to get this happen now. This feels like the right moment to say this.” I said, “Here’s why we’re making the switch,” and finally, I’m so happy about it because finally it feels like we were designing websites instead of pictures of website and that feels
great. I put that out there and I got a huge amount of attraction for one of our blog post. I forget what the traffic was, but it was a lot more than we’re used to. Even, I had people from Australia contact me and were like, “That was a great blog post,” and like, “Neat, Australia. That’s cool.”

I went to the first Build Right. What was it called then? The Sparkbox, build responsibly. Pittsburgh was in their first round of cities, their first tour anyway. They came to Pittsburgh and Ben then contacted me. He had known about me from something, that blog post probably. He asked me to be on a
panel with some of the other folks around here, Jay Fanelli, from at that point United Pixelworkers, now Cotton Bureau; Val Head, who people know from the books she has written on animations. She’s in animationer. She’s speaking at A List Apart now but at that time, we’re all a little more undercover
than that.

We all went into this panel and I remember somebody coming out to me at that thing and we’re just chatting, whatever. He was like, “Yeah, I read this really great blog post that was about designing in the browser and how it’s really important to design websites and not pictures of websites.” I was
like, “That was my blog post.” He was like, “Oh, really? That’s weird,” like, “Yeah, dude. You think it’s weird. That’s weird for me.”

Anyhow, I think that was the point where I was like, okay, like people are reading this and care about something I’ve written. Maybe I should try something like A List Apart. Wouldn’t that be cool? It was just the best place I could think of publishing, like where can I publish … If I could publish
A List Apart that would be crazy. I started submitting there. I also started submitting in Net Magazine which I appreciated a lot. My cycle was just I would write a blog post, I would submit it to everybody, I would wait a few weeks and if nobody got back to me, I’d publish it on my blog.

I did that a bunch of times to A List Apart, maybe three times or something. I didn’t hear anything initially with my first submissions, just no response. I found out later actually they were sort of like in transition with editors and I think things just got … Normally, they’re good about responding
but it was silence at that point and someone was on the way out, whatever. Then, one day, I’m in this client meeting and I came out and I had this email on my phone and it said, it was from Jeffrey Zeldman and it said like, “A List Apart hearts you,” or something like that. It was like the nicest thing
and I opened it up and it was exactly what you thought it was going to be.

We love your article. We want to publish it in two weeks. Here’s some information for you about that. Here’s how it works. Are you okay with that? Of course, I’m like, “Oh, my God.” Jeffrey Zeldman from A List Apart. Can’t wait. This is it. This is my moment and wrote him back. We actually had a long
email exchange. It turns out he went to high school in Pittsburgh and then he went to Indiana University when I went to school and also played bands there like I did. It was just like we did a lot of similar things about ten years apart. We had a really great conversation and the whole time, I’m like
about to pee my pants because it’s Jeffrey Zeldman.

I can’t believe that I’m getting this article published, and so they did and then after that, they knew who I was and they’re just much more receptive. I would send them an article and they would respond instead of just saying like yes or no. At that point, they’d say like, “Okay, we know you like
your writing.” Jeffrey said really nice things like we really like your writing style, or whatever. They would write me back and they’d say, “Well, we like some things about this article but it’s not quite ready yet for us. We think it should be more in this direction.” This would usually be like Sara
Wachter-Boettcher, I think.

Justin Avery: Yeah.

Matt Griffin: It’s how you say it? [crosstalk 00:39:36].

Justin Avery: I can’t pronounce it either, but yes.

Matt Griffin: She’s told me before and I know I butchered it. I should know it by now, but anyway, sorry Sara.

Justin Avery: Sara [crosstalk 00:39:46].

Matt Griffin: Sara [Bunch of Letters 00:39:49] is one of her pseudonyms also. Sara would respond to me at that point and say like, “We like this. We don’t like that. What if you try this direction?” By the way, I know that’s a big thing to ask of you. If you don’t want to change it,
that’s fine but then we’re going to pass on it. Of course, what, like I’m going to pass that? Sure, no, I don’t really feel up to it, Sara. You’re right. I’m really going to stick with this original idea. You guys should pass. I’m not going to do that.”

I worked on it and that first big article I had with them which was, what was it, it was like getting signed off without comps or something like that. It’s basically my designing in a browser article. It took me like two months, I think, to get that editing finished, because Sara, she was just merciless
in a really great way, as she would keep coming back and saying, “You haven’t quite got it yet.” I think I rewrote 90% of that article by the time it was finished. We really just tore it apart again.

I remember it over Christmas, actually, visiting my mother-in-law’s house with my family and just like writing. Sara is going to be so embarrassed to hear this but like writing through Christmas, trying to get it right and get it back to her. But finally, it did. It was finally good enough and then
it was a whole lot better than when we started. She’s an amazing editor and then it got published and then I did that again and it was a little easier the next time. It felt like I wasn’t getting the right [inaudible 00:41:12] as much but really, I was just learning to be a better writer and self-edit
a lot better.

She was just kept doing that and then at a certain point, I was leaving on vacation with my family for something. We’re driving away. We stopped for gas and I was waiting for the gas and being unable to disconnect from the world at that point, I’ve checked my email while the gas was filling. I saw
this letter from Rose Weisburd who was one of the other editors I worked with at A List Apart. She was a wonderful editor, and she said, “We love your new article but we’re thinking that you’d be a really good candidate for this new thing we have called columnists. We would like to give you a call on
A List Apart and you would write every month or two. You would write something for us on a subject of your choosing. Think about what you want the subject to be and if that’s something you’re interested in, we’d like you to do it.” That was actually the next moment where I was like, “Oh, my God. That’s
it,” like holy cow. They want me to do this, like they really like me.

Justin Avery: It’s a family thing now.

Matt Griffin: Yeah. Now, it’s like not job to job or article to article, waiting to see if they’re into it. They’re just saying they like what I’m saying and want me to do it all the time. That was hugely, I mean, it was like very validating but also very humbling like, wow, like I
really looked up to A List Apart since I started being a professional web person. Now, I get to be part of it. That’s a big …

Justin Avery: That is very gold. [crosstalk 00:42:41]

Matt Griffin: It’s like being part of your heroes in a weird way but also a lot of pressure that like, “I better get good at this because …”

Justin Avery: It can cause [inaudible 00:42:48].

Matt Griffin: I don’t want to ruin A List Apart. Not that I have the room to do that but like you want it to be at least up to par. I mean, like John Allsopp of A Dao of Web Design and Ethan Marcotte’s Responsive Design article. These are like [crosstalk 00:43:03]. Yeah. These are things
that changes the web and I don’t think I’d ever going to do that. Now, in some small way, I’m a part of that institution. That was just very exciting for me.

Justin Avery: If anyone that’s listening wants to get in on this, if you go to alistapart.com/about/contribute or in the menu at the top. He’s got articles, columns, blog events, topics, and write for us. They are very receptive. I submitted an article last year. One
of my things I wanted to do is write for A List Apart and it didn’t happen but I did submitted an article idea and the same thing happened. They didn’t get back to me immediately but they did come back and say, “Look, your way of targeting is too narrow. Could you try and open it up a little bit, how
this affect this,” because I just had a child and I wanted to write about how difficult it was to stay so involved with the web when all of the sudden another responsibility is thrust upon you. But of course, this was only targeting new parents and it wasn’t why, and that’s not the majority of the audience.
It had to be opened up.

I never went back and opened it up. I will look at it one day but yeah, they are great. They do feedback on everything. They do take some time sometimes but then I imagine they get a few submissions. If anyone is keen on writing for them too, just send [crosstalk 00:44:30].

Matt Griffin: Absolutely. You just jump on it and just … I mean, if I had waited until I felt like I was good enough to be published on A List Apart, just made to A List Apart, I never would have done it. Honestly, I wasn’t good enough to be published on A List Apart until their editors
worked me over for a while.

Justin Avery: Yeah, and over Christmas. Well done, Sara.

Matt Griffin: Yeah, right. That wasn’t Sara. That was all me deciding to do it over Christmas. I had many months of time that I could it but I’m a much better writer because of those people. I’ve learned an intense amount. Now, I mean, when I submit my columns, Rose does a much lighter
touch and I just could have learned the ropes. I know how to write a tighter article now.

Justin Avery: It is. I’ve read your columns that comes through all the time. They are great. One of the ones that I really did enjoy was the readable wearable stuff.

Matt Griffin: That was a fun one.

Justin Avery: Yeah. Seeing this is rare, like this is timely. How weird is this? This is a Responsive Design podcast. You are talking about designing for watches or small faces. Actually, I wanted to raise this anyway is that last week, during the Environment for Humans
CSS Summit, I used one of your approaches to writing SASS with the mix-in, the heading mix in which I saw you talked about [crosstalk 00:45:46] last year. I was like, “That’s such a great idea.”

You’ve got it in this article as well but I know it’s difficult for people to hear an article but what were the type of things that you were looking at when it comes to designing for watches or designing for small screens?

Matt Griffin: I think it’s worth mentioning too that heading thing isn’t exactly something I came out of my brain. Certainly, I adapted but I’m pretty sure, my recollection is that a developer was working with us at the time. He was our first hire, Dominic Dagradi, who then went to
Heroku and now, has actually started his own service called linebreak.co. He’s a very talented fellow and he instituted that heading thing.

I remember him explaining it to me the way I explained in the article which is, “This might seem a little overwrought at first, but bear with me. You’re going to see why it’s awesome in a minute.” I told him this recently when I was visiting him in San Francisco that that was his thing and he said,
“I have absolutely no memory of doing that.” One of us is wrong but I’m going to try and throw some credit his way anyway. I’m sure he was involved in it in some way. But the idea … You want me to describe the heading thing?

Justin Avery: Yeah, I mean, the article that eventually, if you go to alistapart.com, the link will be in the show notes but it’s about readable wearables and how you design for wearable devices so that you can read the content, just some of the things that you touched
on and like your thoughts around designing for this whole new wave of device.

Matt Griffin: Much like when I wrote that blog post about it’s time to start designing a browser, basically. I had that similar built-up feeling where it was like this feels like the right time for this article. This feels like time to start addressing wearables. There have been enough
background chatter in my life that I thought, “Okay, it’s time.” I went on Amazon, did a little research, looking around various articles to figure out which wearables had browsers on them where I could actually pull up a site and found the Samsung Gear S which had a couple of browser options, sort of.
[inaudible 00:47:48] I had this like I think it was the GearWeb or something that someone made it just basically a plain text browser. Then, the Moto 360 which also has a whole browser on it.

It was fascinating. It was so much fun. It was the most fun I’d had writing an article in a while because I got them all setup, strapped those watches to my wrist and just started playing with the Bearded website which right now is a very simple website. It’s just two pages and not a lot to it. It
is a nice, simple problem to tackle in a very new environment. The first thing I did is just pull up the site on my watches and see how bad they looked.

The first response I had was like, “It’s actually not that bad. Hooray, responsive data line; hurray, fluid layouts and hurray, progressive enhancement.” It’s not bad which is what Brad Frost said when he pulled up TechCrunch like, “Well, it’s okay.” It could be worst for a thing we didn’t know existed
when we built these sites. I started playing with them and my first reaction is we’ve been starting too large. That when we’re resizing our browser while we’re designing things, I was starting at a width that was too wide. My idea of small wasn’t small enough.

We were starting at, I don’t know, around like 350 or something like that. There are noticeable things that happened when you get smaller than that like our headings were too big. The headings just took up way too much size. They’re too much for the screen so like our headline for the site went off
the screen. The whole sentence didn’t fit on and the first word, informed, with a big margin on the left did actually bled off the screen. I’m like, “Okay, the word doesn’t fit. That’s kind of a problem.” Maybe we could do at some smaller headlines.

But I also noticed was that our smallest types stuff that was set at 1em also felt too small. The big stuffs felt too big, the small stuff felt too small. I thought, “That’s weird. Why is that? Why would the small things feel too small?” What I realized wearing the watch for a day and looking at websites,
was that with a phone, the key difference between a watch and a phone, my first statement was a watch is attached to your wrist. That’s not exactly the problem. The phone is in your hand which really isn’t that much different distance wise from your face. But the phone is held in your palm and most folks
strap their watch through the outside of their wrist. There’s a big difference if you have the face on the inside of your wrist. I think a lot of folks have their face in the outside of their wrist.

When you’re doing that on the outside of your wrist, the action to look at a watch screen is to, you can try this at home, you hold up your hand like you’re checking the time and you’re going to tend to hold your arms straight out from your body and then bend your elbow at 90 degrees and then look
at your watch. It’s about, I don’t know, eight inches from your face or something like that or 10 inches, whatever. That posture, if you hold your arm there for maybe one or two minutes, the time to read a web page, you’re going to notice that if you’re anything like me, your arm starts getting tired
pretty quickly, that your biceps are, that’s about the end of my knowledge of anatomy, sorry … Start getting tired. I know one muscle.

If you have your phone in your hand and you flip that arm over, you’ll notice that the first thing that happens is while you flip your arm over, your elbow goes down into a down position and that your bicep stops hurting. In fact, if there’s a table in front of you, your elbow sits very nicely on the
table while you’re phone is at eyeball height. What you find is when you’re looking at a screen on a watch for more than a moment, you’re going to flip it down. You’re going to lower that elbow down to the table or down to the lower height where your arm doesn’t hurt and that’s going to bring the watch
face away from your face. Even though it’s a smaller screen, if it’s for any length of time, you’re going to be holding it further away from your face in the phone which means the small type gets smaller. It’s further away from you.

That was really a fascinating thing for me to realize is that that very physical user experience and body positioning of the device changes how you operate it and changes what your type size is further away from your face, smaller. What we ended up doing was normalizing size. I had this recollection
at that point of my first design job and my boss telling me about doing work in 80’s where she was specifically designing for Xerox copiers. It was some special copier where you could do a little bit of formatting. But all she had at her disposal for design was a little bit of type size, bold, italic,
caps, no caps, maybe that was it. That’s how she had to format a document. Those serious constraints were really … It was a fun problem to deal with, right? Like how do you break up a large complex document with no color, caps, bold, italic. That’s all you got.

This reminded of me that problem. I thought, okay, type size is gone. I have a little bit but I think maybe I have from like I can’t do 1em anymore so my minimum size is maybe 1.1ems and my top size is, I don’t know, maybe 2.5 or 2ems? Let’s say something like that. I have a pretty limited type dynamic
range for my size. I can only go so big and so small. What else do I got? I’ve got bold. I’ve got italic. I’ve got color. I’ve got caps. I’ve got small caps even though it went pretty junky most of the time in a web browser and just start to like iterating on that like what do I have left if I lose size
for headings? Then try to come up with a decent visual type hierarchy ranging from H1 to H6 or at least on H5 because I really use H6 with that limited dynamic range where you could still tell the headings apart and the smallest headings were still clearly headings above a paragraph size.

That was like a really fun exercise and so what I ended up doing was having these more limited base level heading styles and then building up from there. I put media queries in the heading styles that set it back to my standard sizes where I could get really big and get a little smaller. That was a
really neat realization and because I used that heading trick that you were talking about where basically, all my heading styles come from heading base mix-ins that I then roll into the headings and into other things which is nice because it means, if you want to make an H5 look like an H3 or an H3 look
like an H5, you can do that. You just throw the mix-in on it that styles it like the other heading.

It’s all coming from one centralized place. Because I’ve done that very centralized mix-in Sass-based thing, it was really easy to go add those media queries into them and add the base level styles to them and suddenly, my site just worked. Wherever I told something that looked like an H4, now it looked
like the new H4 on tiny, tiny screens.

Justin Avery: Yeah, that’s really cool.

Matt Griffin: It came down to primarily the typography thing but there are some other things that I started playing with too. A spacing was a thing. Grid layout was a thing. We started with a three-column layout on our profile images of the people that worked there and that three-column
looked real bad on a tiny screen. It looked like 200 pixel or 180 pixels but the names are all broken like the pictures were just dots. I thought, okay, I guess I got to start a two-column grid, little stuff like that.

Justin Avery: Pump them up a little bit. Because the … Well, usually, when we’re building typography over CSS, we always go the mobile-first approach or you’ll declare styles which you then build upon as your viewport increases but we usually start with, like you said,
the body styles is 1em. All the font size is 1em because you have to go smaller than that for this. Do you then set like a max-width media query for things under a certain thing and so it go against the grain on that? Or do you just declare a slightly larger one for the next minimum query?

Matt Griffin: I think I misunderstood what the question was there.

Justin Avery: Usually, we would set the body size to 100% and then we would set paragraphs and stuffs to 1em. That would pretty much be stable between from an iPhone through to a super, super 4K display. We wouldn’t change it too much. We might change the body but with
the watches, we’re actually going smaller and like really specific sizes for the headings and stuff which probably wouldn’t naturally grow as you’re going larger and larger.

Matt Griffin: Right, got you. Yeah, what I do is I don’t mess with the body font size at all. Well, actually, I do. As I said, I just scrolled to the part of the article where I said that I’d do that. That’s hilarious. Yes, that is it. I haven’t read my article in a while. One thing
that I suggest in here, I didn’t know I did this. This is like me and Dominic, right? [Crosstalk 00:57:06] published in an article that I started with saying HTML font size 110% and then at breakpoints small which is going to be around 290, I think, which is what I said on this one, which is not device
based. It’s arbitrary … Well, it’s not arbitrary but it’s based on where things started to look okay, instead of reset it back to 100%.

That was one way to go, to just get everything a little larger and that way, I don’t have to go about … Oh, now, I remember why I did it, that you don’t have to go about saying paragraph 1.1em until breakpoint is small and make it 1em and then do the same thing for lists and definition lists and
then every other weird thing because you’re going to forget some … Like you’re going to forget definition list and then at someone point, if someone is going to add a definition list and you’re going to be like, “Fuck, it’s too small.” Right? Like you might as well just fix the base level font size.
Then, the headings are more specific. Man, you’ve read my article more recently than I have. I don’t remember any of these.

Justin Avery: No, I didn’t even scroll down that file. I was just thinking [crosstalk 00:58:08]

Matt Griffin: You’re just guessing.

Justin Avery: How would that actually work? What would you do [crosstalk 00:58:12]

Matt Griffin: That’s great. That’s the part you have to know the answer already.

Justin Avery: No, I didn’t know the answer but the thing is you’ve forgotten the question had already been asked and that you’ve answered it. That’s the weird thing.

Matt Griffin: Oh, I should have prepped for this interview.

Justin Avery: Me too. This is bad.

Matt Griffin: Thank you for asking that question and reminding me of how I did it. I’ll make sure to do it correctly on the next site we build. The reason for that is that … I mean, this is something that I found in general with the web is the more flexible and broad reaching your
solutions can be, the less likely you are to get bit by it later. If you’re going around and making like font size 110% until breakpoint is 100% on paragraphs and then you do it again on ul’s and ol’s and dl’s. At some point, that’s going to go wrong either because you’re like forking that rule and you’re
going to change paragraphs and forget to change the lists or because you left something out of that rule and it’s going to get messed.

Justin Avery: I supposed it’s a great thing about having that thing called … Oh, jeez, my words today. Great thing about having Stubble there. You say you have that base all the time. You don’t have to think about what you’re doing. It’s just sort of there and already
set out for you.

Matt Griffin: You fix it once and forget about it. If you fix it once, fix it everywhere. How many website have we all made? I mean, there are just so many times and that’s why we came out with a starter kit because we were doing the same thing over and over and over again like how
many times had we implemented the hamburger menu that you click on and a drop-down menu falls down and like, “Oh, god, we have to go do that again.” Just throw it in Stubble, guys. Come on. Let’s never think about that again.

Justin Avery: It’s just going to be how we do it forever and ever.

Matt Griffin: Right and then maybe, occasionally, we change it or there may be a point where you realize, “Oh, that was really stupid. Let’s stop doing that,” like the point where we realize like just the hamburger icon is maybe not a good idea. Maybe you should put the word ‘menu’
in there. That’s more understandable to people. Then we just change it in Stubble and now, every website. Their default is there and if we want to deviate, that’s fine but like let’s make our frequent decisions lasting.

Justin Avery: No, that’s a good motto.

Matt Griffin: I’m glad you like it. We make a T-shirt at Cotton Bureau now.

Justin Avery: Yeah, I love Cotton Bureau. I’m glad you mentioned that. They’re really cool. You do have a really good Bearded T-shirt. Actually, I’ll put that in the show notes as well. I like the Bearded T-shirt from Cotton Bureau.

Matt Griffin: Thanks. Yeah, that’s [Matt Brown’s 01:01:00] handy work, our designer here. He makes pretty things.

Justin Avery: Yeah. People always tell you that I put a Responsive Design shirt up there which I like but people like [crosstalk 01:01:11]. Yeah, they’re like, “I love the design.” I’m like, “Thanks. I didn’t do it.”

Matt Griffin: Yeah, right. [crosstalk 01:01:11]

Justin Avery: Someone did the design for me, they say, “No, it’s good.” [crosstalk 01:01:18]

Matt Griffin: I’m in the same boat.

Justin Avery: Yeah, I’m glad that … I’ll put a link to because I can’t think of a name at the moment. The last time we talked was over email and it was back 2012 when you did a Responsive Design interview series for me because I was going on holiday every Christmas.

Matt Griffin: Yes, a book.

Justin Avery: Yes and it ended up releasing as a PDF and everyone was really nice and said, “Yes, absolutely. Put me in there and you can charge for it.” I was going to give it away for free and people encourage me to charge for it which was wonderful.

Matt Griffin: Yeah, you get paid for your time.

Justin Avery: Thank you for everyone. Shoot, I didn’t pay any of the people that did the interview.

Matt Griffin: I think you probably had … Knowing being on the other side of things like that, I think you had more work than they did.

Justin Avery: Oh, man, I only get to a point on that too. Now, what we did talk about though is you came over a couple of your favorite RWD sites which was Polygon and another one from Lorenzo Verzini?

Matt Griffin: Verzini, that guy is amazing.

Justin Avery: We also talked about what you wanted to see like what was missing. Of course, it was 2013 and we didn’t have responsive images and that was the thing that we needed and we’re 2015 and what have we got?

Matt Griffin: We’ve got responsive images.

Justin Avery: Hooray.

Matt Griffin: Yeah, thanks to Mat Marquis and everybody else and the responsive images and now, Responsive Issues Community Group. Good job, guys.

Justin Avery: Awesome, Eric Portis. How do you think it went? Are you happy with the solution?

Matt Griffin: Yeah, I mean, I wasn’t part of that effort in any way so I did not experience any of the drama firsthand of that process. I’ve heard lots about it especially over the course of making the film I’m working on but yeah, I’m certainly not the person to comment on the process
but with the result? Yes, I think, what’s interesting is … I’ve been talking to a lot of people making this movie and this issue has come up many times. It’s a great representative issues of the developer community talking to the standards community about how to make the future web together and have
developer input.

I think there were plenty of hot drama in there but at the end of the day, I think everyone is happier with what they ended up with than what either of them proposed. I think if Mat and Dave Rupert and everyone else who was involved in these early proposals, Filament and all those folks got exactly
their thing. I think they know now that that’s less good than what we have. Likewise, when you talk to people on the browser end and the standards end, I haven’t directly touched people who was pushing for Source Net but I think everyone agrees when I’ve asked, “What do you think about what Source Net
people think?” I think everyone would agree that what we got is more effective than what we started with even though we might have gotten a little hurt in the middle there.

Justin Avery: I think it’s a great solution. I think people are doing very well and Picturefill 3 is coming out. They’re working on it at the moment. I noticed a couple of weeks ago that Edge, the Microsoft’s new browser have incorporated the W descriptor and the sizes
descriptor to fully support a source set implementation so it’s so good to see. Do you think anything is missing still now?

Matt Griffin: I mean, I think images are in good shape. I’m in many ways happy with Picturefill. We’ve been using that for years now.

Justin Avery: I mean, in terms of all of [crosstalk 01:04:45] in terms of building the web to that.

Matt Griffin: I think the most obvious thing I think the Responsive Issues Community Group is now campaigning for is container queries which came out of the idea of element queries. Element queries was the idea that, I’ll give you basic use case in case you will. First of all, go to
A List Apart. Read Mat Marquis’ article that’s there right now about container queries. It’s a great article. But element queries was the idea that, okay, most common use case you’re going to hear from anybody describe this problem. You’ve got some thing that you’re laying out with media queries and
you know that it goes to say like two columns at some widths and then three columns at another widths and it starts at one column on mobile or smaller, whatever.

That’s great and you want to design modularly so you’ve got this modular thing that behaves in a certain way based on its width. The problem is that it starts at one column. It goes to two columns and then it gets wider but now, it’s in a main content area and you’re trying to sidebar next to it. The
main content area just got smaller even though the viewport got wider, if you’re hanging with me on this. Now, you want to go to three columns because your viewport is wider but your containing element is actually smaller so you have to go back down to one or two columns and then wait until it gets even
bigger and now, finally, the main content area is bigger than it was before you had the sidebar and now, you’ve got three columns.

Your CSS for this ends up being nutty because it’s like you start at one column, media query to two columns, media query to three columns, media query back to two columns, media query back to three columns. That’s a big hot mess-up stuff that really what you want to describe is when this thing gets
to the right width, make it in an appropriate number of columns in this layout. The element query was the first proposal for this. Problem with element query was that it described itself by the size of the element. When my element is so wide, do these things.

Problem with that is if you say, this is a great example of developers and browser and standard folks working together. If you were to say, “When the thing is wide enough, make it less wide.” If you said, “When the thing is 600 pixels wide, change the width to 400 pixels. Now, you have an infinite
loop of rules to keep saying, “Make it smaller, make it bigger. Make it smaller, make it bigger.” That was the immediate response from the standard community was, “You can’t do that because if you do that, then no browser will know what to do with that. Try again.” They were like, “Oh, wow, that’s actually
super reasonable and we haven’t thought of that.”

In that case, switch it to the container queries which says, “When my parent is this big, do this.” They can do whatever you want. You can say, “When the parent is 600 pixels, make me 400 pixels,” and that’s perfectly valid thing to say. I’m hoping container queries, it seems like it’s on track and
I think that’s the next thing to solve. When we have that, then we can do truly modular designs and truly modular CSS where we say, “These are the rules for this module. Throw it wherever you want, it will do the right thing.” That’s going to be a beautiful thing.

Justin Avery: Yeah, that will be nice. One day.

Matt Griffin: I don’t think it will be long. The beautiful thing about the web and this is a theme that’s also come up in the film a lot is that the web is built with a backdoor to give us the things that we can’t have yet and that backdoor is JavaScript. The fact that we can have polyfills
and prolyfills for things that are not finalizing the [inaudible 01:08:18] yet to be build the things we want and then let them evolve, Picturefill is a great example. We’ve had responsive images way before we had responsive images. Thanks to [inaudible 01:08:28] JavaScript.

I think, it’s okay. I mean, there are sites right now that are live, big sites that are using effectively element queries or container queries. I’m pretty sure CNN is using them on their website.

Justin Avery: Really?

Matt Griffin: Yeah, no kidding. I was shocked too. I know that websites that were built that we helped out a little bit with Sparkbox working on a very large consumer product suite of websites that we used element queries on together. That’s out in the world.

Justin Avery: Wow, that’s very cool.

Matt Griffin: I’m not sure about nondisclosure stuff so I don’t want to identify who it is.

Justin Avery: Yeah, maybe we’ll check that and if it’s in the show notes, then you can go check it out. Our lawyers will run [crosstalk 01:09:12]

Matt Griffin: We’ll ask [inaudible 01:09:14] if that’s okay.

Justin Avery: Yeah, that’s really good. I mean, you’ve mentioned the video a couple of times. You ran that through Kickstarter?

Matt Griffin: Yeah. We started making a movie, a documentary film called What Comes Next is the Future. It turns out making movies is rather hard so it’s taking me a lot longer than I thought it would, which is a shame but it is going to be, I think, a good film. To me, that’s more
important. We started it. I started it because three things, I was on the schedule to do a lot of speaking in that year and I was on the bill with people that I really admired a lot that I thought have a lot of great things to say. Two, was that is just felt like a time when things were happening. It
felt like a lot of excitement in the air with web design because of noble responsive, the burgeoning in and out of things just felt like a watershed moment that I wanted to capture. I felt like I was capturing it. I thought if nobody else was, I might as well do it. Three was, I’d just gotten a high
definition digital SLR film camera so I could record things.

I just started carting around the light little set of gear and recording interviews with people and just asking them what seemed to be interesting questions and see what their answers were and I didn’t have a big plan for it. I got a bunch of these interviews traveling around and because I’ve been
traveling around and recording these interviews and getting people’s thoughts and people are so receptive to it. Nobody gave me a hard time about it. I really interacted a person with like Jeffrey Zeldman or Ethan Marcotte, who were quite happy to sit down and talk about the web with me in front of the
camera.

It started to seem like I was making a documentary about the web. I went about as far as I could without any funding and in between client work. I was able to put together a trailer for it and threw it on Kickstart and said, “Hey, web world, do you want this movie? If so, I’m willing to make it but
I needed a little money so that I can devote time and buy a bunch of stuff.” People agreed. We got a bit of funding and now, we’re making like a low-budget documentary about the web. It’s been amazing for me. The experiences I’ve had in the 1-1/2 year talking to people that I probably never would have
had access to otherwise and getting a really diverse range of very experienced and interesting perspectives on the web, and what the web is, and what it needs to be and what it can be in, and what it was, it has been really eye-opening for me. It has really changed how I think about the web.

I was lucky enough a few months ago to go to San Francisco and talked to some of the greats of UX Design like people like Irene Au who started the UX Groups of both Yahoo and Google. Indi Young and Peter Merholz who were founders of Adaptive Path and Kelly Goto who’s the founder of Gotomedia and basically
wrote the book on waterfall process. That was huge. I happened to just bump into Jonathan Snook at a conference while I was there and we ended up going out to dinner and then doing an interview which is Jonathan Snook of SMACCS fame, now who recently got Shopify. Before that, he was in charge of Yahoo
mail design [inaudible 01:12:41] SMACCS to help keep all those developers on the same page, lots of other developers.

Then the crowning achievement was getting to talk to folks from standards. I got to talk to Tantek Celik who was involved to some of the original CSS spec. He came up with the micro formats. He’s Indie Web Camp guy like amazing guy, intelligent guy. I got to talk to him. Then, ultimately, Tim Berners-Lee,
who we all know is that guy who created the web was like mind bending for me. To be able to sit down in realm with Sir Tim and asked him about the web and have him answer me on camera. Now, like that’s going to be in our movie.

Justin Avery: That’s awesome.

Matt Griffin: I know. I still don’t believe it. I actually don’t remember the interview at all. I was so anxious about it that I just sat there and like read the questions and just kept checking to make the sure the microphone and everything [crosstalk 01:13:44]. I had no recollection
of the experience other than like sweating profusely and watching the red light. I didn’t hear any of his answers. I just asked him the questions and let him answer and then go, “Oh, that was great.” Then asked him another question.

Justin Avery: Without spoiling any of the movies, they’ve been like an overarching opinion of the web that you’ve received for everyone?

Matt Griffin: Well, I don’t know if I received it from everyone but it’s certainly been formulated for me. I think, when you come down to understand and I don’t want to give anything away either but I think when you really start to get in to understand what is the value of the web,
what’s the history of the web and where has the web gone wrong in the past and what do we need to do to ensure the web goes right in the future and can deal with all these big problems we have. I think there are two big sets of problems the web is going to be dealing with. One is technical problems like
the mobile devices and the things. How do we accommodate these crazy changing technological world.

Also, how do we continue to serve on a social level really well? How do we make sure that people who don’t have access to information under other circumstances have access to this information that people like me when they’re young or underserved can find other people like themselves. That this all
comes down to really one thing for me, fundamentally, and that’s the URL. That that’s what makes the web incredible. It’s the killer feature of the web. Anybody can go hit that URL and get information that they need. Any machine can go and hit that URL too regardless of it’s operating system or browser
or whatever. It doesn’t need to be a browser like things can go hit a URL and pull that information and that’s the big power of the web.

I think we forget that a lot because we live in an era where the web is much like a utility. It’s very invisible. But one of the things that prompted Tim Berners-Lee to make the web is the fact that file formats were not exchangeable or operating systems didn’t talk to each other. He had a NeXT computer.
Other people at CERN had Apple and other people had PC’s and they couldn’t exchange files. This was a way to exchange information amongst everyone at CERN. The first thing he solved was the telephone directory at CERN. That’s how he got the project to go.

Justin Avery: He built an internet.

Matt Griffin: Right. Nobody wanted a web but like we all wanted a phone book so he’s like, “Okay, I’m going to build this phone book that’s also the web.” That’s where it begins. That was a monumental thing that some of these computers could talk to each other and that what’s fascinating
to me is we’re entering an era of the web or we have entered an era of the web that I think is actually really well exemplified by an article that Karen McGrane twitted about last night that I saw about a fellow who spent six years and he was a blogger in Iran that spent six years in Iranian prison and
then came out and was appalled at what happened to the web while he was gone. He was writing about extolling the virtues of the open web basically.

But this era that we’re in now of walled gardens and semi open systems where the walled garden of say, Apple’s app store or made applications in general let’s say Instagram. It’s this world that talks to itself without utilizing URLs in a particular way. You’re in the app looking at stuff in the app
and not breaking through that wall. Or semi-close systems like Facebook where people are putting in information that ultimately is controlled by Facebook. You have to login. Then you have to be connected to people to see their stuff. I mean, privacy is important but also so is the nature of the web as
this independent open entity.

When you take that away, you can’t just go hit a URL and get the information people are wanting to share with you that you hit the URL that says, “Go download this thing for this app store,” or whatever it is. You lose a lot of the power of the web both for people to be able to access things and for
all these for all these future machines that we’re cranking out to access them as well. The URL system is a really powerful universal system for solving a lot of our problems and it’s funny that we have to suddenly have to retain that. I think that’s becoming the central narrative of this film that we’re
making and it’s really quite fascinating to me.

Justin Avery: Have you come across that wonderful [inaudible 01:18:39] the URL as the thing?

Matt Griffin: No.

Justin Avery: Right. I’ll send you a link to it and it will be in the share notes as well. I talked at the Webby’s which is something that Craig Lockwood put together in Cardiff and the guy’s name escapes me. Anyway, it will come to me. It will be in the show notes. It’s
a wonderful, wonderful drawing and it’s free and you can download it. We had it printed up size A1 and put on the wall at work. It’s fantastic. It’s really good. But there’ll be a link here.

One thing that I quite enjoy and it’s more of a selfish and it’s a limited thing but this movie is about and these people are looking at the web as a whole and who has access to it and focuses on everyone that consumes the web. One of the things I love about it is the people who work on the web. That’s
more of a finite number but I think because we work on this thing which is so inherently open and we create that. Anyone that works on it somehow, I don’t think that we start off that way. I think we are molded. Maybe we do start off that way but everyone I talked to is incredibly open like yourself
coming on giving up an hour and a half to speak to me.

On this room we’ve had just email conversations and there are so many people that have been part of this podcast that have donated so much time to just have a chat and share their ideas and experiences when if I brought you into a corporation, people would be charging hundreds of pounds an hour or
thousands of pounds a day and things like that. But when it comes to sharing information with other common people, it’s just automatically, “Yes, of course, I’ll do it.” That I think is amazing. Yeah, it is really amazing.

Matt Griffin: I think that that originals [group 01:20:37] from Tim Berners-Lee and CERN to create the web and then to decree that it was copyright free and available for everyone to use forever. Set that tone for all of us to create this beautiful culture of let’s solve these problems
together. If I figure something out, I’m going to tell you how I did it. If you figure out something out, you tell me because otherwise, we’re never going to do this. It’s just building cooperation and noncompetitiveness there. That’s why I’m still here with web design. It’s a wonderful place to be.

Justin Avery: It is awesome. I think we’ll wrap it up there because we’re getting close to the time. Now, I’ve got these two things which I’ve got … Actually, it’s a couple of things but each week I ask a question of a current guest to ask of a future guest. We’ve got
a question from Nick Schaden who was the front-end developer for Get Pocket and his question was, has responsive web design change the workflow within your company?

Matt Griffin: God, yes. It changed everything. I’ve got a little story for you on this one. One of my favorite things about this story is when I interviewed Ethan Marcotte, I got to tell him this story and see his reaction to it. But when Ethan’s book came out, we bought it right away
as one does with A Book Apart book and it arrived and former employer of Bearded employee number one, Dominic Dagradi, took the book home overnight. He came back the next day and he walked in and I said, “Well, what do you think, Dom? Is this something we want to try out? Is this something worth doing?”
He said, “Oh, no. this is just how we make websites now.” I said, “Really?” And he said, “Yep.” And I said, “Okay.”

I took the book home the next night and read it in an hour or two because it’s a short book and I put down the book and I said, “It’s just how we make websites now.” Went into work and we all talked about it and said, “Stop everything. This is just what we’re doing. Whatever we’re working on right
now, we’re doing this now. We immediately started working on … Well, we have been working on the new Bearded site for two years or something. We just like kept changing it and not launching it and then getting distracted with client projects, those distractions the things that pay the bills and that
you actually do for a living.

We kept not doing it. We had all those Photoshop comps that’s like desktop [useless 01:23:09] thing and we’re like, “Forget it, Dom, just do it. Just make it up like make up to what it looks like on small screens and everything in between.” He goes, “Okay.” Dom was always game so he said, “Sure, yeah.
Why not?” He just meet up with the rest of us like [gave our 01:23:23] Photoshop comps and at the same time we’re building this website for a real estate development company where we just decided, “All right, we’re going to use media queries doing mobile view. What the heck.” It was already underway
as a desktop site. But let’s flip it and do desktop down and just have mobile view, desktop view and let’s go market that or whatever. Let’s just try it out. It’s better than nothing.

We did those at the same time and it was like we were just never going to go back. I saw so many tweets one time, responsive web design is the most fun puzzle ever and it totally is. Here we were getting super boring making elaborate Photoshop comps and desktop sites and then having to go and do it
all over again in CSS and HTML. I was sick of that and I was super excited when responsive came along and made us rethink literally everything about what we did.

Justin Avery: I love that story.

Matt Griffin: Funny, a follow-up to that … Oh, I got to tell that to Ethan, of course, as soon as … I love the footage of it because I’d get to the part where Dom says, “That’s just how we make websites now.” Ethan just loses it. He seems like both amazed and slightly embarrassed
that he’s had an impact on anyone.

Justin Avery: He’s such a humble guy.

Matt Griffin: Which says a lot about Ethan. I mean, he’s just an incredibly wonderful and of course, he’s the guy that gave us responsive web design. He’s such a generous fellow. Interesting story, then we were doing that stuff and we’re trying to desperately finish the Bearded responsive
site for a pitch for the Children’s Museum of Pittsburgh which would have been our first really commercial for a responsive site. At that point, nobody really knew about responsive design, at least in our area. There were very few commercial sites. I mean, there was the Globe. We went in for this pitch
and it was a super weird pitch because they actually invited everybody who was on the pitch into one room to ask their questions.

We were like interviewing with the other agencies. It has never happened to me before. It’s nuts. It was super awkward because the whole time I’m thinking, nobody else in this room knows who responsive web design is. I’m the only person here who knows what that is and that’s what I’m going to offer
them but I can’t tell them about it. They’re going to go look it up. It’s like the only time in my life it’s going to be a competitive advantage. We’d never done anything that big. We were still very small and we had good results with our projects but this would have been a big lead for us. We got through
that interview and then I came back.

We got called back. Luckily, I made a decent approach and we got called back I said, “Okay, guys, here’s what I want to show you and we had just slapped together the responsive Bearded site.” I threw it up on their projector screen and I said, “This is the new Bearded website.” They said, “Okay.” Then
I grabbed the edge of the browser and squished it down and the whole room gasped. I said, “This is called responsive web design and this is what we’re going to do for the Children’s Museum of Pittsburgh. Like that was it. I had the client. That was it. It was over. It was a beautiful thing because that’s
never going to happen again, of course. It never happened again I know you think after that but you knew that was about all.

It was so much fun to go in and do that and they loved it the whole way three. We made a calendar for them. I think it was one of the first commercial responsive calendars where we made it a list view on mobile and then expand it into a calendar layout. It doesn’t use tables which almost every calendars
are tables. We did these articles in sections and just laid it out like a calendar when it hit a large enough screen size. That was like, it felt like the wild west again. It felt right.

Justin Avery: Yeah, back in the days.

Matt Griffin: GeoCities again in a weird day and I feel like it’s been like that ever since. Since things got weird with mobile, it’s put us back to a truer place that’s really about the medium. It’s what the web … Somebody recently said, “The web’s response [inaudible 01:27:14].
It’s our job not to fuck it up. I think Jeremy Keith might have said that at a conference. It’s true like I hated tables layout. I hated flash layout and now, we’re back where we should have been like we got off track and now, we’re back and man, that’s a lot of fun.

Justin Avery: Yeah, thank, Ethan, you did well.

Matt Griffin: Thanks, Ethan, for fixing the web for us. Like I wouldn’t have lasted much longer. I think I would have gone and done something else within two years pretty sure because I was getting really bored and Ethan and mobile really shoot things up for us and it has been fun ever
since.

Justin Avery: It seems to be in the interviews that you’ve had so far, have people likened from the movement from tables to CSS or is it bigger than that?

Matt Griffin: It’s interesting, I think there’s a recurring pattern throughout the history of web design where we don’t have the tools we need to do the thing we need to do so we’ve just figured it out. We’ve come up with a thing. Life finds a way, Jurassic Park. It’s that thing. The
web people find a way and I think table-based layout David Siegel’s approach to creating killer websites was like that. I think flash was like that. I think M-Dot sites were like that. There have been lots of points where we needed a thing and we didn’t have what we needed so we came up with something.

I think what’s interesting is when those approaches like shims and those polyfills, those different approaches, when they get it right and when they don’t and what the underlying themes are there. I don’t want to talk about it too much more because that’s the movie I’m making.

Justin Avery: Spoiler alert.

Matt Griffin: Yes, spoiler alert but I think when we make things the right way before we have them, it leads the way to better standards, better web. We go the wrong way, it creates fragmentation and problems down the line. Flash being a good example of that.

Justin Avery: It’s good. Good point. Matt, you have the opportunity of asking a question of our next guest which is a lot of pressure on the spot, but if you don’t have one ready to mind, you can always email it through at a later date.

Matt Griffin: I think I’ve got for you.

Justin Avery: Yeah, excellent.

Matt Griffin: What’s the first moment that you feel in love with the web?

Justin Avery: Oh, that’s lovely. I like that.

Matt Griffin: Because I think we all have at some point and it’s really fun to hear for different people when that happens.

Justin Avery: Yes, I’m going to answer that now but …

Matt Griffin: Oh, yeah, please.

Justin Avery: It was really, really early like I’m sure it was GeoCities site. I think there were two bits. One is we really liked Army of Darkness. Remember the Evil Dead Three? We made an Army of Darkness fan site reaping off another Army of Darkness fan site for all
their images and hotlinked it to the site and put a hit counter at the bottom and just watched it soar like 20,000, 30,000, 50,000 [crosstalk 01:30:30] yeah. I think it was just potent. I think it was just an animated gif that keeps on counting to a million. Yeah, that was really excited.

Then there was another time shortly after that where I go to Notepad on the PC and just looked up, “How to write HTML” and wrote Header 1 and Header 2 and Header 3 and a paragraph and a list and then I made a link and I included an image and then I saved it and I had this thing which linked from bit
to bit and it was programming but it was really easy and just so exciting. That was it. I think that would have been ’97, ’98 it would have been and that was it. Caught.

Matt Griffin: Yeah, I remember that stuff. It was great.

Justin Avery: Yeah, I loved it.

Matt Griffin: I mean, I still do. I mean that’s lots of fun it’s like that Readable Wearable article. When I was doing that, that felt just like that. It’s like discovering the web again.

Justin Avery: Just playing around.

Matt Griffin: Through a different lens and that’s what so fun about the web is whenever we start getting bored, the web gets weird and you have to look at it all over again.

Justin Avery: The last three days, I’ve been playing around with the other responsive design site to get it running on HTTPS through CloudFlare and that’s just been so much fun.

Matt Griffin: There’s always something.

Justin Avery: It is. It’s just a challenge like I want that to be a green padlock. Why is it not green? [inaudible 01:32:03] the form isn’t secure and then you have to find another solution for that and no, so much fun.

Matt Griffin: I mean, that’s the beautiful thing. It’s like where there used to be a world of webmasters and that can’t exist anymore. The web is too complicated for one master and there’s always a choice of like what do you want to focus on next? What do you want to get good at? Are
you going to work on your command line skills and you’re getting really good at it yet? Or what? Are you going to still working on CSS animations? What’s your thing going to be this week?

Justin Avery: The most wonderful thing is that everyone who walks down that path has written about it and had written about their problems and how they overcame them and that’s how you learn from those people who have already tried that.

Matt Griffin: Yeah, I totally agree. That was one of the best pieces of advice I took from Jason Free [inaudible 01:32:52] in one of his books was if you’ve got something to say, write it down. Just always write it down. If it helped you, write it down because it’s probably going to
help somebody else.

Justin Avery: Yeah, definitely. I always say this as well to [inaudible 01:33:07] that even if you’ve read an article about like you’ve got this one on wearable devices. I have no doubt when I get a wearable device, I’m going to write one not because I’ll cover anything
different from you because there’s a very finite, very, very small chance that someone will read one of my articles [crosstalk 01:33:25] rather than a list of that article and they won’t know the list of that article was there but because mine was there, they found the answer that they needed. I’m all
for people to rehash the same thing because you have a slightly different take on the same problem.

Matt Griffin: The act of writing out something out requires that you figure out your thoughts that are in your head and organize your thoughts and that’s incredibly valuable. I mean, teaching is the same way. Teaching people something makes you understand it better. I went to read Anna
Debenham’s article about working at the Moto 360 that came out before my article. It was really helpful. I think probably hopefully I linked to it at some point. But it’s just yeah, everybody has got a slightly different take on things and there’s a lot to learn or maybe I saw it right after I published
that, I remember. But it was neat. She talks a lot about that round screen. It’s a son of a gun, that round screen, man. You can only read the whole line of text that’s right in the middle of the watch basically.

Justin Avery: Really? Over right to the other areas?

Matt Griffin: Yeah, it just cuts off the corners. One Screen makes a good watch, not so much a web browser.

Justin Avery: I’m reading here. I wonder if we get the CSS areas then?

Matt Griffin: What would I want? I want screen-type round and then just like threw us some margins on the sides.

Justin Avery: Well, sure you could mind, what if you make the buck … No, let’s not get into that.

Matt Griffin: Let’s stop right there.

Justin Avery: Let’s cut it there. Matt, that is a great question. Thank you very much for that. Thank you very much for joining me this evening. I know we’ve gone way, way over time but it’s been great. It has been really good.

Matt Griffin: Thanks. I really enjoyed it. It’s really great finally talking to you.

Justin Avery: Yeah, and you. Now, if people want to read more about what you’ve been doing, follow you on Twitter, do you have any projects, movies or anything that you’re doing that you want to tell people about?

Matt Griffin: Sure. You can always about Bearded at bearded.com. You can learn about the movie futureisnext.com. We have @futureisnext on Twitter. We have @beardedstudio on Twitter and my Twitter is @elefontpress, long story. Letter press thing, don’t worry about it. I think that’s
all the links.

Justin Avery: Awesome. All right, well, thank you very much again. Thank you for all the listeners for tuning in. I’m sure you enjoyed that as much as I did. Write this up to five stars if you feel the need to. That will be awesome if you could. We’ll see you again next
week. Thanks again, Matt, and we’ll talk to you soon.

Matt Griffin: Thanks, Justin. It was great.

Justin Avery: Cheers all, bye.

Matt Griffin: Bye-bye.

RWD Podcast Episode #37 : Ulrik Hogrebe (part 2)
57:47
2017-12-22 20:56:41 UTC 57:47
RWD Podcast Episode #37 : Ulrik Hogrebe (part 2)

Podcast Sponsor

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple’s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That’s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.

RWD Podcast Episode #36 : Karen McGrane
61:15
2017-12-22 20:56:41 UTC 61:15
RWD Podcast Episode #36 : Karen McGrane

Podcast Sponsor

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple&rsquo;s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That&rsquo;s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.

Transcript&nbsp;

Justin Avery: Hey, everyone, and welcome to Episode Number 36 of The Responsive Design Podcast. My name’s Justin Avery, and I’m your host and curator of The Responsive Design Weekly, our weekly newsletter that’s all about … you guessed
it … responsive design stuff.

This week I have another sponsor, which is Media Temple, MediaTemple.net. They’re a web-hosting
company, and they actually provide the hosting for this site, which is pretty cool. They’ve got a range of different things which they offer, different hosting services, so if you’re just getting started with your first website and you want a nice, easy-to-use WordPress site, they’ve got something for
you. A one-click install will get you started and running. If you’re thinking of delving into the dark art of the server world, you can get your own little dev box and install Linux and Ubuntu and build a server with Engine-ex and a whole bunch of stuff. It’s a lot of fun.

They’ve got all that sort of stuff, and if you’ve got a full-stack system or an app, they
also have dedicated boxes as well; so a full range of entry points for anyone at any level. I use them. I can’t recommend them highly enough, even if they weren’t sponsoring this podcast as well. They’ve actually got a special discount for all you listeners out there. If you use the code, RD25, you’ll
get 25% off your web hosting, and that is across all of those ranges of products as well. Go and check out MediaTemple.net.

Thank you for sponsoring the show, guys.

This week I’ve got an awesome special guest, which is Karen McGrane.

Welcome, Karen.

Karen McGrane Thank you. Thanks for having me.

Justin Avery: Thank you for coming on. This is like a crossover show if I could dare say, a responsive design pod-caster and her responsive design podcast.

Karen McGrane It’s like when the characters from Laverne and Shirley showed up on Happy Days.

Justin Avery: What is this? The pod-caster will explode. I want to talk about your podcast a little bit later on as well. We had Ethan on as a guest at one point, and I don’t think he was … You guys hadn’t actually started producing
or at least publishing the podcast when I was speaking to him, so I was really excited to see that he was doing something, and I was equally as excited that you were at the other … What is that? Host, isn’t it? We’re hosts.

Karen McGrane Oh, yeah, co-host, yes.

Justin Avery: For those listeners that aren’t aware of who Karen McGrane is, I was wondering, maybe just give us a bit of a background of what you do and how you got into the industry.

Karen McGrane My goodness. I have been working on the web since 1995, so my 20-year career here. I’m a long-time user experience and content strategist. I got my start working at an agency called Razorfish, where I started the UX group
there, and I worked there for about 10 years. When I left, I went off and started my own little shop and have been doing that ever since. Now I do a lot of independent consulting. I have done tons of work with publishers over the years, lots of big, mainstream publisher redesigns, and I spend a lot of
time now working with companies on really helping them manage their publishing infrastructure and workflow. Even if they’re not a traditional, mainstream publisher, helping them think like a publisher.

Justin Avery: Cool. When I think of publishers, I think of books, which is horrible, because I work in the web. I shouldn’t think of that way, but I think of large-style, large-scale book and publishing houses, but when you talk of publishers,
you don’t necessarily refer to those, do you?

Karen McGrane I guess I mean usually large-scale magazine and newspaper publishers. I work with a lot of companies that have one foot in print and one foot on the web. What I’ve learned from working with big newspapers or big magazines
in many cases applies pretty neatly to talking to organizations like banks or hospitals or universities or government, because they, to some extent, have a huge amount of off-line publishing infrastructure, and so much of that is moving on the web now, and they don’t really have the oversight and operational
insight into how to manage their web and digital publishing effectively. That’s what I do is help them go in and make sense of all that.

Justin Avery: That’s awesome. Do you think that they were getting ready for this when the web turned up, or have they all just …

Karen McGrane Oh, God, no.

Justin Avery: … missed it?

Karen McGrane No. No. To some extent everybody’s been, they’ve been hiding their heads in the sand for the last 15 years with the sense of, “Ugh, ugh, are we going to have to deal with … Oh, God, really? Maybe the web is just a fad.”
I think now with mobile really becoming such, the explosive growth of mobile is in many ways what has caused these organizations to go, “Okay, right,” like, “If we are going to maintain any sanity and get our stuff to work on all of the screen sizes and platforms that we need it to work on, we’ve got
to rationalize what we’re doing in print and what we’re doing on the web.”

Justin Avery: Are they still looking at it from two different beasts as well, like they’ve got a print problem … Not a print problem. They’ve got their print arm and now they need to improve their website arm, which involves mobile
and a whole bunch of other screens. Or are they combining the approach? Are you encouraging the combination of the two?

Karen McGrane Yeah, I think this is the inflection point. I talk to a lot of big banks, big financial institutions or large hospitals or large universities that, yeah, they still have a significant print infrastructure. They’re still
publishing magazines and brochures and white papers and things like that that are created for print and intended to live in print. Their print-to-digital workflow is in many cases that they publish a PDF.

I understand the organizational constructs that lead people to still have those silos in place, but now with mobile, you can just see them.

I want to say, I am actually probably the most sympathetic person out there as to why that
happens. I understand that you’re dealing with people’s jobs. I understand the organizational constructs that lead people to still have those silos in place, but now with mobile, you can just see them. They’re surveying the landscape of saying, “Oh, so now we’ve got to make our stuff work on desktop
screens but also on all these other screens.” Maybe this is the point at which we have to start thinking more agnostically and thinking more holistically about what we publish. We can’t be siloing our publishing efforts by channel anymore or by size of the document anymore. We’ve got to think of what
we create as something that has a fighting shot of being able to be rendered appropriately in whatever context we want to publish it in. That’s a huge shift, but that’s what I do, so there’s plenty of work for me.

Justin Avery: Indeed. There’s probably more and more as it comes on.

Karen McGrane Yeah. Yeah, it’s great. It’s been fantastic.

Justin Avery: I’m sure there must have been the same number of … I just moved roles now, and I’ve moved into a company that has a strategic arm and a creative arm, and within that creative arm they have creative writers, so they have
a writing side, and they also have the visual side as well. It’s amazing. It really is amazing to see that that much effort these days are being put into the actual words themselves or the messaging.

Karen McGrane I too am heartened by that. I wish it had always been that way. Let us look to the future and a world where everyone puts that much effort into the content and the messaging.

Justin Avery: I know. I know. If only. If only. You have worked on a ton of these projects over the time, but back to when you were saying you formed the first UX group, if you started in ’95, that would have to have been one of the
first … Did you call it “UX” back then?

Karen McGrane Yes. I started there in ’97, and yeah, when I started, I was the first person with any user experience or information architecture or content background, and the group, the initial group, we had an information architecture
group, and we had a content strategy group, and eventually we rolled all that up with visual design under one big user experience umbrella.

Justin Avery: Mm-hmm (affirmative).

Karen McGrane Yeah. I would say that was not atypical of the era. I definitely recall interviewing around in 1997. It’s not that user experience was well-established, but I think there was this growing sense that there was something
beyond graphic design and web development, like, that there had to be some other way of thinking about what we were creating.

Justin Avery: It seems to have happened a lot over the years; right? Since the inception of the web. We just keep finding these new roles which never existed, but then we’re like, “How did we never work with them before?” They’re vital
for the actual projects to move forward and for the web to be what it is today.

I think the web has suffered to some extent by this myth that websites are these things that two people in a garage throw together. For many organizations that I work with, it’s like, these are multi-, tens-of-million-dollar endeavors and every bit as complex as a major film

Karen McGrane Yeah. I sometimes make the analogy to film. If you look at the credits roll on any mainstream film production, it boggles the mind how many different roles there are, how many different types of people it takes to make
a movie. I think the web has suffered to some extent by this myth that websites are these things that two people in a garage throw together. For many organizations that I work with, it’s like, these are multi-, tens-of-million-dollar endeavors and every bit as complex as a major film, so why would we
not expect that new roles would emerge and that we would specify more precisely what someone’s task was on the project as a way of making sure that that important work got done.

Justin Avery: Yeah. That’s a really good analogy. Are you seeing anything at the moment that’s cropping up that will be 2016’s new hot job role or job title, like a lack of something or a refining of a role at the moment?

Karen McGrane Yeah. The organizations that I talk to, as they are implementing responsive design, as they are changing their processes in order to do responsive really well and recognize that responsive design now just is web design.
This isn’t like a one-time thing. This is a future thing. The sense that I have gotten from many organizations is that the distinction between design and development, there needs to be a greater overlap between something that traditionally has been thought of as two separate roles.

I’ve heard of a lot of organizations creating a new role that they call creative developer
or front-end designer or something like that. I guess I will say this edges into the whole, “Should designers learn to code?” question or designing in the browser. I think most of the organizations that I talk to say, “Look, it is simply not tenable to expect that every designer is going to learn how
to code, and that’s not what we are expecting. That’s not how we’re trying to hire, but we do need some people who can straddle both camps, who can put a foot in both camps, and so we’re going to try to recruit for those people.”

Again, I see that as a growth. I see that as new roles emerging. I see that as there being
a larger number of people working on the project, not that smart organizations are trying to replace their designers and replace their developers with one hybrid unicorn. That’s just a bad recruiting policy. It is. If you’re basing the success of your recruitment strategy on finding unicorns, you’re
going to fail.

Justin Avery: That is very true. What’s the knock-on effect for this, though? I totally agree. There needs to be more overlap between the designer and the developer, and you can’t expect … I would love to design a site. I’m a terrible
designer, but I can code a lot better, and so there’s equally opposite people in design. They probably would love to be able to code but their brain doesn’t work in that way or they’re just much better at designing. If we both work on a project together, it’s going to be a better project. Do you think
it’s going to cost more money to deliver that? Do we need to start charging more for these things, charging a less an hourly rates or a high project rate?

Karen McGrane This question of how to use scope and staff projects like this is fascinating to me. My sense is that it is a different way of working. For teams that or probably even better to say for lawyers and for procurement people and people who are writing contracts, teams that are really accustomed to working in a strict waterfall fashion, where design gets done and then handed off to developers, they may look at a process like that and go, “Well, this is going to be twice as expensive, because now you’ve got the designers
and developers working at the same time.”

I don’t really think of it that way. I think that the benefit of having a more collaborative
team, having teams prototype earlier and resolve some of the issues faster in the process, I think actually can result in a process that goes more smoothly and thus will be less expensive. Now, could people come up with a million examples, no doubt, of, “Oh, but I did a waterfall process, and it was
cheap and fast,” or, “I did a more iterative prototyping process, and it cost a million dollars, and we got nothing at the end.” Of course you can. Any process can be implemented badly, but I don’t think I would ever point to an iterative process and say, “Oh, you shouldn’t do that because it costs more.”

Mike Monteiro was on our podcast last week, and we raised this issue of how much does it
cost to do a responsive design. He was like, “Well, it’s going to cost you a thousand percent more not to do it.” That’s how I take it. It’s like you shouldn’t be comparing these things, because you’re not comparing apples to apples. You’re comparing, this is how you just need to work now in order to
get this job done.

Justin Avery: Are these things that you take in to … I jump all around the place … You do workshops with Ethan as well. Are these the kind of thoughts and I suppose organizational change that you try and impart as part of the workshops
that you do alone or with Ethan?

Karen McGrane Yes, exactly. I think what we have found in talking to lots of companies as they are anticipating a big responsive redesign is that for them the design and development challenges are to some extent the easy part. I’ve
had lots of companies come to us and say, “Look, this whole business with the fluid grids and the media queries, we got it. We can do that.” It’s all of the other stuff around how do you work, how does your team collaborate, how do you think about prototyping, how do you think about making decisions,
how you make the trade-offs among what content you show on which screen. All of that is, it’s a part of a responsive design process, but to me it’s just good web development. It’s just good user experience design. These are not things that you’re doing just because they’re responsive design. You just
have to do these things now.

Justin Avery: Yeah. No, totally. I’m sure the same is a lot of the listeners are facing these kind of issues in the workplace, working for agencies. It’s a traditional kind of waterfall approach and there’s the split approach where you
have to get designers and developers, and I can just sense the listeners are now just going, “Just tell us how. Just tell us how.” If someone was to start the change within their organization or within their agency, what would be the first thing that you would recommend they start working on as a small
change, small steps. A big bang approach is very difficult to do. Small steps are often best. What’s the key first small step to get going in this more collaborative environment?

Karen McGrane I think that, one of the things that I talk about in the workshops that I do with Ethan is planning your roll-out strategy, and I agree. I think for many companies the idea of a big bang is way too complex. It’s too risky.
It’s going to take too long. Honestly, I think one of the first things that I would say to work on would be figure out what your roll-out strategy is going to be. There’s different approaches that you can take. You could start with a page. You could start with a section. You could create a beta sandbox,
a mobile-only responsive site while the desktop site stays the same, and then you iterate on your beta site over time.

I think understanding the personality of your organization, understanding how that organization
makes decisions, what the internal risks are, like what would cause you to lose traction internally, because executives or stakeholders are looking at your responsive project and saying, “Well, this thing’s gone off the rails because we don’t have progress in this area.” I think being able to anticipate
how you’re going to do that, that’s the first place I’d start.

I would also say that honestly planning out how you’re going to get stakeholders involved
is a big deal, because the challenge that you’re going to have with an organization that is accustomed to reviewing PDFs, reviewing static mock-ups, like if you have to move them to reviewing a prototype, it’s different. They might be 100% on board with it. They might love it to pieces. They might never
want to see a static comp ever again, but they’re going to have to provide feedback in a different way, and so moving to a more iterative prototyping-based model doesn’t just mean getting your designers and developers more engaged. It means getting the whole organization working differently.

Justin Avery: Yeah. Yeah, that’s the hardest sell I find is around that traditional I wanted a PSD to sign off. I want to see the desktop version.

Karen McGrane Yep.

Justin Avery: That’s what I want to sign off and keep going. I’ve been thinking what I want to do is, because there’s the thing that I always see in Jeremy Keith’s talk, which is … and there’s the website; do websites need to look the
same in every browser.com, and of course there’s a resounding no, and depending on what browser you have, it looks like a different no. If it supports web fonts, then it’s a pretty no. If it doesn’t, it’s an unpretty no.

I was thinking the same thing surely goes for static comp as well; right? If you’re viewing
it on a windows monitor as opposed to a MAC monitor, the color is going to be different, so you see shades differently. Even if you printed it out, a printer will have less toner in a particular color and so therefore it will look slightly different again, or if someone’s color-blind …

Karen McGrane Like your projector, yep.

Justin Avery: Exactly.

Karen McGrane Like the projector that you have, it’s not going to look the same.

Justin Avery: These things are the same kinds of things as browsers. Browsers are just the output method and the screen. I disagree with the thing that they need a static comp because it then looks exactly the way it will, because everyone
… If you’re color-blind you will see differently from the person next to you. We have different eyes. Anyway, that’s …

Karen McGrane So true.

Justin Avery: That’s my rant. You’re doing a podcast now as well with Ethan?

Karen McGrane Indeed.

Justin Avery: It’s excellent. I highly recommend all the listeners to go and search for Responsive Web Design in iTunes; right? ResponsiveWebDesign.com?

Karen McGrane It is ResponsiveWebDesign.com. Ethan had that domain. It seemed like, hey, let’s put something there.

Justin Avery: He bought that a long time ago. He said, “I’m onto something here.”

Karen McGrane Yep.

Justin Avery: You guys have been nominated for Net Awards as well as Podcast of the Year. Congratulations.

Karen McGrane Indeed, yes. Yes.

Justin Avery: That’s very cool. Everyone should go and vote for either them or this one. Totally vote for this one, but I’ll understand if you vote for Karen and Ethan, because they’re pretty cool.

Now I’m just looking at the site. You have talked to 41 different companies about launching
responsive web designs and how it was within the company launching. Aside from what we just discussed then, have there been any reoccurring themes within companies that you found in speaking and things that just keep popping up?

Karen McGrane Well, let’s see. I think the themes that we try to touch on in every episode are things like how did you decide to go responsive, do you believe that mobile users and desktop users need something different, how did you
manage the design and development process, how did you manage your content strategy and how did you make decisions about what to keep and what to get rid of. We talk about performance. We talk about support, so how do they think about what they, quote, unquote, “support.” Then we ask people if they have
any advice for other people who are embarking on a responsive design.

I would say probably the most common theme that we ask about that we almost invariably get
people agreeing with is the idea that mobile and desktop users basically need the same stuff. I would say we’ve had very, very few guests on that say that they organizationally think mobile and desktop is somehow different or that their analytics data shows mobile users and desktop users want and need
different stuff. I would say pretty much across the board most organizations are like, “Yep, we did the research. We talked to people. We look at our data,” and consistently, people on every platform on every size screen want the same stuff, and I think that’s … To me, that’s the best argument for
responsive design that I could make.

Justin Avery: Yeah, absolutely. I sometimes find that the counterargument to that is that I’ve looked at my stats and mobile users are on the website less often. They’re there for not as long and they only visit one page and then they
leave, so they’re just there for short, succinct information. I’m like, “Are you sure it’s not just because your website is really slow and just built for desktop and they’re just leaving?” “No. No. That’s what the stats say.”

One thing that I would hear, what people say, “Well, why should we bother building a mobile website, because our
mobile traffic is only 4%.” Well, that’s because you don’t have a mobile website.

Karen McGrane Yeah. Yeah. I think there’s a lot of misinterpretation of stats, especially in the early days of mobile. One thing that I would hear, what people say, “Well, why should we bother building a mobile website, because our
mobile traffic is only 4%.” Well, that’s because you don’t have a mobile website.

Justin Avery: Yeah, that’s funny. That’s really interesting, though. It’s so refreshing to hear that of all the people, that pretty much everyone is understanding that mobile is the same. Just because they’re on a certain device, it
doesn’t mean they want different things. You tweeted the other day an article in I think it was CIO.com or something where it was a paragraph which says, “Mobile users, obviously always on the move …” and then it kept on going. I was like, “Ah, so frustrating. It’s just such a bad thing to be …”

Karen McGrane I agree. It is such a bad myth to be spreading, but yet it still … I guess it’s like the people who we talk to who have implemented responsive design don’t buy into it, but I think broadly in the marketplace I think
that myth is still circulating, and I think there’s probably a lot of people out there, probably with a dog in the fight, who have a reason for wanting to promote mobile as being something different. They’re going to make more money if they promote mobile as something different, so they’re going to sell
that as a concept.

Justin Avery: Yeah, well, mobile-only houses, like if you have a mobile-specific website on a mobile-specific platform, then with mobile-specific content, then that’s another business that can make money just out of mobile without losing
the responsive work and therefore the mobile work to another company that will offer the full range.

Karen McGrane Yeah. I saw some SEO guy writing, “So, yeah, you want a domain-specific strategy where you’ll have your m-dot site and then your t-dot site for tablets. Then in the future you’re going to want to have your w-dot site for
watches and maybe your tv-dot site for televisions,” and you’re like, “Dude, at what point are you going to realize that this is just not a tenable strategy?”

Justin Avery: I had written a very similar post to that around the end of the March, and I didn’t get a chance to finish it because I was going to release it on April Fool’s Day to say that Google had changed their minds, they were actively
now that Apple had released the watch that they adhered to and they thought that you should definitely get a w-dot domain for watch-specific websites and traffic, but it sounds like he was serious. That’s not good.

Karen McGrane No, no, no. I guess when you look at the world through only your lens, so if you’re the SEO person, he had a solid argument from an SEO standpoint of why they wanted device-specific search queries. It’s like, all right,
I guess that makes sense for you, but what about for all of the other people involved in making this website? Even if you can argue that you’re going to get lift in SEO from having this device-specific scenario, is the increased search traffic actually going to pay off? Is the cost benefit trade-off
of having to maintain six different code bases actually going to pay off for you in the long run? No. No, it isn’t.

Justin Avery: That’s such a good point. It’s not like the search engines are going to continue to go down that path; right?

Karen McGrane Absolutely not.

Justin Avery: It seems like they’re favoring more towards another way of building a site.

Karen McGrane Right. If there is one organization out there that is more invested in the idea of one URL and one page, it is Google. That is their entire way of seeing the world. While Google does not necessarily penalize m-dot sites
or other approaches, Google benefits if you serve everything responsibly. They like it if you just have one integrated, one set of content, one URL.

Justin Avery: Yeah. I’m all for it. I suppose the counterargument which I will point out now because I’m sure that the people who are anti-this, they wouldn’t be listening to this anyway, but their reason why everyone who you’ve interviewed
so far is, “Yes, you should have a single piece of content to serve everyone no matter what the device is.” Of course they’re going to say that, because they have bought into responsive design. It’s obvious. It is just the way to go.

Karen McGrane Yeah.

Justin Avery: It’s definitely the way to go. You do the workshops and you do these podcasts as well, but you also do a lot of other consultative work, like you’ve mentioned, and worked in a lot of large-scale successful projects. What
has been in the past few years your most or what you think is one of the most successful responsive projects, and what actually was the key to that success?

Karen McGrane Am I allowed to say, “ResponsiveWebDesign.com?”

Justin Avery: Of course you are. Plug.

Karen McGrane Because honestly, my best advice for people who are looking to do a responsive design is to have Ethan Marcotte build it for them. It’s worked out extremely well for me.

Justin Avery: Yeah.

Karen McGrane I will say, just as a plug [crosstalk 00:30:02].

Justin Avery: That is a great strategy, though.

Karen McGrane Ethan’s fantastic to work with and it’s just been such a delightful collaboration. It’s been really interesting to see how he does things, how he makes things work. That site is lightening fast. There’s a lot of things
about it that I’ve learned just from hearing him explain, “Oh, okay, I’m going to do this differently, and I’m going to tweak this.” Like, “Oh, look, now it loads before people even click on it. It’s amazing.”

Justin Avery: If I was to go back and do another chat with Ethan, he would equally go, “You know it’s the Responsive Web Design site. Do you know how easy it is to do things if you have a content strategist on your team who provides
you with all the content up front?”

Karen McGrane I think he does say that. I gave him a content model when we started working on the site, and I think he was like, “Oh, good, these are the pieces that I’m going to work with. Okay, great.”

Justin Avery: I’m glad you mentioned content model actually. I recently bought and it’s sitting in front of me here at the moment actually, A Book Apart Series, the whole library. I was very lucky. I had got some birthday money and thought
I would invest in some nice library material. You’ve got a book within that as well.

Karen McGrane I do.

Justin Avery: Content Strategy for Mobile.

Karen McGrane Indeed. That came out in 2012 from A Book Apart. Another little plug is that I have just recently finished writing my next book for A Book Apart, which is called Going Responsive, and it’s about some of the bigger management
and organizational changes that people go through with a responsive redesign. That’s being edited right now, and I hope it will be out this year.

Justin Avery: Awesome. That’s very exciting.

Karen McGrane Yeah, pretty excited about that.

Justin Avery: I was about to get upset if you were going to say that you have rewritten the second edition after I’ve just bought the library. Damn it.

Karen McGrane I would love to do that sometime, but, no, that’s not happened yet. Yeah, the Content Strategy for Mobile book was really, I guess I would say it was very dear to my heart, because it articulated and I tried to explain
so many concepts about web and web publishing and how I think about separating content from presentation. Those are things that have been important to me my entire career, but with mobile it’s sort of … I often say that mobile is what makes people have this light bulb moment of, “Oh. Oh, it has to
work in a bunch of different places. We can’t treat it like a piece of paper anymore.”

Justin Avery: Yeah. One of the things …&nbsp; really like the book. One of the things, there’s a lot of stuff in it. I lent it to a friend today, or a work colleague. She’s slowly going through each of the different books, and she
was like, “Whoa. This one’s thick.” I’m like, “Yeah, it’s a little thicker than the last one that we had a look at.” The previous one was I think … Is it Erica Kissane? Did she do the one on …?

Karen McGrane Erin Kissane, yeah. She did The Elements of Content Strategy.

Justin Avery: Elements, yeah. She was like, “I’ve now done that one. I’m ready to move on to the mobile bit.”

When I was going through it, you were talking about content modeling as part, as one of
the parts of the book as well. How important is content modeling for responsive, and is it … How important is it?

Karen McGrane Well, that’s a good question. I think I’ll answer that in two ways. One is that a lot of what I talk about with content modeling and adaptive content, and some of the examples that I use, like the NPR, create once, publish
everywhere model, to some extent, that is intended to support a truly multi-device strategy. If you actually genuinely need to serve content in a different way to different platforms. One example that I like to give is a university that has just recently bought a bunch of digital signs that they want
to put up all over campus, and so they want things like news for students or campus alerts or events listings to be able to render appropriately on their website, on their mobile app, and now on these digital screens.

Even a university that has adopted a responsive design approach for serving their website
still may need an adaptive content solution that helps them serve app platforms and these signs as a great example, because it’s like, “Oh, right, if you just stored all of that as one giant WordPress blob, you’re not going to be able to target that content and render that content style, that content
differently on the sign than you would on the website. A more structured, more modeled approach to that content will allow you to serve both of those platforms from the same content repository. You’ll have one set of content that shows up in three different places and can be styled three different ways.

Do I think that’s necessary? If you’re like, “Well, I don’t have that problem, Karen. I
just have one website and we’re going responsive. Do I really need to model that content?” My answer there is, “Yes, I think you still do” in the sense that, one, this is a chance to really break away from an entirely page-focused model of managing content where all of your content lives on a page the
same way that content used to live on a piece of paper and instead have content that is more flexible to be published in more dynamic ways.

Second, I think one of the things that Ethan and I have spent a fair amount of time talking
about recently is doing conditional loading in responsive, so using techniques to progressively enhance not just the code and the design but actually to progressively enhance the content.

The Guardian has a great simple example of cases where at smaller breakpoints they will
show just a headline, and then as the screen size expands, at larger breakpoints, they will show a headline and an image. That’s a very simple example, but to me, that’s the kind of thing that can be done within a responsive design.

The Guardian has a great simple example of cases where at smaller breakpoints they will
show just a headline, and then as the screen size expands, at larger breakpoints, they will show a headline and an image. That’s a very simple example, but to me, that’s the kind of thing that can be done within a responsive design. It follows the ethos of progressive enhancement. Thinking carefully
about the scenarios under which you want to serve less capable or more capable devices, more-or-less stuff, but it doesn’t require the same server side involvement that dynamic serving adaptive content solution would require.

I think smart organizations should be thinking through those kinds of scenarios, saying,
“Oh, okay, great. What if we treat all of our content as if it’s structured, smaller chunks of content,” and we can do something that, to me, is kind of like adaptive content, but it’s progressively enhancing the content.

Justin Avery: Yeah. Yeah. For those listeners that are thinking about that particular example, the Guardian example, because The Guardian do such a fantastic job. They are probably, them and probably the BBC now as well but mainly The
Guardian …

Karen McGrane Oh, the BBC, yeah, yeah.

Justin Avery: They’re such go-to examples of how a site is well-built, a large site with very complex content. When you were talking about loading in the image, having the image appear on a slightly larger breakpoint, if anyone is thinking
that their display none and then display block and the image loads anyway, that’s not how they’re doing that.

Karen McGrane Right.

Justin Avery: They’re actually detecting the screen width and then ajaxing in, for want of a better word, the additional content based on that screen width. It isn’t an additional hit that someone’s not seeing. We’re not hiding content
on the page. We’re just not loading it on first load. That’s right, isn’t it?

Karen McGrane Exactly. It’s not setting display to none. It’s instead starting with the absolute baseline level experience and then adding, progressively enhancing that up for devices that have greater capabilities. I think that’s hard
for people to wrap their head around. Even when I explain it sometimes or it’s like, “But wait, didn’t you say we weren’t supposed to do that?” I’m like, “No, you don’t want to start with the biggest, most complicated version and then hide the stuff that other versions don’t get.” You want to start with
the smallest, least capable version and then progressively enhance it, layer more on top of it when you know the device can handle it.

Justin Avery: Yeah. Really good advice. Very good advice. I know you deal with a lot of different companies, and you are … Actually, I’m going to say this, and it may be completely untrue. You’re not super-techy so you don’t get in
the fields?

Karen McGrane I’m not.

Justin Avery: CMS’s, but you do come across a lot. Have you found if … I’m not asking you for a recommendation. I am asking you for a recommendation. Have you come across a CMS that may work better for this sort of stuff than not?

Karen McGrane I would have to say that is probably the number one question that I get asked. I thought about [crosstalk 00:39:23].

Justin Avery: Oh, really?

Karen McGrane I have a card that that I hand out or something. Honestly, I often sidestep this question by saying I think that most content management systems on the market today, all of the major platforms out there, can actually do
this in the right way. Even CMS’s that have what I would call a really page-centric model, they don’t have to be used as pages. Things like Sitecore or whatever, they may call the default node of content a page, but it doesn’t have to be a page. Drupal did a very smart thing by not calling
it a page and calling it a node, because that actually models more accurately to the way that pages will get constructed out of these nodes or chunks of content.

Justin Avery: Yeah.

Karen McGrane I guess if pressed to give some examples, I’m an advisor to a product called Contentful. They’re a startup based out of Berlin. I like them because they are an API first based content systems. The model that they use is
that they are entirely authoring and storage, so their goal is to provide the best tools out there for content modeling and as a content repository, and then you can get APIs out of their system and pipe it into whatever you want. They don’t care what you’re using on the front end. You can pipe into
another CMS. You can pipe in to static templates. You can pipe into … There’s a bunch of different ways that you can build the site on the front end using their content repository.

Justin Avery: That’s really cool.

Karen McGrane Yeah. I think that that kind of decoupled model is, I guess it’s like if I have to put my money on anything, it’s that sort of decoupled framework. I think we’ve suffered on the web by having web publishing tools. I don’t
mean to pick on WordPress, but WordPress is the classic example to me of a web publishing tool where authoring and storage are so tightly intertwined with the presentation and theming and publication capabilities that it’s impossible to break them apart. You can’t change anything in there without changing
everything.

I think that decoupling authoring and storage from presentation and display and actually
treating those like those are two separate systems with APIs in between them, that is so much more flexible. It is so much easier. There are challenges in maintaining that too. Don’t get me wrong. I think for the long term for where most organizations need to go, that’s going to give them way more flexibility.

Justin Avery: Yeah, that’s a really good recommendation. I’m going to have a look at Contentful and I’ll put it in the show notes as well. I’m just thinking for people who are building these Ember apps and the new Javascript framework
stuff that doesn’t really have much content, this would be perfect for, but if you are building them with those apps, make sure you progressively enhance them and at least kick some content out instead of just a body tag in Javascript, please.

Karen McGrane Yes.

Justin Avery: Speaking of WordPress as well, this will lead on to, probably getting up to that time now, so probably lead onto the last question, but I used to, my last company I worked for, the CMS that runs the responsivedesign.is similar to your example of Sitecore or somewhere it calls it a page or it calls it a news item. The way we used to build to get around it or I built to get around it is I modeled all the content. You still have the page and the page content, which is where maybe the post would go, but around that
I’ve reused the meta data, so it has a meta data screen.

Usually, traditionally, that is fall back-in stuff for in the code that you can’t see. We
re-purposed it to chunk out, so basically content model all the bits, so I have things like the audio file, the podcast guests, Karen McGrane. Your link will be in it it’s own little individual field. It allows me to then reuse the meta data on a front-end point of view rather than just using on the
back end that you traditionally do, so that’s one way to get around that.

The other point about WordPress, I’m currently building a site in WordPress with my wife
actually, and I’ve used a really good tool called Advanced Custom Fields, and that allows you to get past that blob, and you can create, and I’ve done that exactly the way … I’ve read your book years ago, and it helped me with the way that I put pages together and websites together to make sure everything
can link up and reuse different bits, and depending on where you’re listing it. Advanced Custom Fields is fantastic for that. It allows you to really chunk that content out.

Karen McGrane Yeah. I am working with a designer and developer named Laura Shank right now on my personal website, and she is just an absolute wizard with the Advanced Custom Fields. I don’t mean to pick on WordPress. I use
it myself. I will continue using it, but talking to her I was like, “Wow, this is among the most impressive executions of WordPress I’ve ever seen.” It is absolutely possible to do it.

Justin Avery: Yeah. That was one of the things I jotted down too as well. There’s not as many blog posts on your site, recent ones anyways. Have you fallen out of love with blogging or just been too damn busy?

Karen McGrane Yeah, I think a lot of that creative energy goes toward the podcast now. For the time that you have to spend on doing that kind of, I don’t know, just like, “Hey, I only need to say things in public,” that’s where that
energy goes, but I’ll also say, like many people, Twitter seems to fill that void in my life, like why bother writing an entire blog post when you can just write 130 characters.

Justin Avery: One hundred and forty characters. In a blog, though, Karen, come on.

Karen McGrane I know; right?

Justin Avery: Also, I suppose you do a lot of speaking as well. I’ve seen you at a couple of conferences now and always excellent, excellent talk. That would also be like a really, really long blog post; right? So much effort must go
into writing those and preparing for them.

Karen McGrane I do actually wind up posting the transcript of all of my talks as a post, because I wear hearing aids, and I think it’s really important to support accessibility on the web in all of its forms, and accessibility is another
one of those things where it’s like, “Hey, if you do it right, it makes things better for everybody.” Having a transcript of the talk in addition to the slides and the video if it’s available, I think it’s great for people who don’t want to listen to a video or can’t listen to a video. It’s great for
SCO. It’s just great for everybody.

Justin Avery: Yeah. You guys, yourself and Ethan, both transcribe the podcast that you do, which is great. I started transcribing my one, because one of my good friends is a guy from Poland, and he’s like, “I can understand you when
you speak to me because I can see your lips and I can see your expressions, and I get the gist of what you’re saying, but when I listen to you on the radio or the podcast, you’re Australian, and I don’t understand some things.” To read along, and I’m sure America doesn’t get that quite as much. It is,
for people with English as a second language, it’s sometimes easier to digest it in reading format than listening to it, especially with …

Karen McGrane Yeah. You have a warm and compelling Australian accent.

Justin Avery: I put quotes for different parts of the podcast. That is going to be the quote for this one.

I said I was going to lead into a question, the other thing when I was talking about the
WordPress thing. It’s around content and collecting the content as well. We’re building this site for the studio that we look after, and I’ve found it very difficult to … My wife was looking after writing the content and getting it ready, and I was looking after making the website look good, and I
gave her page templates that she could fill out, like the purpose of the page, a high-level description, what things need to be on the page, and her mind worked more in, “I need to see it on the screen to understand how much I need to write or where the bits go.”

I was just saying, “I need to see the content so I know where it needs to go on the page
and how much space it needs and things like that.” Do you have any recommendations around approaching these kind of problems with new website rebuilds and when you bring content and content modeling into the whole process?

I was just working on a website recently in which the person who was in charge of the website, owned the content, basically kept saying, “No, I need to see the designs first. I need to see
the design so I know where the content is going to go.” I’m laughing at that, because I’m like, “No, no, no, you’re doing it wrong. No.”

Karen McGrane Yeah, that’s a great question. I was just working on a website recently in which the person who was in charge of the website, owned the content, basically kept saying, “No, I need to see the designs first. I need to see
the design so I know where the content is going to go.” I’m laughing at that, because I’m like, “No, no, no, you’re doing it wrong. No.”

I think that when people ask for that, they often don’t mean I need to see a fully rendered,
full designed page. They’re not saying, “Pick out every color and every font and all of the layout and show me all of the color transitions and everything.” What they want to know is roughly a wire frame. I think that wire frames have gotten such a bad rap in the industry. I’m sure if I were to go on
Google right now, I could find a million well-respected designers that are like, “I never make wire frames, and they’re a huge waste of time.”

I think the reputation is that they’re a waste of time from an interaction design and a
visual design standpoint. They are not a waste of time necessarily from a content model standpoint. I think that for us to assume that content creators will always understand what we want by giving them a content model and saying, “Sure, you write a headline and a teaser and a body and some bullet points
and add this meta data, and then you don’t have to care about how it gets laid out on the page.” I don’t think that that’s the answer.

There was a post on the Content Strategy Google group a while back in which a bunch of leading
content strategists were talking about how do you communicate content models to your clients, and pretty much every one of them was like, “Oh, yeah, we use wire frames. We use high-level wire frame sketches that are not really intended to communicate the layout or the design.” They’re just intended to
communicate, this is a headline, this is a teaser, this is a link. The Lego pieces that you’re adding are going to get laid out in this way.

To me, that’s just another argument for saying we need lots of rules in the process. We
need all of the tools at our disposal. Saying that we need prototype thing or more interactive tools doesn’t necessarily mean we throw out Photoshop or we throw out wire frames. It just means that as our work gets more complex, we need more tools to do the work.

Justin Avery: Excellent advice. That’s really good. That is really good. I quite enjoy the approach that Stephen Hay talks about a lot in terms of building up a prototype from a mobile first, and if you don’t have the content, just put
in what you’d expect the place to be, which is kind of like wire frames in the browser as well.

Karen McGrane Sure. Yeah.

Justin Avery: I never thought of it from a content model point of view as well. That’s really good.

Karen McGrane Yeah. I have a post on how much I think everybody should, that Lauren Ipsum is okay. There’s been a whole sense from the industry of Lauren Ipsum is the absolute worst thing ever and you should never use it; it’s the death
of websites. I use it all the time. I use it to this day. There’s lots of scenarios under which you don’t really have all of the content, but you know you’re going to have a headline. You know you’re going to have a teaser. You roughly know how long it’s going to be, and you just drop in some fake words
there. You drop in something where the words are going to go here; are these the right words? Here’s a rough idea of what we want to put here.

Did I do that with ResponsiveWebDesign.com? Absolutely. There were lots of pages that Ethan
could start building where I didn’t have to have written every word on that page. I just needed to have a sense of, “Yeah, okay, yeah, I’m going to write a headline here and then there’s going to be a couple paragraphs of text.” I think any processes where we’re demonizing somebody’s way of working at
it, it’s like I would say in almost every scenario, there’s a bad way to do it and there’s a perfectly acceptable way to do it. Let’s try to communicate like, “Hey, these tools are appropriate in these scenarios. Don’t use them to solve this problem.”

Justin Avery: Yeah. That’s actually really good. I totally agree. I think it’s well wrapped up. I think I’m going to end it there, because I think that’s a good way to finish it.

Karen McGrane All right.

Justin Avery: I do have one more question, though. Each week I ask the guest of the current show, so that’s you, to ask a question of our next guest. I have a good idea who it will be next week, but you won’t know who it is, but last
week, Nick Schaden, who is the front-end developer for Get Pocket … In fact, if anyone likes Get Pocket, go and check it out because he’s done a marvelous job on the web app, but if anyone uses InVision as well, which is, it’s a new tool to allow you to collaborate more around designs that come out
of things like Photoshop and stuff … It’s very good anyway. You should go and check it out.

He recently did a webinar on building responsive teams with InVision, and that was live
last night and will be released later this week, so check that out in the show notes, and you should have a look at that because it’s really cool. I digress. His question for the next guest, and he didn’t know it was you, was, “How has responsive web design changed the workflow within your company?”

Karen McGrane Ah, fascinating. Well, I don’t know that I could speak to my company directly. Ethan and I do have a little company called Responsive Web Design, LLC that we use to manage operating, for operating expenses for our workshops,
but …

Justin Avery: So it’s affected it quite substantially really.

Karen McGrane I think if I were to look at that more broadly and say, “How has it affected the workflow in the companies that I talk to?” I would say the challenge of having to look at the work in context on a variety of different devices,
have a prototype available, often a prototype that’s going to be available to people across the organization all the time, so you’re not waiting until the big reveal where you go into a meeting and you project something up on the screen, and you’re like, “Look, it’s our website.” Instead the prototype
is always available. People can always go and poke at it and bang on it.

That, I think is the biggest shift in how people work. It’s a shift because it’s not just
about the design and development process. It’s about how the entire organization thinks about how do we review this work? If I’m reviewing the work on my personal phone, how do I give you comments on it?

That, I think is the biggest shift in how people work. It’s a shift because it’s not just
about the design and development process. It’s about how the entire organization thinks about how do we review this work? If I’m reviewing the work on my personal phone, how do I give you comments on it?

I used to get a PDF but I would send an email back with comments, notes on this PDF. Now
I have to have new tools for communicating, “Oh, well, at this particular breakpoint or at this point on the screen, this thing doesn’t look right” or it’s not the right size, or it’s too low on the screen. I think that finding ways for people to talk about their feedback on a responsive design is a
big challenge, and it really changes the workflow of the entire team.

Justin Avery: Yeah, that’s a tough nut to crack.

Karen McGrane Yeah, it is. It’s crazy.

Justin Avery: I like the approach of the website always on and no big reveal as well as this continually evolving prototype, because I find some people when you’re doing big website redesigns as well or their first big foray into a large-scale
website, they still have this once it’s live, that’s it, they can’t touch it. It’s not like a book; right? Once it’s printed, that’s it. That really is it. You’ve got to distribute and sell the 10,000 copies or whatever you printed.

The website’s continually iterated. It never stagnates. It will always change. I think the
ongoing prototype and continual update of that throughout that design and development process cements that idea into organization’s brains. I hope it does anyway.

Karen McGrane Yeah. To me that’s the big shift of the web is this is not a piece of paper. When you publish it, it’s not static. It’s going to be constantly evolving, constantly updated, and so that means that how we talk about the
work, how we evaluate and give feedback on the work can’t be paper-based anymore. The tools we use to create and comment on our work also have to be digital.

Justin Avery: Yeah. Yeah. I might go for a search. I remember seeing something where you could provide feedback. It was kind of like a browser plug-in, because ideally that’s about all you can do. You’d hit the browser plug-in. It would
work out what operating system you’re on, what device … not device … possibly device, but what browser you were using, what width it was, the speed of the connection at the time. All these things that are really, really vital for us to be able to nail down what the problem was instead of someone
going, “Menu doesn’t work,” which is practically useless.

Karen McGrane Yeah.

Justin Avery: I’ll have a look for that too, because that was actually a really good tool. I don’t know if it ended up taking off, but, yeah, that’s really good.

Karen, this has been awesome. I’ve had a …

Karen McGrane This has been so much fun.

Justin Avery: Yeah, it’s been really fun. I’ve learned a lot. This is my favorite thing about doing this. I get to learn loads of stuff that I’ve been really interested in. Thank you so much for taking the time out of your day and jumping
on this as well. Now, we talked about a few things that you’re doing and you’ve done. Have you any plugs or have you got an talks coming up, workshops, things that you’ve got going on?

Karen McGrane There’s a fantastic event that’s happening in August in Vancouver, Canada. It is called Design Content Conference, and Ethan and I will be doing a full day on responsive web design there, and I’m also giving a new talk
there on adaptive content, so three years after my book was published, I’m doing a look at where adaptive content is today and how I see organizations doing it, doing it right, doing it wrong, what’s going on there.

Justin Avery: Nice. I like the website. I featured this a few months ago actually. I love the angles. Very triangley, the design content. It’s very cool.

Karen McGrane Yeah, the people who organize it, Steve and Shannon Fisher, are fantastic, and their event producer, Erik Westra, is the same guy who produces the workshops for me and Ethan. I give them two thumbs up. They’re fantastic
people.

Justin Avery: Terrific. It looks like a really good lineup as well actually, looking through the list of folks, all very, very clever people.

Karen McGrane Yep. Yep. Can’t go wrong if you come to that conference.

Justin Avery: Awesome. I will also say that everyone should go to ResponsiveWebDesign.com/podcast and check out the podcast. Go to Net Magazine, The Net Awards and vote for your favorite podcast as well. It has to be the Responsive Design
one that makes it into the finals. Definitely vote down on one of those.

If people want to follow you as well, you said you’re now publishing a lot more on Twitter.
Do you have the tweets?

Karen McGrane Do I have the tweets?

Justin Avery: Do you have the tweets? What is your Twitter handle?

Karen McGrane Oh, my Twitter handle is just Karen McGrane. Keeping it real.

Justin Avery: Keep it simple. Don’t turn up “Content Strategist Number One” or something weird. Cool. I’ll put those up in the show notes, but thank you again, Karen, for coming on. It has been super-fun.

Thank you to all the listeners for tuning in and listening. Write us up in iTunes, give
us five stars. That would be awesome. If anyone would like to join me, if you’ve done a redesign or if you’re working on something which is awesome or you even have questions, go to ResponsiveDesign/Contact and just buy something towards me. I’d love to hear what you’re working on or have a chat to you
on this.

Karen, thank you again.

Karen McGrane It was my pleasure.

Justin Avery: I hope to see at some point, but I’ll definitely be following you on the twitters.

Karen McGrane Wonderful. Well, thank you so much.

Justin Avery: Thank you, and I look forward to the next podcast and the new book as well.

Karen McGrane Yeah, even better.

Justin Avery: Thanks, everyone. Cheers. Bye.

RWD Podcast #35 : Nick Schaden
75:58
2017-12-22 20:56:41 UTC 75:58
RWD Podcast #35 : Nick Schaden

Show notes


Podcast Sponsor

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple&rsquo;s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That&rsquo;s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.


Transcript

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&rsquo;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&rsquo;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 &hellip; London doesn’t seem to be sorted for hot weather. It just struggles.

Nick Schaden: Yeah. I know. It&rsquo;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&rsquo;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&rsquo;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 &hellip; 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 &hellip; 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 &hellip; 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&rsquo;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 &hellip; 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&rsquo;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,&rdquo; and then go from there.

Justin Avery: Nice. I just went through it and I figure out I&rsquo;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 &hellip; 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&rsquo;re involving &hellip; There&rsquo;s a lot of people being involved both design and development wise.

There&rsquo;s quite a few steps to go through to make sure that everything is working from
back to front. I&rsquo;m just thinking here, so 2010, I&rsquo;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&rsquo;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&rsquo;s the official width and height of the web ports on the iPad and we&rsquo;re like, “Oh my God, well, this might actually work for a website,&rdquo; kind of thing. It&rsquo;s the kind of thing where it was myself and other developer and a really good designer.

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

You&rsquo;re writing your own like really web 1.0 swipe event listeners. You&rsquo;re like
I don’t know. I think if I do touch start until end 400 pixels, they&rsquo;ll be good. It was a bit of a crapshoot. It was functional, and I think there&rsquo;s a lot of pressure up top like, “Oh, we want to get this,&rdquo; 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 &hellip; I believe a usually oscillating number between 4 to 6-man web team. Actually, it was really interesting because almost every company I&rsquo;d been in has been even a different experience from a
team standpoint. Gucci, it was I&rsquo;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&rsquo;s a very engineering focused culture. These are people that are dyed-in-the-wool, hardcore technical people, they&rsquo;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&rsquo;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&rsquo;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 &hellip; I don&rsquo;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 &hellip; 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&rsquo;ve never heard of Animoto.&rdquo; You type in the web address or you go and inbound link. What&rsquo;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&rsquo;s
called the first user experience like, “Hey, I&rsquo;ve never heard of Animoto.&rdquo; You type in the web address or you go and inbound link. What&rsquo;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&rsquo;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&rsquo;d say it came from &hellip; Again, that&rsquo;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&rsquo;t come at least from my group.

They don&rsquo;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&rsquo;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&rsquo;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 &hellip; 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&rsquo;ll talk about the whole native versus web to dates sort of thing but
one thing I will say about that is hey, I&rsquo;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&rsquo;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&rsquo;t, say a slack-like experience.

As you said, as you&rsquo;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 &hellip; I mean, again, what Animoto &hellip; 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&rsquo;s not like, say, you&rsquo;re
doing a final cut on the webpage. It&rsquo;s definitely nothing like that. It&rsquo;s meant to be a very user-friendly, novice-like experience where you almost you&rsquo;re rearranging. Think of them as a keynote experience, rearranging slides but they&rsquo;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 &hellip; and browsers, I suppose more to the point that they need to come up
and bridge the gap a little bit like what&rsquo;s missing from making that experience perfect just in the web instead of having to go native?

Nick Schaden: That&rsquo;s a great question. I wonder about that a lot. I think that if we step back from it, I&rsquo;m just trying to think of like where I&rsquo;m excited about some of the innovation on the web. I think that in many
ways a lot of it at least especially where &hellip; I don&rsquo;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&rsquo;ve worked at or done work for. I think of things even things like web components and things of that. It&rsquo;s the kind of thing that I feel like I&rsquo;m trying to reflect in your question a little bit in terms of view.

I guess the short answer is, there are &hellip; I don&rsquo;t want to just say, blatantly
like “Oh, if you&rsquo;re doing a game or hey, man. If you&rsquo;re doing a video app, don&rsquo;t waste your time with the web. It&rsquo;s horrible for that.&rdquo; I mean, you don&rsquo;t want to be too dismissive. I look the overall as the web&rsquo;s advantage is that kind of umbrella, it&rsquo;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&rsquo;s the number 1 goal. I think that if we try to emulate &hellip; I mean I&rsquo;m sorry to go off on a small tangent here but in terms of &hellip; Look at the controversy that I think embroiled Flipboard recently with their &hellip;

Justin Avery: With the canvass approach.

Nick Schaden: Exactly, the canvass approach. Now, again, I don&rsquo;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&rsquo;t aware &hellip;

Nick Schaden: Sorry about that.

Justin Avery: No. That&rsquo;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&rsquo;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&rsquo;s it. There&rsquo;s no full back for that at all. It&rsquo;s that the gist of it?

Nick Schaden: I agree.

Justin Avery: Yeah?

Nick Schaden: Yeah, I think that&rsquo;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 &hellip; 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&rsquo;t hit 60 frames a second, it&rsquo;s over. User experience is over. You won&rsquo;t waste your time there. I just thought that well, I think it&rsquo;s a nice achievement in many ways.

It&rsquo;s at the same time not necessarily priority one depending where you&rsquo;re going
with that. I think it&rsquo;s a fair goal but I guess back to your original question of native versus web, I feel like the goal for web shouldn&rsquo;t be to necessarily chase native. We&rsquo;re saying if it&rsquo;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&rsquo;s reach, is it&rsquo;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&rsquo;s not necessarily right or wrong but don&rsquo;t focus on just that one answer
of the 60 frames a second. There&rsquo;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&rsquo;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&rsquo;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&rsquo;t want to do that. You don&rsquo;t want to use someone&rsquo;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&rsquo;s a wonderful resource, I will say too. Recent discussion with I believe a representative there from &hellip; I forgot his name but he was from &hellip; 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&rsquo;re literally incased in the browser. You can&rsquo;t go outside of it. You can&rsquo;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&rsquo;s again, just small step. It&rsquo;s simple to understand from an API standpoint. If you&rsquo;re a developer in the web, if you look at again the way that Chrome has done it, I think it&rsquo;s pretty shrewd in terms of its implementation.

It&rsquo;s also though it&rsquo;s very necessary. I mean, I talked to many people who they&rsquo;ve
worked with their companies and like, “You know what, Nick, we love it. It&rsquo;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&rsquo;t do a web version?

Everything else was great but that was the one thing we couldn&rsquo;t do. I thought, oh
man. Again, there&rsquo;s a few things like notifications that I think can really what&rsquo;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&rsquo;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&rsquo;ve been using this a bit, would you like to drop this down. The web workers for
the notifications and offline stuff it&rsquo;s all very exciting. Actually do you do much work with offline?

Nick Schaden: We do a little bit. I&rsquo;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&rsquo;m not sure if you go ahead to my homepage.

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

Nick Schaden: I&rsquo;ll send it through, sure. I mean, it is something that &hellip; I mean, it&rsquo;s kind of unveil the curtain. It&rsquo;s definitely the next big frontier that I would love to look at in terms of Pocket&rsquo;s
web app experience. It definitely wasn&rsquo;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&rsquo;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&rsquo;re purporting this as something as effectively great first run experience for users.

We want to make sure that if you&rsquo;re on, let&rsquo;s say you log in to a Windows phone
or whatever, maybe we don&rsquo;t have quite a native app for you, you go in the subway, we want to be able to basically catch the experience. It&rsquo;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 &hellip; I&rsquo;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&rsquo;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&rsquo;s links, it&rsquo;s parsed articles. Also, I think frankly there&rsquo;s
a bit of a &hellip; It might be a bit of a copyright issue too if you&rsquo;re like hey, save this YouTube video.

Justin Avery: Don&rsquo;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&rsquo;s not just for offline. There&rsquo;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 &hellip; Not every
day, it&rsquo;s a little bit obsessive. Let&rsquo;s say, every week or every other week. I&rsquo;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&rsquo;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&rsquo;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 &hellip; Of course, one of the first things we try to do was just prune &hellip; 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&rsquo;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&rsquo;d say
anywhere from 30 to 40%.

It&rsquo;s the kind of thing where you work on it and you&rsquo;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&rsquo;s a week. Why don&rsquo;t you just go and start cleaning this stuff up.&rdquo;

It was a huge saver there. That footprint was big. I&rsquo;d say the other 2 things just
thinking off hand is that from where we started and where we are now is we&rsquo;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&rsquo;re pretty heavily invested in gold at Pocket. It&rsquo;s the kind of things
where it&rsquo;s step 1 was like. Obviously when you automated these things, instead of the one-offs of like I&rsquo;m adding a JavaScript file and I forgot to minify this, it&rsquo;s all there. It&rsquo;s attributably added. In terms of general packaged performance for the user, everyone is in the same
page whether it&rsquo;s me or someone else working on the code base. That&rsquo;s step 1.

You had things like image compression algorithms, step 2. Just things that can be little
things where you wouldn&rsquo;t think of it where we&rsquo;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&rsquo;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&rsquo;s going to be coming hopefully in the near future. We&rsquo;ve moved the entire code base from the web app from traditional Vanilla CSS to a Sass base.

Let&rsquo;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&rsquo;s great. It&rsquo;s the kind of thing where the thing I almost regret not doing it earlier with a web app because it&rsquo;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&rsquo;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&rsquo;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 &hellip; 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&rsquo;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 &hellip; Obviously he&rsquo;s Filament Group, right?

Justin Avery: Yeah.

Nick Schaden: We&rsquo;re a huge fan. I mean, I&rsquo;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&rsquo;s going again on a switching subject
here but the before approach when we were trying to think of “clean way&rdquo; to handle responsive imagery and then the after end using that design library.

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

Justin Avery: Before you go back, it&rsquo;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&rsquo; portfolio, because it&rsquo;s very heavily image based. I had a look and they had &hellip; It was like query strings in the URL to produce a certain size image and that&rsquo;s fine.

They were just image pegs and I questioned and said is there any reason you&rsquo;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&rsquo;t approach
it but also it&rsquo;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&rsquo;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&rsquo;s something that I learned both good and the hard way starting my career web wise. You go and you&rsquo;re like, Hey, man. Learn this new technique, let&rsquo;s kick it out there.

Look at your user analytics, who are your users. Even at Pocket, Pocket versus Gucci. Gucci,
we&rsquo;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&rsquo;s no 1 right answer. You have to take it from there but then going back to your
point about responsive imagery. I&rsquo;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 &hellip; both students and a lot of them are in the workforce.

They&rsquo;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&rsquo;s much like you said, it&rsquo;s the notion of well, it feels really junky and experimental. I don&rsquo;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&rsquo;t even include was SourceSet. SourceSet, I always don&rsquo;t know how to pronounce it.

Justin Avery: SourceSet is good.

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

It&rsquo;s going to spread everywhere. I feel like there&rsquo;s &hellip; I don&rsquo;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&rsquo;t support it. HTML is so forgiving. It just ignores. It&rsquo;s like I don&rsquo;t understand that.

Nick Schaden: Exactly.

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

I don’t know if it&rsquo;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&rsquo;t support SourceSet, the Picturefill would fill that and download the SourceSet image as well, so you&rsquo;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 &hellip; 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&rsquo;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&rsquo;t have to worry about this yet,&rdquo; or worst of all just say, “Let&rsquo;s load a 2X image for everybody.&rdquo;

Justin Avery: That was the full back for these. It&rsquo;s just like well, it&rsquo;s a portfolio so let&rsquo;s just load the biggest image because we want it to be beautiful which I can see that it&rsquo;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&rsquo;s a 1 day workshop class. It&rsquo;s really meant for pretty much complete beginners, mainly people that
you have to have some basic HTML CSS but it&rsquo;s not all meant to be technical of a class even we do have a code.

When we talk about imagery, it&rsquo;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&rsquo;s call it the responsive world. I feel imagery is still the one that&rsquo;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 &hellip;

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&rsquo;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&rsquo;re deep in the weeds. We&rsquo;ve got some technical talks which is good but on a completely non-technical side, they&rsquo;re so surprised on how much they&rsquo;re flow changes as a company.

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

Business people have to think about QA, has to approach it differently and it&rsquo;s not
just a bit of code. I think it&rsquo;s a very transformative experience for a lot of companies. I think that&rsquo;s in many ways the eye opening experience that a lot of my students have. That&rsquo;s it. It&rsquo;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&rsquo;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 &hellip; 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&rsquo;t communicate often and early, you can really get into trouble.

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

Justin Avery: That&rsquo;s good advice. On the fast thing, you were talking about the build tools that you were using and Gulp specifically. I&rsquo;ve recently seen people incorporating performance budgets, say, Tim Kadlec, fantastic
person. He&rsquo;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&rsquo;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&rsquo;s definitely something that we&rsquo;re striving always for at Pocket. Especially, honestly as we grow as a company. We&rsquo;re small now but invariably I think we&rsquo;re going to grow in terms of hiring people. We&rsquo;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&rsquo;m going to double check that just to make sure. I&rsquo;m pretty certain that&rsquo;s it. Let me just make sure here. Exactly, getpocket.com/jobs, we actually have quite
a few positions that we&rsquo;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&rsquo;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&rsquo;s definitely a factor.

It&rsquo;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&rsquo;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&rsquo;m the focused user. I have this huge list of here&rsquo;s what I like to do. One thing I&rsquo;m experimenting with is things like PhantomJS and doing
snap shots. It&rsquo;s minor and again, it&rsquo;s very limited. I don&rsquo;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&rsquo;re getting there. We&rsquo;re such a small team. The more we can automate, the
better the process. I&rsquo;m sorry, I feel like I&rsquo;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&rsquo;s the kind of thing where it&rsquo;s, honestly, it&rsquo;s frankly a little bit
too informal now. It&rsquo;s the kind of thing where it&rsquo;s like me going, “Hey, wait a minute. I think we&rsquo;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&rsquo;s on GitHub and basically
it takes a snapshot when you&rsquo;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&rsquo;re looking at it, check that out. That will be in the show next as well.&nbsp;

Nick Schaden: I will look at it. The more we can do for automated visual testing, the better. I think that&rsquo;s something even &hellip; It&rsquo;s like when I talked about earlier the notion of even developer-designer relations. Part
of it is buy-ins. It&rsquo;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&rsquo;s really open people&rsquo;s eyes. It&rsquo;s
been little things like internationalization like, “Hey, we prepped this new page. How does it look on every browser?&rdquo; It&rsquo;s like boom, you press 1 button. It&rsquo;s loose, it&rsquo;s not perfect but then even just setting that little thing off to the designers, everyone is like that&rsquo;s
cool. That&rsquo;s something that I would love to look into in the future.

Justin Avery: That is so awesome. It is pretty awesome. We&rsquo;re getting towards the end of the hour. I could keep going for ages but I&rsquo;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&rsquo;t live without?

Nick Schaden: Responsive plug-ins that I couldn&rsquo;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&rsquo;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.&rdquo; That&rsquo;s one. Two, what would be a second plug-in on how I feel. I mean, honestly I&rsquo;m still a huge fan of &hellip; Wait, this is a question specific to responsive, right?

Justin Avery: I mean, it&rsquo;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&rsquo;t much around,
but nowadays we use things like Flexbox, we&rsquo;ve got the box-sizing, border-box thing there. I couldn&rsquo;t live without that these days. It&rsquo;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&rsquo;t just use it loosely. I think there&rsquo;s too many people
that just do something like download the HTML5 Boilerplate. They&rsquo;re like, “Hey, man. I got the test version. Let&rsquo;s throw this up there because there&rsquo;s definitely performance implications if you don&rsquo;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&rsquo;s
less of a responsive thing but just let&rsquo;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&rsquo;s really a great resource.

Justin Avery: It&rsquo;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&rsquo;s not just responsive is a new thing, it&rsquo;s how we build websites. What&rsquo;s one thing that you want to see improved on the web in terms of tooling you have access to?

Nick Schaden: That&rsquo;s is a great question and it&rsquo;s a good question that is a bit open-ended but in a good way because I&rsquo;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&rsquo;s true. We come a really long way. You know what, I would actually say &hellip; I was about to say a really good grid format but then nowadays &hellip; I know &hellip; Susie has moved to I think the LibSaas over
there. There&rsquo;s something we&rsquo;re very interested in. We‘ve grown our own grid here at Pocket.

It&rsquo;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&rsquo;s that for an answer?

Justin Avery: That&rsquo;s good.

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

They tend to have a bit of croft and done and they tend to be &hellip; I mean actually they
were great. I don&rsquo;t want to knock them for that but they&rsquo;re very uniformed, they&rsquo;re very simple. One of the things when I think about where the web is going and I think we&rsquo;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&rsquo;s exciting to guys. It&rsquo;s almost because of responsiveness
we&rsquo;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&rsquo;re going to see a lot more exciting designs out there.

Now, I think that&rsquo;s great and it&rsquo;s ironic because at Pocket we have a pretty
uniformed grid. Actually for the web app, it&rsquo;s completely just done by ourselves. We&rsquo;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&rsquo;s really funky, really out there, something
that really impress people visually, I don’t know. I&rsquo;m really excited about that.&nbsp;

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

Nick Schaden: I&rsquo;ve heard of it. I&rsquo;ve looked a little bit into it. Not too in depth but &hellip;

Justin Avery: Just brain exploding.

Nick Schaden: Yeah.

Justin Avery: It is. Just regions &hellip;

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

Justin Avery: Is it April 1st. What&rsquo;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&rsquo;m sure that if any of our extremely talented designers, Nikki or Maggie or Diego listen to this, they&rsquo;re going to be like, “Nick always brings up the style
guide thing. Come on guys, we need the style guide.&rdquo; We&rsquo;re getting there. We&rsquo;re a growing company. Style guides was a big proponent.

We had actually a very much a living style guide. I&rsquo;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&rsquo;re getting there. It&rsquo;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&rsquo;t have anything open sourced or public for now.

Justin Avery: That&rsquo;s good. The final question, so each week, I ask you, the guest to ask a question of next week&rsquo;s guest. I will get you to ask a question after I ask you this one. It can be about anything preferably responsive&rsquo;ish
or [inaudible 00:58:51] web design. We&rsquo;ve had like what&rsquo;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&rsquo;re familiar with HTTP/2 specification and what&rsquo;s coming
bit his question is, HTTP/2 is around the corner and it&rsquo;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&rsquo;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&rsquo;ve heard of it and I&rsquo;ve heard of it, bleakly.

Justin Avery: That tough question to answer then if you &hellip;

Nick Schaden: It is a tough question. I mean, I can take &hellip; I guess I could answer it&rsquo;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 &hellip;

Justin Avery: No, that&rsquo;s good. I&rsquo;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 &hellip; I already said that for grids. I&rsquo;m cheating. I&rsquo;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&rsquo;s call them scenarios where you&rsquo;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&rsquo;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&rsquo;t make it responsive. That&rsquo;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&rsquo;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&rsquo;s a really interesting point. Again, when I think about that, I think
of look at the recent New York Times &hellip; Well, it&rsquo;s not that recent now but the New York Times redesign. It&rsquo;s also true with The Guardian, the BBC as well. It&rsquo;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&rsquo;m worried there&rsquo;s not enough attention drawn on that. I don&rsquo;t want to say we&rsquo;re debating phase 1.

I mean we have to. Things like responsive imagery, we still have to &hellip; I don&rsquo;t
want to say figure things out but we still maybe have a bit of little room where we&rsquo;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&rsquo;s very true. If anyone that wants some more information around that the stuff The Guardian was doing, there&rsquo;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 &hellip; 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&rsquo;re related, metadata and related post and a whole bunch of stuff. There&rsquo;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 &hellip; Because that&rsquo;s what the user wants. They&rsquo;re there to read that one article when you land on an article page.

If only 1 request works and that&rsquo;s the one that you want. Then everything else that&rsquo;s
done in the navigation, the sidebars, the comments, the polls, they&rsquo;re all done subsequently and depending on the device you&rsquo;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&rsquo;s only smart. I mean, I&rsquo;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&rsquo;s an article, here&rsquo;s it on different devices, let&rsquo;s use this as a starting point for talking about this. They&rsquo;re very impressive in terms of what they do.

Justin Avery: It&rsquo;s also one of the only places where I think you can get away with it because they&rsquo;ve done it in a &hellip; 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&rsquo;re after and just load up the stuff as you need it. That&rsquo;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&rsquo;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&rsquo;s a non-blocking request
or putting it in a sync or a differ attribute on sprite images.

All these things that we&rsquo;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&rsquo;s a HTTP request every single time. Then there&rsquo;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 &hellip; We&rsquo;ve
done all these things together around the limitation of that protocol. That protocol is what&rsquo;s changing. It would do a push. It&rsquo;ll do things small. It&rsquo;ll keep your connection open.

It&rsquo;ll send multiple things back so you get the HTML file and you can declare that
there&rsquo;s a few things that are needed. It sends them all back at once. It just gets past all the hacks we&rsquo;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&rsquo;s keep everything separate
because we can now.

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

Nick Schaden: I mean, with that last point you mention, the pipes will handle it, it&rsquo;s very dangerous. Again, I think that&rsquo;s something that I think it&rsquo;s part of just doing what we all do. Whether you&rsquo;re in web
design or development. Part of it is just being humble in realizing that &hellip; I mean, I&rsquo;m guilty of doing this too is that you&rsquo;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&rsquo;re on right on displays. They&rsquo;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&rsquo;s just really important. I mean, again, we haven&rsquo;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&rsquo;s only another half a second.&rdquo; Everyone has got a fast enough connection for this. I think that, I don&rsquo;t want to say has led to the point where we are. I think there&rsquo;s a lot more than just speed that&rsquo;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&rsquo;m not the first to point
this out. There&rsquo;s a lot of smarter people out there than I am on this but it is that &hellip; It&rsquo;s drawing attention to performance in a good way. It&rsquo;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&rsquo;s dangerous.

Justin Avery: Totally. I&rsquo;ve read the other Facebook article thing in the last episode. I think it&rsquo;s a very interesting time around that and I agree. It&rsquo;s racing. It&rsquo;s good that it&rsquo;s come up because it is
pointing the finger back at a slow web. It&rsquo;s not slow inherently. We&rsquo;ve just made it that way. It&rsquo;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&rsquo;s 11 cents. In United States, it&rsquo;s 8 cents.

It&rsquo;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&rsquo;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&rsquo;d love to run that older ugly site back through this.

Nick Schaden: I know what you&rsquo;re talking about.

Justin Avery: It&rsquo;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&rsquo;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&rsquo;s probably less technical but I think it&rsquo;s still relevant which is I would ask the next guest, so I&rsquo;m assuming which obviously is involved with responsive web design or the probably won&rsquo;t
be talking with you. The question would, how has responsive web design changed the workflow in your company?

That&rsquo;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&rsquo;s a lot more that&rsquo;s changing than just again, just code or just how, “Hey, will you sketch more a lot aggressively than
Photoshop,&rdquo; or something like that. There&rsquo;s more to it. There&rsquo;s a lot more to it, I think.

Justin Avery: Absolutely. That is a good question. I&rsquo;ll look forward to hearing how people &hellip; I might use that for a couple of guests the next time so I won&rsquo;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&rsquo;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&rsquo;m on that.

In terms of upcoming talks or events, the only that I would mention that&rsquo;s coming
up soon is I&rsquo;m actually working with Invision specifically. I think a bit of a cross promotion with both Invision and Pocket. We&rsquo;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&rsquo;s
June 9th.

We haven&rsquo;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 &hellip; I&rsquo;m guessing in the next few days, there will probably be a landing page for this. It&rsquo;s going to be a free webinar that I&rsquo;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&rsquo;s
basely just a little bit of a talk on multi device flow, why it&rsquo;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&rsquo;s about the only plug I have on
my side.

Justin Avery: Awesome. All right, June 9th. I&rsquo;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&rsquo;re still &hellip; I think as we speak today, they&rsquo;re actually putting the quick landing page to sign up for that. Again, as far as I know, it&rsquo;s completely free but I&rsquo;ll
definitely shoot you that once it&rsquo;s locked up.

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

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

Justin Avery: I really like Invision stuff. They&rsquo;re really running some really good articles as well. They&rsquo;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&rsquo;s got some really great articles on there. There&rsquo;s one about approaching whereas I&rsquo;ve got here bridging the designer-developer gap on responsive web projects. It&rsquo;s an excellent rate. We&rsquo;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&rsquo;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.

RWD Podcast Episode #34 : Nathan Ford
67:32
2017-12-22 20:56:41 UTC 67:32
RWD Podcast Episode #34 : Nathan Ford

Show Notes


Podcast Sponsor

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple&rsquo;s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That&rsquo;s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.


Transcript

Justin Avery: Hey, and welcome to Episode 34 of Responsive Design Podcast. My name is Justin Avery, and I&rsquo;m your host and curator of the Responsive Design Weekly Newsletter, a weekly newsletter all about, you guessed it, responsive design. Before I get into introducing our guest for this week,
I just wanted to have a quick shout out for our sponsor. Our sponsor is Media Temple. Media Temple, you can find them at MediaTemple.net. They&rsquo;re a web hosting company. Incidentally, they are hosting the Responsive Design Weekly website as well.

We&rsquo;re using them for years now. I use them for some personal projects, some friends&rsquo; sites, and also for business sites as well. They&rsquo;ve got a range of different entry points that you can choose from. They&rsquo;ve got a self-designer website tool as well called &hellip; I think it&rsquo;s
called “Virb&rdquo; where you can go, and drag and drop components, and build one up yourself. They&rsquo;ve got basic WordPress hosting, so you can host a single WordPress instance. They&rsquo;ve got instances where you can host hundreds of WordPress instances for your clients as well. It just
depends with what you need. They&rsquo;ll be able to sort you out as well.

If you head over to MediaTemple.net, you can use the code “RD25&rdquo;, and that will get you 25% of the cost of your hosting. Go check them out and thank them for supporting the weekly podcast chat. This week, speaking of WordPress, the Virb, and the ability to design websites, we have got Nathan
Ford, a web designer, on. Welcome, Nathan.

Nathan Ford: Hello. Good to be here.

Justin Avery: Yeah, good to have you. Did I get web designer right, or am I way off?

Nathan Ford: I call myself a web designer first, but I&rsquo;m also a product manager now.

Justin Avery: Stepping up in the world or stepping back?

Nathan Ford: I think it&rsquo;s up because what I get to do now is make great products for fellow web designers to do their job better.

Justin Avery: Also, now I have some questions about some of those products that you&rsquo;re working on now.

Nathan Ford: Cool.

Justin Avery: Before I get to those, maybe just bring people up to speed, list us up to speed with how you got involved from being a web designer or as a designer into being a product manager over the years?

Nathan Ford: Sure. Yeah. It&rsquo;s been an odd trajectory, I guess, but not too odd. I went to school for graphic design, so I got my degree, my Bachelor of Fine Arts in Graphic Design, and went immediately to work for an ad agency. I had a really clued-in professor that told me, “Hey, you should
probably learn this HTML/CSS stuff,&rdquo; because I was interested in interactive. I ended doing that on the side. When I got my job in the ad agency, I was like the only guy that can build websites, so I got thrown all of those jobs. I got thrown big jobs, bigger jobs that I probably should have gotten
with so little experience, but I got to cut my teeth on some really interesting projects and with some consequence, which is cool.

Slowly, I got better, and then I actually started moving into like real jobs in web design, focusing solely on that rather than &hellip; Because advertising really wasn&rsquo;t my thing. It was a little too much flash as a technology and too much flash as in how you &hellip; The big idea and stuff like
that, and I was more interested in making things work. Yeah. For the past few years, I&rsquo;ve worked for a few different excellent web designer shops. Then recently, I was working for Mark Boulton Design, and we were acquired by Monotype.

Monotype makes &hellip; It&rsquo;s a type foundry first, but it also makes really cool products like &hellip; Actually, the team that&rsquo;s at Monotype has made cool stuff like Typecast, which you probably heard of. I had made Gridset while working at Mark Boulton Design. Now, that&rsquo;s part of
the Monotype thing. Slowly, but surely, I started just getting more interested in how to make the job of a web designer easier, and so that&rsquo;s what I&rsquo;ve been focusing on. Now, I&rsquo;m a product manager.

Justin Avery: That&rsquo;s awesome. There&rsquo;s a couple of new tools that are out, neither the ones that you just mentioned, but I do want to ask you about those.

Nathan Ford: Sure.

Justin Avery: With the goal of making these things easier for web designers too, so remind me to get back and ask you about your thoughts on those specific tools.

Nathan Ford: Okay.

Justin Avery: With Monotype, you just mentioned they manage Gridset app, which was built previous, and you&rsquo;re on that, so an application about making grids and taking the difficulty away from it which is good because I hate trying to make grids and that is very helpful. Typecast, which is more
around the typography layouts from a hierarchical point of view or design point of view rather than the actual grid layouts. Can you explain a little bit about what each of the apps do and how they crossover or complement each other?

Nathan Ford: Sure. Of course. Yeah. I&rsquo;ll start with Gridset because that&rsquo;s my baby. That app was basically designed right at the beginning of the whole responsive design movement if you want to call it that. It was just because we were making a lot of prototypes, and quick little mockups,
and stuff like that in HTML using Bootstrap &hellip; No, not Bootstrap, actually. Going back, way back to the 960 Grid System, and then &hellip; I can&rsquo;t remember some of the &hellip; Basically, frameworks.

Justin Avery: Yeah.

Frameworks are great. I think they&rsquo;re really good to get some ideas off the ground, but over time, you&rsquo;re very limited by what you can do with that

Nathan Ford: Frameworks are great. I think they&rsquo;re really good to get some ideas off the ground, but over time, you&rsquo;re very limited by what you can do with that, and so we wanted something &hellip; First of all, like 960 Grid System wasn&rsquo;t even responsive, so we wanted to build something
that just spat out like 12 columns responsively, and then we decided &hellip; Mark actually had quite a lot of background in graphic design, of course, and I do too.

I remember the days learning about the different grid systems and stuff that people would use classically. We thought, “What if we could just push it? Since it&rsquo;s programmatic, we can make it do all sorts of crazy stuff.&rdquo; We built something that allows you to make it your own framework,
your own grid system completely accustomed, so completely tailored to what the content is for your site.

That&rsquo;s the whole idea behind Gridset. It&rsquo;s just to make &hellip; Basically, make it easy to make responsive grid systems that are completely tailored for your content. That&rsquo;s Gridset. You asked about Typecast as well. Now, Typecast, I don&rsquo;t have as much to do with as how it&rsquo;s
created and everything. That was the team out in Belfast that used to be Design By Front, then they became Typecast and became solely that, and then they&rsquo;ve been acquired by Monotype as well a couple years back.

Typecast is a great product. I&rsquo;ve used it a lot. In fact, I had the pleasure of getting to work with those guys on quite a few new features right after the &hellip; We were acquired back in April of last year. I think Typecast is a great thing because it&rsquo;s very difficult to work with web
fonts right now, even right now, even how many years later. I think it&rsquo;s been about five, six years since they&rsquo;ve been really widely adopted. It&rsquo;s hard to go find what you need and test it with your content. I think Typecast does a great job of solving those problems.

Justin Avery: Yeah. I&rsquo;ve used Typecast a little bit with &hellip; I think I did that when I was looking for a job like a resume site and a portfolio site. That was good because I could just import all of the content that I had, and then just start playing around because I&rsquo;m a terrible designer.
Tools like that makes it quite a bit easier. With Gridset, does Gridset also &hellip; Are you able to put your content directly within the app itself and work out what kind of grid layouts work well with that?

Nathan Ford: No. No, not at the moment. It&rsquo;s something that I&rsquo;m looking at adding as a feature, so I still &hellip; Actually, we&rsquo;re on good sets, so that&rsquo;s just &hellip; It&rsquo;s my side project. It&rsquo;s not something that gets a lot of attention within Monotype, so I can
do what I want to with it, which is fine. As far as like how it works, the whole concept was really just to generate what is essentially a framework or what people think of a framework, but basically, a grid system. It&rsquo;s not going to decide your button styles, and your heading size, and things
like that, but just purely layout. It helps you generate grids for layout, and then you can take that.

You can basically grab a code snippet, add that into your site. You get a little bit of JavaScript that allows you to put an overlay on your site, and then you can start using classes to move things around. Basically, just like you would with Bootstrap, or Foundation, or something like that. The only
difference being this is exactly what you&rsquo;ve designed and exactly tailored for your content.

Justin Avery: Perfect. The other benefit is that &hellip; You touched on a bit earlier as well is a gain for people. I know when something looks nice, but I don&rsquo;t actually know how to get to that point. You have a whole set of well-predefined grids like well-known grids that work or have been
known to work in the past?

Nathan Ford: Yeah. Yeah. We did adapt a few templates that you can jump right into that are based on historic grids like the Gerstner, which is based on his &hellip; Karl Gerstner&rsquo;s design for Capital Magazine, the grid that he designed for them and &hellip; Back in the ‘60s, and things
like that. I&rsquo;ve never actually been super convinced about how many people are like, “Yeah, the Gerstner grid,&rdquo; but like at the same time, what we try to do is adapt them to make them very useful in a responsive environment and give you a lot of options, but not too many options.

That&rsquo;s the balance we try to strike with a grid is to have just enough options to get the job done for your content, but not too many because then when you start extrapolating this system and sharing it with others, people are going to abuse it and stops &hellip; The whole thing falls apart. That&rsquo;s
why I&rsquo;m not a big proponent of like 12-column grids or more than that because I think the less grids, the better because it provides clarity for your content.

Justin Avery: Like restrictions, right?

Nathan Ford: Exactly. Yeah. Yeah, there&rsquo;s less &hellip; Basically, the more options there are on the page for layout, then the less that the actual layout itself is going to feel like your site. Yeah. Really, the more restrictions you put on it, the more guidelines or I guess less guidelines you
give it, the better.

Justin Avery: Yeah. Where does it fit in from a &hellip; As a product owner, where does it fit in to a responsive design workflow or a redesign of a site if I was going to rebuild a site or a large company is going to rebuild a site? Where does the Gridset part of that fit in from your design approach?

Nathan Ford: We&rsquo;ve designed it to work at many different points of a workflow. Sorry. Are you still there?

Justin Avery: Yeah, yeah.

Nathan Ford: Sorry. My Skype just gave me this little notification that I was away. [I wasn&rsquo;t switched 00:11:50], so I know I&rsquo;m still here.

Justin Avery: No, we&rsquo;re still here. We&rsquo;re still [logged into 00:11:53] Skype.

Nathan Ford: Okay. Sorry. Yeah. Basically, yeah. We designed Gridset to work at many different points of a workflow. The idea would be that you come in and say, maybe just throw together a very simple grid just to start getting an idea together for a prototype or whatever. You could throw that together,
start working directly at HTML like a lot of us like to do these days, and put together a simple gray box prototype right in the browser. Gridset gives you the guidelines for that. It gives you the overlay for your site, so that you can actually see what you&rsquo;re doing and what columns you&rsquo;re
using.

Then over time, you can revisit your grid and keep saving out new versions of it, so that &hellip; Or basically republishing new versions of it that start fitting more closely to what your content needs, and you know that. You feel it as you&rsquo;re going, especially as you start increasing the fidelity
of whatever you&rsquo;re designing or building, and you start realizing that, “Oh, these images are just way too small. This needs to be a big image site,&rdquo; or, “This measure on this chunk of typography here is just too short. We need it longer.&rdquo; Things like that.

You just start noticing all these little problems, and then you can start tweaking the grid to fit that. From there, you can also see where the whole layout is breaking down as you&rsquo;re resizing your browser, and you can go ahead and start new grids for those different sizes and block off where
those grids lie within the different viewport sizes.

Justin Avery: Cool.

Nathan Ford: It&rsquo;s definitely a &hellip; It&rsquo;s a process. It&rsquo;s something that you&rsquo;re supposed to work through, and it&rsquo;s just there. You dip in and out of it as you go through your process, and that&rsquo;s how I use it.

Justin Avery: If those are &hellip; Taking it from someone in the backend and stuff that wanted to incorporate it as part of build process of their &hellip; Does spit out just flat CSS? Could you hook it up to a build process like global grunt? Does it have &hellip; Is it a Sass-based thing or a Less?

Nathan Ford: We have a theory with Gridset or &hellip; No, more of a mantra that is, “It&rsquo;s your design where you need it.&rdquo; Whatever you&rsquo;ve designed for the grid, we should be outputting it in whatever format you need it. Right? Over time, we have been building new and different
ways to access that data because all you&rsquo;re really doing is saving in a few data points that describe a grid, and then we just put it out. “Do you need it in an overlay, visual with your content?&rdquo; “Here you go. Here&rsquo;s some JavaScript.&rdquo; “Do you need it in your
Photoshop comps?&rdquo; “Here you go. Here&rsquo;s a PNG. You can do that now.&rdquo;

Also, if you need it for some sort of &hellip; Basically, what we consider, the real production phase. After you&rsquo;re past the prototyping and you&rsquo;re on to building out the site in an optimized manner, then we have a Sass output that you can use. When you&rsquo;re in the prototyping, you can
use a CSS link that we just host for you. As you&rsquo;re making changes, it happens immediately on your site, but for this &hellip; When you&rsquo;re at that point, when you want to optimize because we basically give you everything in kitchen sink upfront.

We don&rsquo;t advise that you actually use that in production, so you have the Sass output that you can just put in. It&rsquo;s a bunch of mix-ins and functions that you can &hellip; I think are pretty easy to use. A lot of people tell me they&rsquo;re pretty easy to use, so you can just then spit
out what you need from the grid.

Justin Avery: That&rsquo;s cool. As a product designer of a web app, a couple of the CIOs lucky enough to &hellip; I caught up with MailChimp and talked about &hellip; I get to use MailChimp in a weekly basis. I love it. I just really enjoy the interface. It&rsquo;s a nice web app to use, especially
how often I actually have to get in there and do things. One of the nice things is that it is very responsive, right? From the largest screen to the smallest, it just does some neat stuff and it just &hellip; It stacks appropriately, and it moves things around, and it&rsquo;s just a &hellip; It&rsquo;s
a well-thought-out app.

I was having a look at Gridset and &hellip; Do tell me if I&rsquo;m wrong, but when I was looking at Gridset and Typecast, Gridset looked like it was predominantly built for the desktop, and Typecast has a couple of responsive sprinkles in there, but it&rsquo;s still very desktop-y. The reason I asked
that is because a lot of people do ask, write in, or ping me tweets and say, “I&rsquo;m building a web app. Should I build it responsively, or should I build a native version of it instead?&rdquo; I just wondered if there&rsquo;s like a thought process that went into the design and the target devices
that you&rsquo;re looking at, and your thoughts around that whole what is a web app and should you make it native, or a desktop version, or responsive? There&rsquo;s a lot in that question. I do [inaudible 00:17:01].

Nathan Ford: Yeah.

Justin Avery: Go.

Nathan Ford: I think the jest of it is &hellip; Yeah. Do web apps have to be responsive? I definitely subscribe to the Jeremy Keith line of thinking that it depends. Right? I think what we need to do is basically look at what your user is trying to do and say, “Are they going to be &hellip; Is
it going to be useful in all these different environments?&rdquo; With Gridset, we didn&rsquo;t feel like it would be. Designing a grid for &hellip; Or a grid system, you have to incorporate grids for desktop and all the way down to mobile. Sorry, responsive grid system that is.

Trying to design an 18-column grid, which is the maximum for Gridset, on a mobile device would be really, really difficult and probably more frustrating than its worth, so &hellip; Just because of the screen real estate that you need to even &hellip; Being able to grab it with your thumbs. It&rsquo;d
be ridiculous, right?

Justin Avery: Yeah, totally.

Nathan Ford: We figured that Gridset for the most part would be a desktop experience. You could probably get away with it on mobile &hellip; I&rsquo;m sorry, a tablet, but mobile is a bit too small to actually get the job done. Typecast on the other hand, I think there&rsquo;s quite a few things you
can do with selecting type and trying type in a mobile environment. I think they&rsquo;ve done a decent job of that. I don&rsquo;t know. I think that basically, you just have to look at what your users are trying to do and make the decision from there.

Justin Avery: Good answer. It&rsquo;s well-rounded. “It depends&rdquo; is always such a good answer for these things too, isn&rsquo;t it?

Nathan Ford: Yeah, because I think one of the problems, I think, in the web industry that I&rsquo;ve seen in the last &hellip; I don&rsquo;t know. I&rsquo;ve been in it about eight years, is that too many people beat their drums about one specific thing, and they get really adamant about, “You
have to do this. You should do this.&rdquo; There&rsquo;s a lot of “should&rsquo;s&rdquo;. People hear a lot of “should&rsquo;s&rdquo; when they&rsquo;re learning web design. I don&rsquo;t know. Design should be more about finding the right solution for the problem, not “Am I meeting
everybody else&rsquo;s expectations?&rdquo;

Justin Avery: Yeah. Over the year, the last &hellip; Talking about when you first started, it was at Foundation that you were first working? When you first started, you were saying it wasn&rsquo;t quite Bootstrap, it wasn&rsquo;t quite 960. Was it Foundation, or was it something else?

Nathan Ford: I think it was 960. Yeah.

Justin Avery: Yeah.

Nathan Ford: It was 960. Yeah.

Justin Avery: When these guys started releasing all of these foundations, and Bootstrap, and stuff, it was &hellip; They were trying to release modules or design modules, and you have the atomic design stuff that Brad is doing as well. Do you have any thoughts around that as a web designer and someone
who designs responsive layouts and responsive sites? What are your thoughts around this whole approach of modular design rather than designing from the outside in, they do it from the inside out?

I believe totally that the web is completely suited for modularity, which makes it a very interesting
design problem

Nathan Ford: Yeah. I actually wrote an article for A List Apart last year about content-out layout, which is a term that was coined by Mark Boulton who I used to work with or I still work with actually. Sorry. I just recently moved back to Dallas. I&rsquo;m not in the same office with him every day,
but yeah. We still work together. Yeah. The whole idea of the article was, “Yeah. How do you start with the elements of your design, the content itself, and how do you build out from there?&rdquo; I believe totally that the web is completely suited for modularity, which makes it a very interesting
design problem because designers have always had &hellip; Not always, I guess, but at least from my experience.

In print design, you have very set dimensions, which is pretty comfortable, and you can figure out how to carve up the space in unique ways and functional ways. With the web, that&rsquo;s always changing. It&rsquo;s actually the advent of responsive design. You have to start thinking about a new way
of approaching a canvas, and that was Mark&rsquo;s whole idea was content-out. That&rsquo;s what I think with grid systems actually, the way they fit in really well is that you can go both ways.

You can carve up the available space with a &hellip; What I call a “layout grid&rdquo;, and you can carve up your content or you can create relationships within your content with what I call “content grids&rdquo;. Like a content grid being the relationship of an image to a piece of text
next to it. Should the image be twice the size of the piece of text? Should it be maybe ratio-based on &hellip; The golden ratio, something like that? That&rsquo;s basically what you would call a module, so it&rsquo;s like a small modular grid.

Justin Avery: It&rsquo;s looking at it like an item of news, and then otherwise, long list of news items. Right? A little image that goes with the title description?

Nathan Ford: Right, exactly. You can build like a small grid that will handle all of your use cases for that type of content, and then place that within a larger grid that can handle what to do with the available space.

Justin Avery: Cool. Is the ideas and thoughts based upon &hellip;? I don&rsquo;t suppose it is based upon the technology that&rsquo;s becoming available, right? I&rsquo;m thinking more in terms of in the upcoming specs that are around. We&rsquo;re looking at Flexbox?

Nathan Ford: Mm-hmm (affirmative). Yes.

Justin Avery: Then also, there&rsquo;s the grids, layouts as well, specifications.

Nathan Ford: Yeah.

Justin Avery: Is that along the &hellip; Do you the spec writers have gone, “Well, that&rsquo;s probably the best way to approach it,&rdquo; or do you think people are looking at specs and going, “Well, this is probably the best way to approach it from a design point of view.&rdquo;?

Nathan Ford: I honestly don&rsquo;t know. Actually, I think one of the reasons I&rsquo;ve been so attracted to product management is that it&rsquo;s more about building and testing, and then seeing what happens. That&rsquo;s how I&rsquo;ve always approached things on the web as well. That&rsquo;s why
I think the Standards Movement was a great thing, but that was standardizing stuff that was already there, which is always, I think, a good thing. It&rsquo;s simplification. It helps people learn. People are able to get up to speed a lot faster on what to do on the web.

Now, we&rsquo;re at a point where we&rsquo;re writing solutions for things that haven&rsquo;t really been well-tested yet. We don&rsquo;t know the problems yet. I think that&rsquo;s a problem that we&rsquo;re seeing with layouts. Flexbox is really interesting, and I think it&rsquo;s great. That&rsquo;s
something I think is more closer to the fabric of what the web is built off; whereas the grid layout module seems to be more, I guess, focused on what print designers would expect to be on the web. It&rsquo;s not really &hellip; To me, it doesn&rsquo;t seem as flexible or as new and interesting. It doesn&rsquo;t
create as many new possibilities for what the web needs. It&rsquo;s just like, “Here&rsquo;s the way to do grids.&rdquo;

Justin Avery: Do you think it&rsquo;s &hellip; Are we trying to put a spec around something which we think should be there rather than it being helpful?

Nathan Ford: Exactly. I think it&rsquo;s instead of being born of need from saying, “This is how the web works. I keep coming into these problems, and I&rsquo;m trying &hellip; I need to solve this problem with something that&rsquo;s not there yet,&rdquo; it&rsquo;s more saying, “Okay. What
will people have a problem with? Let&rsquo;s try to think about that, and then try and create a solution for imagined problems,&rdquo; or at least they&rsquo;re not imagined. It&rsquo;s definitely more practical than that, but it&rsquo;s &hellip; I just feel like we haven&rsquo;t quite understood the
problems well enough yet to write a spec that&rsquo;s going to solve it all.

Justin Avery: Is it like, “These are the problems we had from the print era. Let&rsquo;s apply the same thinking to a solution that we perhaps might need in the web era.&rdquo;?

Nathan Ford: Yeah, something &hellip; Yeah, like that.&nbsp; I guess what I&rsquo;ve always seen is that there&rsquo;s been that hangover in web design from print where it&rsquo;s like, “This doesn&rsquo;t work like print. Let&rsquo;s make it work like print,&rdquo; which doesn&rsquo;t excite
me. I think that there&rsquo;s &hellip; The web is such an interesting new medium that we need to really explore, and really understand the nature of, and start just embracing. I think that&rsquo;s what the whole responsive design thing was.

As people realizing, “Holy cow, we can actually make designs that adapt to their environment,&rdquo; and then it&rsquo;s gone crazy from there. There&rsquo;s all sorts of weird solutions and stuff popping up, but that&rsquo;s exciting. That&rsquo;s what&rsquo;s a lot more fun. Trying to standardize
it at this point is almost like putting a cap on it.

Justin Avery: Yeah. Let&rsquo;s just say we had the power. We fired XE, and we fired [Tabakens 00:26:09]. Although, they do, do a very good work, so we wouldn&rsquo;t actually do that, but &hellip; And then you&rsquo;re the product manager of the web.

Nathan Ford: Okay.

Justin Avery: You&rsquo;ve got the CSS specs and HTML specs in your hand. How would you approach it?

Nathan Ford: That&rsquo;s a gigantic question.

Justin Avery: It is massive, isn&rsquo;t it? Sorry about that, Nathan.

Nathan Ford: Yeah. I feel like even answering it is a big self-aggrandizement, but &hellip; No, I &hellip;

Justin Avery: You walk away from the job.

Nathan Ford: Yeah. Actually, in many ways, yes, I would. I&rsquo;d just leave it in the hands. I think that that&rsquo;s what&rsquo;s so interesting about the web is there is no one central control. You just let it bubble up. The anarchy of it is what makes it work so well, and so trying to control
it, I think, is a problem. I guess that&rsquo;s where my renaissance with standards comes from. I&rsquo;d rather see things really &hellip; Let me them be messy for a while and let them play out, and then start trying to standardized when we have really good understand &hellip; When we understand the
problems really well and we have a pretty good understanding of what the solution would look like.

Justin Avery: Yeah, good. I was wondering if I gave you enough rope, whether or not you&rsquo;d make a nice noose, but no. That was nice. That&rsquo;s good. Sorry about that.

Nathan Ford: That&rsquo;s all right.

Justin Avery: Matt Griffin recently wrote an A List Apart article as well, and he was talking about his experiences designing with a new form factor. It&rsquo;s probably not new, but the Apple Watches come out now. Do you see that affecting the industry and designers in the same way that the release
of this like the iPhone or the tablet has affected as well? Do you think there&rsquo;d be a change in approach, or is it as big as what people are building them up to be?

Nathan Ford: I think in many ways it&rsquo;s a pretty big shift, and this is just my personal opinion. I&rsquo;m not an expert on any of this though, but I think &hellip; I&rsquo;m interested to see how &hellip; Every time something like this comes out, I&rsquo;d go, “No, I would never use that,&rdquo;
but I&rsquo;ve started learning in my 30&rsquo;s now, I&rsquo;m getting so old and wise, that I shouldn&rsquo;t be so quick to react. Just let it play out, and I think it&rsquo;s &hellip; So I&rsquo;m pretty sure my gut reaction is like, “I&rsquo;m never going to use a smartwatch,&rdquo; but who
knows?

There will be that one or two features that come out, and I&rsquo;ll be like, “Oh, now I need one.&rdquo; The same thing happened with the iPhone and everything else or smartphones. I think there are ways that this is going to play out that are going to be very interesting. Now, I&rsquo;m not
sure right off the bat though that it&rsquo;s going to have a web browser. Is it, the app? Last I heard &hellip;

Justin Avery: Yeah. I think it will. I want to say it will because I&rsquo;m very sure. When Matt was running through his testing, he had &hellip; He called up to see how something would look across it. Maybe I&rsquo;m wrong.

I think the smaller the screen,
the less you had to concern yourself with layout. You had to use other tools, so color, and type, and typography are going to be basically all we have to work with.

Nathan Ford: Yeah. I&rsquo;m not sure. Now, readability on something that size is going to be a really big challenge for typographers, which again, challenges are interesting. Right? I think that&rsquo;s where the real challenge lies is, how do we create something readable? I think the smaller the screen,
the less you had to concern yourself with layout. You had to use other tools, so color, and type, and typography are going to be basically all we have to work with.

Justin Avery: Yeah. I think you&rsquo;re right. I don&rsquo;t think it has a browser.

Nathan Ford: It will eventually though.

Justin Avery: Yeah.

Nathan Ford: Everything that you can put a browser on will have a browser eventually.

Justin Avery: I&rsquo;m actually surprised that it doesn&rsquo;t have one, at least a very basic one included.

Nathan Ford: Yeah. I think there&rsquo;s just all sorts of usability issues there when it comes to browsing the web as it is now.

Justin Avery: Yeah, but it&rsquo;s Apple. Surely, they would have come up with new ways to double-tap, quick move with a brand new approach to swiping through websites.

Nathan Ford: Yeah. I think some of the other smartwatches have attempted it at least. I&rsquo;m not sure how successful they&rsquo;ve been.

Justin Avery: Maybe not very successful if Apple have chosen to leave it off.

Nathan Ford: Yeah, yeah. It&rsquo;s definitely one of those things where you can go to market. It&rsquo;s not a crucial feature, so you can go to market with something that&rsquo;s still going to be very &hellip; It&rsquo;s still internet connected. It still got all of your information in the cloud
coming down whenever you need it in a very accessible interface. It&rsquo;s just not going to have the web.

Justin Avery: Yeah. Hey. You recently spent a lot of time putting together the Gridset App Report for Responsive Design from last year. Thank you very much in behalf of the community in the internet for doing that. Before I do, I want to ask a couple of questions around the findings of that and stuff.
We met building products to help designers be able to create responsive designs a bit easier with things like Macaw, and Webflow, and Web DO, and &hellip; What else is there? There&rsquo;s FROONT. A whole bunch of systems that are there or new tools and stuff. Have you checked them out? Have you tried
them out? Do you think they&rsquo;re on the right path, or are we still missing a few key things to make the process easier?

Nathan Ford: It&rsquo;s a good question. I have strong opinions on this, but that&rsquo;s only because I&rsquo;m in the space and I&rsquo;ve been working on apps here. Yeah. I actually wrote an article awhile back for Net Mag a couple years ago like back &hellip; Right around the time we launched Gridset,
and I was hailing the idea of small tools that get like one simple job done, and Typecast being one of them. At the same time, about the same time, BrowserStack came out, and that was a really cool little tool to get one thing done well. It&rsquo;s just solving a real need.

I feel like sometimes like the reason Adobe hasn&rsquo;t been able to crack the one web design tool to rule them all. Some of these other guys are doing a valiant job out of it, but they&rsquo;re not quite getting there. The reason is, is because they&rsquo;re trying to do too much. Working
responsively has just cracked this wide open. Web design involves so many different moving parts, so many components, and is quite a complicated workflow when compared to like traditional design just because there&rsquo;s so many different stakeholders involved and so many different expertise that need
to be known to get the job done properly.

I just think that this kind of idea of one big app to do it is not the right way to go, but that&rsquo;s just my opinion. I&rsquo;m not going to step on anybody and say, “Oh, they&rsquo;re doing it wrong,&rdquo; because that&rsquo;s silly. I&rsquo;m glad to see people are out there. I&rsquo;m
downloading every new app that comes out, and trying it, and really excited about it, but I think that so far, I think finding these little gap tools that help you like &hellip; A lot of web designers already know how to write code, so they can do that. A lot of web designers already know how to use
Photoshop, or Fireworks, or Sketch, or something like that. I think what we really need are these little connective pieces, things that help us do these difficult parts better.

Justin Avery: One thing that I do like within &hellip; I think it was FROONT. Have you seen that one, the FROONT, F-R-O-O-N-T?

Nathan Ford: I get a lot of emails from the, so I&rsquo;m guessing I&rsquo;ve used it at some point in time.

Justin Avery: Probably, yeah. One of the things that I do like about their approach is that it was an interesting approach from like a &hellip; It&rsquo;s probably more of a mantra again. You&rsquo;re talking about it earlier is that he &hellip; They wanted it to be a toolkit for people to be able to
create really nice modules, and then put that back up for other designers to learn from and reuse. Almost like a free marketplace of, “This has worked really well for me. You could also use this.&rdquo;

I like the idea of that like &hellip; I think of it like an OmniGraffle which I use for wireframing and stuff. You could download like a sketch sheet, and you could just drag and drop elements on the page to test them out and wireframe something back when we&rsquo;re doing static wireframes. The ability
to do that to put together a proof of concept, maybe not a final design.

Nathan Ford: Yeah.

Justin Avery: I like that idea.

Nathan Ford: Yeah. I think that&rsquo;s a cool idea. There&rsquo;s only so many ways you can put an image next to a text with a headline. There are very established patterns, and I&rsquo;ve always &hellip; I guess I need to go back and check out that in more depth because I&rsquo;ve always thought that&rsquo;s
a missing tool, some way to share modules, or patterns, or whatever you want to call them because yeah, there&rsquo;s only so many ways you can do it right.

Justin Avery: Yeah. Yeah. I don&rsquo;t know how well it&rsquo;s been executed. Like you, I get a lot of emails from a lot of different things, but yeah. That was just one thing that stood out from those guys. Yeah. The other thing that I&rsquo;ve got, which popped up a couple of days ago actually as
I was chatting on a forum with a couple of friends, and they were finding it difficult or they were working as a designer, freelancing for a company who wanted to do agile web design, or agile design, or design in an agile environment as well. Have you ever looked at the processes or workflows around
how that&rsquo;s accomplished?

Nathan Ford: What? Agile?

Justin Avery: Yeah, from a &hellip; But more from like a web design point of view. Building or designing things within sprints rather than &hellip; Because the traditional thing is you come up with your wireframes, you design based upon those and the content that you have, and then someone develops
it and builds it, and then it&rsquo;s shipped out just because you needed those signoff points, right, from clients.

Nathan Ford: Right.

Justin Avery: Have you seen that change a lot in the recent years, and how are you &hellip; Because you worked with Mark Boulton Design before? Also, did client work as well, not just internal apps and stuff?

Nathan Ford: Right.

Justin Avery: How did you find that process, or did that process change for you at all, or was it always waterfall?

Nathan Ford: No. I&rsquo;m pretty sure that Mark Boulton and I, we popularized the idea of working agile in design. I know Mark talks about it a ton, and it&rsquo;s something that I learned, I picked up when I first got there. Between him and the other people that worked there, we&rsquo;ve really refined
it down to something that worked really well for us.

Yeah. Like you explained, working in sprints with design actually was quite nice, so we would start with &hellip; Basically, we took a lot of what worked about agile, what we liked, and pieced it back together into a design process. Giving some space for design to work because that&rsquo;s one of the
problems with combine &hellip; Just mashing together agile and design would be &hellip; Design has to turn on a dime. Sometimes, it doesn&rsquo;t get that opportunity for inspiration, or to grow, or for the designers to really think about a problem.

The other thing is we wouldn&rsquo;t start until we had content which really makes a difference as well.

What we&rsquo;d do is &hellip; I think some of the key things that we did that worked and actually that we&rsquo;re still doing that works, only from Monotype, would be &hellip; We&rsquo;d write up a bunch of user stories with the client, so we understood the full breath of what needs to be done. That
was always a very enlightening process, but it usually took a lot of time. Then, we actually knew what was on the table, and then we&rsquo;d pick up pieces of that every sprint. We&rsquo;d be very clear about what we&rsquo;re going to do each time. We&rsquo;d work in prototypes, so live prototypes that
work. Basically, grey box websites in HTML and CSS, and we just build everything out.

The other thing is we wouldn&rsquo;t start until we had content which really makes a difference as well. From there, we just start increasing the fidelity as we went. We&rsquo;d do some design explorations in parallel with the production of the &hellip; Or with the &hellip; Yeah, the production of these
prototypes that define the information architecture, the layout, the hierarchy of information, what content we absolutely need, and the tone of that.

All of that was progressing in one line, and off to the side, we&rsquo;d pick up these comps and work either in Style Tiles or full comps, depending on the comfort level of the client, and progress what would be the design language, and then inject that back into the prototype to increase the fidelity
of retirement till we had a product at the end. That really worked well for us. I think that was a way that we found to adapt the ever-changing needs of a project because some of our projects lasted for three years. A lot of changes in three years.

Justin Avery: Yeah. I remember Mark not being a huge fan of atomic design because the idea of designing such a small element without seeing how it fits within a hole didn&rsquo;t make sense.

Nathan Ford: Yeah.

Justin Avery: If you&rsquo;re running the sprints, do you sprint as try and get the entire website laid out before you start detailing like the functionality of a news page or a news listing? Otherwise, I could imagine getting into that same problem of, if one sprint is all about &hellip; I don&rsquo;t
know, doing the news and the blog section that you designed for those, but then lose sight of what the homepage is going to look like or all the other areas.

Nathan Ford: Yeah, that&rsquo;s always a problem. What I just described in just a couple of minutes sounded pretty encapsulated and easy, but actually, it was a big mess all the time, right? We were always running around from one &hellip; Jumping from one discipline to another to make sure that what
came together as a whole made sense. Yeah. I completely agree. You can&rsquo;t just design a very &hellip; There&rsquo;s a level of detail that you&rsquo;re just too small to design anything, really. You really do have to find that right balance somewhere in the middle where you&rsquo;ve got enough information
to piece together something that&rsquo;s cohesive, but then also, you have the broader picture of how everything is going to come together in the end. It&rsquo;s always a balance.

Justin Avery: Yeah. You almost need someone &hellip; You always have someone running the project, right, but someone who has that vision, right, the way through that can bring everything together at the end?

Nathan Ford: Yeah. Each of us, the way we run things, every designer had full reign of what they were doing. I was Creative Director at Mark Boulton Design, so I would jump in and just help people here and there when they get stuck. Same with Mark, that was also something he really enjoyed with jumping
in and helping us get past points where we couldn&rsquo;t really see what the next step was. Yeah. I think everyone of us learned over time how to pull it all together, and it was really just because created an environment where we didn&rsquo;t have a lot of signoffs.

What we said is every &hellip; “For two weeks, we&rsquo;re going to work really hard on this. What we have at the end of that time is &hellip; It doesn&rsquo;t have to be final either.&rdquo; It&rsquo;s just we&rsquo;re going to go move the ball forward. It was never about, “You&rsquo;re
going to get 100 pages with a high-level of design in 50 days.&rdquo; It was never something like that. It&rsquo;s more like, “Your problem will be solved over time.&rdquo;

Justin Avery: I imagine a lot of this is solved by being upfront with clients and &hellip;

Nathan Ford: Yeah.

Justin Avery: I suppose making them aware of how you&rsquo;re working, and how the web works, and how a responsive project is run like having a good client understanding is probably 90% of the issues asserted.

Nathan Ford: Yeah, and we were so lucky to have some excellent clients that just &hellip; Basically, our whole philosophy was to get embedded. Basically, become part of their team. That&rsquo;s what we did. We were like a whole functioning team, half us, half them. We would work our problems that way,
and it works so much better.

Justin Avery: That&rsquo;s such a good approach. Thank you for that. That was just off the cuff. I just wanted to know myself, so hopefully it&rsquo;s okay to find out as well.

Nathan Ford: I do think it&rsquo;s very important for responsive design because it has completely destroyed our workflows and our traditional ways of working with design. It&rsquo;s important that we all share and talk about these things because it&rsquo;s not the really exciting stuff. It&rsquo;s the
nuts and bolts stuff that actually helps us get the job done.

Justin Avery: Yeah, and it&rsquo;s supposed to like &hellip; You could design three widths, right? Go desktop, tablet, and mobile, and you could have them in full comp and get them all signed off, but I&rsquo;ve not seen a single project which has done that, end up when you actually built it on those
devices go &hellip; Actually, that doesn&rsquo;t work at all.

Nathan Ford: Yeah.

Justin Avery: Let&rsquo;s change this around. Yeah.

it&rsquo;s
always going to look good full width in your desktop and on your mobile, but you just get to those random little awkward places and just see what happens because usually, it just falls apart.

Nathan Ford: One thing I love to do is to go &hellip; Anytime there&rsquo;s like a big, new responsive redesign like go to the site, go about halfway down, pull your browser to some random size, and just see what happens because it&rsquo;s always going to look good at the top of the page and it&rsquo;s
always going to look good full width in your desktop and on your mobile, but you just get to those random little awkward places and just see what happens because usually, it just falls apart.

Justin Avery: An afterthought, just get it live. Just get it live. Deal with it afterwards.

Nathan Ford: Yeah. Ship it, ship it.

Justin Avery: Shipping is good.

Nathan Ford: Yeah.

Justin Avery: Iterations, that&rsquo;s the best thing about websites, and the best thing about working on a project, I think, is that if you can get the client to buy in on this as well. It&rsquo;s not a final product. When you release it, when you go live, that&rsquo;s the first iteration of it. You
change it many, many times.

Nathan Ford: I agree.

Justin Avery: Now, you recently spent a lot of time putting together this Responsive Report on Responsive Design from last year?

Nathan Ford: Yes.

Justin Avery: Can you just give us a bit of background to what the report is and what you guys or you have been trying to accomplish with that?

Nathan Ford: Sure, of course. It started in 2012 actually. Mark put out a survey to help him get some background on a presentation that he was doing, and so he basically just put it aside, and then he did it again for another presentation about a year later. We had this like wealth of data in like &hellip;
I think it&rsquo;s like something like 400 people answered the first, and 500 answered the next one, and we were just like, “This is very useful.&rdquo; Especially, building a &hellip; I&rsquo;m sorry. This survey was specifically focused on responsive design and workflow problems, things like
that.

I was very interested to look at it just because it happened to &hellip; We built Gridset for that, so it is really a good bit of data for us to look at. Then, we just took that and said, “Okay. Well, other people might find this useful too.&rdquo; I think one of the main things is when you&rsquo;re
going through something difficult, to know that other people are going through the same thing really helps, right?

Justin Avery: Yeah.

Nathan Ford: That was the story of the first report. When we dug through the thousand responses over two years &hellip; Sorry. It didn&rsquo;t take us two years. It took us a couple of days, but responses came in over two years. We merely saw this story of people being stressed out, really excited about
this sea change within the industry and the way we&rsquo;re doing things, but frustrated, lonely like all these negative emotions. We decided to put together this report and share it with everybody, and to see if it&rsquo;s useful for people. It got a really good response.

The whole theme of the 2013 report was this agitation and frustration, just to commiserate with others, fellow designers going through this. Because it had a really good response, it got us in talking with Ethan Marcotte, and you, and a lot of other people that were interested in how responsive design
is progressing as a bigger idea, and so we decided to go ahead and do it again. We put out a survey in October. Thanks to you, and Vitally at Smashing Mag, and Net Mag, and a few others, and of course, Ethan getting the word out, we got a tremendous response.

We doubled our response rate this year, and then we put together a report this year, and this year has &hellip; The whole design and theme of the report is more about leveling up, being a lot happier with what we&rsquo;re doing because we&rsquo;re getting to a better place. Now, we&rsquo;re just seeing
the proliferation of responsive thinking in new areas, which is pretty exciting.

Justin Avery: That&rsquo;s really cool. It does seem like it from the report, people are feeling better about responsive design as a whole. What do you think has changed over the three years?

Nathan Ford: Really, we&rsquo;ve worked out processes, so I think one of the main problems we saw in 2012, 2013 was workflow. A lot of people didn&rsquo;t know how to work responsively, and a lot of great ideas have been put out about that, and a lot of people have shifted their mindset, and they&rsquo;ve
probably &hellip; I don&rsquo;t know if anybody is subscribing to one idea or another, but they&rsquo;ve taken piecemeal and pieced together their own workflows that worked for their teams. I think that&rsquo;s what the main difference has been.

I think there have been some great tools that have come out as well, but I think mainly, it&rsquo;s just people finding what works for them. Like with any change, it takes a little time to get comfortable and used to it, and then, you&rsquo;re back to doing your day-to-day work. It&rsquo;s not as much
of a grind.

Justin Avery: Yeah, that&rsquo;s very true. I was going to say big thanks to you and to everyone that has written articles about workflow as well because that&rsquo;s how we learn. Right? We make mistakes. We blog about how badly we&rsquo;ve done in a particular thing and how we would have done it better
the next time. Then when something is successful, we tell everyone about it, and we all learn. That&rsquo;s too fun and amazing that we do that. Although, we&rsquo;re the only industry that does that.

Nathan Ford: Yeah. I think we are. A lot of industries are very guarded, but the web started as a free thing for everybody to quote Tim Berners-Lee. I think you&rsquo;re doing it wrong. This is the only time I&rsquo;ll say you&rsquo;re doing it wrong. If you&rsquo;re trying to keep all that stuff bottled
up to yourself, [you&rsquo;d be sharing 00:50:16].

Justin Avery: Yeah, yeah. Totally. I just cannot think of like a sponsor or a builder just going, “You know what? I found the best, cheapest, most awesome way to do this house. I&rsquo;m going to tell all my builder friends how to do that.&rdquo;

Nathan Ford: Yeah. It&rsquo;s unfortunate like that other industries can&rsquo;t work that way. We are very fortunate that ours works through sharing.

Justin Avery: [Inaudible 00:50:41]. Is the speed of the industry that we&rsquo;re working in moving forward so quickly because of the whole Morse Law thing and we&rsquo;re working in technology, or because of the fact that we are sharing so much?

Nathan Ford: If I were to pick, I would say probably because we&rsquo;re sharing so much. I think we just can &hellip; We can build upon things. I was actually reading a really good book on this called “Where Good Ideas Come From&rdquo;. The whole concept behind it is &hellip; I can&rsquo;t remember
what his background was, but it&rsquo;s this guy who wrote &hellip; Was really investigating how good ideas happen in the world.

when you have these environments where ideas can combine very loosely, then you see innovation and things progress much faster.

The whole idea was basically that when you have these environments where ideas can combine very loosely, then you see innovation and things progress much faster. Actually, and he took it all the way down to like the scientific level like evolutionarily, but all the way in the back into like the design
process and things like that. It&rsquo;s a really good book, “Where Good Ideas Come From&rdquo;. Great book.

Justin Avery: Shoot us a link to that. I&rsquo;ll add it to the show notes as well.

Nathan Ford: Yeah, will do. Yeah. That&rsquo;s what&rsquo;s happening with our industry is that we have this loose connection between people where we can just share it as freely. There&rsquo;s not too much control or anybody telling us how to do it, and so we&rsquo;re coming up with all sorts of crazy
stuff, and we&rsquo;re progressing very fast because of it.

Justin Avery: Yeah, it&rsquo;s cool. As part of the findings of the report &hellip; And everyone should go and check that out, by the way. What&rsquo;s the URL again?

Nathan Ford: It&rsquo;s 2014.report.gridsetapp.com.

Justin Avery: There you go, so go check that out and have a look at Gridset while you&rsquo;re there as well, but that link will be in the show notes. As part of the report, you mentioned or you&rsquo;re looking at the forecasting for next year, and you pit out two elements, which was speed and business.
Now, a friend of mine, Chris, has asked a question about speed, but could you go into a little bit more detail about what you mean by “business-ing&rdquo; with regards to the Responsive Report?

Nathan Ford: I think one of the most interesting trends &hellip; So what we try to do is provide the report &hellip; Let me back up. Emma Boulton, Mark&rsquo;s wife, her whole background is research. She used to be a researcher for the BBC. She understands how to do research. She brought that to our
team, and it&rsquo;s been tremendously helpful. She helps us with this every year. She&rsquo;s basically taught us, “Present a report without a lot of thought in it like &hellip;&rdquo; Sorry, that sounds terrible. No. Present a report that is very neutral.

Here&rsquo;s exactly what we saw an objective, and then let people drive their own whatever, conclusions from that. We don&rsquo;t harp on the trend that we put in there, but we do try to isolate a couple of things that, “Hey. If you hadn&rsquo;t been looking for it, here&rsquo;s something that&rsquo;s
interesting.&rdquo; I do think that what we&rsquo;ve seen in this latest iteration of the survey and the report is that more people within organizations are paying attention to responsive design, and these people are project managers, business owners. They&rsquo;re the ones that are starting to worry
about this kind of stuff.

They&rsquo;ve heard about it. They&rsquo;ve learned about it. They&rsquo;ve read about it somewhere, and they&rsquo;re asking the designers about it, or on the agency side, the higher-ups in the chain are selling this now to clients and things like that. It&rsquo;s becoming a very &hellip; Or they&rsquo;re
finding out that, “Hey, we can&rsquo;t do this as fast as we used to because of this thing called the ‘responsive design&rsquo;.&rdquo; There&rsquo;s so many more people that are involved in it now that we need to understand it. It&rsquo;s not just going to be the developer and designer thing
anymore. Really, developers owned it for quite a while, and designers have tried to adapt to it from what we&rsquo;ve read in the surveys. Now, we&rsquo;re going to have all sorts of people we have to explain these ideas to.

Justin Avery: Yeah. For a question for any freelancers or people looking to get &hellip; Start a business on their own, what advice would you give to anyone starting out on their own or getting into freelancing based on what you found in the survey to give them a leg up?

Nathan Ford: Let&rsquo;s see.

Justin Avery: Like things to focus on or areas which are in most need.

Nathan Ford: I think actually what &hellip; It pains me to say it because I&rsquo;m a designer that does frontend development as well, and I always have and I&rsquo;ve always felt this. The best way to be a web designer is to do both, to be this hybrid, but there&rsquo;s really a growing need for frontend
developers that know all of these stuff inside and out, and that&rsquo;s where I think &hellip; Right now, if you will look at the trends on the report you can actually click through and see how things have grown over time in the audience that&rsquo;s been answering this survey, and we
break it down by role. We break it down by organization.

You can see that frontend developers are &hellip; That role has been growing more and more each year, and everything else has been shrinking, and we&rsquo;re adding a few new things at the end. I would say really know yourself on the frontend because there&rsquo;s not always going to be a design job
opened up. I&rsquo;ve seen this in my career. Designing is not always &hellip; Or the design role is not always opened up quite as often as frontend development like there&rsquo;s &hellip; Somebody always needs something coded. Right?

Justin Avery: Yeah.

Nathan Ford: Or marked up, I should say. I say make sure you really know that, and then you can learn design. The principles of design are not really difficult. It&rsquo;s just doing it over, and over, and over again, and learning from that. That takes time, but frontend development, you can pick that
up, and you can be immediately very useful both to your client and to a team if you decided to work it out somewhere.

Justin Avery: Yeah. I think one of the things as well is that even frontend designers can design, right? It might be bad design, but some design.

Nathan Ford: Yeah.

Justin Avery: You need at least to list a bit of understanding of frontend to be &hellip; You can&rsquo;t just type random characters into a notepad, and then hope a webpage pops up. Although the web is very forgiving, but JavaScript is a little bit less.

Nathan Ford: Yeah, yeah. Yeah, definitely. Markup is a wall for a lot of designers. If you can get over that, then you&rsquo;re in good shape.

Justin Avery: Yeah. I always try to encourage the designers that I&rsquo;ve worked with in the past and will continue to as well to just like learn a little bit of HTML and a little bit of CSS. Just having that understanding, I think, will make the better designers. Although, it&rsquo;d be essentially
what your thoughts are. I saw it with a designer who flatly refused. His reasoning was that if he understands limitations of it, he&rsquo;ll be less of a designer because of that.

Nathan Ford: Absolutely not. You have to know your medium. When I was in school, we learned how ink lays down on paper. There&rsquo;s just no reason to not understand. To be ignorant of it is just &hellip; It&rsquo;s just trying to make your job easier while making somebody else&rsquo;s harder, and
I don&rsquo;t agree with that.

Justin Avery: Good.

You can still be imaginative, you can still come up with excellent solutions, but they have to be grounded in reality.

Nathan Ford: You can still be imaginative, you can still come up with excellent solutions, but they have to be grounded in reality.

Justin Avery: It&rsquo;s the good solutions. The layout, and the interactivity, and the way the data was displayed in the report is responsive and also very good. Was that your design chops on that one?

Nathan Ford: Yes, that was me. Yeah.

Justin Avery: Did you code that as well?

Nathan Ford: Yeah. I built it all from the beginning, even the JavaScript for the asymmetric graphs and stuff. Yeah. That&rsquo;s just like &hellip; It&rsquo;s my pet project. The last couple of years, I leave that aside for myself to do because I don&rsquo;t &hellip; I talked about my progression in
my career earlier. As that&rsquo;s happened, I&rsquo;ve gotten to do less and less design. You know?

Justin Avery: Yeah.

Nathan Ford: That&rsquo;s just how things go. I rely on the people I work with to do a lot of design. They do a great job, but every now and then, I just want to take something and do the best I can with it. It was a lot of fun.

Justin Avery: That&rsquo;s awesome. It is. It is lovely, and so everyone should go and check that out. The link will be in the show notes as well. Nathan, it&rsquo;s come just on the hour, so I&rsquo;ll wrap things up. I do have one more question for you, and in turn, I&rsquo;ll get you to ask a question
as well. Each week, I get the guest to ask a question of the upcoming guest. Last week, we had two guests on from Airbnb. They had two questions, so lucky you. The first question was, will Microsoft ever have a chance to enter the mobile device market successfully?

Nathan Ford: I have no idea. They&rsquo;re Microsoft. I&rsquo;m sure they&rsquo;ll find a way. They haven&rsquo;t really been held down for too long in any area, so sure.

Justin Avery: Yeah, and they bought Nokia, didn&rsquo;t they?

Nathan Ford: Right. Yeah, that&rsquo;s right.

Justin Avery: Yeah, so surely. Nokia know a thing or two about mobile devices as well.

Nathan Ford: Yeah, I&rsquo;ve actually &hellip; I spent a week using a Windows 7 phone.

Justin Avery: How was it?

Nathan Ford: The Nokia one that came out &hellip; Jesus, couple weeks &hellip;

Justin Avery: The Lumias?

Nathan Ford: Yeah, yeah. I think it&rsquo;s the first Lumia or something like that. It&rsquo;s just the first Nokia Windows 7 phone, and it was amazing. I really actually liked it. The form factor of the phone was excellent. The feel of the OS was great. I&rsquo;m surprised it hasn&rsquo;t taken off,
actually.

Justin Avery: Yeah, yeah.

Nathan Ford: Whatever. I don&rsquo;t predict things.

Justin Avery: Are you normally an iOS or an Android?

Nathan Ford: I&rsquo;ve used all of them, actually. I was on Android for a few years, and I&rsquo;m on iOS now mainly because that&rsquo;s what work gives me, but I like them all. I find it interesting just to see different takes on how things are built. Yeah, so I&rsquo;m not much a picky.

Justin Avery: And always good for testing as well if you have a few other devices lying around.

Nathan Ford: Totally. Yeah.

Justin Avery: The other question that &hellip; So the first one was from Fiona Tay, and the other one was from Mike Fowler. He was asking &hellip; He had [Tabakens 01:02:04] come and do a talk. He talked about movements to make CSS more pluggable, so you can in the same way that web component is trying
to allow you to write your own custom components that you can plug in as HTML that you can write your own custom CSS that you can plug into CSS. He asks, have you read any of the latest CSS specifications? If you have or haven&rsquo;t, what are your thoughts about this direction that we&rsquo;re heading
in that aspect?

as a typography nerd over the past eight years I&rsquo;ve been in the web industry, I&rsquo;ve been very frustrated by the lack of finer typographic
controls …&nbsp;so I&rsquo;ve written something recently or complied this into something I&rsquo;ve been calling “Type JS&rdquo;, and it&rsquo;s at TypeJS.org

Nathan Ford: I don&rsquo;t know what&rsquo;s in the specification, except for what is actually usable right now. It&rsquo;s all I tend to focus on. I know that as a typography nerd over the past eight years I&rsquo;ve been in the web industry, I&rsquo;ve been very frustrated by the lack of finer typographic
controls. I actually write a lot of like JavaScripts and things like that in my spare time, then I put them up on my blog and in GitHub, and try to fill these gaps.

Actually, so I&rsquo;ve written something recently or complied this into something I&rsquo;ve been calling “Type JS&rdquo;, and it&rsquo;s at TypeJS.org if you want to check it out. It is. It&rsquo;s exactly what you&rsquo;re talking about there. It&rsquo;s basically using JavaScript to create
new CSS properties for typography. As far as an idea goes, yeah, I totally agree.

Justin Avery: That&rsquo;s really cool. I like the site. I got something to do for the rest of the afternoon now.

Nathan Ford: Yeah. I&rsquo;m really advocating people to hop on there, and then go to the GitHub project, and throw some issues at me, throw some ideas at me because I want to try to start building all of these little things that people are not able to do in typography right now on the web and try to
make it into something that little useful. What I like about it is it can start showing and testing ways that we can solve these problems, so that we can write a smarter spec later.

Justin Avery: Yeah, that&rsquo;s a great idea. That aspect should be written, right, like take what is missing, play with it, find out what everyone likes to use, and then make that the specification?

Nathan Ford: That&rsquo;s what I think. Yeah.

Justin Avery: Good start with the TypeJS.org. Thank you very much. That was wonderful. I learned tons, and that&rsquo;s why I do this. I&rsquo;m sure the rest of the listeners will learn lots as well. Apart from TypeJS.org, you have a blog. Do you have a Twitter where people can learn more and read
more about what you&rsquo;re doing?

Nathan Ford: Sure. Yeah. I&rsquo;ve got my blog is ArtEqualsWork.com. “Equals&rdquo; is spelled out. My Twitter handle is “nathan_ford&rdquo;. The guy who has “Nathan Ford&rdquo; is not very happy with me because apparently, he gets a lot of my tweets. Please make sure you get the
underscore in there.

Justin Avery: Surely. If he is getting sick of it, you could just hand it over.

Nathan Ford: No. We&rsquo;ve had that conversation. It&rsquo;s adamant, but that&rsquo;s okay. I understand. It&rsquo;s cool.

Justin Avery: That&rsquo;s fair enough.

Nathan Ford: He got there first.

Justin Avery: Is he a webdev?

Nathan Ford: I don&rsquo;t know. I think he&rsquo;s a designer. I don&rsquo;t know. I try to pick up what I can from his Twitter bio. That&rsquo;s about it.

Justin Avery: I&rsquo;ll make sure I tweet him and thank him for coming on the podcast.

Nathan Ford: Yeah, please do.

Justin Avery: Thank you very much for coming to podcast. Is there anything else that you &hellip; I caught you at a talk, actually. Was it late last year? At The Web is conference in Wales?

Nathan Ford: Correct.

Justin Avery: That was awesome, by the way. If anyone is keen to see Nathan speaking, if you go to BeSquare.me, all of those videos are up there, and you should check out Nathan&rsquo;s talk on &hellip; It was content grids as well, wasn&rsquo;t it?

Nathan Ford: I had a bit of that mixed in there too. It&rsquo;s basically how to design for a responsive environment without going crazy or something like that. [That&rsquo;s all 01:06:15]

Justin Avery: Yeah. I think I&rsquo;ve got a list of the couple of videos that they need to add as links on to the site as well, so I might just check that up after this as well. Yeah. You should definitely go and check that out. Are you doing any more talks, or you&rsquo;re settling into Dallas?

Nathan Ford: Yeah. With the big move and everything, I made no plans for the year. Yeah, no talks this year. I&rsquo;m mostly focused in on my new role at Monotype and making really making cool stuff.

Justin Avery: Cool. If anyone has feedback for different products?

Nathan Ford: Yeah. They can hit me up on Twitter or email me at nathan@monotype.com. I&rsquo;m always open for feedback.

Justin Avery: Awesome. Thank you very much again for putting aside an afternoon to have a chat. Yeah. Thank you everyone for joining in and listening. You can find some of the older podcasts on ResponsiveDesign.is/podcast if you want to go back through the old archives. If you liked today&rsquo;s show,
which I&rsquo;m sure you all have, go into iTunes and rate up five stars. That would be awesome. Thank you again, Nathan. Thanks everyone for tuning in.

Nathan Ford: Yeah. Thanks, Justin. This has been fun.

Justin Avery: Cheers, all. Bye.

RWD Podcast Episode #33 : Airbnb
63
2017-12-22 20:56:41 UTC 63
RWD Podcast Episode #33 : Airbnb

PODCAST SPONSOR

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple&rsquo;s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That&rsquo;s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.

Transcript

Justin Avery: Hi, everyone. Welcome to Episode 33 of Responsive Design Podcast. My name is Justin Avery and I’m your host and curator of the Responsive Design weekly newsletter. I have a weekly newsletter, all about responsive design funnily enough. This week I’m really
excited to say that we’ve got a team from Airbnb joining us for a chat.

This chat has been in the makings for quite a few weeks in between illnesses and me going away on a sabbatical back to Australia. I finally managed to track them down and get some of their time but before we meet those guys, I just want a quick shout out to Media Temple. Media Temple are
sponsoring the podcast again this week.

Media Temple is a web hosting company. You can see them at MediaTemple.net. They provide hosting for the Responsive Design Weekly site as well. They’ve got a whole bunch of different levels of their server. It depends of what level you’re coming in as well. They’ve got this thing called
Virb that allows you to design your own website, really point and click if you’re just getting started all the way up to a full-stack dedicated server.

Anything that you really need, they have. Very simple to use. Very easy to get started. Good, good service as well. If you use the code ID25, you get 25% off the cost of your hosting so ID25. Go and check out Media Temple at MediaTemple.net. This week like I said we’ve got Mike Fowler
and Fiona Tay from Airbnb. Welcome along.

Mike Fowler: Hey.

Fiona Tay: How is it going?

Justin Avery: It’s going great. How are you guys?

Mike Fowler: Doing pretty good over here. I think we just talked about it earlier, partly sunny in San Francisco. Yeah.

Justin Avery: Awesome. Mike, are you originally from San Francisco?

Mike Fowler: I’m not. [00:02:00] I’m from the East Coast. Grew up in Connecticut and lived in Vermont for 6 years after that.

Justin Avery: How nice. Are you reasonably new to the sunshine, slightly cloudy and coolish state?

Mike Fowler: No, I’ve been here for a couple of years now, about 2 and a half years. I’m used to at this point.

Justin Avery: Great. Before we get into what you both do at Airbnb and what you have been doing on the new launched website, I thought maybe just touch on your history a little bit and how you got into the industry, how you fell into where you’re working now. Fiona, do
you want to start off?

Fiona Tay: Sure. For me actually, I’ve been writing codes for about 5 years. When I was done I thought I would be a scientist. I actually went to college for chemistry but ended up taking a computer science class and then loved it. My first job was doing consulting at Pivotal Labs.
Then after a year of that I decided to go in-house at Airbnb. I’ve been here about 2 years now working on a variety of things, worked on our big rebrand last year and been working on this responsive project for the past 6 months or so.

Justin Avery: Cool. What about you, Mike?

Mike Fowler: I have a similar windy path towards where I am now. I started making websites in Dreamweaver when I was in high school just as a way of making simple websites for a group of friends that used to make short films. We needed a website to put our YouTube videos up on. I taught
myself how to use Dreamweaver. Then I went to college for animation so completely unrelated to programming. Programming was a hobby on the side and then after I graduated decided that’s what I [00:04:00] wanted to do. From then it’s been transitioning from being just strictly front-end to becoming more
full-stack over the years.

Justin Avery: Did you not enjoy the animation side of things or is it just that you found that the web offered you a little bit more freedom in what you were looking to do?

Mike Fowler: I think it was just one of those classic situations of you’ve been learning something else for a while but suddenly you realize that your hobby is actually your passion. A job fell into my lap right after I graduated, took it and just haven’t looked back.

Justin Avery: That’s awesome, Fiona. Being a budding scientist, was it just the chemistry stuff you were into or were you into all kinds of sciency things?

Fiona Tay: Actually when I was in high school I wanted to really take a work for physics. Then I went into chemistry because I thought that that was a little bit more exciting, chemical things.

Justin Avery: What could be more exciting than physics?

Fiona Tay: I actually was featured in a newspaper for being the first female winner of the Singapore National Physics Competition. That was the apex of my career up to this day.

Justin Avery: That’s amazing. That’s absolutely amazing. I had an embarrassing thing happen once. It was with, at the time girlfriend and now wife, we were in Paris for the Tour de France. They had the world-wide physicist meet-up. Basically all the brilliant minds in
physics were all meeting up. I love physics. I’m terrible. I’m horrible at it but I was like, “We should go. They’ll have like things about space and gravity. We should go and check it out.” We turned up.

I basically got ushered out. “You’re not allowed to be here. The French President is going to turn [00:06:00] up tomorrow. You’re not supposed to be around.” Really, really embarrassing. On a really positive note that’s not embarrassing for me, NASA just released their responsive site.

Mike Fowler: Cool.

Justin Avery: Which is really super cool. I’ve been looking at NASA a lot over the last couple of months and posting pictures. I always think they’ve got such amazing content. Their website was so terrible and did such a bad job at showing that off. I was so happy that
they’ve launched that now.

Mike Fowler: That’s cool.

Fiona Tay: Have you seen the full knowledge repository that they have? They actually post all the learning lessons they’ve had like the failed rocket launches or whatever. It’s all free. It’s all on the site so you can earn about bolts and nuts and engineering and things like that.

Justin Avery: That’s insane. I might go back and see how well they’ve done that from a Responsive point of view as well. I actually can’t wait. It’s going to be the next example site on the site. I’ve spent quite a bit of time, we’ll call it work, going through the NASA
stuff but we’re not here to talk about NASA. We here to talk about the Airbnb site. You guys recently went through, maybe not so recently now, but recently went through a launch to launch the site responsiveness. How did that all come about?

Mike Fowler: Sure. I believe the project kicked off I want to say last September or October, at least the early talks about whether it was a good idea to basically go responsive as opposed to over-hauling what was previously a separate mobile-only site which was on a completely different
texts act. It was I believe about 4 years old. It was un-owned. It didn’t have a clear owner here. It [00:08:00] was a decision between focusing on an area where we hadn’t previously put a lot of resources in the past or it just making bad responses.

Fiona Tay: Yeah. Just to maybe give a little bit more background on that. Actually, from the very first mandate I joined Airbnb, we’ve been talking about providing a better mobile web experience to customers. It’s actually a little bit funny that since we’re a travel company and our
users always on the go, that we haven’t built yet a great mobile web experience for so long.

Part of that was just, as Mike said, our mobile web platform was a little bit integrated, a little bit hard to work with and not really well maintained. I’m just really happy that we managed to get everything together and just start doing it and that came about last year as you said.

Justin Avery: Was it a huge sell? I know everyone instead of pushing responsiveness, the way to go, we also know that some e-commerce retailers, people that like gambling sites and stuff, they still go for the M dot site. Because they can load a lower stack basically,
it’s a lighter load and they can spend more time redeveloping a mobile site. Were there discussions around maybe we should just keep it on this old technology and just be very focused on mobile?

Fiona Tay: I definitely see a lot of people are doing like Facebook does that. All my favorite shopping sites, they all have a separate M site and it infuriates me because it’s such a … They’re usually not very well maintained, like the nature of the website is really terrible. I
can’t believe that. I’d love to go off on a [inaudible 00:09:59] [00:10:00].

I think for us since we have so many new features and also evolving on a continual basis. For us responsive wasn’t by approach because they allowed us to keep using the same … for instance, on our second mobile site we had a whole different mechanism for computing pricing, distinct images, all that
was custom built for the different texting. A more mature site like Notstrom, they’d probably have all that stuff figured out and they really don’t, but it’s much less difficult to maintain it.

We don’t want to run ads right now because we’re, in a sense ashamed at putting an ad on a mobile site and then redirecting to something that is more fresh out or more recent.

Mike Fowler: Early conversations that I was apart of, a point of conversation was being able to maintain the same brand standards across multiple platforms. One of the things that came up a lot was our marketing team was holding off on doing marketing on our mobile website, just because
they felt like the brand standards on the mobile website were falling behind the main website. They were actually saying, “We don’t want to run ads right now because we’re, in a sense ashamed at putting an ad on a mobile site and then redirecting to something that is more fresh out or more recent.”

Justin Avery: Yeah. That’s understandable for sure. There’s a lot of Airbnb sites right? How many different country sites are you guys responsible for?

Mike Fowler: I don’t have an exact figure in front of me, but I’m going to say in the realm of 25 to 30 at least. As far as separate languages do you mean?

Justin Avery: Yeah. Domain based and also probably language based as well. I was looking through … I may or may not have been viewing your source. [00:12:00] There’s a whole bunch of meditags which is like alternate versions of the URL for the different languages. You
hit there and your browser is based on that particular language, then it will offer you that particular site. Are you responsible for all of those or do they have separate teams that manage?

Mike Fowler: It’s all the same code base. We have a fairly sophisticated mechanism for putting a string in our mark up, which then gets automatically pulled into a translation system, then one language at a time we can convert what started out as an English string into however many
languages we’re supporting. In our rails code we’re calling one ruby method with a symbol and a default text, and that gets output as the proper language if a translated version exists when somebody views the site on a different TLB.

Justin Avery: Brilliant. That would have been quite difficult to design for as well, right? Like the same word across a variety of languages, or have different lengths, and saying one thing could have five words, or one word, or three really, really long words?

Mike Fowler: Totally.

Justin Avery: Yeah. For me, when I first joined Airbnb, having come from a consulting background, that was one of the biggest things to get used to because thinking of all the multilingual approaches are really different. You need to make sure that you’re formulating
a translation piece correctly, that you aren’t sending [inaudible 00:13:38]. All those kind of code strings that you have, and it just gets more complicated when you’re looking at a difference between, let’s say Chinese and German. Chinese is very short and German is very long, even like a normal, middle
of the road&nbsp; [00:14:00] English sentence, and I hope to hear it in Chinese because it’s only like two characters. In German, it’s like five gazillion characters.

Mike Fowler: Honestly throughout this project we discovered a lot of, not to conflate this term, but like breaking points in our design where everything has always looked fine, even in German for example. Suddenly it goes from being a fixed width 400 pixel wide element to 100% width,
and then potentially as narrow as 320 on an older iPhone or Android. Suddenly the string would wrap when it was never intended to wrap, and so we had to redesign certain parts of the UI that have never been problematic, but suddenly when we introduced a little bit of fluidity to the elements instead
of fixed width elements, it became an issue.

Justin Avery: But you’ve still been able to maintain a single code base right, across all these different languages?

Mike Fowler: Yeah exactly.

Justin Avery: Yeah that’s brilliant. Kudos to you guys, that’s cool. You talk about testing and stuff, how did the whole … at the end of the process or … was the testing like a continuous improvement thing? What was the testing methodologies behind this redevelopment?

Mike Fowler: We focused on the most prominent tablets and phones that were out at the time, pretty much still the same. Recent iPhones, recent iPads, Android tablets and phones that have come out in the past couple of years. Honestly we were doing a lot of using the site on the phones
and on the tablets, and while we were going through the end stages of starting to release this stuff, we would just do as much … use the site exclusively [00:16:00] using the device, and just write down everything you see that could be improved.

Then triage a bunch of issues and knock out a bunch of things that, UI or UX, stuff that could have been tweaked a little bit to make it better. That was primarily our testing strategy. Just as we were crunching through getting the core flow of our site to be responsive.

Justin Avery: Cool. Testing’s kind of like the end part of any kind of process, how did the rest of the process go for the whole redesign? You would go back, and you’ve come out of the meeting and have gone, “Get rid of this old platform that’s just mobile only, let’s
go responsive with all these different sites and languages.” How did this kick off from then in terms of why framing, was there designs, meetings, prototyping, how did that all work?

Basically mocked up our existing pages as responsive alternatives using bootstrap. We have an internal UI tool kit that is very similar to bootstrap.

Mike Fowler: The way it started was … this was where I came into the project because this was getting started just as I got to Airbnb. We had a contractor who did high fidelity mocks in code. Basically mocked up our existing pages as responsive alternatives using bootstrap. We have
an internal UI tool kit that is very similar to bootstrap. All of our front end code is … all the layout is written using one tool kit, so he was able to use bootstrap, and fairly closely proximate how we would be writing code to implement the same layouts.

For about two months we had biweekly design reviews which involved engineers with the contractor. Basically it was him showing off progress designs saying, “Yes. No.” Or [00:18:00] “We need to work on this.” Then engineering giving us input as to how this will work with our existing setup.
Even high fidelity code mocks are pretty idealistic when you’re talking about a massive six year-old code base. You have anything else you want to add Fiona?

Fiona Tay: Justin, maybe you can have some throw out questions on this.

Justin Avery: Once they were coming back, was it a more of an agile approach than a scoped out, waterhole based … ?

Mike Fowler: This project was a pretty tight deadline project and so there wasn’t a huge amount of process other than … we ended with these high fidelity mocks. As far as engineering it was sprint to the finish. Between getting these design ready, or rather engineering ready, mocks
in code from our contractor, we ended up implementing our core flow which is the primary pages you see as a guest on Airbnb. This excludes any of the tools that hosts use to manage their properties.

For the core flow, you’re a guest, you come in, you hit the home page, you search, you see a map with all the results, you click into a listing, you see the listing, you check out. That was our MVP for this project is we made the core flow, the core booking flow responsive. The time from
start to finish, engineering wise on that project, was only about a month and a half.

Justin Avery: Wow.

Mike Fowler: It was a fairly aggressive timeline. There wasn’t a huge amount of process, [00:20:00] it was just sort of like go go go go go.

Justin Avery: Apart from do you know you’re at home until you’re finished.

We did have to make some hard decisions along the way about features that we wanted to cut such as maps on the mobile search page, just because it would be really hard to support that in bolts.

Fiona Tay: I think that’s interesting coming from an agile consulting company, and see how that really applies in the [inaudible 00:20:14]. I don’t know that I know these terms, most certainly not directly. I would say that it was probably more towards [inaudible 00:20:21] waterfall
could, just because this was a pretty big project that was scoped out and designed , but at the upset. Then edge ring kind of came afterwards, and that’s because of the nature of the project.

We wanted to get the core booking for responsive, and there was a scope of it. There wasn’t a lot of taking out, because the core booking’s, or the core booking for it, take out a unique part of the pages it doesn’t really function that well. The rest was an experience. We did have to make some hard
decisions along the way about features that we wanted to cut such as maps on the mobile search page, just because it would be really hard to support that in bolts.

The rest of the world which uses Google maps, and China which doesn’t support Google maps, really [inaudible 00:21:19] macro writer for China. That’s an example. That’s something that would be more than … I don’t really think it’s the job I guess, it’s just an example of like [inaudible 00:21:33]
our MVP.

Justin Avery: I can’t believe that you guys nailed that in such a short amount of time. You did a very, very good job. Were there any guidelines set out to begin with? Fiona, you mentioned that most of your clients on the move, and would probably be on mobile devices
[00:22:00] generally traveling, possibly overseas, perhaps not on their mobile tel care provider, paying through the nose for [dotter?] and things like that. Was that a big part of the project?

A lot of our work right now is being uniformed by performance, and how to make the site more performant for people who, again may not be on wireless networks.

Mike Fowler: There was some consideration. That’s an ongoing process for us now. A lot of our work right now is being uniformed by performance, and how to make the site more performant for people who, again may not be on wireless networks. For the MVP, we were pretty highly focused
just on layout to be honest. We wanted to be able to replace our existing mobile website, our MDOT site with some sort of equivalent on the full website. Sort of a trade off, we had to make there, just because of the aggressive timeline was, “Yeah we’re going to probably take a performance hit initially,
but that will be the long tail of making the responsive site be as performant as the mobile website was previously.”

Justin Avery: Are you working towards that now?

Mike Fowler: Yeah, totally. The responsive site, or the MVP of it, launched in about mid December. We launched it just a week before we went off for our holiday break, and the reason we pushed for that deadline was to see how it affected bookings over, what is historically been one
of the most important days of our year which is New Year’s, as you can probably imagine. Launching on that aggressive timeline allowed us to collect a lot of good data about how it was performing. Even excluding the performance optimizations that we could have made, or are making now, [00:24:00] we were
able to see a very positive effect in the responsive site as compared to the mobile website.

Justin Avery: That’s really good.

Fiona Tay: Tell us go back to the higher level question now and think about performance. We did a bunch of work when we first launched the project on quick [inaudible 00:24:21] performance, that we cut down websites and [inaudible 00:24:24] and we stopped loading so many parts. That
was the only way to process. Making a really great little snappy performance on the longest tail of doing these processes is a very hard challenge. I was just in Singapore, China and I took the opportunity to work offsite.

When I was on vacation using the hotel Wi-Fi, then a lot of interesting challenges around there. For me, I found that being a foreign country where the network just takes longer, that was like a huge part of it. Another part of that would be like ancient data. I felt like in my [inaudible 00:25:11]
database calls and that kind of thing. I think there’s just a lot that goes into making a great performance for those longest tails to process, especially for Google, for 4G.

I feel that that’s probably something where you have put in 80% of the effort to get 80% of the performances, but to make the great experience that what Facebook does for it and you nurse it. You say like those cheap mobile phones can buy the kilobyte, that’s something that’s more fined out longer
term goal for us.

Mike Fowler: It was really interesting. One of the things that we dealt with performance wise right before we shipped was, we were noticing that [00:26:00] the performance on iPads for instance which is a huge amount of our mobile traffic, we noticed that the pages would load and there
would be like this weird 15 second lockup where literally the page would freeze. You couldn’t even scroll. Obviously a huge blocker for shipping. What we discovered was that we were competing against an optimization that we had made previously for desktop, and what we were doing, when they said it had
been worked on by another team so nobody on our team knew that this was in place.

Since we have such a defined flow through our site, where you hit the homepage, and then you search, and then you go to a listing. We know that that flow is so prominent with our users, we were pre=loading all of the java script and assets for the next page when you hit the homepage. When you hit that
second page, we were then immediately pre-loading all the stuff for the third page.

Justin Avery: Which is a good idea.

Mike Fowler: Which is a good optimization for desktop, but what we were seeing is that on iPad, it was causing performance bottlenecks. Kind of ironic, but we were circumventing previous performance optimizations as a way of improving the performance of the responsive site. We weren’t
quite circumventing them, but in a sense, we ended up refactoring some stuff to make it work better with mobile devices. It’s just interesting to see the kind of things you were up against. Taking a site that has over six years, never been considered as something that would be used on an iPhone for instance,
and taking it backwards.

I have a lot of experience coming from the opposite direction of like, “What’s the best way to create a responsive site from nothing?” That experience is just so different, and it’s also really idealistic. Especially if you’re [00:28:00] at a big company, you’re very instantly going to be starting
out on a project that you’re going to be making responsive with a clean code base.

Justin Avery: Were there any other things that you noticed similar to that, like inherited issues that you had coming from a desktop first site previously, besides the performance ones?

Mike Fowler: I can think of one other recent example. This we didn’t actually find until after we launched the initial MVP is, we have this internal UI tool kit which includes a paired down sub set of similar things that bootstrap offers. Tabs, and modals, and tooltips. We noticed after
the fact that historically our tooltips and our modals, the mark up that they would use in the tooltipper and the modal would be in the dom.

Because performance on desktop had never been a huge concern of ours. whoever initially could have used elements way back, I mean we’re talking like three or four year old code, had implemented them in such a way that the mark up was still visible and being rendered in the dom that was just being hidden
using paucity of Z indexes. There was also some trans forums, and translates going on in there, on certain pages that had a lot of tooltips for instance, notably our listing page which is one of the most important pages on our site, if you zoomed in to the page on iPad it would just flat out crash safari.

Because it’s basically recalculating all of the trans forums at one time. We’re talking like calculating the trans forums on upwards of 40 elements at one time. Stuff like that. We’ve been finding a lot of legacy things that wouldn’t have been considerations for performance on desktop, because you
know on a desktop, even if you’re zooming in [00:30:00] it’s not animating the zoom in it’s just snapping to it. On iPad when you have a dynamic resize when you’re zooming in, pinch zoom, we’ve started noticing a bunch of stuff around that.

Justin Avery: These performance … I’m sorry were you going to say something Fiona?

Fiona Tay: I was wanting to talk about some of the user interface elements. If a lot of user interactions that focus on hover, like showing more information when you hover are expanding when you hover, and those are things that are available on the mobile device. We couldn’t have just
went through the core flow, look for bits of the flow that didn’t quite make sense, and refactor them or when [inaudible 00:30:45] designs better. Did we just drop the call?

Justin Avery: No. Sorry that was just me. Just thinking about that. With the performancy, these are some of the things I’m guessing like the iPad locking up, or these tabs and stuff, are these reports coming back from other users or have you got a way of monitoring or
tracking the performance?

Mike Fowler: Sorry Justin, could you repeat that question? We were just making sure that we’re not touching the microphone anymore.

Justin Avery: In terms of the performance, these seem like things that you all have found during testing, or people will have reported during the use of the site. Are you using anything to monitor the performance during the build processes and things, kind of like a speed
curve or a site speed kind of thing? Just seeing how many assets are loading, the size of the CSS, the size of the JS?

Mike Fowler: Yeah. [00:32:00] We had some of that going on previous to the responsive project. It was mostly being done in the browser. It wasn’t part of the build process but it was data that we were collecting through the available developer tools. I’m forgetting the name of the API
that allows you to, at page load, measure the size of the assets.

Fiona Tay: RUM?

Mike Fowler: Yeah. We were reporting data back to our internal data stores about size of java script, size of CSS assets. Most of that had been done previously for performance tuning in China, but we hadn’t been doing any testing as far as part of the build process for like front end
performance regressions. That’s the kind of stuff we’re starting to think about now. Is it possible to, for example put a step in the build that measures, like you said, something like page speed, and if your chain step has resulted in an over large change due to page speed or some other metric like
throw an error on the build or something. We don’t have any of that kind of stuff in place yet, but it’s the kind of stuff that we’re thinking about now that we have a base line responsive core flow.

Justin Avery: That’s really cool. If you’re looking into performance and stuff, I spoke with one of the guys from the Guardian. Have you ever heard of the Guardian newspaper?

Mike Fowler: Yeah sure.

Justin Avery: Patrick Hamannk is one of their front end dev leads, and he’s always talking about performance and stuff. They went to the point of trying to get to their news site to load in less than a second. [00:34:00] Basically delivering news in less than a second
and trying to get their page speed index lower than a thousand. They went so far as … they’re rewriting the way that the database is queried and the way that the CMS worked and things, but basically if someone requests an article it only does a single database query for that article, and then the rest
of the page is built up around it as well for advertising related links. They’ve gone to an enormous length to try and make it as performant as possible. Really good stuff those guys are doing.

Mike Fowler: Cool. I think Fiona sort of hinted at this earlier but, it seems like there’s such a huge amount of work you can do on that front that one thing that we’ve struggled a little bit with since implementing the initial go at responsive is kind of like, “What do you focus on?
Especially, do you try to hit a percentile of every device or do you hit the devices that are most commonly using your site.” In our case that’s what we’ve been doing, at least in the past couple months, is really focusing heavily on iPads since we’ve seen that a huge amount of our mobile traffic is
from iPads.

At the same time there’s the consideration of like, “Well are you excluding other devices because people weren’t visiting your site on them to begin with because the experience wasn’t a great experience?” It’s kind of hard to choose what devices you pursue because there are just so many. We now have
a brand new phone factor that would be Apple Watch. That’s a native app experience, but just as an example, it’s almost impossible to know who’s going to be viewing your site on what, and [00:36:00] where do you focus? That’s a really hard question.

Fiona Tay: I really admire the work of people like the Guardian that have a need to push a big response needs down to so low. Going back to the earlier point of how do you accommodate the user and their goal who’s hanging by the kilobyte. I’m not really sure that a one second load time
is going to be impossible for us anytime soon just because this stuff is so complicated. There are many different issues around performance that for instance, red or [inaudible 00:36:37] are http caches, and they have http caches over in China. Those are all really end based queries. I don’t know how
many queries you make on a listing page, but I think it’s at least ten. This is no shame right?

Mike Fowler: Right. I think it all still comes back to like this is a six year-old code base that, up until four months ago, nobody had ever considered for use with an iPhone. Never mind an iPhone on a 3G connection or even less than that.

Fiona Tay: Yeah. It’s a completely new and annex dot territory for us, and we are definitely trying to figure out what the user personas are that are complicating. Is it your mom at home with an iPad, or is it like the Indian trail run by the kilobyte.

Justin Avery: Even now though, Fiona you put it well earlier, that you knocked out 80% of the issues with the [inaudible 00:37:39] out of the way, then up front and that’s really dialing it. Get that 80% done and you’ve done that work and so it’s performing. Mike, like
you were saying to focus on the customers that you have at the moment. You’ve got statistics there. One of the things I always used to recommend to people when they used [00:38:00] keniu’s. They’re like, “Well we can’t use that because it’s not supported anywhere.” I’m like, “Well have you seen this
little thing here? It’s part of the site where it let’s you use the Google analytics of the people that are visiting your site, that show the different percentages between the global usage and your usage.

I think follow your usage.” Having said that I thought it was a funny story from YouTube, where there was a really great article around how they saved the amount of content, or the number of meg that went into the player. It was a couple of meg and they dropped it down to like 128 kilobytes or something
crazy, and they saw load times increase by 300% or more. The reason was because the player was now accessible in all these countries that previously couldn’t download the player itself let alone the movie.

These people were downloading the player and watching the movies, therefore the overall perceived space of YouTube was increased, but they actually got out to a wider market which is a tough gig for them. We go back to the way that you guys are working, we talked about the testing for performance at
the end of a build process and stuff, what about before the process, or during the build process? Do you have a build process internally? Do you use Gulp or Grunt, or one of these other short names, formulatic pre-processing tools?

Mike Fowler: Right now most of our asset processing is done just through the rail of asset pipeline. Internally we have a fair bit of java script being compiled with the help of rockets [00:40:00] through Brazzerfy. We’ve been doing a slow process of converting a lot of our java script
to common JS. As far as CSS, we use Sass. That’s all just compiled through the rail sprockets asset pipeline. Certain micro sites would have been our main ecosystem to use Grunt or Gulp, unfortunately both exists in our code base, but in general, I would say probably 95% of our assets across Airbnb.com
are compiled via the asset pipeline.

Justin Avery: Nice. I have to admit I’ve never used rails so I’m not sure of the asset pipeline. I’ve heard it mentioned a number of times though.

Mike Fowler: Yeah. What can I compare it to? Basically it allows you to create manifest files which allow you to be kind of statically require files, and it acts like a bundler almost. It doesn’t do any sort of magic as far as dependence management, it’s more just like a flat manifest
that says, “Wrap all these files into one big file.” It does handle things like compiling Sass, compressing images, stuff like that. Then that …

Fiona Tay: It doesn’t compress images.

Mike Fowler: Does it not?

Fiona Tay: No it doesn’t.

Mike Fowler: Okay.

Fiona Tay: That’s why we’re always yelling at people who request. They’re not checking one megabyte assets. It provides [minification?] managing, ergo managing, all that kind of good stuff to get the owner nice and formatted java script to that compressed, one line, six thousand [inaudible
00:41:57] file.

Justin Avery: That no one can understand or [00:42:00] decipher when they decide to have a look at what you’ve been doing.

Mike Fowler: In a way.

Justin Avery: I always find it funny that we’re more than happy to compress our CSS, and uglify our java script and compress that, been when it comes to Html, we like that well structured. We never compressed the Html, it’s a weird thing.

Mike Fowler: It’s tricky, right? Some things in Html are affected by the white space, and some things aren’t.

Justin Avery: That’s very true. Although do you know that’s affected negatively by having no white space?

Mike Fowler: Yeah. For instance if you look through a lot of old legacy sites, if you go back to 2002-2003 era and look at some Html, you’ll notice for instance a lot of people, when they’re making horizontal lists using lists like UL or OL tags, will actually just line up their LI’s
all in a row. Because a line break plus the tab character in between LI tags, if they’re inline box, will actually need the space between those elements, whereas if there’s no white space between the tags and they will not have white space between them. I think there’s little stuff like that that you
have to pay attention to if you’re minifying Html. I don’t have too much experience at any company I’ve been at, minifying Html.

Justin Avery: It’s always when someone asks. Where it’s like, “Well if you’re going to minify everything, why don’t you minify your Html.” I’m like, “No. We can’t do that. How will people read it? How will people view source and understand what I’ve been doing.”

Mike Fowler: Right. Which is funny because everyone who knows what they’re doing in a browser is not going to view the source. They’re not going to right click and click view source, they’re going to open the dev tools, which that’s going to all look fine because it’s based on the domitry.

Justin Avery: Exactly. The lovely formats of dom.

Fiona Tay: Hashtag what people ask front end developers.

Mike Fowler: I know, yeah. [00:44:00]

Justin Avery: I was talking about moving away from the old MDOT site as well, do you think this ever … also talked about before we go chatting as well about how there’s a native side of things and you’re not really, partake too much on the native side of what … it’s
a different team. Do you guys share any elements? I see sometimes native apps have web views and things like that, do you share any elements between the teams?

Mike Fowler: I know historically one component that is shared is the help center. The native apps use a web based repository of help questions that is also served on our mobile site. Hospitality I think maybe has a page that is shared like in a web view between the mobile, the mobile
site or the legacy mobile site now, and then the apps. Largely no. It’s largely that the teams are separate, and the apps are completely separate.

Justin Avery: Do you think that’s still, not for Airbnb in particular, but do you think that’s going to be the case for awhile yet, or do you see the walls starting to break down a little between native and web?

Fiona Tay: It’s funny because I just said this at same congregation for the engineer at the Android team. [inaudible 00:45:29] things that, with material design, and Google’s [inaudible 00:45:34] had mobile site that the lines would become through it more quickly. I think that I disagree
with him. I think right now, the experiences are just so different on mobile site than on native apps. I don’t really see the lines blurring the app. The most I know about media [00:46:00] and mobile sites, are probably Facebook experiments. Not sure anyone else is going to know what a space user is.
It doesn’t really provide a very … using a mobile site within the web view doesn’t really provide a very natural, nice experience within that app. I see that using my Galaxy. It does seem a little confusing as it takes longer to load, the interactions don’t [inaudible 00:46:34], we feel like there’s
a big difference right there.

Mike Fowler: Yeah. It’s funny because on the web we’re always waiting, not fighting, but definitely waiting for browsers to catch up. I was working on a personal project recently, and noticed because I hadn’t looked at this API in awhile, but I noticed that still two or three years
later get user media that’s not supported in safari at all. Like still, like three years after that spec was in almost final draft form. You can’t get the users microphone input on safari, just period. Which is so basic for any kind of app if you’re doing any sort of microphone capture on native, then
you’re out of luck unless you are going to use flash on desktop. But that’s not supported on iPhone and a lot of Androids, so it’s like where do you go?

Fiona Tay: It all comes to the fact that developing at the [inaudible 00:47:35] is just a much more controlled, much more standardized environment than developing for the Ram. Sometimes when I’m doing some nasty CSS code, I with I could just throw my hands up and cover Android developing.

Mike Fowler: I know, right?

Fiona Tay: My best friend is an Android developer so I entertain that on quite a frequent basis.

Justin Avery: It’s even easier if you’re an iOS developer. [00:48:00] Are you at less devices to worry about than Android as well.

Fiona Tay: I say that I’ve heard the offers and it’s too easy. Way too easy. There is so many Android phones out there. Probably ones you’ve never even heard of. In China, nobody there uses Samsung or Google Nexus. I’m not really sure why anyone even uses the Nexus phones it is terrible,
sorry.

I think a really important distinction to make is not necessarily a fight between web and native, it’s always how it’s been framed, at least for the past three or four years.

Mike Fowler: I think a really important distinction to make is not necessarily a fight between web and native, it’s always how it’s been framed, at least for the past three or four years. It’s like, “Who will win? Web versus native.” I think the use cases are totally different often
times. You talk about a site like Airbnb, in the grand scheme of things, it’s kind of like a high of arch to assume that somebody’s going to use Airbnb for the first time on a native app because that would require them to learn about the company, and then of their own volition to go and download the
app from the app store and then sign up for an account using the native app.

I think a much more realistic for us and many other companies is that a users first impression of your site, if they’re on a mobile device, is going to be through some sort of mobile website. It’s kind of a unique opportunity for mobile web or responsive web in our case now, to introduce a user to
a product that they might be seeing for the first time. It’s pretty aware that somebody’s going to see a product for the first time on native, unless it’s a native only company. Even look at a very common use case like, somebody who uses the internet primarily on their phone which we’re seeing more and
more.

A crazy percentage of people only use the internet on their mobile device. A friend emails them a link to an Airbnb listing, [00:50:00] or they’re on Twitter and somebody posts about an Airbnb listing, or the link to it and says, “Check this out, this listing is really cool.” Few fairly common uses
and that’s going to be their first experience of Airbnb is on the mobile website. I guess I always tend to think of it less of like a competition, and more of like how do they compliment each other. I think that’s a fairly common scenario.

Fiona Tay: I think I agree with Mike on that. I guess the question that I ask myself is, five years down the road we see ourselves computing that every industry should have a separate mobile site, and have posed a threat at the users and API, are we going to be able to build a [inaudible
00:50:44] code sharing. I think for a lot of us Android or web developers, the holy grail is code sharing, right? Not having to reintervent all these complicated price [inaudible 00:50:57] on to a different system. I guess I just don’t see it as something that we’ll have for a few years. For at least
ten or so years until web connectivity is better and that we have got … and they all allow us to blur the lines a little bit more.

Justin Avery: That’s awesome. Both extremely good responses. I might actually … I’m going to wrap it up there.

Mike Fowler: Sure. Yeah.

Justin Avery: We got to go out on a high. That was awesome. Thank you very much both of you for joining in. I’m sorry it’s taken so long to get you on, but I think it was very much well worth the wait. Before I do go though, each week the guest who was on previously asks
a question of the next guest. I’ve got a question here for you from Adam [Lodteck?] from Rally Interavtive, and after I ask you, I’ll ask you [00:52:00] this question, I’ll ask you to ask a question of the next guest as well. One of you can have your brains tuned into thinking of a question while the
other person answers this, then you can switch over again.

Adam asks, “It’s hard to predict where technology is going, where the holy water’s always playing with things, and you minority reports and whatnot, what are you excited about? What are you seeing glimmers of in the technology space now? Do you think it’s going to be really useful, just a fun tie of
something that might genuinely change how we use computers or interact with information? What are you excited about?”

Mike Fowler: Fiona, do you have an answer? I’m thinking still.

Fiona Tay: I guess I’m feeling cliché about saying this in front of [inaudible 00:52:53], and in your technology going to have the ties. You’re going to have the useless stuff, and then you’re going to have some business, and being Airbnb of course, we see technology changing the world
in terms of businesses. I think for me the one I’m most excited about is quantify itself, being able to use technology to better track your personal metrics like whether it’s a normal steps you take everyday, or your motives recycle, I think that’s a great way that technology is happening for each of
us. To a better understanding.

Mike Fowler: I often jokingly refer to myself as sort of a Luddite engineer in that I don’t always necessarily think that, what we use technology for is a good use of technology. [00:54:00] Often times I feel like technology is being used for the sake of technology. One place that I
feel there’s a lot of potential in are rumored just started to scrape the surface is, using technology for home care, especially in the space for elder care. There is a company that’s just starting up right now, I’m forgetting the name. It’s by an ex Google employee. Basically using technology to help
people check in on people, or take care of yourself, or request specific needs. Somebody who’s maybe home bound or doesn’t have all their full mobility. I think just in general I’m really excited about shifting the conversation about technology more from how far can we take technology, to more like how
can we better use the technology that we already have.

Justin Avery: Yeah. I like that. During both those answers, did either of you … who’s going to be responsible for asking the question of our next guest.

Mike Fowler: I had one and now I’m having a hard time remembering it.

Fiona Tay: I have one. Do you think Microsoft will ever have a chance of entering the mobile device market successfully?

Mike Fowler: I just remembered mine too if you want to take …

Justin Avery: Yes please do.

Mike Fowler: Last month I helped co-host a Sass meetup here in San Francisco, and one of our speakers last month was Tav Atkins. For those of you who don’t know, Tav Atkins is the primary spec writer for the CSS spec right now, and maybe Html spec I’m forgetting, but definitely the
CSS spec. He works down at Google, and Mt. Dew. [00:56:00] One of the things he talked about at our meetup is the some of the upcoming features in CSS that are scoped out for being specked in the next two to three years, and one of the things he talked about was finally making CSS pluggable, being able
to add your own functionality of the CSS through the browser which is something that’s always been impossible via java script.

We see it a lot with web components where you can basically, effectively create an Html element that has it’s own encapsulated functionality. What they’re working on right now in the CSS spec is being able to define functionality whether by java script or some other method, to create your own CSS elements
that maybe even have their own functionality, CSS properties if you will. I guess my question is: Have you read the new future plans for the CSS spec and what are your thoughts on them?

Justin Avery: I haven’t read them.

Mike Fowler: They’re cool you should check them out.

Justin Avery: Definitely they sound very cool. I know that Tav had a bit to do with poking his nose in and saying “Yes,” or “No,” to a lot of the picture element conversations. Picture in source set as well. It’s very hard to sway Tav but he’s got a lot of responsibility
on his shoulders I think. That’s a tough job. Very tough job.

Mike Fowler: In the many questions I could ask people, I think one thing we’ve been talking a lot about here is how to do responsive images on a large scale, especially when you’re supporting back to us for now, in explorer eight, [00:58:00] I’d be curious to know how other large companies
are doing responsive images right now. Are you taking them out of images and source set, are you using picture, or are you relying on more like a service side compliant that serves an asset that’s based on the user agents ring of the incoming request or something like that?

Justin Avery: Before we do go, how are you guys handling responsive images at the moment.

Mike Fowler: Right now we are still figuring out how we’re going to do it, but what is seeming like a likely path for us right now is using a product that [hockmeyer?] has just released a service side solution. Something that works with your CDN to serve an image that is appropriate
to the device that is requesting the image. That way there isn’t a huge amount of juggling different CSS, and Html elements on our side. You get an image that is going to be ideally the right pixel ratio, the right dimensions for the device.

Justin Avery: That kind of gets past Fiona’s issue. You mentioned before where people have bought assets that are too large, or is that just for like icons and … ?

Fiona Tay: The issue that we have with the [inaudible 00:59:22] developers upload to that asset. The chief pre-process user generator content, so that’s why [inaudible 00:59:30] you like them to create better mobile capabilities in the pulled process images, if that makes sense.

Justin Avery: I’ll make sure I’ll have a couple of podcasts lined up with a few other people who run some largish sites with lots of images, I’ll be sure to ask that image question and see how they’re dealing with those as well. Before we do go, thank you very much Mike
and Fiona, [01:00:00] for coming on and spending some time on I’m quite sure is a busy afternoon for you both. If people want to follow what you’re up to and what you’re doing, do you have logs and Twitter handles?

Mike Fowler: Sure. I’m on Twitter @michaelrfowler, and @mikefowler.me. We also have an Airbnb nerds Twitter handle and an Airbnb nerds blog that you can follow.

Justin Avery: Is that @airbnbnerds?

Mike Fowler: It’s nerd.airbnb.com.

Justin Avery: Nice. I’ve got a few of these things coming through on the Skype so I’ll post them on the show, Fiona how about yourself?

Fiona Tay: You can find me on Twitter @missfionatay.

Justin Avery: Do you have a blog or are you into the micro blogging?

Fiona Tay: If you call Twitter my micro blogging.

Justin Avery: Fantastic. Well thank you very much again both of you for coming on and joining. Are you organizing anymore Sass meetups or is there Airbnb meetups? What’s coming up in the future, anything exciting?

Mike Fowler: Totally. As far as Airbnb goes, we have airbnb.com/meetups is where you can find out about any event that’s being put on by us at our headquarters here in San Francisco. We typically do one meetup per month. As far as the meetups that I help run, it’s called the Mix In.
We’re at the mixinsf.com, and we are hosting this months meetup at Airbnb where we will be having … I’m forgetting one of those speakers so I’m not going to say them out loud here so I don’t forget one. Check out the mixinsf.com, we’ll be announcing that event, probably in the next few days. [01:02:00]

Fiona Tay: Oh yeah and I’m also organizing a series of talks centered around the learning computing, so we’re going to be hosting a series of [inaudible 01:02:10] talks on the new premier about [inaudible 01:02:12], so be there or be square.

Justin Avery: Great. How do people find out a little bit more about that one?

Fiona Tay: [inaudible 01:02:20] posting and on Twitter [inaudible 01:02:21]

Justin Avery: On the Twitter scene, all right. Well if you shoot me a link as well I’ll make sure to put it goes up in the show nights. Thank you both again, I can’t thank you enough for coming on. Thank you to all the listeners for dialing in or downloading, do write
us up in iTunes or whatever podcasting type thing you are downloading this from. Next week we’ve got another exciting episode with Mr. Nathan Ford so don’t miss out on that. Thanks again Fiona and Mike, and see everyone later.

Mike Fowler: Thanks Justin.

Justin Avery: Cheers all. Bye.

RWD Podcast Episode #32 : Dao of Web Design
33:37
2017-12-22 20:56:41 UTC 33:37
RWD Podcast Episode #32 : Dao of Web Design

I will not be posting a transcript of this weeks podcast as it’s practically read straight from the original article on A List Apart.

Podcast Sponsor

A huge thanks to MediaTemple.net for their support of this weeks podcast.

For years, Media Temple’s Grid service has been the web hosting choice of more designers, developers, and creative professionals than any other platform. That’s because a single Grid account can host anything from your portfolio site to 100 different client projects. And the Grid is ready for anything — hundreds of servers work together in the cloud to keep your sites online, even if you suddenly hit the front page of Reddit.

  • Also, check out their New WordPress Hosting product as well as their launching of Google Apps for Work.
  • Virtual Private Server solutions are also available with their DV and DV Developer hosting plans.

Special discount for Responsive Design listeners, use promo code RD25 for 25% off web hosting. Go to mediatemple.net and enter your promo code upon signup.

RWD Podcast Episode #31: Adam Luptak
98:38
2017-12-22 20:56:41 UTC 98:38
RWD Podcast Episode #31: Adam Luptak

This weeks show is sponsored by Media Temple,&nbsp;use promo code RD25 for 25% off web hosting.

Shownotes

Transcript

Justin Avery: Hey everyone. Welcome to another edition of Responsive Design Weekly podcast. My name is Justin Avery and I’m your curator. Well no, your curator and your podcast host and the curator of Responsive Design Weekly, a weekly newsletter all about responsive design. This is edition number 31. It’s episode number 31.

I have another lovely guest. Before we get to our guest, I just wanted to say, give a shout out to Media Temple is our sponsor for this week. Media Temple, all about the hosting. They host the Responsive Design website. They host a whole bunch of different websites actually for me. I love them. I think they’re really good. The service that they have, the help desk, is super simple.
There’s always someone online to help you out.

This week, I was looking at, if you go into mediatemple.net/landing/grid, you can cruise in there and you can get $5 for the first month of grid hosting, if you use the coupon code GRID05, so GRID05 when you sign up for this. The grid hosting is awesome. It’s like a shared hosting thing so you can run your WordPress site off it. You can run any site off it really. You can host up
to about 100 websites on that. Get about a terabyte worth of monthly band width, SSD storage, a whole bunch of email accounts. It ramps up based on how much traffic you’re getting.

If you suddenly write some awesome blog that gets picked up on Reddit and you just get a ton of traffic, it will actually ramp up your site so that it will handle that traffic. You won’t go down. That’s kind of cool. Go and check out Media Temple. Thank you very much to those guys for sponsoring the podcast. We’ll move and actually do [00:02:00] the podcast. We’ll welcome along Adam
Luptak from Rally Interactive. Welcome, Adam.

Adam Luptak: Hi Justin.

Justin Avery: How are you doing?

Adam Luptak: I’m good.

Justin Avery: Excellent. Whereabouts are you dialing in from?

Adam Luptak: Salt Lake City, Utah in the USA.

Justin Avery: Nice. What’s Salt Lake City like?

Adam Luptak: Oh my. It’s kind of a strange place, honestly. We love it because we’re an office of guys who we love what we do and we love being able to do digital work. There’s enough of a community and a city to support that. It’s also a great place for doing things outdoors. There are guys in the office who are into skiing, snowboarding, mountain biking, running, fly fishing. From my house, it’s 15 minutes to drive into work and it’s 15 minutes to be up in the mountains.

Justin Avery: Perfect. That sounds like a great place. Is there a, this is showing my poor general knowledge, but is there an Olympic-based event held around Salt Lake City?

Adam Luptak: Yes. The Winter Olympics in, well this is me showing my … I believe it was 2004. I believe it was here. I’m pretty sure.

Justin Avery: Were you around then?

Adam Luptak: I actually was in Idaho then. That was my senior year of high school.

Justin Avery: Nice.

Adam Luptak: A young’un.

Justin Avery: Don’t say that. It makes me feel old.

Adam Luptak: Oh that’s really cool. For those that haven’t heard about [00:04:00] Rally, do you want to just give us a bit of background about who Rally is and what they do?

Justin Avery: Yeah. Absolutely. We are pretty small digital shop. We’re only a couple years old at this point. This is actually I’m going into my 3rd year with the company. They were around about a year before I joined up. So about 4 years old. We grew out of the digital advertising space. A couple of us had worked for different digital advertising shops or production shops that were doing this was coming directly out of the Flash microsite days.

We were a little sick of microsites and advertising in general. We really wanted to do great digital work. We wanted to be able to, push the boundaries is really cliché, but we wanted to experiment with things and prototype and figure out new stuff. We wanted to do some work that, to say work that matters is a little bit lofty, but things that were actually that somebody might use.

Adam Luptak: Yeah. That’s really cool. That’s a good ethos to have around the company.

Justin Avery: Yeah. I mean it’s something that we, it’s not always easy to achieve, but we’ve had a lot of luck with it in our few years being around. We’ve been really lucky to work with some really great [00:06:00] really great clients. We got to work with National Geographic pretty early.

Adam Luptak: That’s cool.

Justin Avery: That was a big part of honestly helping us get to where we are today.

Adam Luptak: That’s really cool. I love National Geographic. Its one of the only … I love their website. I’m going to ask you a lot about their website now. It’s one of the only print materials that I buy on a monthly basis. It’s just something nice about having a National Geographic to flick through.

Justin Avery: Oh yeah. It’s gorgeous work. To be clear, we didn’t do their website. We’ve done a couple IOS apps for them that we can get into if you’d like.

Adam Luptak: Yeah for sure. I like the … I’ll get to that. I’ll get to that stuff. I’ll ask-

Justin Avery: I guess I should say is a bit more background on our company, we like to say we’re technology agnostic in that we want to pick the best technology for the given project. We’ve done some web work, some Native mobile work. We like to say that we could do iPhone or Android or even Windows phone. The reality is, with economics and how the different ecosystems work, so far we’ve only done IOS work.

We haven’t done any of the … We haven’t done Android or Windows phone yet. We’re not opposed to that, even though we are, a lot of us are Apple people. We’re open to anything. It’s kind of about figuring out what’s going to reach [00:08:00] the most people, what’s going to be the best solution for the client and for the users of a given product.

Adam Luptak: Yeah, that’s what’s most important right, what’s best for the clients and their budgets and future things. Talking about being a technology agnostic, when you are building websites, do you favor any particular kind of technologies from a CMS point of view or do you just build on PHP or on Ruby or WordPress or Drupal or Embraco?

Justin Avery: We’re [Jungo 00:08:40] guys mostly partially because it’s what we all happen to know, all of the developers at the moment. We all have more background with Jungo than anything else. That said, we have some Ruby experience and some PHP from back in the day that we don’t like to talk about it. We like Jungo because it’s pretty quick for us to set up. Part of that is the nature of it and part of that is a familiarity with it.

We also really like how flexible it is. The Ruby community is great and I’m hopefully not going to upset people. They have a culture of conventions and conforming to conventions and using the same tool chain. That’s really efficient for some things. We really appreciate the Jungo ethos, which is here’s a set of tools for setting up your data base and your views and, beyond that, you
can configure anything. You can use any [00:10:00] tool chain you want. It doesn’t give you quite as much out of the box but we like it that way.

Adam Luptak: I’ll ask you a little bit more-

Justin Avery: That’s our back end system and then, in terms of front end web stuff, we’re kind of I don’t know about old school but we’re pretty strict HTML, JavaScript guys. We’ve dabbled in SAS and LAS a little bit. There are some nice things in it. There’s not a ton there and, at the end of the day, it’s compiling down into CSS. As far as JavaScript goes, we’re big fans of writing just pure JavaScript.

We don’t go in much for jQuery or we haven’t done anything that’s web app-y enough, if I can use that term, to really necessitate using something like Angular Backbone. I know there are people who think that you should use a framework like that, no matter what size the project. We feel like most of the time for us so far at least, it’s more overhead than we really want.

Adam Luptak: I heard another podcast recently with a guy from Ember.js. Have you seen Ember?

Justin Avery: I think so. Is that-

Adam Luptak: I’ll probably get shot for this as well but it’s like Angular. I think there’s this thing where Angular is going from version 1 to version 2 [00:12:00]. There’s this huge big re-write.

Justin Avery: Oh yeah, I’ve heard about that.

Adam Luptak: Because so many people have built these huge big web apps on Angular 1, it’s going to take them ages to write number 2, which means they’re not advancing the framework quick enough. Embers built a little bit better I suppose. Second to the party, you’ve already learned all of the issues.

I tried it out the other day. It just felt dirty, like all it was doing was it created an index to HTML page and then I just added script tags. It was just all very … It didn’t feel clean to just have all this JavaScript in the head and then no content on the page at all. All the content just gets pulled through an API and displayed using JavaScript, which is kind of what apps do.
It just didn’t feel right. There was something wrong with it.

Justin Avery: Yeah I mean there are some people out there who talk about progressive enhancement, the idea of structuring your pages so that if you’ve got your whole web stack and you take away JavaScript, it’s still going to function with HTML and CSS. If you take away the CSS, it’s still going to work as HTML.

In reality, sometimes that’s just not worth it. The fraction of people not using JavaScript is so low. It’s kind of pointless. It feels, from a computer science perspective, that separation of having your content in one place and your styling somewhere else, as much as you can keep those separate, it just [00:14:00] feels better. I’m with you there.

Adam Luptak: Yeah. I have this constant argument with a friend of mine, Daniel Simmons, about I’m a big proponent of SAS or a CSS pre-poster because it makes my life easier.

Justin Avery: Yeah.

Adam Luptak: I can’t see a situation where I would not want to use it, just because of the way I’ve now started writing my CSS. We always have this argument about, he’s like, “No you just write CSS. SAS produces bad CSS.” I’m like, “Well bad SAS authors create bad CSS.” It’s crap in, crap out. Then he has this progressive enhancement thing as well.

He had a really good point at one point where he was doing a train app, like a train ticket app. You had to choose from a list of 10,000 stations. It was you either loaded those 10,000 in as an option list, which then made the page really heavy, or you would let someone start typing it and then you would load in the bits that they needed. He’s like, “You can’t progressively enhance
that.”

Justin Avery: Yeah.

Adam Luptak: That’s just it. I was in complete agreement and then I sent something back and said, “Well couldn’t that just be a search form field where you type the name of the place that you wanted and you hit submit as the beginning part. Then you got a list of the matches back to choose from in an option list.” He’s just like, “Well that would take a lot longer than just doing this Ajax list” which is right. I suppose that’s the thing, right? How much time do you have on a project and have close to the natural progressive
enhancement do you want to stand?

Justin Avery: Yeah. Absolutely.

Adam Luptak: Anyway, rant over. [00:16:00] Before, like I say, I featured Rally Interactive’s site a couple weeks ago on the Responsive Design Weekly. I think it’s awesome. I think Ethan Marcotte tweeted about it saying that it looked super awesome. That’s how I picked it up and covered it as well. I want to ask you a bunch of questions about that.

Before we get onto what you’ve just recently done, let me go back to Adam in 2004, just graduating from high school, coming out. Had you done much web development before, like in high school? The web was something in 2004. I was definitely working in it for a few years by then. How did you fall into your current role at Rally?

Justin Avery: Oh man. It’s kind of a long story. I’ll try not to go too crazy deep into it. I had done a bit of web work before, even before high school. I think like a lot of kids my age grew up around computers and playing games, that sort of thing. I think I was around probably 12 when our ISP at the time, this is probably right before or right around Geocities, the explosion of that.

Our ISP gave you FTP space for one web page, one HTML file, which is about the most absurd limit. I’m not sure there was actually a file size space but you could have index.htm [00:18:00]. My older brother had his index.htm file, which was I think a Nine Inch Nails site for a few years and then decided he didn’t want to deal with it anymore. He taught me how to use it was Netscape
composer at the time.

Adam Luptak: Oh yeah.

Justin Avery: Yes. I built my first web page, font tags and all, the whole nine yards, animated gifs, as a fan site for a old Sierra game series from the late ’80’s, early ’90’s called-

Adam Luptak: Yeah, yeah, which …

Justin Avery: The Quest For Glory series.

Adam Luptak: I don’t think I even know the Quest For Glory.

Justin Avery: Yeah it was right around the same time as their Golden Age adventure games, your King’s Quest and your Space Quest and whatnot. The interesting thing about them was they were actually an adventure game role playing game hybrid.

In addition to having the adventure game, finding items to use in puzzles and whatnot, you also had character classes and stats and combat. I was obsessed with them growing up and loved them. There was also a heavy mythology component to them. Each of the games is rooted in a particular area’s mythology. I learned, without realizing it, a good deal about different mythologies growing
up with those games. That was my [00:20:00] basis of getting into building a website.

That grew over time into I swam competitively growing up and, for a little bit, I built a website for my local swim team. I didn’t really think about it as a career option, strangely enough. I don’t know why it never occurred to me but it just didn’t. It was something that I enjoyed doing but didn’t think about doing for the rest of my life. Then, when I was in high school, looking
at colleges, I didn’t know what I wanted to do, thought maybe I wanted to get into filmmaking or who knew?

Was looking at schools all over the United States and ended up finding a school in Rochester, New York, Rochester Institute of Technology that was actually near where I was born, was part of the reason why I was poking around that area. They had a program that ended up catching my interest called New Media Design and Imaging. I think New Media is kind of a dated terms at this point but,
at that time, it was a program that was just looking at a lot of different disciplines in the digital area, websites and programming.

They were doing a lot of Flash work with animation. They were doing 3-D modeling and animation web design, just this big smorgasbord of skills that just seemed really interesting [00:22:00] and fascinating to me. That’s what I ended up going to college to do and spent four years at RIT learning in a design program. I have a Bachelor’s of Fine Arts, which is absurd. Came out with a really
broad skill set.

That I think has served me really well because coming out of school, between my junior and senior years of college, I got an internship at a little, to call it a digital production shop is probably reductive, but it’s a little shop that was based out of, at the time, purely out of Salt Lake City, called Struck. Struck Creative. I interned there and then went to work for them full-time
after I got out, which was great. Like I said, this was the Flash microsite days.

At the beginning of my career, we were doing a lot of that. We were getting jobs from the bigger, more established agencies, Butler Shine and goodness, the names are escaping me now, Goodby, [Pra-or 00:23:49] O’Dell, just a bunch of things. The digital team at Struck were also there’s a print team there and a traditional advertising team [00:24:00]. Was there for a couple years. I
was only there for about a year because I was hired as a designer, who had animation skills and this broad skill set but could also program a little bit.

I wasn’t there for that long before I started saying, “You know what? I’m okay at this design thing but these people I’m working with are way better than me, partially because they’ve been doing it longer but also they have a little more natural aptitude than I do. I could beat my head against the wall. I’m also pretty good at this programming thing naturally.” I’d had some exposure to
it in school. We’d been doing a lot of action script.

I kind of fell into it and quickly discovered that was the most effective way for me to contribute to the team. I also found out pretty quick that I loved building a thing and then having it work and being able to play with it. There’s that danger in any project where you finish one thing that feels really nice. It’s a rollover effect or something and you just want to sit and play
with it for hours. Yeah, I was at Struck for a couple years and learned a lot there.

Then I eventually moved on from there to Rally. They had been around for … The company was founded by 3 guys, Wes, Ben, and Thomas [00:26:00]. They’d been around for about a year and had been pulling in freelance help when they needed it here or there. They had just been out to Washington, DC to pitch for a National Geographic project. They had landed it as a 3-person company.

Adam Luptak: Nice.

Justin Avery: They decided that maybe they needed a little help. I had worked with Wes and Thomas before in the past. They had both been at Struck at one point. We ended up having some meetings and we all got along great. We knew that we had from the past. I jumped over then and I’ve been here ever since.

Adam Luptak: When you started working on the … You were saying the National Geographic thing was an IOS-related thing. Does that mean you’ve been designing it or building coding in IOS or are you-

Justin Avery: Yes.

Adam Luptak: Yeah? As well?

Justin Avery: Yup. Honestly, it’s part of I think maybe it’s from our heritage, if you will, as people coming from the advertising digital world. So far, all of the developers here, we’re guys who are used to having to roll in a bunch of different technologies and pick different things up. I mean some of the guys started out in HTML and more basic web technologies in a more professional sense. I suppose I did too but I’m not really counting my experience when I was younger.

I feel like I really started programming in Flash. Over the years, we’ve just learned to pick different things up. I feel like [00:28:00] your first language is hard and intimidating. Your second language is pretty hard an intimidating because you already know one thing and you’re afraid to pick up a new thing. After that, I feel like it gets pretty easy. You start to develop as
a programmer and understand how systems work. So you start getting much better at jumping from platform to platform.

There are idiosyncrasies to everything and different stuff, but a lot of stuff is just syntax and figuring out how to accomplish the same sort of things that you used to and solve the same problems but with different tools or different syntax.

Adam Luptak: Having a background in IOS and developing this IOS app for National Geographic, this is about 3 years ago did you say?

Justin Avery: Yeah.

Adam Luptak: Going back to 2012. As the web has evolved to what it is today, if you were to go back, what’s your thoughts on developing something specifically for IOS [verse 00:29:24] building it as a mobile first website and putting it in a wrapper for discoverability rather than the interactions? Do you think that the web is ready to take that step up or is there still some lag behind that you need to develop an IOS?

Justin Avery: I think there’s still some lag definitely. It’s definitely getting closer than it was. I’m not sure, from my perspective, I’m not sure [00:30:00] that web technology is ever going to be quite as good as Native. We may get to the point with the technology, as it gets more powerful where it doesn’t matter. It’s there’s the joke about Microsoft Word that after how every many years they’ve been building it that, at the end of the day, you’re putting text into a document and the boot time for it hasn’t gotten faster.
It’s gotten slower. It’s because we take for granted the amount of processing power we have available to us and fritter it away now because we can.

Adam Luptak: Yeah.

Justin Avery: Certainly even in the time we’ve been building IOS apps, the devices have gotten a lot more powerful. You can get away with things that you couldn’t before. Those first IOS apps, particularly the ones Apple made before the SDK was opened up, those things had to be optimized to within an inch of their lives because the device just wasn’t that powerful. They’ve come a long way but they’re still just a lot of [cruft 00:31:28] in the web stack. Some of that is by design. There’s some weirdness, JavaScript behaves
in some strange ways, which can be useful to you sometimes but sometimes it’s just weird.

Adam Luptak: That’s the hardest thing, right? You develop with IOS. You know the platform that you’re running on. You know how it’s going to behave. When you do a website, you don’t know what JavaScript whether the engine’s going to be running it [00:32:00]. There’s so many other unknown variables I suppose.

Justin Avery: Yeah that’s one of the big things. There are just so many variables with web work. There are things like when you tap on, I was just discussing this one with Anton, one of my other colleagues here. When you tap on a link in a mobile browser, it needs to wait for a second before it does anything because it needs to see if you’re performing a double tap because that does something different to repress and hold. Whereas in a Native app, you can tell it, “All we care about is taps.”

You can react immediately where if you start trying to get in the way of that stuff on the web, you run the risk of making the experience feel weird and broken because it’s not working how people expect it to because it’s a website. There’s cruft there. You’ve got garbage collection that you have to worry about that we’re fortunate to not have to stress about in IOS. We have other
memory management things to concern ourselves with.

It’s just a different thing that the web is really astounding how far it’s come in the last, really kind of the last five years honestly, as far as all of the different things we can do with it now. It is still just a slightly different platform. I’m not sure if the performance is really ever going to be the same. Maybe I’m wrong.

Adam Luptak: Only time [00:34:00] will tell. I agree with you. The last five years it seems … I don’t know if you’ve felt this as well but I used to consider myself to be reasonably competent with building websites. Over the last five years, I feel less competent because there aren’t just website builders now. There’s just front end guys and just people that work purely on CSS. There’s just JavaScript developers. There’s just performance engineers that just look at a website’s performance and that’s their one role.

Everything is very, compartmentalized maybe is the wrong word but there’s so much involved with the web these days that there are becoming these fractions of jobs and people getting very, very good at very specific things instead of being generalists.

Justin Avery: Yeah. Absolutely. That’s something that we’ve talked about. When we’re starting to grow, finding generalists is harder these days. It seems like everybody’s specializing and we’re saying, “Are we big enough yet to take on generalists?” That’s the struggle of being a company that bounces from technology to technology. We don’t always have a web project going or always have an IOS project.

Adam Luptak: Yeah it’s tough. One project that you have had recently has been your website itself.

Justin Avery: Yeah.

Adam Luptak: Well done that. That’s awesome.

Justin Avery: Thank you. We really appreciate the feature. There’s been a lot of attention around it and it’s been quite flattering.

Adam Luptak: Did you guys internally approach this in the same way that you would approach a client’s project?

Justin Avery: Kind of. I mean there’s [00:36:00] they say that building your own site as an agency is the hardest thing that you’re ever going to do. That’s certainly true in our experience. It’s a tricky one. Part of it we’re perfectionists maybe. We care a lot about getting the details right on everything we do but there’s extra pressure when you’re doing it for yourself.

Adam Luptak: You’re baring your soul kind of thing right?

Justin Avery: Yeah.

Adam Luptak: You can’t then go, “Well this is what the client wanted.” It’s like, “This is honestly what we think ourselves is the best possible thing for our business.” Because if you miss the mark and someone looks at it, they’ll be like, “Well I’m not going to get you to build my site. You can’t even get your own stuff right.”

Justin Avery: Yeah. Absolutely.

Adam Luptak: Huge pressure.

Justin Avery: Yeah. It’s been a long process. Honestly it’s the longest process that we’ve had on a single project so far. Some of that is due to the reality of doing work for clients. We don’t have the money to just endlessly do our own thing. There have been times that we’ve been working on the site that we’ve had to put it on the back burner a bit. The process of building it lasted at least around 2 years from the first time I saw any designs.

Adam Luptak: Oh wow.

Justin Avery: Yeah it’s been-

Adam Luptak: Before you even got to the design phase though, was there a reason behind [00:38:00] the redesign? The 3 guys that founded the Rally Interactive, was there business reasons behind it? Were there business reasons behind it?

Justin Avery: Yeah. Some of that goes back to the formation of the company. When they started it, obviously you’re a company in the digital space. You need a website so that people can find you. There was a lot of discussion about what the website could be. Obviously the 3 guys that started the website, as Thomas was the business guy and Wes was the developer and Ben was the designer. They had all the skills they needed. They could have just built a studio website, a pretty standard studio thing. They talked about different
options.

There was some discussion about more whimsical prototype ideas. Wes was playing with a site that was just a huge Facebook like button that was comprised of small Facebook like buttons. I think they ended up figuring out they could technically do it, but it violated the heck out of Facebook’s [crosstalk 00:39:25]. So ended up not doing that. What they wound up doing, which was really,
as far as I understand it not intended to live that long, was a quick little site with a little information about the guys and what they were about.

Then Dribbble, the website Dribbble, was … I’m sure I’m going to be wrong about this. I want to say it was pretty new at that point. Ben [00:40:00] had been using it a lot as a tool for sharing process and getting feedback so thought we’re a brand new shop. We don’t really have any work yet to speak of so let’s just show off our process. They came up with a way of showing Dribbble
shots and came up with a pretty cool way of doing it, these little triangles that were actually a canvas element with JavaScript. It’s a little triangle element that when you hovered over it, it rotated, and when you clicked on it, it spun around and turned into a circle. It’s actually still, as
we record this, up at rallyinteractive.com.

Adam Luptak: It shows you how many likes and views and feedback and you can view this shot on Dribbble from there?

Justin Avery: Yup. That concept still exists in a modified and updated way. At the bottom of our Rally site, each of the case studies actually has Dribbble shots from that particular project. They came up with the solution to show that off. It was great. Actually, over the years as this site has lasted probably longer than it was ever really intended to, people still talk about it and seem to really enjoy it. Ben and I were actually at a Google through a design conference last fall in San Francisco that we were lucky enough
to snag some invites to.

Having conversations with people, I had more than one conversation where I told somebody that I was from Rally Interactive. They’d think for a second and say, “Oh yeah. You guys have [00:42:00] the website where the triangles turn into circles.” I was like, “Right. About that, we’re working on a new website.” That site did really well for particularly within the design community
because Dribbble has become such a big thing and people love it. A, it started to feel kind of dated to us and the company has grown. It’s not just 3 guys anymore.

Part of the problem was we’d get all of these business inquiries from people who think that it’s just 3 guys or just 1 guy because they don’t read very carefully or they think we’re only a design shop. There was a real impetus behind doing, in our new site, we really wanted to do something that communicated really who we are and that we care about doing the whole thing. We found that
because we’ve done some design-only projects and when we do design and hand it off, we have no control over the end product. Almost invariably, it’s not quite as good as we would like it to be. We always nitpick our own stuff too but we like being able to take projects from the beginning to end.

That’s really important for us to be able to A, get the level of polish that we want out of a project and also there are a lot of things that it’s hard to account for in the design process. By keeping development in-house, when we run into a problem, which we invariably do [00:44:00], one of the developers will go over and bug one of the designers and say “Oh hey, this thing doesn’t
work or doesn’t make sense” or we haven’t thought about this and how are we going to fix this? It’s maybe not the most efficient process time-wise but it’s how we like to work because we feel like it gives us the best product at the end.

Adam Luptak: The product that you have at the end is second to none. It’s awesome. Like the [Beater 00:44:29] is something else. It’s quite cool. Should we have a … When you went through, did you get designs handed to you?

Justin Avery: Yeah. Yeah.

Adam Luptak: The site itself, I suppose it would be interesting to hear how you guys work with interactions. Some of the things I quite enjoy about the site is that when you first get there, there’s this ribbon, like paper folded up across the page, which then moves across and then, at least on the desktop, you’ve got this diamonds which says one of four with arrows going left and right.

As you hover across that, if you hover on the right, then the diamond changes perspective and almost leans, pushes across to the right and everything comes off the page a little bit to indicate you need to click. Same thing with the other way. Those interactions, how are they communicated from design across to development?

Justin Avery: It’s a lot of … It varies from project-to-project. In this one particularly it was just a lot of communication from the designers to the developers. We, particularly in some of our IOS apps, will often prototype things either in Aftereffects or [00:46:00] more recently in tools like Quartz. For the site, we ended up just having a lot of conversations about design elements and how we’d like them to animate and move.

I’m pretty sure, for instance, the diamond element in the comps, even back to some of the earliest ones, that the diamond was just there as a UI element to communicate where you were and how many options you were. Like you mentioned, it’s an element that goes away at certain screen sizes just for screen real estate reasons.

The actual tilt was just an element of a designer throwing something out and trying it in development and back and forth of figuring out how far to tilt, how much to do the alpha to get it to feel right. As for the ribbon, the ribbon is kind of a funny story. The ribbon is kind of my baby.

Adam Luptak: Before you enter the ribbon, just a really quick on. On the diamond and the tilt, is a lot of this stuff you’re doing here do you just fall back to using JavaScript for the interactions or do you try and use the CSS 3 animation things as well?

Justin Avery: It’s actually that’s a funny story because our first impulse is always to use the CSS transitions because what we’ve found is most of the time, 90 percent of the time, you want to use those because on your weaker devices, your iPhones and tablets and whatnot, they’re actually really well optimized to put those animations on the GPU [00:48:00] and you tend to get much smoother animations there. What we ran into on this site was that because of the specifics of the ribbon, which I’ll get into in a second, it had
to be a JavaScript run loop.

We were discovering that by having that running and CSS transitions running on top of it, the weaker devices, when push came to shove, would just completely cannibalize the JavaScript run loop in order to make the GPU animation work, which meant that we got a beautiful, smooth CSS animation while, behind it, the entire canvas element shuddered down to 10 frames a second, if that.
It just looked terrible.

We ended up having to, in that top portion of the site, when that JavaScript run loop is active, everything’s powered off of JavaScript. Then when you move down into the body of the site and we can turn that run loop off, everything switches over to CSS.

Adam Luptak: That’s a great, great solution.

Justin Avery: Thank you. A lot of what we do, it’s i don’t feel like none of us are geniuses. We don’t really understand how browsers work. We’re not incredibly technical guys. We have just done enough experimentation. We only know that because we tried about 8 different combinations of getting things to work and just discovered over and over that the second we took out all of the CSS transitions, all of a sudden the JavaScript [00:50:00] ran great. It’s a lot of it is trial and error. That’s the sort of thing that, in a lot
of cases, there probably isn’t time to do. Because it was our site and we were committed to getting it right, we took the time for it.

Adam Luptak: I just love that. I’ve just been sitting here going back and forth between the transitions of having that header and the ribbon running across and when you go down to the content below it. This is the worst thing about doing a podcast like this is that no one can see what we’re talking about. Everybody should just go check out Rally Interactive. Just that interaction of the ribbon then becoming the header bar, where you have the navigation stuff as well, there’s lots of very small things around the site.

One of the things I noticed is it feels like you were talking about running with something like Angular or whatever else there is, the one page web app kind of things which more and more people are doing these days. This site feels like a one page web app because there’s no you don’t get this loading. The perceived performance is exceptionally fast. I don’t feel as though I’m waiting
for a page to load. As I click through the navigation stuff, I go for the home page and move through the different pages, so to speak. You’ve got the city guides, the snow bird, and then the national parks, which is the National Geographic work that you did. They’re all different URL’s.

Justin Avery: Yup.

Adam Luptak: It feels like a single page app. How are you magically [00:52:00] making that occur?

Justin Avery: It’s magic, Justin. No. I mean honestly what we’re doing is another thing that evolved over the process. The reason it feels like there’s not a load is because there isn’t. We’re cheating. What we’re doing is each, and this is another thing that we love about Jungo. We have our views set up such that when you hit any of those URL’s, you get the HTML you asked for. You get that page and obviously the style sheets in JavaScript and all that stuff.

For instance, if you save it into a reader like Pocket or Instapaper or any of those, it does actually more or less work correctly. Immediately after that loads, we’re going ahead and doing a second Ajax request to a separate URL we have set up that basically says, “I’m on this page. Give me the rest of the pages in a JSON object.

The beauty of that is in terms of memory footprint HTML is just text and text is small. We can just get the rest of the mark up for the site and just hang onto it. At that point, we essentially have the mark up for the entire site sitting in an array so we can just populate a page to each side whenever we need it.

Adam Luptak: If I’m on the home page, do you get the page to the left and [00:54:00] to the right of that or do you just-

Justin Avery: You get all of them.

Adam Luptak: All of them down.

Justin Avery: Yup.

Adam Luptak: Any problems with the storage limits across different devices, different browsers?

Justin Avery: Oh you wouldn’t believe. I mean actually not with that particular request but the big problem we ran into, because I’m sure you noticed, and people who go to the site will notice, the case studies are enormous. They’re super long, just not even bordering on too long didn’t read. You need an attention span for these things. That was kind of on purpose.

Adam Luptak: I think thorough is the word.

Justin Avery: Yeah thorough. I say that. I wrote the first drafts for all of these. I’m criticizing myself. It was on purpose because again we wanted to really take the chance to tell our story, talk about all of the ups and downs we have with projects, struggles, things about our process. I really wanted to write case studies that would be interesting and instructive for different kinds of people. I feel like so many case studies that you see are really marketing speak. They look great and they have beautiful images and
you read them and you say, “Oh well I just learned nothing.”

We really wanted to craft these in a way that if you’re a designer, you can read these and maybe you won’t understand all of the technical details, but you understand the process, how we got there and our design solution. If you’re a developer, you’ll understand these technical things and you’ll get a window into [00:56:00] how our designers think, which maybe is different than how
you think or how the people you work with think. We’re hoping that will be useful to different groups of people. I’ve gone off on a huge tangent but that’s all to say these pages are really, really long.

The problem we ran into was no so much the length but because they’re long and because we want to illustrate things as we go along, there are a lot of images. We found pretty quickly that on devices that are a little old at this point but not even that old, the iPhone 4S, the iPad 3, if you load that many images up, the device will crash. Safari will crash. It will run out of memory
and just go. We actually had to be a bit trickier with loading images as they came on-screen and unloading them when they go off so not everything is sitting in memory.

Adam Luptak: Yeah I noticed that. I’ve just been scrolling up and down the city guides. There’s some great things there. The device Chrome is loaded in. I assume that’s almost like a very small PGN or SVG. All the images load in as you reach there. If you scroll through quickly and don’t hang around … If I scroll past a section where you would normally load in a bunch of images, it’s not like it just loads them in there. Right? You’re waiting for someone to hang on that spot for a second before you’re loading it in?

Justin Avery: Yeah.

Adam Luptak: I would have thought though that once it’s loaded in, is it no being cached [00:58:00] and therefore you don’t have to unload it? You’re saying that unloading it helps for memory on older devices?

Justin Avery: It seems like unloading them helps. This is a place where I have to confess a bit of ignorance. We’re not sure. We definitely couldn’t load them all in at once. I don’t think we can have all of the images for all of … Because if I remember right, and this is getting into pieces of the site that I didn’t build. Obviously something of this size and complexity takes a team. I didn’t touch some of these pieces.

I think the HTML, once it gets loaded in, actually gets created in the DOM and left there but is just hidden when you don’t need it because there’s a hit on the processor when you render things into the DOM. That can cause animations to hitch. We wanted to hide that. We definitely need to, when we went from case study to case study, we would need to unload everything in the case study
left.

We just, for now at least, came up with a compromise where whenever you scroll everything on screen or a screen in either direction should load up and everything else should not be loaded. It seems to, so far, be working out okay.

Adam Luptak: Yeah, it looks super smooth. One of the funny things is when I had the banner going through for a while, the ribbon. It does spin the fan a little.

Justin Avery: Yeah.

Adam Luptak: Mind you, I’m one of those people that have 7 [01:00:00] versions of, or 7 different Chrome browsers open each with an unreadable number of tabs in each browser. I’m not saying that it’s specific just to the site but if you’ve got 78 or more windows open and you leave it on the ribbon, it’s-

Justin Avery: Oh absolutely.

Adam Luptak: -it will spin a bit. With the images and stuff, do you guys have a particular responsive image go to approach? Yeah? I’ll leave that open.

Justin Avery: Yeah. I mean our approach such that it is, I think this applies more generally to all sorts of responsive things. We don’t feel like there’s really any great magic bullet solutions to any of this. We don’t have any magic wands for anything, which is partially why the site took so long is because this stuff is hard, especially when you’re doing something that doesn’t … A lot of responsive sites can tend to look the same. I’m not sure that’s a failure of imagination so much as there is definitely easier ways
to build responsive sites than others.

I think some of the [stops 01:01:31] that we see a lot in responsive sites happen to be the things that are actually more efficient to build. Back to the images specifically, we just started off very simply. A mentor of mine back in the day used to say, “Optimize later.” We just started off with the biggest images [01:02:00] that we had, our retina size images, and we started with
those. Then we sized the containing DIVs.

My co-worker, well actually both of my co-workers, Anton and Wes, are CSS geniuses, they’re way better than me at it, came up with a system for keeping the device Chromes. I believe those are CSS backgrounds. It’s a container system where that background is there and the whole thing can be sized down. It keeps its aspect ratio and sizes down the image inside it properly. The whole system
just works. Of course a lot of these images, if we’ve got the full retina screen shot, particularly God forbid it’s an iPad or desktop retina screen shot, way too big for a phone.

You don’t need three quarters of those pixels. We started as part of our memory woes also saying, “You know what? We could also have smaller versions of these.” We do have, it’s actually built into the same system I believe that does the image loading. As you scroll, it’s also doing a check. We’ve got some defined break points. It’s saying if the width is smaller than 768 and the
image attribute, because how those work, those image tags that we do the loading with. They’ve just got a very small, and I’m blanking the word for it. It’s a way of encoding images into [01:04:00] text.

Adam Luptak: Of the Data URI?

Justin Avery: Yeah. We’ve got the source in there are just basically a transparent gif.

Adam Luptak: Yup. One pixel by one pixel gif that’s encoded in that way. Then it has additional attributes since HTML 5 allows us to do that and just put whatever we want in there legally. You can get away with it before then but they updated the spec so that we were legally allowed to do what everyone was doing anyways. We’ve just got a URL in there for what the actual image is so we can swap that in.

Justin Avery: Whenever it comes in the view.

Adam Luptak: Whenever it comes into screen. Obviously it’s a little trickier than that because of the CSS transitions, but that’s the basic concept. Additionally, we can just have an additional property on there, which is a 768 image, for screen sizes smaller than 768. It just kind of makes that switch at run time and says, “Oh you’re on a smaller screen. Get this asset instead.”

Justin Avery: That’s very cool. Like I said, it is a really lovely site. It’s just a joy to scroll through. It’s working well. You shouldn’t take too much longer before you push this to the www.

Adam Luptak: Yeah, we’re hoping to do that soon. Honestly, this week we’re working on there are still a couple small issues. We are very focused on WebKit browsers [01:06:00]. There is at this moment and maybe will be fixed within a few hours a Firefox bug that prevents the menu from closing. We haven’t really tested that much on Internet Explorer recently. We’re mostly hoping to just knock out some bugs and do a couple tiny visual polish things before we push it.

Justin Avery: I’m just now quickly loading it up in Opera mini.

Adam Luptak: Oh dear. Oh dear. I am afraid.

Justin Avery: It’ll be fine.

Adam Luptak: I’m afraid.

Justin Avery: I’m sure it will be fine. While I’m typing this into Google mini, Opera mini, the workflow, a little about the design, a little about the front end stuff. Are there specific workflows that you approach from a technical point of view? I’m thinking more of the listeners out there might be using Grunt or Gulp and they might have particular workflow processes of pushing things and working in teams. Do you guys have a set way of working?

Adam Luptak: We don’t really, except for it’s a horrible cliché to say that our process is that we have no process. That may be something that changes as we get bigger. I’ve worked in teams before that had slightly more defined processes. I’ve seen it work and I’ve seen it not work. I’ve dabbled in some Agile methodologies. I see value in some of that. Honestly, so far our process is mostly sit everybody in the same space and make them talk to each other [01:08:00]. We’ve got one shared space that we sit in and the designers ideally,
this breaks down sometimes when people are stuck on other projects and everybody’s jammed up.

Ideally we’ve got designers working on a project and developers, either they call us over or we’re nosy and we go butt our heads in and weigh in. Then when we start building the thing, whether design is done or not, design they’re poking their heads in and seeing things and giving us feedback. Oftentimes the end of a project, particularly IOS projects, we’ll have a big polish push
at the end where we I think we’ve made a name for ourselves a little bit with some of our animations on IOS.

Ben particularly is really picky about easing on animations and he’ll sit over the shoulder of whichever developer has the longest fuse left at that point and kibbutz the easing on an animation for hours sometimes to get them right.

Justin Avery: It does seem to show.

Adam Luptak: Thank you. The site has been an interesting … It’s both emblematic of that process and also it’s been a little bit strange. Like I said, it’s such a long process.

Justin Avery: Two years.

Adam Luptak: Yeah. The original designer, as far as I know, the first designer to start on it [01:10:00] doesn’t work with us anymore, has since moved on to a different gig.

Justin Avery: Hopefully not because of that.

Adam Luptak: No. I don’t think so. In the original comp, that ribbon element you were talking about was just a nice design element, a little bit of visual flair, this little interesting ribbon up there. It really just existed to give you a little bit of sense that there was the notion of having the website exist in this horizontal plane, where you could move left and right. That existed from the beginning. The ribbon was just there to suggest a little movement and be a fun little thing. We played a little bit with web GL
solutions but weren’t real happy with the effects we were getting there so came up with a Canvas solution to do it and had a very rudimentary system for drawing the ribbon kind of how it looks now.

It didn’t have as much movement to it. When you moved left and right, it didn’t actually straighten out how it does now, it actually flexes out a little bit. Instead it started moving faster and, as we created new segments, they just got straighter and straighter. Then as it slowed down, they went back because that was an easier thing to build and weren’t totally happy with it but
it was fine. We got busy with client projects. It got put on the back burner. Other designers got moved onto the project.

One day, one of the designers [01:12:00] calls me over to his desk and says, “We had this idea” which is always a scary moment. He said, “We have this idea because the ribbon up here is really cool and when we move down into the site, we’ve got this sticky nav that we’re header bar that we’re sticking at the top. They’re the same color but it feels disconnected. It doesn’t really
feel the same. Is there any way we could straighten the ribbon out and turn it into that nav?” I had a moment of saying, “I don’t know. Yes, I think. It’s going to take some doing.”

We worked it out and it was okay because I wasn’t really happy with how the ribbon was functioning anyways. It was that extra kick in the pants to say, “Okay go back to the math. Figure out how to actually straighten this thing out and relax it back into its folded-up state programmatically so that we can do that and then do …” It’s from Raiders of the Lost Ark, the Indiana Jones bag of
sand thing where we animate that ribbon up until it’s straight and then immediately swap it out with a HTML element that just happens to be sized the same, the same color. It’s just a seamless hand off.

Justin Avery: Except you don’t have a giant boulder then chasing you down a thin alley.

Adam Luptak: You weren’t here for the development process, Justin. You don’t know.

Justin Avery: It probably was. Look, good news too. I did fire up, now albeit I fired up your site on an iPhone 5 [01:14:00] but with Opera mini and it works. The animation is there as well. The ribbon goes through. It looks good. It scrolls well. I’m on Opera Turbo, whatever that means. I’ve got savings enabled so I saved 7 out of 11 megabytes.

Adam Luptak: I’ll be.

Justin Avery: Yeah so there you go. I don’t know what that means but it all seems to work fine.

Adam Luptak: It means we’re really quite good, Justin.

Justin Avery: Win, win for you.

Adam Luptak: Wow, I’m surprised.

Justin Avery: No, that’s really cool.

Adam Luptak: Hopefully very soon. Trust me, we want to get it launched. We A, want the monkey off our backs. It’s gotten a lot of attention on Twitter and Dribbble. Ben’s been publicizing it. We’ve gotten a lot of great attention. Ultimately our goal with the site, we want all kinds of people to see it.

We want designers to see it. We want developers to see it. We want businesses that might want to work with us to see it. We’re hoping that not all of them understood Dribbble necessarily and maybe didn’t quite get what we were doing with our old site. Hopefully the case studies at least, if we don’t scare them off with the crazy ribbon, will communicate who we are and what we like
to do.

Justin Avery: No it is. It is a good advertisement of what you can provide anyway. Well I think it does. I want to ask you. I’ve got a couple of questions which people have sent through. One that I wanted to ask before we go onto those, and I know that I’ve enjoyed talking to you so much that I’ve lost track of time. We’ve actually gone on for quite a while [01:16:00]. Is there anything you would like to see these days? This is just generic.

Anything that you would like to see these days on, and I was going to say responsive sites, but just websites in general? Are there things that people aren’t taking advantage of that you think they can do?

Adam Luptak: Oh let’s see. I mean there’s still it’s hard because as a person who’s built responsive sites, responsive work isn’t easy. We know that and we’ve taken different approaches to different things over time. If people, I won’t get into it, but if people read the case study about the Snow Bird site, they’ll see we took a very different approach to that site than we did our own site. It’s a difficult challenge to make things run as well on a desktop as well as it does on a phone or the other way around usually.

If people take advantage of the modern CSS tools, where they work best. There’s a lot you can do and the devices are getting better every day. It’s great to see sites get better and better at that because you don’t want … You want the experience to be correct for what the user’s coming to. I feel like I think it’s going away. I hope it’s going away.

I feel like when responsive web design became a thing [01:18:00], there was people in the design community got excited about it. You’d get a responsive site and you’d re-size your browser and watch things animate around the screen. It’s like “Whee, isn’t this cool? No one uses the web like that. Why are we doing that?” It’s about providing the right experience for where the user is.
Making sure you do that.

A personal pet peeve of mine is I despise when, because I see this all the time because of Twitter. Somebody shares a story from a news site and they haven’t updated their site in however many years. Suddenly I’m looking at M.dot whatever dot com and I’m looking at the browser layout across my desktop screen. I’m saying, “There is no purpose for this.”

Not to be pedantic but URL stands for Uniform Resource Locator. It’s a place to get at content. I expect that content to be the same wherever I look at it. I don’t expect it to look the same. It should look appropriate to what I’m looking at it on.

Justin Avery: Very true.

Adam Luptak: I think a lot of people are getting much better at that, better every year. I hope that people continue to get better at it and just pay attention to serving the users the best thing for where they are.

Justin Avery: Hear, hear. Well said. I’d cheers you if I had something to cheers you with.

Adam Luptak: I’m raising my water bottle to you [01:20:00] sir.

Justin Avery: That’s very true. I like the. The other thing that annoys me is when you click on a desktop link on a mobile and it takes you to the M.dot site, but not the M.dot site with the article, just the home page.

Adam Luptak: Oh yeah.

Justin Avery: That’s the worst. I know what you’re after but here’s the mobile site and home page in case you were looking for something else.

Adam Luptak: Yeah and that’s the trick. It’s a hard solution and it takes thinking about it. You should, no matter how you’re doing your site, whether you’re making decisions on the back end and serving different content for different devices or whether it’s all one response and uses JavaScript or Media Queries or however it’s making those decisions, every URL has to exist at every platform. It has to give you the correct information in every place.

Justin Avery: There’s a talk a few months ago now by Phil Hawksworth. He used to work with a guy who did some sketches, like big sketches on A-1 sheets. It was a Biro-sketch which says the URI is the thing. It’s just this amazing piece. I’ll shoot you, once we finish with this, I’ll shoot you a link to it and I’ll put a link in the show notes.

Also, anything that Adam has talked about through this conversation, there will be links to all those things in the show notes as well. Yeah, no, it’s this magical thing, really cool sketch. We got it printed up in AO in the office. It’s very cool.

Adam Luptak: Fantastic. I look forward to seeing that.

Justin Avery: Yeah, it’s [welco 01:21:59]. So look, I’ve got [01:22:00] like I said, we’re coming very close to the end. I have two questions for you. One was actually sent in through the newsletter. I get some replies sometimes. I’ve got this thing now of ask me anything. If someone’s having problems with building responsively or just their websites in general, they can write in. Max Angless, I’m going to massacre the names through this process.

He said that he’s designing a portfolio and he’s working on making it responsive, which is good, [Auto Max 01:22:33]. He says he’s done a lot of responsive work before using Media Queries and hamburger menus.

In the latest newsletter when he wrote this in, I featured a company called Red Booth, who had dropped a hamburger menu from their IOS app and put a fixed toolbar menu at the bottom of the app instead. It had a lot better take up of the app. People were finding things more, based on their stats that they’re all looking at as well. I know that the Rally Interactive site, you’ve gone
Hamburger menu all the way through. It doesn’t matter what size it’s at. What are your thoughts around that? Is it, yeah, well what are your thoughts around that?

Adam Luptak: Yeah. Hey, Max, I’ll shout out. I mean I think the truth is maybe people who can quantify things will disagree with me but I feel like there’s not really one right solution for everything. The hamburger menu is, even though it feels new, it actually has a long history. I remember seeing a Medium article about it, something, about the history of the hamburger icon. It is burying your nav [01:24:00] behind a tap.

We were having a discussion about that. We’re working on a new IOS app for National Geographic right now. It’s the third app we’ve done for them. We were having a discussion about a certain feature, whether it should be hidden in a menu or out on the home screen because there’s always that trade-off and it’s even harder on responsive sites or on mobile sizes. Your screen size is incredibly
limited.

If you’re in a position where you don’t have to hide your nav behind a hamburger icon or drop down menus, which have largely gone away I feel like in response to responsive design and hovers that don’t work in responsive sites really. If you can get away with not doing that because of the content and because of how things are structured, by all means don’t. There are times that it
just seems the more appropriate solution … I get why a lot of people do. You’ll see some sites where even on the largest sizes, if it’s one responsive solution, they just go with the hamburger icon for everything. We’re doing that with our site.

Part of that is just in terms of both economy of code and [01:26:00] design thinking, keeping one consistent solution as well as, even though I just said that people aren’t really re-sizing your site a ton. That said, if they look at your site on a phone and they look at your site on a desktop, it should be appropriate to where they’re looking at. You don’t want them to be lost either.
Where you can, be consistent. That’s good too. It’s always so much of design is a balancing act. You’re trying to find the right balance of everything. I think I’ve talked around it a lot but I think there are places where the hamburger is great.

There are places where it’s the lesser of all evils and just the most efficient solution. Then there are places where maybe you don’t need it, so don’t. That’s my thinking about the hamburger icon.

Justin Avery: Good advice for Max. Hopefully Max, that has given you some insight into how to approach your portfolio site anyway. It’s never finished anyway. Try it. Try two different ones. See how well you go-

Adam Luptak: Yeah. Absolutely.

Justin Avery: -as well before. Right?

Adam Luptak: Yeah. If you have the appetite for putting analytics onto your own site, that would be a great way to AB test some solutions if you’ve got the free time for it.

Justin Avery: Yeah. Exactly. I love doing that sort of stuff. I do and I don’t. The things that I learn from it, there’s two things. One, I learn how to apply analytics and do AB testing. The other is I work out what works best. Both things are beneficial. For Max, if he’s doing work for clients, both of those things are beneficial [01:28:00]. One, you have a better recommendation for a particular scenario and the other is you know how to implement analytics for them to measure their own stuff as well.

Adam Luptak: Absolutely.

Justin Avery: Win, win, win. I have one more question before we’ll wrap up. Thank you so much for coming on. This question is a post from our last guest. Each week, I get a guest to ask a question of the next guest. Once I ask you this question, I’ll get you to ask a question for our guest next week. This one is, what is the single most interesting current mobile pattern that you’ve seen come out?

Adam Luptak: Oh dear.

Justin Avery: That’s the question to you.

Adam Luptak: Single most interesting mobile pattern. I’m going to assume that he’s talking about design patterns.

Justin Avery: It’s your question. It might be. You can take it in any way, shape or form. It’s your own opinion whereas I don’t have the answer written.

Adam Luptak: That’s convenient.

Justin Avery: It’s not hamburger icon just [crosstalk 01:29:16].

Adam Luptak: Wouldn’t dream of suggesting it. I really think it’s that tray that Facebook pioneered four years ago. No. I mean I will be the first person to admit that I don’t troll for inspiration quite the same way that designers do. They’re out there looking at Dribbble and looking at sites a lot more than I do. They see a lot more of the fancy stuff going on. My use of the web is a bit more utilitarian. That being said [01:30:00], I like that we’re finding ways to go back to doing I think what the web is good at.

There was, at least from my own perspective being in advertising, there was this big exodus to Flash. “Oh my gosh, we can do all these things with Flash. The web used to be so boring and now we can do all this stuff.” The beauty of the last maybe decade, five years, however long that period’s been going on, people have been simultaneously figuring out how to do fun stuff with more Native
technologies.

I’ve never been a Flash basher. I came up on it and it was a great experience but it’s clearly not the best tool for everything going forward or even most things going forward. Now we can do a lot of those things. We’re also figuring out you can make great experiences, beautiful sites, with pretty simple design. More than anything else, the web excels at delivering images and text on a
page. I think that’s beautiful in a pure way.

It’s like the work of Massimo Vignelli&nbsp; or any of those old amazing graphic designers. They didn’t complicate everything. It’s about [01:32:00] clarity of vision and communication. I actually really like that a lot of people have been going back to that, both on the desktop and on mobile devices.

Justin Avery: Cool. Nice. That was very well answered.

Adam Luptak: Thank you.

Justin Avery: I’m glad you didn’t stick with the tray.

Adam Luptak: No, that was-

Justin Avery: That was good. Now for the next guest though, do you have a question that you can pose for the next person on?

Adam Luptak: A question for the next person? I assume related to technology and digital design and the web ideally?

Justin Avery: As a responsive design podcast, it can be related to anything you choose but something to do with the web is always good.

Adam Luptak: I think I would be curious to hear what the next guest thinks. It’s so hard to predict where technology is going, whether Hollywood is always playing with things and your minority reports and whatnot. I’m curious what the next guest thinks what they’re excited about, what they’re just seeing glimmers of in the technology space now, whether they think it’s not really going to be useful but just a fun toy or if something that might genuinely change how we use our computers and interact with information and learn
things [01:34:00]. I think I’d be curious to see what they think might coming next and what they’re stoked about.

Justin Avery: That’s a good question. It is very interesting at the moment as well with the number of input devices we have now. We’ve got these Smart Watches coming out soon, the internet of things or stuff that talks to the internet. They’re all going to be things that we’re going to have to deal with in one way, shape, or form. Good question. I’m going to be very interested to hear the answer.

Adam Luptak: Me too. I’ll have to tune in.

Justin Avery: Which you do every week though, right?

Adam Luptak: Of course.

Justin Avery: It doesn’t matter. It’s just part of your normal week. Adam, thank you very much for joining us. I’m sorry I kept you for so long. It has been wonderful talking to you and hearing stories of Rally and your past and how you’ve put together such an amazing site. If people want to hear more about that or more about the work that Rally does or that you’re doing, how do they follow you and get in touch? Things like that?

Adam Luptak: Let’s see, well first I’d direct them to, for them time being, beta.rallyinteractive.com. As soon as we have that pushed over to, once we’ve worked out our Firefox bugs and our last polish issues, that will be redirecting to rallyinteractive.com, without the sub-domain. As for me, my Twitter handle is [Zoomgoo 01:35:42] 777 and I will just let you put that in the show notes. That’s probably the best place to shout out to me. There are also [01:36:00] if you’ve got questions for the studio, I think there’s an info@rallyinteractive.com
email address that you can hit. Obviously there are email addresses on our website.

Justin Avery: Awesome. Very, very cool. Like I said, thank you very much again for joining in. Thank you everyone for listening this week. I hope that you’ve learned. I’ve definitely learned something. I’m sure you will have as well. Feel free to write the podcast up in iTunes or share it with any of your friends if that’s what you’re into. Next week, I’ll be here with another edition of the podcast with another special guest, answering Adam’s very tough question. Adam, thank you again for joining us. Yeah.

Adam Luptak: Absolutely, Justin. Thank you. I should mention Rally is @let’sgorally on Twitter.

Justin Avery: Oh yes. Good.

Adam Luptak: Be sure to follow the company there and I think we’re @rally on Dribbble, if you’re on Dribbble.

Justin Avery: Or just scroll to the bottom of the site and see-

Adam Luptak: Or scroll to the bottom of the site. It will get you there.

Justin Avery: Yeah, good triangles. Are you guys hiring soon if anyone’s interested in working for a cool?

Adam Luptak: We definitely are. We’re always on the lookout for new talent, particularly developers right now. We’re a bit overstaffed on designers I would say, not that we don’t love our designers. We want a good balance and, like I said, we love building things from beginning to end. That said, we’re always interested in [01:38:00] getting, touching base with people if they’re interested in us, if they think they might want to come work with us or just want to say, “Hey.” We’d love to hear from people. We like keeping an
eye on the community and saying, “Hey.” Absolutely reach out.

Justin Avery: Good to hear. You can go and live in Salt Lake City.

Adam Luptak: It’s beautiful.Justin Avery: Lots of outdoor sports stuff. Famous for Olympics. It’s a good place. Yeah, thanks everyone for joining in. Thank you again, Adam. We’ll see you guys next week.

RWD Podcast Episode #30 : Ulrik Hogrebe (part 1)
29:48
2017-12-22 20:56:41 UTC 29:48
RWD Podcast Episode #30 : Ulrik Hogrebe (part 1)

Justin Avery: Hi everyone. Just a quick note at the top of the show. This week, I had a few problems with connectivity to the interwebs. As a result, some of the audio is a little bit patchy in places.

This week, we speak with one of the creative directors for the BBC News and the 28 different country sites, so I urge you. Ulrik has a lot of awesome stuff to share. Although the audio does get a little patchy here and there, it does come good. What he has to say is amazing. Please bear with me, and
I’ll make an effort to make sure this doesn’t happen again. Big thanks to Ulrik for putting up with my bad internet. Here it is.

Hey everyone. Welcome to another edition of Responsive Design weekly podcast. This is episode number 30. This week, we have a very special guest from the BBC, but before I get over and talk a little bit about him, I just wanted to say thank you to Media Temple. They are our sponsor for this week.

Media Temple are a web hosting company. I’ve got a couple of my sites hosted on there. I go and use their DV hosting as well, which I think I might change soon because DV hosting requires quite a bit of CIS admin knowledge and I really don’t have much. I tend to break things more often than not, but
they’re actually really cool. If you do break them, they have ways of fixing it.

The other day, I accidentally deleted one of my friends’ website domains and WordPress instance that they had had up and done lots of work for their business. Media Temple restored that for me at a very, very reasonable cost and got everything running again. I didn’t actually have to worry too much
about it. Very reasonably priced. They’ve got a whole bunch of different products. I’d highly recommend. Go check them out, MediaTemple.net [00:02:00]. It’s what I use and will continue to use for a very long time.

Let’s move across, away from our sponsor this week and get onto our guest. Our guest this week is Urlik Hogrebe. He is one of 2 creative directors for BBC.co.uk/news. He’s responsible for the UK site and some 28 language sites as well. Welcome Ulrik.

Ulrik Hogrebe: Thank you. It’s good to be here.

Justin Avery: It’s really good to have you as well. You’re dialing in from London as well?

Ulrik Hogrebe: I’m dialing in from Hackney of all places, so very much London.

Justin Avery: Of all the places. I’m just on the other side of the river over on Waterloo, so I’m just as bitterly cold as you are perhaps. It’s not too bad.

Ulrik Hogrebe: Believe me, our house is leaky at best, so I know what you mean.

Justin Avery: That’s good. Just for the people that haven’t heard of you before and don’t follow you on Twitter or anything like that, can you just give us a bit of background about how you got into your role?

Ulrik Hogrebe: Yeah sure. I’m originally from Copenhagen. I guess I have a checkered past in the sense that I got out of high school and then just goofed around for a while and then got into all sorts of weird universities. I did some business and this, that and the other.

In the meantime, I landed this internship at a Danish strategic design company called e-Types and started working there mainly on the branding side and then slowly got more and more interested in the hands-on doing side of things. Had the opportunity to go to Copenhagen Institute Of Interaction Design.
At that point, I’d been quite into design, but not really a [00:04:00] practitioner. Went to CIID, as it’s called.

Then as I came out of there, I was lucky enough to meet one of the former heads of design for the BBC, a guy called Michael Albers. He asked me to join. Then I was at the BBC as a senior designer for about 3 years or so. Then a little bit shy of a year ago, I started as creative director for what we
call core responsive, which is essentially the responsive site and World Service, which is the 28 aforementioned language sites.

Justin Avery: That’s cool. When you were doing your internship in the branding company and working at the … Is it the Interaction Design? Copenhagen Interaction Design, did you say?

Ulrik Hogrebe: The Copenhagen Institute Of Interaction Design. It’s not the most forthright name.

Justin Avery: CIID or something? Were you working digitally or physical products, print products? What was it like?

Ulrik Hogrebe: e-Types did a lot of brand identity work, so a lot of graphic design. We were doing a lot of letterheads, corporate identities, all that kind of stuff. They had probably what I think are some of the best typographers in the world working with them. We were heavily immersed
in this very print heavy brand identity world, but then, of course, as things were becoming digital, we were starting to do websites.

Then slowly, I helped start up what became e-Types Digital at that point, the digital division, where I was just basically interning and helping out, sorting stuff out. It’s definitely a company [00:06:00] that was very steeped in print [tradition 00:06:02], then quite quickly has become actually astoundingly
good at web as well.

Justin Avery: That’s awesome. When you started [crosstalk 00:06:12]. When you started as senior designer at the BBC, what were the kind of things that you were responsible for?

Ulrik Hogrebe: Basically, we got hired onto this team that was called the service design team, which was a bit of a misnomer really. What we were doing was we were looking a little bit more ahead of the day-to-day at the BBC. The because of various reorganizations that team then got
absorbed back into what we call UXB at the BBC, the bigger UX division.

I started working quite heavily on personalization, looking at personalization patterns not just for one part of the BBC, but essentially for all the different what we call products, sport, news weather, iPlayer, radio, music, kids, etc, trying to figure out how do you develop one pattern that can
sit across all these different products.

We were working to this called GEL. This is the Global Experience Language, which is our visual guidelines, our interaction guidelines. The philosophy is that we try to design things once and then try to make them work for the different products as best we can. Obviously that doesn’t work all the time,
so we have to come up with new stuff. That drives the wheels of innovation around patterns and stuff. It’s quite a good system really.

Justin Avery: Pattern libraries and style guides and stuff are starting to really become something onto their own these days. I’m seeing more and more that Brad Frost and [00:08:00] Anna Debenham are doing a podcast just about style guides now and patterns.

Ulrik Hogrebe: Absolutely. I think how do you do not just style guides, but responsive style guides that work across devices and break points and screen sizes and all that kind of stuff is incredibly interesting. I think the general feeling, at least from my team of designers, is that
we can design as much as we want and illustrate. We have this template system where we say, “Well, we design to 4 different break points.” We open up our art boards and we’ve got 4 different art boards in different sizes. Then we try to make things work within those 4 art boards.

Then, of course, as soon as bring this into a browser, everything breaks because they’re not static as such. My team … The teams across the BBC are trying to do more and more stuff directly in browser. Also we’re trying to get our styles guides and all that kind of stuff and our documentation as
well, trying to figure out how do we put them basically in the browser so you can see them work at different sizes and stuff.

That’s a challenge. Not all of our designers are super fluent in code, so it’s a gradual thing that we’re doing that moves ahead. I work with the developers to do it. We’re just trying to work it out and make everything easier for all of us. The developers don’t have to sit and look at art boards and
flats and go, “Oh, I wonder what that looks like in this and this size. We don’t have to do reams of documentation for every possible permutation.”

That’s how we’re approaching it, but it’s a tricky thing. I don’t think we’ve cracked it quite yet [00:10:00] to get the workflow going. We can do it, but getting the workflow doing, doing it in the day-to-day, slightly more tricky, I think.

Justin Avery: Yeah, sounds like you’re on the right track though with these things. It sounds really cool. I used to have this discussion with a designer at our previous role. I would always try and get him to get into the code more. He was always of the opinion, “The
more in know about the limitations, then the less I’ll push you to [inaudible 00:10:29].”

I thought that was just a cop out that he didn’t want to learn anything anyway, but it seems great that your designers are learning to code. Is that something that you see designers should be looking to do or would you … Have you seen things like [Mccore 00:10:46] and Webflow and [Frunes 00:10:49]
and things like that are more like the Wizzy Wig that designers can explore upon?

Ulrik Hogrebe: Yeah, absolutely. I’ll try to answer. I think every designer that does digital should have a basic understanding of HTML and CSS and JS just from a basic understanding and a communication point of view with the people that will actually be doing the work in browser. I
think that always helps. I don’t think understanding what the CSS can do, especially when you’re moving toward a world of transitions and motions and that kind of thing.

I think that is by no way, no means, a limitation. On the contrary, I think, for most of us, as we find out what CSS can actually do, it becomes a source of inspiration. I urge every designer to at least get into the code and just understand what it is, even if it’s just opening up your inspector and
fiddling with a couple of values and it will preview in your browser.

I think even that base level [00:12:00] understanding of how it works is enormously valuable. Then, for my team, I encouraged them to play around with the different tools. One of my guys, he loves working in this thing called Hype, which is this half illustrator/ half coding hybrid thing. He does amazing
work in it. He does amazing work in it. It really works. I think he’s become quite specialized in it, but whatever rocks your boat. I have got another designer who has a software development background, so he just does everything in code. Amazing.

I’m learning code slowly, so I don’t do everything in code, but it’s that kind of dynamic. Then we try to get together and learn from each other and look at how these things, they work and try to figure out what is the best tool for what time. We do prototypes as well, which don’t have to be pixel
perfect, so what’s the best tool for that? Can we do that quickly, etc, etc? Really it’s the right tool at the right time, I think.

Justin Avery: That’s really refreshing to hear that. I’d say a lot of people sometimes they decide that, “We are using Photoshop and we are using WebStorm,” and you just learn it. It might not actually be applicable to the particular project that you’re working on, so
it’s good to hear that someone the size of the BBC enterprise level isn’t being that prescriptive, that you are following that process.

With the process as well, you touched briefly on the workflow. You were saying that different people within your team have different sets of skills. How does the creative process go in any particular project within your team?

Ulrik Hogrebe: Again, it’s the right tool for the right thing. [00:14:00] Ideally, in a perfect world, we were in a relatively agile fashion. When we’re working with so many designers … We have so many workstreams going on. The developers as well, they’ve got tons of workstream. They’re
not just working on front end stuff. They’re working on backend stuff. That really tight integration between developers and designer sometimes just for logistical reasons just doesn’t quite work as much as we’d like it to do.

We generally try to be relatively agile. Let’s call it that. Agile brings up a number of other challenges around when you’re doing it at scale, like we are. We have these 28 language sites, and we have the UK site. Then we’re doing elections. Then we have an app. Then we have this, we have that. From
a design point of view, of course, what you want to be doing is trying to get some sort of consolidation and strategic direction about what all of these different products and platforms are doing.

On the one hand, Agile is an enormously powerful software delivery tool, and it’s great for that. You know where you’re going. You just bang out and you iterate and you test and you try and that kind of thing. Defining, A, where you’re going can sometimes … Having that rough idea, “In the future,
this is where we want to go,” where you need sometimes to step out of that Agile process and have a little bit of time to think sometimes, especially when you’ve got, like I said, multiple platforms, multiple things that need to work together.

“Is the app really doing the thing that it’s good at for our audiences?” “Is the responsive website doing that good thing?” Then down to the micro level, which is just about, “Have we got a [00:16:00] consolidation of patterns?” “Are patterns consistent across everything?” Sometimes you just have to
step out a little bit and have a good look at that and say, “We need to fix these things.” We jump in and out of an agile process, a little bit depending on what we’re doing and what kind of project we’re working on, but once it comes down to delivery, we try to be as agile as possible.

Justin Avery: Nice. You’ve just delivered a couple of projects recently. There’s a launch I think of the tablet and maybe the full responsive design site.

Ulrik Hogrebe: Yeah. Just before Christmas, we relaunched all of the 28 language sites to responsive. That is everything from Russian to Sinhala to Persian. Basically, we launched them all the way up to desktop, so they are the default sites that you go to if you punch in BBC.co.uk/Persian,
for example. Of course, we’re looking to do the same thing with the UK site. Was it last week? I think we put the desktop opt-in out. .

If you go to the static site, in the indexes, you should be seeing a banner that will redirect you to the responsive site. Obviously, once we’re offering you to opt into the desktop experience, then we are not far away from actually having released to the responsive site. We’re almost there. Pretty
exciting.

Justin Avery: That’s really cool. How did you approach the language sites? What were the differences around the language? Did you have to use different fonts? You had different languages, different encoding, right to left [00:18:00] stuff. That must have been a nightmare.

Ulrik Hogrebe: I have to say that I came into the project relatively late where a lot of this heavy lifting around typing scripts and that kind of stuff was already done by one of the former creative directors called Kutlu Canlioglu. He’ll hate me for mangling his last name there.

Justin Avery: A bit like I did yours at the beginning.

Ulrik Hogrebe: Actually, if you’re interested in that kind of stuff, there’s a nice little talk that he did for Ampersand in Brighton in 2013, where he talks about some of the difficulties of designing for things like Arabic scripts. Arabic, obviously, it’s right to left, but not only
is it right to left, it’s also got several different variants based off the same alphabet [reading 00:18:57]. They change a little bit depending on which region you are globally.

If you look at the standard system fonts that were available at the time when they embarked on all this stuff, essentially there was 4 standard system fonts that would do Arabic and they would do a simplified version of Arabic. All the glyphs would be the same, so it would essentially be 4 different
type faces with one Arabic glyph set in something called simplified Arabic.

They were just not really cutting it. They had no cultural differences. It completely undervalues the calligraphy tradition in each region and all that stuff. Kutlu actually worked extensively to work on a font that was already created called [Masin 00:19:50] by a typographer, whose name escapes me
right now.

To actually create [00:20:00] localized versions and actually really beautiful scripts that would work in web browsers across all these different nations. We’re doing quite a lot of that. From the design side of course, for each script that you’re using, they’re slightly different line heights because
of the ascenders and descenders and all that stuff, but luckily, bless his heart, Kutlu worked out all that detail before I joined. They are now embedded in code, so we have those different line heights.

Justin Avery: I’m thinking this is not front end of your strategy. I come from more of a CMS background. I’m just thinking that when people are writing copy, you usually … They go, “This is a headline. It has this many characters,” or “This many words are allowed to
be within that headline.” Does everyone work off the same restrictions for languages because I’m thinking that a headline in Arabic could be a hell of a lot longer or in Russian it could be crazy long, right?

Ulrik Hogrebe: Yeah, the Russians have extremely long words. That’s definitely one of our main challenges around the way that we’re … It will pay off if I talk a little bit about how the design of the website or how we’re building the websites at the moment. Essentially, what we’re
doing is that instead of looking at pages, we’re looking very much at components and modules.

For us, a page is essentially just a stack of modules that we put together in different ways. What that allows us to do is we can then design a module and then we can draw up that module different places in different pages. The way that we design those modules is that we then design them from the start
so that they work not only with Latin scripts, but also with left to right [00:22:00] and with all the other different scripts that we’ve got.

We take a very language agnostic approach to how we design the sites and such. Every module, regardless of whether they’re using it on a Latin script site or an Arabic site will work. At this point everybody in the team has quite a bit of experience in this so we per gut feeling, we can see, “Ah, this
is not going to work for Russian.” It’s too tight. It’s never going to fit. Words without brakes and orphans and all that kind of other stuff. Essentially we will do some language testing. Typically we’ll choose 2 or 3 of the most difficult scripts, then we’ll run the modules through them so we’re sure
that they’ll work.

Justin Avery: Do those modules go back into the global experience language or is it something separate?

Ulrik Hogrebe: They’re slightly separate. They’re built on the global experience language, the foundations of that. We work to a set grid that is more or less consistent across BBC. The patterns that we are creating for news obviously are pretty specific for news, a lot of them. We
have a separate pattern library for that, this responsive pattern library, which essentially shows every single module in a different permutation at different break points.

In that way, we are building up this pattern library, a module library. Really also just let’s us drop things onto pages. If some of our indexes for some of our pages at this point, we almost don’t have to do any designs for them. We can more or less just do [00:24:00] wire frames and say, “This is
a 3 module. This is a 2 module, and that gets followed by a 5 module,” and they all react responsively and they just work.

Because we’re doing it that way, that also means our designers don’t have to do everything from scratch. We tend to do mock up sometimes to show stakeholders, “This is the final thing that you’re getting.” A lot of it, in theory, we could basically take requirements and plop them down on page and they’d
kind of work. Of course there’s finessing in there as well.

Justin Avery: I can imagine there’s a lot of finessing to get these things to fit together, especially across, as you said, 28 different languages. [crosstalk 00:24:39]

Ulrik Hogrebe: Oh yeah, absolutely.

Justin Avery: With all those different languages and stuff, the BBC, and not just the new site as well, even at a greater level after anything BBC.co.uk/whatever. There’s so much content. It has to be one of the largest, if not the largest, news or content creation area
outside of things like Twitter and YouTube and Facebook, but that’s people creating, that’s us, me and you creating that content. What are some of the challenges around all of that different … What is the biggest challenge for the BBC and for you around all that different content?

Ulrik Hogrebe: There’s a lot of challenges around that. First of all I have to say, that is a luxury problem for any organizations that have too much content. It’s almost unheard of, and that’s such a privilege to be in that position.

When that’s said, then one of the trick thing for us is how do we then surface all this content to the user and make sure that it’s interesting [00:26:00] and appropriate depending on devices and all that kind of stuff.

That also comes down to, especially with a news site, which is very … News is traditionally a print led. Then it became a desktop led. We talked very much about things that are above the fold. That’s your premium content. As soon as you go responsive, then that fold becomes slightly meaningless.

One of the things we do around content is trying to figure out what is the relative hierarchy of this content? What do people want and is there a system where we can start putting content into the right brackets at the right time with the right device. That can definitely be challenging because there
is a lot of good content. Choosing which ones, what is the most important one, is a really difficult … It goes back to print times. What goes on the front page, essentially.

Justin Avery: When there actually was a fold.

Ulrik Hogrebe: When there actually was a fold, yes, exactly. That can be enormously tricky. We do different things. The way that we think about responsive let’s us do things, for example, we can position things relatively high up in desktop, but then instead of doing the simple reflow
where everything …

Ours is a 2 column system. We’ve got a primary column and we’ve got a secondary column, a left hand and a right hand for [inaudible 00:27:39] and scripts anyway. Normally what you do is you take that right hand column and you shunt it below so that everything is linear on a mobile device, for example,
but that doesn’t work really well for our content because some of it …

We want to take advantage of the 2 column system and say, “Well actually that means that we can have 2 pieces of content [00:28:00] of equal importance on a desktop next to each other, but if we then do a simple reflow, then that 1 important piece of content then falls below.

WE’re doing these things where we’re saying, actually we’re going to have 1 thing reflow under the other top most important thing and then all the other stuff in the right hand column reflows right at the bottom. We’re trying to do all this kind of stuff that let’s us think a little bit harder about
where we place our content and how we make sure that things reflow so that the importance of the content doesn’t just disappear just because technically it’s the easiest thing to do. Does that make sense? I feel like I just ramble the way.

Justin Avery: No, no, it’s good. The more you run away with these things, the better these tings go. That’s really cool.

Ulrik Hogrebe: I have Post-its and markers, and then I sketch things.

Justin Avery: It’s always easier to explain things when you have a white board or something to draw. That is actually really good.

RWD Podcast Episode #29 : Jason Beaird
60:00
2017-12-22 20:56:41 UTC 60:00
RWD Podcast Episode #29 : Jason Beaird

Transcript

Justin Avery: Hi everyone and welcome to another edition of Responsive Design podcast. This week is episode 29. My name is Justin Avery. I’m your host and the curator of Responsive Design weekly newsletter, a newsletter all about responsive design, funnily enough.

&nbsp; This week our special unofficial sponsor is MailChimp. If you are on the newsletter list you experience MailChimp at least once a week because that’s what I use to send my emails. It’s a very simple to use tool, very responsive. I’ve enjoyed using it over the past 146 weeks now. If you’re looking to send newsletters, I highly recommend going and checking out MailChimp. Speaking of MailChimp, this week’s guest is a very special guest from MailChimp itself, Jason Beaird. Welcome Jason.

Jason Beaird: Hi Justin. It’s good to be here.

Justin Avery: Whereabouts are you dialing in from, Jason?

Jason Beaird: I’m coming from our headquarters in Atlanta, Georgia.

Justin Avery: Oh, nice. Nice weather there today?

Jason Beaird: It’s chilly. The weekend was great, though. Now that it’s the week day and we’re all working it’s cold and wet.

Justin Avery: Doesn’t matter how it is outside when it’s when it’s [crosstalk 00:01:15].

Jason Beaird: Exactly.

Justin Avery: I have the [crosstalk 00:01:17].

Jason Beaird: We’re all setting in front of our computers.

Justin Avery: I have the exact opposite experience in the UK where all week it’s sunny, and my wife goes out with our little boy and enjoys the sunshine, and on the weekend it rains. It’s not all-

Jason Beaird: That’s usually the case here in Atlanta, but last weekend was glorious.

Justin Avery: Good to hear. Now, can you tell us a little bit about what you’re doing at MailChimp, maybe a bit of history of how you got into the web and your role currently?

Jason Beaird: You just cut out for a minute there, Justin.

Justin Avery: Oh, sorry. Skype. No, we were just talking before about Skype how their start of the call quality’s very good, and they might taper off. This might be one of those occasions. [00:02:00] Keen to know a little bit about your role at MailChimp, what you do there and how you got into the web.

Jason Beaird: Sure. My current role is the lead UX developer. I manage 3 other awesome front end developers that work on the MailChimp application. I’ve been there since March of 2010, so it’s hard to believe, but I’m coming up on 5 years now with MailChimp.

&nbsp; How I got into that and my background, I went to school for graphic design, but I’d been writing HTML and was making hideous websites long before I started learning how to design. I started doing webdesign professionally in 2003 during the heyday of all the CSS gallery sites, where I managed to get featured a few times. As a result of some of that in 2007, I had the opportunity to write a book for Site Point called the ‘The Principles of Beautiful Web Design’ and just worked in web design for a very long time doing client-based web design development work. Then, started with MailChimp, like I said, in March of 2010 and been having fun since.

Justin Avery: That’s really cool. I bought that book.

Jason Beaird: Oh, really?

Justin Avery: Yeah.

Jason Beaird: That’s always weird to hear when somebody says, “Oh, I have your book.” It’s like, “You know something about me already and I don’t know who you are.”

Justin Avery: It’s weird to invite someone on to a podcast and start talking to them without knowing that they’d written a book that you’d read. You mentioned that you got featured a couple of times with the sites that you were creating. Are there any of them still up and around?

Jason Beaird: Not in the same form. It was mostly my personal site that I was working on. A few client sites. None of them are. This was, like I said, 2003, 4, 5. At that point I didn’t have kids yet, so I was re-designing my site every 6 months to a year. A lot’s changed since then. My site pretty much remains the same for [00:04:00] periods of years now. I try to write a blog post every few months.

Justin Avery: I was talking to someone the other day. There’s a new year’s resolution where you look at everyone’s blog, and there’s a post every couple of days for January and then one in December talking about how they’re going to do posts once a week for the rest of the year, the following year.

Jason Beaird: I’ve stopped doing that now. It’s been so many years of telling myself, “I’m going to write more posts,” and then it not happening.

Justin Avery: It’s terrible. With MailChimp, so you look after the front end crew. Now, there’s lots of front ends to MailChimp, right?

Jason Beaird: Yes. There is different aspects of the front end in MailChimp.

Justin Avery: I use MailChimp, the application itself, so I login and I go through. Many years ago when I was signing up I had a marketing site to it. Then there’s also the email templating side of it as well, I suppose, with design. What are the different areas of design that you look after?

Jason Beaird: The team that I work with is part of the greater product team at MailChimp. We look after everything that you see when you log into MailChimp. All the email templating stuff, that’s mostly Fabio. He’s our email template designer. He’s got another person that’s working with him on that. Then the front end dev team we manage all of the front end assets and aspects of the interface. We have 2 really talented UI designers that also create comps for us to pull from. Like I said, we manage everything you see at the login screen and beyond. Everything you see at MailChimp.com is part of the marketing sites, the marketing team handles all that.

&nbsp; Then, we have various other products, even. We have TinyLetter and Mandrill. TinyLetter is managed by us. We kind of take turns working on bits and pieces of it, but Mandrill operates as it’s own separate company. Their marketing site [00:06:00] and their application are a completely different team that works on that.

Justin Avery: Oh, wow. I haven’t checked out TinyLetter. I need to go and have a look at that.

Jason Beaird: We basically call it MailChimp lite because it’s a very simple interface for creating and sending an email, usually for individual authors, to be able to send out a news letter, and it’s totally free.

Justin Avery: Oh, wow. That’s good. Everyone should go and check out MailChimp lite, and or TinyLetter. We’ll put a link in the show notes as well. I suppose, with all the different interfaces, everything still looks very similar across. It’s a good brand experience. Do you have someone who looks after the branding side of things, or do you guys work together when you’re working on the different sites?

Jason Beaird: We tend to work together a lot. MailChimp started in 2001, so there’s a long history of front end elements that that have come and gone since then. When I first started in 2010, we started on the first redesign of the MailChimp application that I was apart of. That was, actually, a part of the marketing team’s redesign of the site. We weren’t using the same front end crew at the time, but we were looking at what the marketing team was doing and adjusting what we were doing. They were doing the same, looking at how we were reshaping the interface of the app and adjusting what they were doing for the marketing site. That was back in 2010.

&nbsp; We just redesigned again in 2013, again, based on some changes the marketing team were making to MailChimp.com to kind of freshen things up. As part of those last 2 redesigns, we ended up creating a pattern library that has come along and evolved. We’ve released it publicly at ux.mailchimp.com that shows the front end elements that are re-usable in the app. [00:08:00] The other products I mentioned, TinyLetter and Mandrill, both borrow from that pattern library. The marketing team, although they don’t use the pattern library wholesale, they have their own pattern library based on our patterns. That’s one way that we help keep that consistent look and feel.

Justin Avery: Oh, nice. With the patterns that you have, is that where you do a lot of your testing? Do you have another internal site? Do you test things out in the pattern library to make sure they work across all the different iterations and then push that up? How does the work flow work?

Jason Beaird: We have a dev environment that we create new interfaces in. The pattern library, it’s more a collection of common elements than it is a testing grounds for new elements. I like to say that the pattern library is for anything that’s used 2 or 3 times in the application. A lot of times we have a new comp for some new process or new campaign creation flow. We just build that up as if it’s a one-off, using as many of our existing patterns as possible usually. Then if we end up, say, extending from that for another component of the app we might … We don’t know if something will become part of another area. We don’t know how to generically write it and class it, because we don’t know how it’s going to be used. When we do find out that, we can take something that already exists and use it in another place, that’s usually the point at which we make it a pattern, and or pull parts of it out and put in the pattern library.

Justin Avery: Cool. Is there anything that you use to maintain the pattern libraries? There’s things out there like Atomic Design. There’s a couple of other, I think, roll-your-own pattern library stuff. Is it something you do just in-house, on the fly, or is that a system which you use? [00:10:00]

Jason Beaird: We’ve kind of built our own pattern library. When I started the original pattern library with the 2010 redesign, that was actually before Bootstrap even. When Bootstrap came out, we saw what Bootstrap was doing and we’re like, “Wow, this is kind of what we’ve been doing with MailChimp,” creating an archive of re-usable parts that we can assembly-line [features 00:10:22] off of. We looked at what Bootstrap was doing.

&nbsp; Everybody has come up with their own solutions and roll-your-own systems for pattern libraries. It’s really been inspirational. It’s shaped ours, but ours is still very much our own. Like I said, it’s released publicly, but we don’t provide any way to download the code or fork it on github. It’s really built specifically for the challenges that we have at MailChimp and the interface that we’re working around. We don’t really feel like it’s something that somebody can take and use, as much as it’s something that might inspire people to create their own.

Justin Avery: It’s great that you’re publishing it live. I had an example yesterday where I needed something to work in a particular way and just ended up going to Foundation’s layout grids to workout how they achieved a particular interaction or a particular way of laying something out on a screen, found out the CSS, stole it, and applied it for my own stuff.

Jason Beaird: Exactly. Zurb’s another good system. Really, it’s part of my belief that that’s the way the web operates. As someone who learned everything that I know from looking at other people’s source codes, I wish everybody would do the same thing and release how they’re doing things to publicly show it. Anybody can look at the source and view it, so why not just show how you’re doing things? It doesn’t mean, necessarily, it has to be released as an opensource project, but at least that way other people can see what you’re doing and point out your mistakes and show you how you can [00:12:00] do better, or extend off it, take the good parts and do something amazing with it.

Justin Avery: That’s such good advice. People should write about it, too. I know that we both don’t do any blog posts anymore, but people should if they have time and don’t have kids running around, definitely blog about it.

Jason Beaird: We try to do that as often as possible on the UX team at MailChimp. We have a newsletter that we write. It started off bi-weekly, but that got to be too much work to try to produce a bi-weekly newsletter. We do once a month. It’s the uxnewsletter.com. We’re trying to have one guest author, so maybe we’ll have you, or somebody else awesome in your listening audience write an article for our newsletter. We try to have going forward one awesome guest author, and then have something within MailChimp about challenges that we’re facing. We’ve got an article coming up internally about IOS 8 extensions. We’re going to have a guest author from Center Centre, the new UX school from Chattanooga, is going to be writing a piece for us for the next issue.

Justin Avery: That’s really cool. If you do find you’re running short, I’d be honored to be able to write something for a MailChimp news letter. It’d be very [meta 00:13:14] right? Writing a newsletter for MailChimp?

Jason Beaird: While talking about it on a podcast.

Justin Avery: Exactly. You said you had a couple of awesome UI designers. The process of building something for a requirement, and then if that requirement occurs a few times, you put it into the pattern library. How does it look from a internal process point of view, from “We have a problem,” or, “Someone’s reported a problem,” or, “We’ve seen something that we want to be able to do,” to, “Let’s push it”?

Jason Beaird: The process varies quite a bit depending on the situation. We have a lot of those, “We have a problem.” People are complaining that this [00:14:00] process is confusing, or the onboarding, people are getting lost, or there’s some back end thing that needs to change in order to allow people to use MailChimp the way that they’re trying to use it. Those are bugs or support issues. Then we have feature requests, people want to be able to do something new. Then we have features that we have cooked up that haven’t been requested, but things that we’ve come up on our own. Depending on the situation, the process looks a little different, but, really, it ends going down the same pipe. We talk about it as a team, the whole product team we end up talking about a lot of the ideas.

&nbsp; Our UI designers usually flush things out, several different options for ways that we can build it. It’s interesting because we have UI designers and they’re working in Photoshop and Sketch, but they’re not necessarily just creating things off the fly. They actually have their versions of our pattern library as reusable patterns that they’re drawing from most of the time. They try to avoid creating new patterns as much as possible. A lot of new features require new interfaces. It’ll go through them.

&nbsp; Then, once we all agree that a comp feels right as far as thinking through the process, then we start prototyping, maybe building-out individual pieces that are new, and then start building out the entire feature. We’ll work with the engineering team to add the database tables we need to store the information that we’re trying to show, and just start building.

Justin Avery: Cool. I’m fortunate, I use it quite often, once a week. The admin interface is responsive, right? It doesn’t matter which size screen. [00:16:00] It’s not a fixed, rigid one, which I find a lot of administrative interfaces tend to be.

Jason Beaird: Right.

Justin Avery: When you’re coming up with the UI designs and stuff, do you have a strict mobile-first policy? Do you have an approach in that particular?

Jason Beaird: Our mobile policy and our responsive policy is pretty interesting. When we redesigned in 2013, the last redesign I was talking about, that was one of our goals, was to make the app responsive. The app was already fluid. It had been since the beginning. Since the beginning it was a fluid application, and we used a fluid grid. When we redesigned it in 2013 our goal was to make it fluid-responsive. We didn’t necessarily take a mobile-first approach, but we wanted to make sure that everything was accessible, down to phone size. That has been a little difficult because a lot of times you’re developing and working on new features thinking about it from a desktop perspective. Sometimes you’re checking on a table, but the phone size screen becomes an afterthought and it ends up becoming a QA support issue before it gets launched. It’s like, “Oh, it’s broken on this size.”

&nbsp; The one thing that’s helped us a lot with that is actually the pattern library itself. When we started the redesign, in stead of starting with comps for the redesign, we started with the existing patterns we had and how we make those responsive. If we’re using one of our existing patterns, most of the time those will work fine down to mobile because we’ve planned the pattern to be responsive. We don’t have to worry so much about how it will look on mobile because it’s already coded to work that way. A lot of times when we’re adding new features and building new interfaces it becomes a bit of a maintenance issue.

&nbsp; Then there’s some [00:18:00] things in the app that we actually have a separate view for phone size, for instance, creating a campaign, because CK Editor which is our WYSIWYG, HTML editor for building campaigns doesn’t work that well on a phone, at least the version of it that we’re using. To show a 600 pixel email campaign that you’re actually working on to edit in a responsive really much smaller interface, it becomes difficult. I would say we’re not mobile-first, but we’re very mobile-aware and trying to find solutions for those things that are still not quite there yet.

Justin Avery: There’s a MailChimp app that you can download from the IOS, from the store.

Jason Beaird: Right.

Justin Avery: Is that a separate, specific app? It feels as if it’s a wrapper to the web interface.

Jason Beaird: The actual MailChimp app is it’s own app. The IOS and Android version are both native apps that are not based on the MailChimp interface. They use the MailChimp API. We are working on an experiment API that’ll allow you to do more of the things that you do in an application, but it is a completely separate system. The mobile team is actually part of the product team that I’m on. We end up doing together quite a bit with them, so we try to keep things consistent across. We want it to feel like a wrapper. Both the IOS and Android versions are completely custom, native apps that are designed for that operating system.

Justin Avery: Cool. I was wondering, because, like I said, you’ve done well in terms of carrying the experience from one to the other.

Jason Beaird: Yeah. [00:20:00] The head of design for the product is actually over my team, and he was the head of design for mobile team before. Now he is managing design for the web apps and mobile apps as well, so we do have a consistent voice for all of those products.

Justin Avery: Cool. You were talking about going to engineering and creating database tables and stuff to be able to display certain information. A lot of the information in the admin stuff that is very tabular and is long lists and stuff, are there any challenges that you’ve been able to overcome and still being able to see or access all of that data on those smaller screens?

Jason Beaird: Yeah. We have worked a lot in trying to make, everybody’s been working on, making better, responsive tables, right? There’ve been lots of good posts about it. We’ve used a lot of the recent things that have come out to create our subscriber [table 00:21:03]. The subscriber table’s typically the biggest example of a table that you need to be able to see all the way across. In the mobile view you get a scroll box. If you’re looking at, for instance, a subscriber, you might just have first name, last name, email. That’s the typical lists of merge fields for a individual subscriber, but you can add as many merge fields as you want. You might have first name, last name, postal address, phone number, how you got into the web industry, check lists and check boxes, whether you’re a a designer and developer, UI person. The list goes on depending what merge tags you have.

We had to be able to make a table that can scroll to fit all those things down to mobile sizes. We have our own custom responsive table system that a couple of our guys, Alvaro [00:22:00] and [Marta 00:22:00] on my team, have worked on that quite a bit. I haven’t worked on that as much as they have. Yeah, that’s definitely a concern, is making things like tables and things that are normally extending way off the desktop screen work well down in small sizes.

Justin Avery: Part of the pattern library has the table stuff in there already. Is it something that someone can go and steal, borrow, see how well you’ve done?

Jason Beaird: I would say borrow away, at your own risk. Things change so fast in this industry. Best practices for things, specifically like responsive tables, change often. We try to apply things as fast as we can, but we aren’t as fast as some of the new front end techniques that are coming out. I would stay, steal liberally, but know that-

Justin Avery: [inaudible 00:22:58]

Jason Beaird: … we’re constantly changing as well looking for ways to do it better. We may not have the best solution, but right now it’s working for us and we’ll be updating it as we go along.

Justin Avery: Speaking of changing fast and iterating and the industry moving quickly, is there anything that you’ve seen recently that you’ve been like, “Yeah, that needs to be the next thing that we’re going to tackle.” Not even recently, but the next thing that you’re like, “Let’s put this into the app and the interface. Let’s solve this problem.”

Jason Beaird: A lot of the mobile patterns that have been coming up, or have become standardized for display of menus, we’re doing some things in the app, slide out a panel, designing on the Z index, having multiple elements that come in and out of the view depending on which mode you’re in. I feel like we’re not doing as good of a job as we can with that. At the same time, I kind of wonder how much we need the web app to handle that [00:24:00] mobile aspect, and how much needs to be put off onto existing apps.

&nbsp; I was just having this discussion with Stephen Martin, the head of design at MailChimp. What is our goal for mobile support of the web app, and how much of it should be part of the native apps? Our original view was that you should be able to do everything in the web app, right? We’re the people that create the web app, so we want to make it as useful as possible. Even if you haven’t downloaded the app, but you happen to open a browser and login you should be able to do everything, right? Sometimes that’s not the case. Sometimes you’ll get a much better experience if it’s done in the native app.

Justin Avery: Yeah. In terms of just the usage of it, performance wise?

Jason Beaird: Right.

Justin Avery: That’ll be interesting to see which way you go with it. With regards to performance, that seems to be something which is the current in-thing, and it should have been for ages with websites in general, with the arrival of responsive design. It’s weird to say arrival. It’s been here for ages because we’ve built websites that can now work across all of the different devices and browsers and view ports, that we just, not we, a lot of people, just shoved lots of stuff in there. Of course, performance was one of the things which were then an issue with responsive sites. Not a responsive design problem, it’s a general web problem, and it’s the implementation of it. Are you guys focusing tons on performance? Have you got a performance team, or any bench marks that you need to follow?

Jason Beaird: We don’t have a performance team. I would say we’re always thinking about it, and we should be thinking about it more. [00:26:00] For a big, well-know location it’s really easy to sit on your heels and say, “Okay, everybody’s going to be on a desktop and have a decent internet connection, and all of those CSSs are going to get cached, anyway, right? We can make it as big as possible.” We’re trying as much as possible to cut as much of the CSS as we can, compress things. We use LESS and then compress our output as much as possible. We look for ways to reduce the number of requests on a page. Still, there’s a lot more that we could be doing for performance. Honestly, we probably should have somebody that’s focused specifically on performance because as a web app that is used outside of the desktop and outside of fast internet connections, it should be as snappy as possible.

&nbsp; I feel like there’s a lot of things you can do to enhance the appearance of performance. It was really interesting, we just went through a redesign of the navigation of the app, moving the branding and the main navigation up to the top as a horizontal navigation and getting rid of the vertical navigation we had on the side of the app. We did quite a bit of clean up of our CSS. We looked at the load of a page before and after, and it wasn’t a significant reduction of kilobytes.

&nbsp; We got tons of people telling us how much snappier it felt and how much and how much faster MailChimp was after this redesign. We just had to laugh because we felt like we were forgoing the performance and focusing on enhancing the UI. The changes to the UI actually had the effect of making it feel snappier and faster. It was interesting, but with that said, we do need to focus more on performance and, like I said, reducing more of our page load size and requests. We try to keep that as much as possible [00:28:00] to minimum.

Justin Avery: Yeah. I imagine it’s quite hard to monitor a web app for a front end performance, because it’s not really like a public URL that you can point something at and follow. Everyone has a different access kind of thing, almost. Somehow it seems different than just looking at a public website.

Jason Beaird: One easy thing to watch, especially if your version for each release is the output size of the compiled CSS, you can cut down the HTML size as well. It’s really easy to see that, “Oh, we cut 40k from the main style sheet with the changes and the cleanup we did on this last release.” Anytime that you can compile elements of the app that are used in a couple of places into a pattern, usually we get a little bit of savings here and a little bit of savings there in terms of file size as well since that’s one easy metric to watch, is the size of your CSS. Always reducing images helps a lot.

Justin Avery: Yeah. I think you guys are quite fortunate in terms of it’s a very visually stimulating site, but it’s not a huge use of images it never seems.

Jason Beaird: Right. Unless you’re looking at an email campaign that we’re working on that has a ton of images in it. Usually we don’t [inaudible 00:29:30] images in our interface that we’re loading. Even when you do have a campaign, we are serving all those images from S3 through, I can’t remember the service, it’s to make it as fast as possible as well.

Justin Avery: The CloudFront?

Jason Beaird: Yes.

Justin Avery: Yeah, that’s really good. The other thing I quite enjoy if I do a feature site of the week, [00:30:00] right, so that goes in the top, and I usually optimize that before I upload it into the campaign. Sometimes I forget, I just do a screen shot, and it’s like 1200 pixels wide, which is crazy. There’s a warning in the app, it just says, “This is 1200 pixels wide. You only need it to be 600. Maybe you should make it smaller.”

Jason Beaird: I believe the [inaudible 00:30:24] has a little [blurry 00:30:26] in boxes, you should re-size your images.

Justin Avery: That’s the other good thing. I do like the marker copy with MailChimp. You’ve got it nailed. Although, there used to be a page where you could stretch your campaign to see how wide it was, and you end up-

Jason Beaird: Freddie’s arm pops off.

Justin Avery: [Who 00:30:49]?

Jason Beaird: I said, and Freddie’s arm popped off.

Justin Avery: Yeah.

Jason Beaird: It’s too wide.

Justin Avery: You [tear 00:30:52] Freddie’s arm off. This is one of the reasons I loved using MailChimp.

Jason Beaird: [inaudible 00:31:00] I miss that feature a lot.

Justin Avery: Bring [crosstalk 00:31:02] back. Can I put in a feature request?

Jason Beaird: I wish we could. That joke just got old over time.

Justin Avery: Yeah.

Jason Beaird: It’s hard when a joke gets stale, you want to keep the fun and the attitude and the culture in the app. As things get old you have to pull them, and then you’ve got to find new ways to introduce fun things. We’re constantly looking for ways to introduce surprise and delight into the app. Sometimes it’s hard because you’re so focused on adding your very important feature that you forget to add some humor. We try to keep introducing things like that as well.

Justin Avery: Yeah, I think you do very well with those sort of things, so kudos to you guys. You mentioned using LESS. That’s for those that aren’t up to speed with-

Jason Beaird: You just dropped out.

Justin Avery: Oh, sorry. [00:32:00] I was talking about using LESS. For those who aren’t up to speed with LESS, or SAS, is a pre-processor for CSS, allows you to write CSS a little bit quicker and use things like variables and compress them. Do you use a tool for that like Grunt or [Golf 00:32:21], are there any other workflow tools that you use internally?

Jason Beaird: There reason why we decided to use LESS, one of our goals with the redesign of 2013 was to switch to a CSS pre-processor. For those of you that aren’t using SAS or LESS, the CSS pre-processor, it makes things a lot easier, especially if you have a large application with a lot of common pieces. You have things like variables and mix-ins that make it much easier to manager.

&nbsp; We ended up choosing LESS over SAS mainly because the JavaScript library that we use, it’s called Dojo, they use LESS as the source theming creating method. Since we had our own custom Dojo theme for the library, it made since for us to use LESS instead of SAS. I’m kind of CSS pre-processor agnostic, I would say. It’s awesome as long as you can use one of them. We don’t use any kind of specific tools. We compile on our dev environments just like we compile on the production environment, our LESS down to one file so we can see it as it will be on production. Yeah.

Justin Avery: Cool. Are there any other JavaScript tools or plugins to aid your front end responsiveness?

Jason Beaird: No. The JavaScript library, I mentioned Dojo. It isn’t as intuitive as JQuery to pick up and use for a designer or front end person, [00:34:00] but it’s a very powerful interface. The widgets that they have, while somewhat bloated at times, are usually built responsive to begin with, so that does help us quite a bit. We don’t have any other JavaScript-specific solutions for making the site responsive. We do have a separate view handler that allows us to do things like I mentioned before about providing a view that says that if you’re trying to go into the editor on a phone-sized device, that it’s handled on the back end, just sort of a separate view for phone-sized interfaces. Really that’s about it. There’s nothing really specific on the front end or the back end that we’re doing differently. We try to make it as universal as possible.

Justin Avery: Cool. In terms of making things as universally accessible as possible and stuff, one of the most popular pages on the site and questions that I get asked for price-specific break points, or actually the most popular page on the site is Common Device Breakpoints, where I have a list of the different iPhones, the different iPads, the different Galaxies, the different Samsungs. I have a caveat at the top, it’s like, “Don’t use these please, but …”

Jason Beaird: “It will change next week”?

Justin Avery: Yeah. “These aren’t staying the same. Get away.” At the same time people-

Jason Beaird: We size to several different sizes and see how it will look. If it looks broken when you hit a certain size, don’t focus on break points. Focus on whatever size they happen to have the screen set to. That’s the best advice I can offer. If you get too focused on breakpoints and specific devices, then you’re going to be playing Whack-a-mole with your support.

Justin Avery: Yeah. That’s good advice. There’s a new site that came out a couple of days ago. I think it was [00:36:00] iamthefolds.com. Have you come across that at all?

Jason Beaird: I have not seen that. I’ll check it out.

Justin Avery: Yeah. It’s really cool. I won’t feel bad if you check it out now. You’ve got to be quiet. It was created by a guy, I think, Ian, I’m going to totally get it wrong. He’s @_iest on Twitter. It came from an article and a Tweet from Jordan Moore who we’ve had on this show before. It’s really cool. Basically, you visit the site and he writes to the database how tall your screen is, so where the fold line would be. When you visit the site it has a line drawn through the page for every single different height in pixels someone’s fold was. It’s crazy. He’s got-

Jason Beaird: Somebody’s fold is 234 pixels.

Justin Avery: Yeah, 234 pixels. The largest one I’ve seen is 2,732 pixels tall. That is a tall, tall phone.

Jason Beaird: There’s one there that is 3,112. Someone has a very tall vertical monitor.

Justin Avery: Yeah. I’m waiting for those 5k monitors to come out that someone puts on portrait.

Jason Beaird: That’s fascinating. I have not seen this before, but it’s very interesting. Yeah, the fold it’s very synonymous, right? For years and years now we’ve been thinking about the fold and telling people not to think about the fold. It kind of goes the same horizontally with break points. Thinking about the terms of device width, you’d have a very similar list of lines for the horizontal display of the devices that people are on. You probably get some groupings around desktop ideal widths and some around template ideal widths and some around phone ideal widths, but when you looked them all on parallel, you’d probably just see a bunch of lines horizontally. [00:38:00] It kind of goes the same with this. This ‘I am the fold’ site is fascinating. It does seem to be some groupings. There’s a thicker white area where you can see that’s the typical fold, but you can’t nail it down.

Justin Avery: No. There’s a whole bunch. It’s really strong between, say, 1300 and 500. It’s kind of hard to see anything in particular. One of the things he did say with this particular page is that if everyone comes on with a 768, or a 1024 fold line, it will only show up as one line. There’s no like, “It will become bolder because more people have it.” This is every possibility.

Jason Beaird: How many people have a browser that’s set to exactly 1024, 768? That’s not the way your browser works, even though that’s the way that we have been telling people to design for years now.

Justin Avery: Oh, exactly.

Jason Beaird: It’s like, “Oh, well think about somebody that’s on a 800 x 600 monitor.” Oh, I’m dating myself with that one. We’ve always given people specific pixel sizes of monitors to think about, but who has their browser re-sized to fill the whole monitor?

Justin Avery: Exactly.

Jason Beaird: Not many people.

Justin Avery: Not even just filling the full monitor. You might do, I’m sitting on a Mac now, and I’ve got a tool bar which takes up probably, I don’t know, 20 pixels, maybe 30 pixels? I’ve got a bookmark up there which pushes it down. You still can’t have a fold fold.

Jason Beaird: Then if you have Web Inspector open all the time like I do, then …

Justin Avery: Then nothing is cached ever.

Jason Beaird: Nope.

Justin Avery: I’m always like, “Why is this site so slow? Oh, I’ve disabled cached on Web Inspector,” really good, powerful tool. Oh, man I had a point about that at some point. It’s gone, it’s gone. [00:40:00] Oh, I know it was the thing-

Jason Beaird: We’ve gone off topic of responsive with thinking about the fold.

Justin Avery: I know. It’s more prevalent than ever, I think, with the fold thing. Oh, that was it. I’m going to get a bunch of responsive notebooks printed up shortly, and, fortunately, the guests on this podcast get a notebook. I’ll get one across to you one we get off this call.

Jason Beaird: Excellent.

Justin Avery: One of the things when I was building this site, I really like the Pelican Book site. I love the pelicanbooks.com, I think it is. It loads up the page and there’s maybe a 40 of 50 pixel space at the bottom where the background color will change. There’s a little bit of text which encourages you to move down to the next section. There’s also a button that has a click through action on the section that you’re at. Then you go to the next section and it’s a little bit more easier to go to the next section. It’s really well done, and they use Flex Box for layout. They also use the VH units for the view port heights unit.

Jason Beaird: Right.

Justin Avery: I’ve been playing around with that as well. I really like it. You can set a section to be 85 VH, and it will give you 85% of the viewable area within the view port, so you will always have a bit of space at the bottom.

Jason Beaird: That opens up a lot of interesting possibilities for designing interfaces that are really fluid and responsive.

Justin Avery: Yeah. With stuff coming, I could do it on the little notebook site that I have because, let’s face, 200 people are going to visit it, and most of them have state of the art browsers. You, on the other hand, have to accommodate a hell of a lot more. You have an application, you’re providing a service for people. Is there anything that you’re [00:42:00] really keen to check out and include, but it’s not quite ready? Is there stuff that you would really like to see come up and available through something like CSS that would solve some of your responsive problems?

Jason Beaird: I’m thinking, but I know I’ve pointed out a few of those things. Looking at future [inaudible 00:42:18] and things like that. We’re fortunate to only support IE9. I say that, but when I started, we had just dropped I86. I was so excited not to be designing for I86 and more. I had to deal with 7 for along time, and then stopped actively supporting 8. Having a lot of users and having to support older browsers it really limits a lot of what you can do. It’s hard to think of a specific example.

&nbsp; One thing that I realize that we are not having to worry about anymore that we had to worry about with IE8 was setting background size. For [retina 00:43:03] devices that’s critical for using sprites in any kind of way that looks good. I just, for a future I was working on for the next release, I was creating a 2X sprite and I was thinking to myself, “Oh, I need to create a 1X version of this sprite sheet for IE9,” and I went back and said, “Oh, IE9 supports that, so I won’t even have to worry about that anymore.” It’s nice when you realize things like that have happened, that it’s something that used to bug you, it used to be an extra chore that isn’t there anymore.

Justin Avery: Yeah. Totally. I’m just wondering, coming up to about time that I’d have to start wrapping things up, or at least stay thinking about the fact that I have to wrap things up. I have a couple of questions which people have [00:44:00] sent through. Actually, I have one question that someone has sent through the newsletter and asked me about, which I thought I might pass on to you and see if you have any thoughts on the subject. Also, just to warn you, I’ve got a question from our previous guest. Each week the guest has an opportunity to ask the next guest a question. You don’t know who the next guest is going to be, but you’ll be able to ask them a mystery question. Yeah, you can ask them anything. We’ve had some strange ones, we’ve had some good ones.

&nbsp; The first question was someone that sent something through and it was MJ. They’re asking, “Wondering if you can offer some tips on selling mobile-first workflow clients. Our clients have fully adopted and realize the necessity of responsive design, but they insist on seeing a desktop first in it’s entirety to sell it up the food chain for sign off.” This causes issues in the future because they then have to address mobile very hastily, and it’s either a huge development cost, or the website looks rubbish. Do you have any tips around trying to sell a mobile-first approach?

Jason Beaird: It’s an interesting question because we kind of had to do that with the last redesign. I don’t feel like we have to answer up the chain of command to do anything that we do on the application, but it took some justification that said, “Listen, the app needs to be responsive as one of the goals for the redesign.” Especially with clients, I don’t know if you need to deal with mobile-first, but you definitely have to make the case for making mobile a priority with the project. That’s one of the best things about going from client-based webdesign to working on a big internal application. I’ve been in that situation for 5 years now when responsive design wasn’t quite a thing yet. [00:46:00]

&nbsp; Even in 2010, 2009, when I was doing client-based web design work, we had to convince clients to think about mobile. We did a website for a regional airport and we told them, “Listen, a lot of people are going to be accessing your website on the phone. It needs to look good on phone.” At the time, we ended up developing a separate site for the airport on mobile. That was us pushing the client to do that. I feel you’re in the same boat now with the responsive. It’s kind of an obligation for you as the person creating the site.

&nbsp; You’re going to make more work for yourself if you don’t push the client to think about responsive from the get-go because you’re going to be the one maintaining that site or application. If you can get that out of the way at the beginning of the project, it’s much easier than going back and trying to redesign something to make it mobile-friendly or responsive. Like I said, I think trying to make a client think mobile first is probably hard to do unless you’re a site or application that people are looking for on their mobile device the majority of the time.

Justin Avery: Yeah.

Jason Beaird: Getting them to think about what the audience is, will they be accessing your site on a mobile. It really depends on the application and the purpose of the site as to how you sell it to them.

Justin Avery: Yeah, because there’s nothing wrong with MJ developing it for a mobile-first, but then still just sending through the desktop version for the sign-off, right?

Jason Beaird: I think it should be an upfront thing, otherwise you might be doing work [00:48:00] that you’re not getting paid for, right?

Justin Avery: Good point.

Jason Beaird: You’re not going to waste your time. It takes some time to think about it from a mobile-first. You want to let them know that that’s a priority of yours, and if they want to have the site developed, you’re going to do what’s best for their users, not for them, and you’re going to advise them to do what’s best for their users, not for them. It’s usually in the client’s best interest to take that way as well.

&nbsp; You have to find the angle for what makes it the most appealing for the client. In most cases that comes down to financial. The little bit of extra time to make something work well on a phone will payoff if it’s e-commerce related. If you’re trying to drive traffic to a business, in most of the cases people are going to be accessing it on the way there. If you’re trying to drive e-commerce traffic, they’re going to be looking at when they have lull time on the train. Making the case for responsive I think is pretty easy these days. It’s not so much of an [inaudible 00:49:08] case anymore, it’s a standard.

Justin Avery: No, that’s actually a really good point, then, for MJ to go and make that case around why it’s a business benefit. Like you said, is it going to sell more when it comes down to money, right? That’s what clients respond to. “Will it make me more money, or cost me more money?” They don’t mind doing it if it costs them more money and makes them more money at the same time.

Jason Beaird: Exactly.

Justin Avery: Oh, well. That’s good, I like that. The next question was, actually, from our last guest, which was Kathrine [Farman 00:49:51]. It’s a relatively easy one for you to get into 2015 which is, “What are you most [00:50:00] excited for in 2015?” This, actually, wasn’t specific to web development, or responsive design. She was just, “What are you most excited about.” Cover either.

Jason Beaird: I am most excited about in 2015 about hover boards because ‘Back to the Future’ said that we would have them, and that should be coming along. In terms of responsive design …

Justin Avery: The hover boards, though, wasn’t there a Kickstarter campaign for an actual company that did hover boards in-

Jason Beaird: It was, I believe it was called Hendo that was doing-

Justin Avery: Yeah.

Jason Beaird: I saw that at Kickstarter and I was kind of fascinated. I’m such a ‘Back to the Future’ geek.

Justin Avery: Me too.

Jason Beaird: Really, this is kind of a cop-out answer, but I’m excited about the future. Seeing the things that are coming, even Microsoft’s latest announcement of new interface ideas, new devices, new screens and new places where our work will show up. In some ways I think it makes a lot of people poop their pants, but for me it just gets me excited about the possibilities of what we can do with those applications. I’m excited to see how things will evolve past mobile, past desktop into new territory.

Justin Avery: Yeah.

Jason Beaird: Is that a legit answer?

Justin Avery: Any answer’s a legit answer.

Jason Beaird: Hover boards, that’s my answer. Hover boards.

Justin Avery: It’s your answer. Any answer, no, that is cool. I agree, I think it’s very exciting what’s going to come up and how things are going change. Everything changes so quickly and in weird directions. It should be another good year. Back to table-based layouts.

Jason Beaird: Oh, boy. That’s where I started.

Justin Avery: It’s funny, you kind of go back to it. You started with [00:52:00] table-based, get into email apps and all the emails are sent table-based.

Jason Beaird: You don’t get this [not 00:52:05] thinking about it ever.

Justin Avery: It’s evil. You’re paying penance for something you did in one of your earlier sites. Having to-

Jason Beaird: Fortunately, I’m not doing table-based email designs. That is Fabio, and Alex is working with him on creating new email patterns for responsive. It’s weird, it’s backwards table-based HTML that is responsive for the email clients that support it. The things that they’re doing there is just fascinating. It’s like-

Justin Avery: Is that going to be something that’s going to stick around for a fair while? Are we going to be in 2016 and still table-based, it’s here for the long run?

Jason Beaird: Fabio can probably answer that better than I can because he’s been watching the support of email clients go up and down. When will Outlook disappear is the question of whether or not we’ll be able to get rid of table-based email. He would be able to answer that question better than I can. I really hope it goes away soon so we can start designing emails the same way we design regular front end applications and sites.

Justin Avery: Yeah, that’s funny.

Jason Beaird: I don’t see it happening soon. In the meantime, we’re using MacGyver methods to duct tape and bubble gum things together in ways that make them work well on mobile devices, but still working backwards email rendering clients like Outlook.

Justin Avery: Let’s design websites like it’s 1999. Go back to the old school. It will be interesting. I also think things like Gmail have an effect as well where they did something weird by stripping out CSS because their email essentially is a web [00:54:00] app anyway. It has some funky things where it has to strip any styles out. I’ve always had weird things happen with Gmail, the mail client and even the app client as well.

Jason Beaird: The thing about it in terms of designing like 1999, it’s like playing Mine Sweeper, dealing with all these different email clients and things that could potentially go wrong.

Justin Avery: Just bombs everywhere. The last thing is, basically, what’s your question for our next guest, Jason?

Jason Beaird: I’ve been thinking about that since you mentioned that I would have to ask something myself. I think the one thing that I would ask is, because you asked about the future, what’s the single most interesting current mobile pattern that’s come out, since I’m kind of a pattern geek. What’s the most interesting mobile interface interaction pattern that you’ve seen? That should be a fairly tough one that you can’t answer with just hover boards.

Justin Avery: I can have a list of answers that people aren’t allowed reuse, so you’ve now taken hover boards from anyone else that want’s to use it. Yeah, I’ll try and get someone to ask a ‘Back to the Future’ question then and that will make it very difficult for someone to answer without being able to use the word hover boards.

&nbsp; Jason, thank you very much for joining on the call today. I found it really interesting. Like I said, I love the stuff that MailChimp does, and it, effectively, is what you do on a day-to-day basis. If anyone wants to get in touch with you, or follow what you do and read your blog post that may start again soon, how do they get in touch with you or find you on line?

Jason Beaird: First off, thank you so much for the invite. It’s people like you and your audience that are thinking about responsive design that shapes what we do as well at [00:56:00] MailChimp. We try to keep an ear to the ground as far as what’s going on and what we can do better. If anybody wants to follow me personally, I’m at Jason Graphix on Twitter, and that’s my website domain as well. The UX newsletter is where we write about MailChimp-y things, and that is the uxnewsletter.com. We recently created an e-book from the most popular articles that we did last year, and that is the uxreader.com, or, actually, uxreader without the dot com. We were selling it for $5 with all proceeds going to charity, but we just about a month ago made it available for free, so anybody can come and download it and check it out.

Justin Avery: Awesome. Can you still chuck in fiver if it’s going to charity, if they appreciate, or it’s just free now?

Jason Beaird: Yeah, we do still link to the charity that we were benefiting. We would definitely appreciate it if people went in, donated to that non-profit organization.

Justin Avery: Who is the non-profit, just out of …

Jason Beaird: Now I’m drawing a blank.

Justin Avery: That’s all right, go to the Uxreader.

Jason Beaird: It is Rails Bridge.

Justin Avery: Ah, cool.

Jason Beaird: They’re an organization that helps women and minorities learn to code. It’s a very interesting organization.

Justin Avery: Very cool. Actually, everyone should just go to the uxreader.com because it’s just a lovely, really pretty, simple site.

Jason Beaird: We had a-

Justin Avery: And responsive.

Jason Beaird: … campaign that went along with it. It was a responsive email that Fabio, the email developer I mentioned, created that looked exactly like the site.

Justin Avery: Very cool.

Jason Beaird: We’re trying to have fun and do things that are … It’s kind of hard when you’re stuck in an application that you’re stuck doing things a certain way to be able to experiment and do fun things. It’s products like this that allow us to try new things, which we try to do that often. [00:58:00]

Justin Avery: Yeah. Also, it’s just good to see you putting that sort of stuff up, sending a newsletter out about the things around UX. I’ve subscribed to that. I think it’s an excellent newsletter as well, and then putting them all into a nice little downloadable pack as well. It’s great. You guys do very well, and you do well for the community as well, so thank you. I think that is about it. Is there anything else you want to mention before we sign off?

Jason Beaird: No, that’s it. Thanks for using MailChimp for the past 146 weeks.

Justin Avery: I can honestly say it has been an absolute pleasure. Freddie the mascot, for those that don’t use it, every Thursday night, or Friday morning depending on how late I’m up, a little high five pops up every time I hit send on the MailChimp. I hear a whoosh sound as I hit the sent as well. Yeah, I enjoy using it thoroughly. Thank you for designing such a fun app online for being able to do, mine’s not really a business-y thing, but it’s kind of. Everyone uses it for different reasons, and it’s fun to use, so thank you.

&nbsp; Thank you also to all of the listeners for joining in. Feel free to rate-up the podcast on iTunes and share it with your friends if that’s what you would like to do. I’ll join you again next week with another edition of Responsive Design podcast with all things responsive and another special guest as well. Thank you very much, Jason, for joining us, and thank you everyone for listening. Cheers.

Jason Beaird: High fives.

RWD Podcast Episode #28 : Catherine Farman
53:53
2017-12-22 20:56:41 UTC 53:53
RWD Podcast Episode #28 : Catherine Farman

Show Notes


As a non profit organisation Girl Develop It rely heavily upon donations, no matter how big or small, from people like yourself. If you would like to help contribute to the cause the industry will appreciate it.

Donate to Girl Develop It


Transcript

Transcript goes here.

Justin Avery: Hey, everyone and welcome to another edition of Responsive Design Podcast. This is Episode 28. My name is Justin Avery. I’m your host and curator of Responsive Design Weekly, a weekly newsletter all about friendly enough responsive design. This week’s sponsor, a big shout out and a big thank you to Girl Develop It they are our sponsor this week. We’ll hear a little bit more about them afterwards. Basically, their mission on their site is … It’s a nonprofit organization and they exist to provide affordable and accessible programs to women who want to learn web and software development through mentorship and hands-on instruction.

I’ve see them come quite a few times and I know we featured one of their courses or one of their events recently, one of their newsletters when Ethan Marcotte went to speak in Boston. This week, I’m very fortunate to be joined with Catherine Farman who will tell us a little bit more about Girl Develop It. Welcome, Catherine.

Catherine Farman: Hi. Thank you so much for having me. I’m so excited to talk to you.

Justin Avery: Yeah. Thank you for coming along. Where are you dialing in from?

Catherine Farman: I am in Philadelphia which is where I’ve been living for 6 years.

Justin Avery: Nice.

Catherine Farman: It’s nice and chilly, and rainy here today so I’m really happy to be inside.

Justin Avery: It seems to match the same kind of weather we’re having over here in London.

Catherine Farman: Nice.

Justin Avery: Now, for those of you listeners out there that aren’t aware of Catherine, Catherine, maybe you could tell us a little bit about how you got into the web and some of the things that you’re doing now, maybe in particular around the Girl Develop It stuff.

Catherine Farman: Yeah, absolutely. I am a web developer/front end developer and I’ve been doing this for about 6 years as my career. The way that I got into web stuff was really through design [00:02:00] and playing around with stuff. I’ve told this story a few times so I’m sorry to have to repeat it again. My first website that I ever built was a Hanson fan website when I was about 12 years old, maybe 11 or 12. Yeah, and I just was really into the Internet and like using the family computer to like join web rings and Hanson fan web rings, and stuff like that. I started making my own website using an FTP program to upload it. I was on all of the hosts like GeoCities and Yahoo, and Tripod, I had sites on all of them. I would just code things in Notepad and look stuff up, and this was like before Google even. I was really just learning from those thorough experimenters that I was meeting online in this kind of fan space of music fans.

Justin Avery: Was this all done with tables?

Catherine Farman: Yeah, tables. No CSS. We’re talking tables and font tags, link tags. I was a huge fan of link tag. I remember using JavaScript for the first time. I just like copied someone’s code into the page, at the bottom of the page, and like it was to make an alert come up and ask you for your name. Then it would print your name on the page and like I didn’t even know how that worked. I just like copied it from some other site and I was like, “Yes. This is the best thing ever.” That was my first exposure to building websites.

Justin Avery: That’s awesome. I’m pretty sure that’s how everyone still builds them today.

Catherine Farman: Yeah, yeah. One of my former colleagues, Yesenia Perez-Cruz, we worked at Happy Cog together. She also says that she got into web stuff because she was building I think it was a Christina Aguilera fan website. Everyone kind of has these embarrassing web pasts that I wish we could still like find those sites and [00:04:00] –

Justin Avery: It’s one of the saddest things that all these things have gone by the way. You don’t still have the URL? It was sort of like one of those Hanson.yahoo.pages.

Catherine Farman: Yeah. I think I remember the neighborhood that I was in on GeoCities, but that’s it. There’s some archives that’s still available and I’ve tried to go in and like find my old website, but there’s just too many pages to click through. There’s got to be like an automated way to dig that stuff up someway and have someone else look into that.

Justin Avery: Yeah, definitely. It’s a project for Christmas. While things are a little bit quiet just go back and try and dig up a GeoCities.

Catherine Farman: Yeah, like crawl through the GeoCities looking for my name plus Hanson. I will find it.

Justin Avery: Did you graduate much from Notepad across to the old Macromedias or FrontPage?

Catherine Farman: Yeah, I did. I was really lucky. I grew up in Texas and I went to like a public school. We’re very lucky to have a teacher who was like into this stuff. She taught a web design class when I was in high school that used Dreamweaver and was just like, “You make websites using Dreamweaver, which is really cool.” We got to play around on the Internet before people came up with the idea of blocking schools and stuff. We got into a lot of trouble like downloading Kazaa and songs, and music all into all the computers at school because they weren’t locked down at all.

I was really lucky. I had learned to type in elementary school and knew how to use a