RWD Podcast Episode #33 : Airbnb

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