Mobile Matters #027: Zack Argyle | Building the Pinterest PWA

Stephanie Cox: I'm Stephanie Cox and this is Mobile Matters. Today, I'm joined by Zack Argyle. Zack is a software engineering manager at Facebook for react native. Prior to Facebook he was an engineering manager at Pinterest, where he launched the Pinterest progressive web app, and he's held software engineering roles at PlayStation and VarusAge. Zack also serves on the Chrome Customer Advisory Board. In this episode Zack and I talked a lot about how he started college thinking he wanted to be a broadcast journalist to now leading software engineering teams for some of the most well-known brands such as Facebook and Pinterest, why we can't truly compare native mobile app engagement metrics to mobile web metrics, and how the Pinterest team went about caching including experimentation in their PWA. And make sure you stick around to the end where I'll give my recap and top takeaways so that you could not only think about mobile differently, but implement it effectively. Welcome to the show Zack.

So I am super stoked to talk to you and really would love to just start off and find out, how did you get started in tech and end up where you are right now at Facebook?

Zack Argyle: Yeah, it's been a long road. So, my first year of college I actually was studying broadcast journalism and I wanted to be a TV anchorman. So things have changed a lot since then.

Stephanie Cox: That's funny. Similar story, I started college and thought I wanted to be a newspaper reporter.

Zack Argyle: So, I was studying broadcast journalism and I had always been good at math and I got to the point where I was like, I need to actually think about my career and not just what I'm studying. And the idea of being a reporter for 10 years, before I could be a TV anchorman and that terrible schedule that goes along with it, was just not intriguing. So, I was like, I need something a little bit more stable. I want to have a family, I want to get married. So, I want to make sure I have a job that's a little bit less chaotic than the reporter job. And I'm like hey, I'm good at math I should check out this engineering stuff. So, I started looking at engineering and I had to retake all of the math that I had stopped taking my sophomore year of high school, which took a really long time to get caught back up. And yeah, so I ended up studying electrical engineering, which was a big shift. And added some time to my college since I had switched after that first year. But it was a good change. It was really hard. But I learned a lot about computers and coding in electrical engineering. At the school I went to, the electrical engineering program is so close to computer engineering that you're not allowed to double major, which was interesting.

Stephanie Cox: Wow, that is interesting.

Zack Argyle: So, I went the computer engineering route but my degree is in electrical engineering. And I I learned later on that I did like the software aspect better, but I didn't want to switch majors again. So, my first job with software engineering was this little consulting company called VarusAge that took a bet on me and they were awesome. They ended up creating a coding boot camp in Utah that's done very well. And so, I got to be a mentor for that for a little bit, which was really cool. And then I moved out to the Bay Area to work for Playstation and to work on Javascript for Playstation, which was weird for me. I had no idea that so much of the PlayStation software for like PS4 for the actual console was actually written with Javascript. So, that's where I got a lot of my in-depth Javascript knowledge from building PS4 features, where it's all just straight Javascript because they didn't have any DOM, right? So there was no way for me to use any of these frameworks that existed at the time. And then from there, I went on to Pinterest and now on Facebook. So, it's been a ride.

Stephanie Cox: One of the things that I know I want to talk to you a lot about is progressive web apps, because if you look in the space of who's doing PWAs, Pinterest is one of the top brands that keeps coming up. I know I've talked to people like Google and Microsoft and they all mention you and Pinterest as one of their favorites. So I would just love to find out, how did you get involved with progressive web apps? I'm sure there's a ton of new tech opportunities and concepts out there and how did you realize that this was something that was worth investing time in?

Zack Argyle: That's a great question. I think part of it started out with being at PlayStation. I mean PlayStation is essentially a like embedded Javascript app. So it's like a PWA, but instead of having it added to your home screen on your phone, you have it added to your home screen on your Playstation. And so, the ideas felt very familiar when the ideas of a PWA and add to home screen and all those kinds of things. They all felt very familiar to me and they got me really excited. I was like, OK, I can take these things that I learned and I can apply them to the broader web, which is really cool. So, I started to learn about that. And then, when I got to Pinterest, actually one of the first teams I was on was the growth team. And I am not particularly fond of a lot of growth engineering. So, what I ended up doing was instead of doing all of these like small A/B experiments to improve metrics that way, I wanted to test the effects of performance on growth. And so, I rebuilt a small portion of Pinterest mobile web outside of the current framework that it had. And this was like four or five years ago. And the metrics were amazing because it was super fast, it was very lightweight. I called it SuperLite. And yeah, so it showed everybody this idea that if we were to invest in the mobile web and make performance a priority, then there is a lot of growth potential. So that's like the initial part of it. It was also a time when we were experimenting with all of these app interstitials. So, they've become very, very popular these days. I'm glad that Pinterest no longer has it, but we were one of the first to actually do it. And so instead of investing in the mobile web at that time, the decision was made to put up a barrier and say, let's just send people to the native apps because they're way better. According to our metrics. So, I was bummed out, I switched teams. I was like, I'm going to work on some other stuff. And then two years later, I did a hackathon project with a couple people and we showed what Pinterest mobile web could be. That was the plan. So, we rebuilt it. We made it so that it worked offline and we made it really fast and we showed it and one of the co-founders Evan Sharp looked at it and he was like "This is amazing. I didn't know the Web could do this! Oh man, this is amazing." And I was like, OK cool. So, this could be a thing all right. And then, a couple of people from the growth org started looking into more of what the opportunity would actually be. And, at this time, I was on the web platform team at Pinterest. And so, eventually we got the buy in after me being incredibly annoying for probably three or four months. I actually made a Slack hack rule that every time someone would say the word "mweb" or "mobile web", it would insert some text that said, "Hey, do want to talk with Zack Argyle about mobile web?"

Stephanie Cox: Oh my gosh, I love that!

Zack Argyle: And this was before the PWA project existed. I was like, I want everyone to know that if they want to talk about mobile web, I have opinions and they should talk to me about it so we can make it better. Somebody, I still don't know who, but somebody shut that rule off without asking me and I was annoyed with that. But I wasn't super annoyed because I knew that I was the one being annoying, so I just let it go. And then, so the growth team did some investigation. They said hey, especially internationally, this can be really big. And so, we created a team cross functionally between growth and the web platform with three engineers from both. And ended up rebuilding it all pretty quickly. So, it turned out really good.

Stephanie Cox: I think it turned out phenomenal. It's really one of the, I mean, just from the results that Pinterest has shared and that the overall opinions from I've heard from other people that are leaders in the space. So, thinking about progressive web apps and trying to get everyone on board, what were some of the common just really challenges that you faced?

Zack Argyle: I think the biggest one was this idea of legacy assumptions. So, people saw our old mobile web, which was essentially just an upsell and pretty difficult to use. You could actually sign up on the mobile web and and use things limitedly. But it was really difficult. One because the actual site was just bad and then two because we kept throwing all of these things in your face telling you to use the native app. And so, whenever we talked about metrics, it was in regards to that old experience. And we said, oh, the native app is so much more engaging than the old mobile web. I'm like, OK, well that's the old mobile web. Think about what it could be. Of course that engagement is really bad, because experience is really bad. So, let's not talk about, we had to throw out the idea of metrics at the start. Because we had this huge legacy assumption that mobile web was not engaging at all. And it turns out that it actually can be very engaging if you make it that way. So, I think that was the biggest thing was getting people's minds to shift from mobile web is not engaging to but it could be. And so, that was probably the biggest change.

Stephanie Cox: Do you think part of that was due to people just being so used to having native mobile apps as really like the only option to have that app-like experience and they just can't see past what the web used to be five years ago?

Zack Argyle: That's a good point, yeah. There's also a very metrics driven result of that, as well. Which is, if you have a native app that means you installed it. If you're using the mobile web, that doesn't mean you install it. That doesn't mean that you have this big barrier to entry. If you've added it to your home screen, then that's a different story. But, if you're just visiting the mobile web, there is like so, for Pinterest, for example, the amount of people going to mobile web is enormous. Yeah, there's so many people, but a lot of them are not signed up. And if they do sign up, then they're probably like flakey people. And that's just because of like the raw number of people coming through. Whereas, the barrier to entry to native is so high that the people using it are gonna be much more engaged. But that doesn't mean that there will not be a highly engaged people on mobile web, as well. It just means that there's also going to be this huge segment of people who are more flaky by default, because it's so accessible.

Stephanie Cox: That's a really good point. I don't know how many people think about it that way. Because you're right, there is such a high barrier to entry to native mobile apps. So, you are typically going to get your more loyal user base.

Zack Argyle: So, when you want to talk about engagement you don't want to compare mobile web with native. You want to compare native with people who have added your mobile web site to their home screen. That's the comparison you want to make.

Stephanie Cox: There's a really good point. I don't think I've heard anyone explain it that way, especially when you start thinking about progressive web apps and where the web is headed today. So, you mentioned six engineers and you were able to do it relatively fast. One of the things that I've heard a lot from other people and I agree with is that, how you guys have thought about the user experience is really just well done. So, can you talk me through a little bit of how that project works? How did you guys figure out how you wanted it? I know you want it to be more lightweight and faster, but how did you think about what that was going to end up being? And how to make it something that was different and compelling.

Zack Argyle: I think that's actually one of the really hard issues when making, especially a mobile site, because you want that initial page load to be really fast. That's the thing that people always talk about. That initial page has to be fast! But you also want your following experience to be engaging. And, there are a lot of tradeoffs that you have to make between those two. Like, I can codesplit my entire everything that I'm not using up front, but that means that if they click on something, something is going to be slow. Because their network is bad. And so, that was some of the trade-offs that we had to make was, hey, we want to make sure that the initial page load stays fast. We also don't want to throw to the wind the rest of the experience. Because that's really what we were going for, we want to give people who don't want the native app a platform where they can still get the full experience. So, that was really interesting. I guess some of the things that we had to think about while trying to do that were first, it was especially like around the routing. That's a big thing with apps and especially PWAs. We did code split all of our routes, but we built in a manual preloader. So, all of our tabs that are at the bottom of the screen in your little navbar, all of those routes get immediately preloaded, as soon as you load up the app. And so, that makes it a lot faster when you're clicking through, which is good. And then also, on and this was something that I had to manually do, I went to each one of our pages and I said, which are the two or three most likely pages that they're going to go to from here? And then I manually stick in hey, preload that wrap, preload that wrap, preload that other wrap. And then I go to those and I say ok, from here what are the next ones that they probably going to load? And then preload those ones. So that way, we're not preloading everything upfront, because we wanted to be very conscientious of people's data. And that's one thing that I've seen different from a few other PWAs, is where they'll just like stick in, usually in their service worker, and they'll just say hey, preload all of our other bundles. And that was something that we did not want to do. We didn't want to take over all of the network and we don't want to bloat their data usage. So, we decided hey, we're going to take this hit for ourselves because it's more work, but we're going to actually like manually preload what we think that you actually need. But it's better for their data. So that was cool.

Stephanie Cox: Well, and it's also I think a better overall user experience too. You're not sticking everything on my phone or trying to get me everything all at once. You're giving me what I need when I'm probably going to need it. So talk about caching. How do you think about whether or not caching would work for you, how would you do it?

Zack Argyle: Yeah, caching is such a big, big question. Yes. So, I guess the first thing that comes to mind is we've got these service workers. And one of the big benefits is, you can cache this app shell. And so, that way we don't have to go all the way back to the server to be able to see anything, which is a huge, huge win. But there are some huge caveats with that. So the first is if you have any kind of experimentation framework, where does that go, right? Because I can't load my app until I know what experience you're in because it can totally change the rendering. But I don't want to have to block my full rendering on whether or not you're in the experiment. I don't want to go fetch from the network to see what experiments you're in. And then, wait for that to get back before I can actually render anything. So, one of the things that we did was, we actually ended up caching the experiments in the app shell and then, periodically, throughout your visit while you're on the site. We'll go fetch the experiments and we'll override it in local storage. And so, that way if there's anything in local storage, we'll use that as a priority, otherwise, we'll use what's on the app shell. So, we have a more up to date version of what actual experiments you're in. And it was tricky because there's weird invalidation questions when it comes to like, now I've got stuff in the app shell, I've got stuff in the local storage. What if I update my app shell, now I need to delete everything in local storage, but I want to use everything that's in the new app shell, because that's got the up to date experiments. And then, there's user information if you're not signed up. I don't have any user information for you, but if you are signed up, I need to have all of that cached, as well. At least information about you, so that I know you don't have to sign up when I render the initial page. So then, if you go to your settings and change settings and all of that information about your user that we've cached. Now, we have to update all of that. So, if it's in the app shell now I've got to invalidate your app shell every time you change a setting and update your app shell. So, there's a lot of really weird quirks with authentication and experimentation around having an app shell. That was a really long rant, sorry!

Stephanie Cox: I absolutely love it because typically when I talk to people and ask them the same question like, how do they about caching? The answer they give me is like, well a lot of times I hear well, with caching comes a lot of responsibility. So, basically don't make poor choices and cache everything. And then, and really bloat people's phones, but then also they give me like well, depending on what's available and that type of stuff. But you're the first person I've ever talked to that has mentioned experimentation, which I think is really fascinating. Do you think was always part of the plan for what you guys were going to do or was that part partly brought up because you had been on the growth team and the growth team was involved? That you guys thought about how we can gracefully include experimentation in our caching process.

Zack Argyle: Yeah, for Pinterest, experimentation is huge, just like a lot of these other big companies. So, it was no question from the start. Experimentation had to be supported. And we wanted to make sure that it was supported well. So, as soon as questions about the app shell arose, we were like oh, shoot, what about experiments? Oh no, we don't wanna block on user authentication and experimentation information to render the page. We want to be able to render the page fast, that's like the whole benefit of caching the app shell. So yeah it was all upfront, what are we gonna do about this try and figure it out.

Stephanie Cox: So, I've known a lot about the results from the Pinterest PWA, but can you tell me your perspective on what you are most proud of that you were able to accomplish with that?

Zack Argyle: Yeah. So, I think the thing that I ended up being most proud of, which was a weird thing, was how good it felt for a touch interface. So, one of my big opinions that I have now is that, if you have the resources then you should not reuse your mobile and desktop site. And they should not be a scaled down version of the other.

Stephanie Cox: Preach!

Zack Argyle: You should have a fork, if you have the resources and a big reason for that when people ask me why, I won't be able to reuse everything. OK, well you can reuse some of like the library code but like the actual view code is going to be very different always. Because it's a huge screen and it's a mouse or it's a small screen and it's a touch. So, they're very, very different interfaces. And so, yeah that was those were the things I was really proud of. We have a component called TAP area that enforced accessibility and that input press area. What did we call it...press states! So, when you like touch on a pin, it compresses a little bit and a little background appears. And little things like that were like when I'm interacting with my finger, I want it to feel native. And so those like mini micro animations that make it really feel good. And so, I don't know why but that's still like one of the things that I really, really like about it is it just feels good when I'm touching things on the site.

Stephanie Cox: Ok, I have similar opinions, strong opinions on those subjects, which are very similar to yours, which is interesting. But same thing, right? Well I don't think there is. Yes. But no, one of the things I always think about with, especially as people are thinking about mobile web and progressive web apps and they're thinking about them as companions to their native mobile. And if you're wanting to create an app-like experience, it needs to feel like an app-like experience. It doesn't need to feel like you took your desktop and you made it small. But, I also have a rant about button size and I have adult fingers and I should be able to tap things without like tapping four things. So, if someone came to you and said "Zack! I think I want to do a progressive web app for the first time", what would you tell them? What would be your advice?

Zack Argyle: Do it. It's the best. No, I think, I mean obviously like the first place to get started is learning about service workers. And, I think that's really important. But, you could probably get by using something like Workbox, which I'm a huge fan of that Google made. It's like a service worker library. It makes things really, really easy. So, I originally wrote all of Pinterest's desktop web service worker code by hand. And it's super tedious and dangerous, to be honest. And when we built our mobile web, we ended up using Workbox instead. And it took two hundred lines down to like 40 or something like that. And it was way better. So, I was a big fan of WorkBox, so I would say if you're looking into PWAs, read up about WorkBox. It's an awesome tool and then study up on service workers, just because there's a lot of quirks with them. And so, you should be aware of it before diving fully into it. I remember when the CreateReact app library adopted service workers for the first time. They were like, yeah, this is awesome, let's do service workers. And then there was all of these issues, because people didn't understand service workers. So, they ended up disabling it. And I think that's what ends up happening with people who are like, let's do PWAs, add your service worker. And then they have all these issues with a service worker and they're like Oh no! Stop using service workers. Yeah. One thing I think is important when you build your first service worker for your app is to create a kill switch. You should have a way to turn off your service worker, without redeploying your site. Like that's really, really important.

Stephanie Cox: I'm guessing that Pinterest is one of your favorite PWAs, but do you have any others?

Zack Argyle: Yeah, I mean I think Twitters’ great. I think it's cool that they're adding it to desktop, though I do have news that it's made the mobile one a little bit more bloated than it needs to be. What are other ones? I mean, those are the main ones. Instagram's actually got a really cool one. I've had it with some of the people here at Facebook that work on Instagram and that PWA has really, really come a long way in the last year and I think it's pretty awesome. I don't know if you've tried that one out. I think a lot of people haven't tried that one out, but it's a great one.

Stephanie Cox: I think I have a list of all progressive web apps that I know of. And I am a little addicted to trying them out and seeing what different companies are doing and how they're thinking about it. Just because I believe it's the future of mobile web and will fundamentally change everything for years to come.

Zack Argyle: Preach it, I like it!

Stephanie Cox: Also, a separate rant. So, last question if you think into the future look into your crystal ball. Where do you think in three to five years, the future of mobile is headed? And what should companies be thinking about to get us ready for that?

Zack Argyle: I really believe it is this idea of shared rendering between mobile web and the native apps. And so, companies. I think they should start investing more into frameworks that will enable that. I think React is a great one. View has ViewNative, which I haven't looked a whole lot into. I think Flutter is looking at some of this stuff, as well. So, companies should really start paying attention to this idea of shared rendering and how can they make it possible. Because it's going to save them a lot of money. Like right now, you've got to have your iOS, Android and your Web engineers. And at some point, it's just gonna be, you're going to have your client engineers and they're gonna be writing very similar code for like, their one set of code for their mobile phone and one set of code for their desktop. But, it's going to be the same framework. And so, I think that's what people need to pay attention to is how can we start looking forward to that in a way that we're going to be able to take full, we can take advantage of the full beauty of what it's going to be.

Stephanie Cox: Zack has been in my dream guest list ever since I started learning about the phenomenal results of the Pinterest PWA and I'm talking about 103% increase in weekly active users and 800,000 weekly lodges from the home screen, but it wasn't just the result that compelled me to want to talk to Zack. I was also intrigued by how Pinterest actually implemented their PWA. Almost every major player in the PWA space cites Pinterest as one of their favorite progressive web app examples, so I knew I had to find out more about what went into building it. Before we jump to takeaways don't forget to take a few minutes to rate and review the podcast. Please tell me what you think, who you want to see have on, and what we can do to better improve the experience.

There are so many great insights from my conversation with Zack that can really help transform how you think about mobile. Let's dive into my top three takeaways. First, can we all just take a minute and recognize how committed Zack was to create a better mobile web experience for Pinterest. How many other people do you know create a Slack hack that automatically responds to anyone who sends a Slack message about mobile web with a message to go talk to a specific person about it. And how many people rebuilt part of their mobile web for a brand as part of a hackathon to prove out what can be done and the results you could see from it. Personally, I absolutely love that. He did both of those things because it further shows his dedication to delivering amazing mobile web experience for users. It's this level of dedication that I wish more of us would show about the user experience in mobile and wanting to push the boundaries of what's possible to continually deliver an exceptional experience for users

Next, most of us are likely running experiments on various digital properties right now and have in the past. It's almost become a Hallmark of digital marketing today to constantly test and iterate across all of our digital channels. What does this mean when you start thinking about a progressive web app and offline caching? I’ve seen a ton of PWAs over the past three years, but Zack is the first person I've talked to that's actually shared how they thought about experimentation working offline their PWA. Frankly, it was a bit mind-blowing because they're basically allowing some level of experimentation to still work while you're offline. Think about that for a second. I also love how they were thinking about caching. I've said this before, but with new technology becomes a big opportunity to do what's best for users and prevent ourselves from abusing it. That's honestly why we've seen so many regulations. It's because marketers have basically taken a new tech, made poor decisions, and required the government to regulate us. And that's why I really hope that more companies will take a similar approach to caching as Pinterest did. Yes, it took more work on their end, but it also insured a lightning-fast progressive web app while also being super respectful of the user storage.

Finally, it's really easy for us to want to compare native mobile apps to PWAs. I get it trust me. Especially when you start thinking of so many PWAs are actually exact replicas of native mobile apps, but what's really important to remember is that the steps a Native mobile app user has to take to get that app on their phone is much more complex and complicated than someone accessing a PWA for the first time since PWAs are designed to take the friction out of accessing them. So based on the sheer effort involved in getting a native mobile app on your phone. You're more than likely going to see a more engaged user base with Native mobile apps, than you would have just the web in general. Comparing engagement metrics between these two aren't always going to show you a true picture of engagement. Instead, if you want an apples to apples comparison, you're going to need a look at your native mobile app engagement with the engagement level of people who have installed the PWA on their home screen. This is an extremely important point to remember as company's continue to implement PWAs in their mobile strategy. We need to make sure that we're thinking about how to measure them accurately.

Now, here's my mobile marketing challenge for the week, set aside an hour, you're probably not going to need that full amount of time, and run your mobile website, or progressive web apps if you already have one, through Google Lighthouse and check out your performance scores. You're likely going to have multiple areas where you can improve the speed of your site. Find out what they are and make a plan within the hour to address them. Personally, I think a PWA is a great option. If you don't already have one.

I'm Stephanie Cox and you've been listening to Mobile Matters. If you haven't yet be sure to subscribe, rate, and review this podcast.Until then be sure to visit Lumavate.com and subscribe to get more access to thought leaders, best practices, and all things mobile.

An Insider’s Look at Building the Pinterest PWA

Episode Information

Stephanie's Strong Opinions

Find us at:

Stay Up-to-date On All Things Digital

See Lumavate in Action

Meet with one of our experts to see how easy it is to centralize your product data, manage digital assets, and create digital product experiences. Trust us…you’re going to be wowed.