(playful music) (audience applauding) - Thank you Thank you everyone.
I have a lot to talk about and I know that the schedule actually had the session for a shorter period of time than was expected, so I'm just gonna get going.
So I wanna talk to you a little bit about a situation that some of our clients, a couple of clients, have found themselves in, or particularly the web teams of those clients. And what happened is the president or the CEO of the organisation suddenly came to the web team and just demanded a progressive web app.
This is sort of atypical.
This is not what normally what happens.
As a matter of fact, I haven't seen this really since the early of the mobile when we had sort of senior executives getting really excited about mobile technology and sort of demanding that people create native applications.
And so the teams of these organisations when faced with this have a lot of questions. For example, the product owner might ask, "What is a progressive web app?" And the project manager might wonder, "How do we create a plan for this?" The business owner might ask, "Do we even need a progressive web app?" Designer sort of starts to wonder like, "How does the CEO even know about a progressive web app?" And then there might be a developer in the room who gets really excited like, "I've been wanting to do stuff with service workers, "and this might allow us "to re-architect everything in Vue.js "and like all of this different "technologies that I've been excited about." And the thing is that this team, this disparate team actually has to come together to some sort of consensus about what it is they're going to build.
And what I see is that because progressive web apps have such a broad definition and people don't have a common understanding, it's hard for teams to figure out what actually makes sense for them.
So today, I wanna talk about how to look at this and talk about a framework for making decisions for what your progressive web app should be. And I'm going to try to answer the questions that your teams may have.
So, first I wanna start with the most important question, which is how does a CEO even know about progressive web apps.
And I'm not making this up.
We have had two clients came to us because the presidents of the organisations basically went to the team and said, "We need to do progressive web apps." And the reason that this is happening is because it's not just the tech press that's covering progressive web apps.
It's publications like Total Retail, which I had never heard of, but it's actually a publication for executives at e-commerce companies and retail companies, or publications like Digiday.
They're all talking about businesses that are seeing success with progressive web apps. We hear stories like eXtra Electronics saw a 12% increase in click-through rate, 100% more sales from people who came from push notifications, four X increase in web re-engagement.
Or, one of my personal favourites which is Ola Cabs, which is an Indian-based company.
And they rolled out a progressive web app, and not only did they see increases, but they actually saw customers who had deleted their accounts, deleted their native applications who came back after having access to a progressive web app.
Pinterest has talked about how when they implemented a progressive web app, they saw increases in user engagement across the board. Not only that, but they wrote sort of year later followup where they talked about the fact that before they did the progressive web app, the least likely path that someone would take to become a new user of Pinterest was via mobile web. And after the progressive web app launched a year later, it was the most likely way.
It was the thing that was creating their most growth. We hear so many of these stories that we created a website called pwastats.com where we keep track of these stories.
And so that if you're trying to convince people in your organisation that PWAs might make a difference for you that hopefully you can find an organisation that's similar. So, I encourage you to go check that out.
The second question seems like it should be easy to answer, particularly for a group of people who are developers or designers, which is what is a progressive web app. And as John talked about, Frances and Alex actually coined the phrase. And when they coined the phrase, actually described 10 characteristics that progressive web app were responsive, that they were connectivity independent, that they had network resiliency, network fluctuations would have caused problems, that they had app-like interactions, they were fresh, they were safe, discoverable, re-engageable.
Push notifications would bring people back in. Discoverability meant that people could instal them to their home screen.
These last two though, the fact that they are linkable and progressive I think are the things that make progressive web app stand out.
In the past, we've had attempts to make app-like experiences, using web technology, things like Adobe Air or PhoneGap, things that used the web but are not off the web. And I think that's a fundamental difference when it comes to PWAs, that we have technology where we can share a link, and somebody can get a web experience.
And then if their device is capable enough, they actually get a more advanced experience, or then they could add it to their home screen. So this definition is great.
It described behaviour that they were seeing out in the wild, works well.
As a matter of fact, it seemed to be working well. But as I said, I think the definition is tough, because even someone like Bel Halpren who had shipped a progressive web app actually wrote about how he didn't know what a progressive web app was.
He had created one.
He's like, "What the heck is a progressive web app?" And the challenge I think, unfortunately, our friends at Google have a lot to do with the fact that there's confusion.
Because originally, they've had the same 10 characteristics that Frances and Alex had on their website. And then at some point, they changed it to six. And this six is actually pretty good.
This is actually the list that I would point to, that it's fast, nearly instantaneous, that it's like an app.
You can instal it on your home screen.
It's responsive.
This is actually a really good list.
If they would just stopped here, it would've been great. But then a year later they changed it to be reliable, fast, and engaging.
I no longer really know what these mean.
A year after that, they added integrated.
So now it's fast, integrated, reliable, and engaging. So now they've got an acronym.
It's on fire.
It's amazing.
But I don't know, like fast, integrated, reliable, engaging.
Craigslist might qualify, right? Like classified website, fast, reliable, engaging.
I think that's it.
I don't know what integrated means.
I literally just wanna just kinda burn this whole thing up. It doesn't help.
It doesn't help us actually understand.
It doesn't help that team figure out what it is we're going to build.
So, thankfully, Jeremy Keith articulated it I think pretty simply, and that said a progressive web app is a website that's been enhanced with HTTPS, a service worker, and a manifest file, right? That is a technical definition.
If you don't have those three things, you're not actually technically PWA.
You can have those three things and have many more things, and you would be PWA. But the range is pretty large.
As you can imagine, you can have websites that are very simple that fit this criteria, and you can have Twitter.
The range of this thing is huge.
The key actually is a service worker, and I'm not going to spend a lot of time digging into service workers unfortunately today, but I just want to point out that the main power here comes from the fact that we can intercept network request, and we can decide what we want to do with them. And so, we can explicitly say things should go in the cache, and then the next time somebody makes a request for that asset, we can say check the cache and fall back to the network, or check the network and fall back to the cache, or check the cache, and if you don't find it, don't go to the network, or just replace it all with whatever we want so we can hijack entire pages.
We've never had this level of control in a browser, and service workers make all of that possible. They're also the key to huge improvements and performance. So Google did a study where they looked at websites that were using service workers versus ones that didn't. This is the graph for the sites that did not have a service worker.
And basically what we want is we want higher bar to the left because those mean that more people are getting nearly instantaneous responses. And with the service worker, we see that people were having those sorts of fast, instantaneous experience. Service workers are also key to providing offline experiences and doing push notifications. It's a really, really powerful set of technology. So, again, a progressive web app is a website that's been enhanced with HTTPS, a service worker, and manifest file, but it can be much, much more than that.
Progressive web apps allow us to build experience that we use to require native applications, and sort give you a sense of what that looks like. I wanna show you a quick video that Google did describing PWAs.
(beeping) (upbeat music) - [Narrator] The only thing that evolves faster than technology is our expectations.
We want everything better, easier, now.
Suddenly, downloading an app feels like it takes forever. And in many parts of the world, data is still at a premium.
With one megabyte costing up to 5% of a monthly wage. Let's face it though, until now, the alternative to native apps hasn't been great. (soft music) But that was then.
Progressive web apps can noW deliver mobile web experiences with a native look and feel, offering features like real time push notifications, adding a site to your home screen so you can easily jump back to it with a single tap, even when you're offline.
Plus the ability to make quick payments on the go. And all from your browser.
(upbeat music) (dramatic music) This is the next generation of the mobile web. So what are we waiting for? (dramatic music) Let's go and build something great.
- Yeah.
Don't you all wanna do that, right? Like if we build PWAs, like we'll all have just like four or five horses running down the beach in the sunset.
It's amazing.
I'm like, let's just stop and go build them now. I bring this up because...
I gotta ask this question on Twitter, but like, what's the difference between PWAs and just regular web best practises? And I think that it can be, the hype can be a bit of a turnoff.
I know it was, for me, the first time I started haring about progressive web apps. We've done stuff with app cache in the past. We were like following what was going on with service workers.
There have been versions of manifest files for years. Before iPhone, there were things that were sort of defining app characteristics on the web. And so, when I looked at progressive web apps, I didn't understand why anyone really cared, but then I was speaking on a panel at a digital marketing conference, and somebody in the audience asked a question. And for whatever reason, it made me think about PWAs.
So I mentioned it in my response, and then I just started getting all these follow-up questions all about progressive web apps.
And then after the session, people were asking about progressive web apps. And like the broad consciousness with PWAs wasn't there yet. This was really early on.
And what I realise was that even though it didn't seem like something that was that interesting to me, to that audience of digital markers, it was a big, big deal. Frances Berriman has actually written about this. She talks about how the name isn't for us, right? And there's been a lot of discussion about whether it should've been progressive websites versus progressive web apps, but she's like, "It's not for us.
"It's for your boss, for your investor, for your marketer. "It's something to get them excited "and look at the web in a new way." And so, I've come around this idea that actually what the hype is it's a tool for us. It's a way for us to get people to get excited about maybe having that icon on their home screen.
And they were like, "Oh yeah, "but your Lighthouse score is really bad, "and we've gotta address that." And so now all of a sudden we've got sort of a Trojan horse for a performance conversation. Jeremy has written, Jeremy Keith has written about how it's important to use a right language for the right audience.
If you're talking to business people, talk about the return on investment from PWAs. If you're talking to marketing people, talk about the experiences that you can create with progressive web apps.
If you're talking to developers, progressive web app is a website with HTTPS, and service worker, and a manifest file.
So, what about do we actually need a progressive web app? And to this, I think we need to answer two questions. The first is, does your organisation have a website? Then, yeah, you probably would benefit from progressive web app.
Because that question that was asked about whether there's anything different between progressive web apps and just web best practises. There is no difference.
We should have websites that are fast.
We should provide people with the best experience possible. And so, a website should be a progressive webs app. But the second question is, do you make money on your website? Are you doing e-commerce, or advertising, or things of that nature, in which case you definitely need a progressive web app for all of these sorts of return on investment reason, sort of the increases in user engagement and stuff that we're seeing.
And if you don't do it, your competitors probably will. Now, despite this fact, I actually hear a lot of FUD when I talk to organisations about progressive web apps. So I just wanna address a couple of things that you might bump into.
The first is why do we need a progressive web app if we already have a native application? And I actually think that the two can exist side by side. There's no reason for these to be competing. The reason why we need a progressive web app is because not every customer has your naive application installed.
Even people who do have them installed may be on a device where they don't have access to it, and 100% of your potential customers do not have your native application installed. So it makes sense to have a way to provide a better experience for people who do not have the native application. Not only that, but like, I don't know if you looked lately, but the App Store is kinda having some trouble. In the United States, the average smartphone user instals zero apps per month.
In the Android marketplace, the average app losses 77% of its daily active users within the first three days after instal.
Within 30 days, its loss 90% of daily active users. So simply being in the App Store is no longer sufficient. And the cost of acquisition is much higher. The cost of keeping people in the application is much higher.
And mobile web audiences are three times as large and growing twice as fast. So a lot of reasons to focus on the web.
So, one of the things that I talked to companies about is that your website is going to be the first interaction people have with your business.
It's much likely actually if you have a great web experience that people will instal the native application than if you don't. I think it was Expedia.
There was company at Chrome Dev Summit last fall that actually talked about how they were concerned that their PWA would cannibalise their native app instals. And actually, after they launched their PWA, they saw their native app instals go up.
That's just one data point that is not scientifically significant, but I think it is worth thinking about.
The second reason that I often times hear is like the web can't do X.
We can't do this on the web.
I mean we're all web folks.
We know that there are some things that the web can't do.
If you want to do say something with health, and you want to integrate with Apple's HealthKit or something of that nature, you're going to need a native application have access to it. But often times what I hear people say is stuff that actually just isn't true.
It's like this Mobile Marketer article where in the middle of what was actually really good article, it just talks about how PWAs do not support hardware components that native apps do, like the camera, the GPS sensor, and the fingerprint scanners.
What? So, Instagram has a progressive web app, and the last time I checked, they're kind of big into photography and using cameras, right? About the geolocation, don't have access to geolocation? Geolocation has been available on phones since iPhone OS 3, not even iOS.
It wasn't even renamed yet.
This was 2009.
I questioned whether this author had actually spent any time on the mobile web, because I can't go to any sites without them prompting me and asking where I am. You hit a homepage and they're like, "Tell us your location." NO, no.
I'll get back to that later.
And then as for the fingerprint scanner.
So here's the deal.
These socks that I'm wearing right now.
These socks are proof that you can use the fingerprint scanner on the web. Because I was trying to take a screenshot for the book that I wrote, and I forgot that the home button was also the fingerprint scanner, and it's also how take screenshots, and I couldn't figure out why the screen wasn't working, and I bought a pair of socks.
(audience laughs) Yeah.
For those in the back who can't see, this is the socks.
I actually picked them intentionally because I was afraid that I might accidentally buy something, but I didn't think it would happen on my first try. And for those who wants to zoom, these are actually groundhogs.
I don't think you have anything similar in Australia. But in the United States, we have Groundhogs Day where in Philadelphia they like pull a groundhog out of the ground.
And then if the groundhog sees its shadow, then we're supposed to have more weeks of winter, something silly like that.
It's a ridiculous thing, but it's February 2nd, and that's actually the day that my son was born. So, the socks are pretty cool.
I'm happy that I accidentally bought them.
But I will tell you that I went to buy the second pair and I put gloves on and that didn't work, and then I used my pinky, and then I finally succeeded in making the screenshot. And then I picked up the phone and I put my thumb on the home screen and freaked out, but I actually didn't buy the second pair.
The point of this really is to say that the web can do much more than we think it can. If you've been looking at a particular feature that you weren't able to use in the past, you might wanna revisit it.
We have a lot of mythology about what the web can and can't do, and it's changed. So it's time to look again, and progressive web apps given us that opportunity. Alright, so the team gets together, and they're like, "Yeah, let's do this.
"Let's build a progressive web app.
"Now what are we gonna do?" And this is where I spent a lot of time sort of thinking about the frameworks were for looking at features of progressive web apps, because the range is so large.
And I came up with these five things.
How much something feels like an app, what you're going to do with installation and discovery, what you're going to do with offline capabilities, what, if anything, you want with push notifications, and then the things that are beyond PWAs, things that are not actually part of this, with the definition of the progressive web app, but that people often times lump in.
So I wanna look at these and sort of look at sort of a range on this one.
So how do we make something feel like an app? Now this is an interesting question because Chris Coyier on CSS-Tricks asked people if it's useful to distinguish between sites an apps.
And at the time, 72% of the people who responded said that, yep, they are different things with different concerns. And it's amazing, because if you read that, everybody agrees that it's important, or nearly everybody agrees that it's important. But if you go read the comments, nobody can agree what actually makes something an app versus a site.
Like the comments thread is everybody arguing. As Jeremy says, like obscenity and brunch, web apps can be described but not defined.
So, here's what this means from my perspective. You get a bunch of people in a room, you bring your team together.
I am fairly certain that everybody is going to think that it's important that your progressive web app feels like an app. And I also am fairly certain that nobody is goin to have the same vision in their mind as to what that means.
So I think we have to break it down into some more discreet things.
How much do we wanted to feel like or look like a native application? And we can do some of this.
We can use material design.
We can use sort of iOS design to make it feel like various platforms.
Of course then there are other platforms as well, like Amazon's Fire devices or Windows devices, and then what about desktop browser? And then if they change design systems, Metro UI to Fluent Design that Microsoft went through recently, are we going to change our applications? So, in this particular case, I think that it makes a lot more sense, and this is what I recommend is defining your own design system, own design language based on your brand, and then being consistent in that regard.
This is TripCase, it's a phone PhoneGap application. Full disclosure, we happen to do some work on it, but we didn't do any of the design work.
I think it does a really good job, whether you're on Android or on iOS.
It feels like it fits in, but it doesn't feel like either one of those platforms just kinda feels mobily, I don't know.
But I thin that that's sort of the direction we need to go for that.
Another way that people want something to feel more like an app is to have a more immersive experience.
And this is something that's possible with progressive web apps, because we can define the display mode in our manifest file where we can basically describe, like how much browser Chrome do we want? We can have everything from browser which is full browser Chrome all the way to full screen. And there's a tremendous temptation actually to go full screen.
We've been fighting the browser Chrome for quite some time. But when you go full screen, you forget all the things that the browser provides for us.
We're spoiled by browsers.
Inside the warm comforts of the browser are things like the status bar, the address bar, like navigation.
Inside menus, we have things like the ability to have tabs and find a page and downloads, and then also things that are pretty important, like printing, and sharing, and emailing.
And so, if you go full screen, you're basically ruffing it in the way that people have done with native applications where you have to make conscious decisions to add those features back in.
And sometimes you may not even be able to reliably add those features back in.
For example, social sharing is something that we now have a Web Share API that's inconsistently supported. It actually has a really nice future for the ability to allow you to create an interface that allow somebody to sort of pull up the native share profiles.
But if your sit does a lot of work with social, if that's a big way that you get traffic, maybe you don't wanna get rid of the browser Chrome. Maybe that is actually something that's beneficial to you.
Even things like adding a back button, when you start looking at it, it's harder that it seems.
A lot of native applications make an assumption about a very strict app hierarchy.
So go from the home screen to a product category to a product, and then up to a category and down to a product. You've got this holistic behaviour happening. And even though there is a possibility in native applications now to sort of deep link, it's not a common behaviour, but it is fundamental to the web, right? So, you may follow a link from search or from social and end up right on a product page.
In which case, where does the button in that page go, that back button? And does it do the same thing as the back button that the browser provides? Because they look actually incredibly close. It almost looks like somebody copied the back button to be honest.
Now spoiler alert, actually, they go to different locations.
The one in the page will go up to the category page, and the one in the browser would go back to your search or your social.
Do we even need that back button in the page in this context? Probably not, right? We need to design for these different context. You can get into some pretty fun situations here. So in this video, actually I end up using the back button to get back to the category page, and then the forward button to get back to the category page, and then the back button to get to the category page, and the forward to get back to the category page. And so, all roads lead to the category page. It basically doesn't matter.
The good news is that there's a display mode media query that you can use to actually detected what display mode you're in, and then maybe not show the button if you're in standalone or full screen.
You can make those decisions.
But I think what's really important here is that in the same way in which we've had to learn what it means to deal with a lot of screen sizes and device capabilities, we actually need to star thinking about different browsing context, whether somebody has the app installed on their home screen, and so they get sort of that full screen experience versus somebody who may be still viewing it in the browser, and maybe viewing it on desktop versus mobile. It's responsive across those context.
Another thing we can do to make something feel like it feels like an app is to have sort of fast and fluid experiences.
This isn't PWA-specific necessary, but these are the sorts of expectation that people have when they start talking about progressive web apps. So Wego is actually one of my favourite progressive web apps. They do a lot of stuff right.
And in their interface, essentially as you make your way through the application, they're doing a lot of transitions that reinforce their app hierarchy.
Transitions and animations has sort of establish relationships between the objects on the page.
And then as you make your way sort of back up, like things slide in the opposite direction. So they're doing a lot of work to help reinforce what we would expect from that application.
We can also do things like making sure the experience is very smooth.
So, something that native applications do is that they sort of have skeleton pages or skeleton screens before the full data loads in.
And with service workers, we can store placeholder images, and place holder content, and actually then load additional content once that information is available.
This is sort of related to something that Google talks a lot about, which is this idea of having an app shell.
So you've got like the header in your navigation and your footer, all those items that are common from page to page. Because with the service worker, we can store those and we can sort of reliably cache them. We put those things in to the cache so that when the next page is viewed, we can paint those to the screen nearly instantaneously.
And because the perceived performance matters much more than the actual performance of webpages, being able to paint stuff to the screen really quickly will create an experience that people think is faster. In many ways, this is what native apps provide. We download the app ahead of time, so that then on subsequent loads all we have to do is go get additional content. Just a bit of warning, often times when you start looking at doing that sort of stuff, looking at app shell, it often times will lead to discussions about doing single-page applications.
There's nothing wrong with that.
But if your architecture is not SPA, if you're not doing single-page applications now, just beware that you don't have to do a single-page application to build a progressive web app. There's no requirement, and I see a lot of misconceptions where people think that you have to do that. Our website was really fast.
Before we made it into progressive web app, there wasn't a real advantage to re-architecting it as a single-page application.
It's built on top of WordPress.
It's primarily a writing tool.
So, there is no reason to do it, and our website score is really high Lighthouse and it's a PWA.
Finally, I think it's something your organisation should ask, is whether feeling like an app is really the goal. I don't think users are going to care whether your experience feels more like a site or an app, as long as the experience is good.
That's all that really matters to them.
And their definition of where that line is is not gonna map to your line, so you might as well just provide a great experience. So, we've go this continuum from a website that's basically just something that using progressive web app technology to have performance improvements to something that might like a full-screen application using native design language.
And depending on where end up, you could be looking at something that might be like a month's worth of work or something that could be a year, like depending on what you want to accomplish. Second thing from a progressive web app perspective is installation and discovery.
So, once we have a PWA, once we have a manifest file, an HTTPS, a service worker, we want to announce it. That's where the manifest file comes in.
It allows us to declare what the name is of the application, what the icons are, colours, things of that nature.
That allows us to define what the startup screen should look like, and you'll note that they're not all the same. So this is a good thing for testing on multiple devices because you won't get consistent behaviour. There are also things like theme colour where somebody doesn't even have to instal a PWA. Actually, it doesn't even have to be PWA to take advantage of this with the manifest file. And you can end up with something that actually looks much better.
Lyft does this pretty well.
Their PWA, even in the browser, feels more like a cohesive experience because of their use of theme colour to sort of tie in with their brand.
Once you have a progressive web app and you've got a manifest file, then you will probably see browser at the home screen prompts.
For example, in Firefox and Samsung, it's basically just a button that's like a home with a plus sign in the bottom of it or in the middle of it that you then can use to add it to your home screen. Chrome and Opera had something that was much intrusive. They have this add to home screen banner that would pop up at the bottom of web pages, and they would just basically take over a portion of the screen and ask people to add it to their home screen. Over time they've started moving away from that. Now they've got the mini info bar, and eventually what they're going to have is essentially just the same sort of ambient badging. That's what it is on desktop, like something that's in the omni bar that allows you to add it to your home screen. And instead, you actually can control that option on the right, that full screen sort of permission-based prompt, and you can programme this.
You can do this in JavaScript by firing the prompt event, but you can only do it after the browser has developed some sort of heuristic about user engagement with your website.
So they'll fire an event that says, actually, now you're able to prompt someone.
And then you have to figure out when you want to prompt them.
So for example, Flipkart moved their prompt even before this changed happened.
They moved it from sort of whenever the browser decided the prompt to actually on the order confirmation page. And by doing this, they saw a three X increase on the number of people who actually added the icon to their home screen.
So, when we do this, we have to figure out when somebody is likely to do it.
With native applications, we often times have app stores. So, what are our options from an app store perspective? Well, PWAs don't need any app stores.
That's the awesome part, right? That doesn't mean that people stop asking about the though. So the goodness is that from Microsoft's perspective you can submit progressive web apps into the Microsoft Store, they will live side by side with native applications, no difference at all.
Microsoft also used to look for progressive web apps using Bing search engine, and then automatically add them to the App Store or to the Microsoft Store.
As far as I know, they're not doing it anymore, but they haven't announced it yet, so you didn't hear that from me.
Anyway, so if you wanted to be in the Microsoft Store, you're much better off actually submitting it yourself, so you get control over the listing and everything else. On Android, there is something called the trusted web activity, which if you go and you read the documentation, you may not realise it's actually related to progressive web apps, because the don't talk about it much.
I think because they were kind of like trying to make sure that people thought that it would work for Android apps in general and that it didn't raise any red flags.
I don't know why, but basically if you go read it, it doesn't sound like it's about PWAs, but it really is.
And this will allow you to basically establish that you own both the app and the website, and the app is basically just a shell around the website. And so you can ship stuff to the Android store much more quickly.
In the long run, Google will probably be enabling additional APIs for apps that have that sort of trusted experience. Jason Miller who works on Preact is now at Google, but at the time he was just working on Preact, wrote about how trusted web activities are essentially like PhoneGap for Android, built into Android.
And we could use PhoneGap to submit things to any app store.
I do wanna point out though that just because we have the option to be in App Store doesn't mean that that's actually what we should bank on. If anything, progressive web apps, because they are a website, means that we should be using all the tools we use to get people to our website in the same way in which we would do, for the progressive web app, the same way we do for our websites, social, and search, and all of those things. I also feel like this question gets too much focus. This idea of the icon on the home screen is something that people really focus in on, and I don't think they should.
Because if we think about sort of the life cycle of a progressive web app, there's a bunch of people who then you search your social and they end up at your website, which is awesome, right? We've done the first part.
We've actually got them to look at our content. And then we have a service worker instal, it goes through that life cycle of installation, and now the service worker is active, and we've now got a progressive web app.
And then we can do things like offline, and push notifications, and payment request API, and then maybe somebody adds it to their home screen. And so I find myself wondering why we focus so much on that little bit on the right when all of that other stuff is just as important if not more important. Remember, not every customer will add your progressive web app to their home screen, but every customer will instal your progressive web app. That seems like a contradiction, right? But what happens is is that the first time somebody visits your webpage, after the page has rendered, after sort of the JavaScript that's needed to actually create user interactions on the page of process, then the service worker gets installed.
And so on the second page that you visit, the service worker is running and the advantage of having a service worker available to you.
And then you might ask if they want to send push notifications or you might other things of that nature.
But basically, every person who visits your website if they have a device that supports service workers will have their service worker installed.
So, what does it mean to instal it? I think every person who visits a site instals it, and then icons is just cherry on top.
So, again, we've got an installation.
We've got clients who don't want people to instal the PWA because they're afraid that it will cost confusion with their native application or they're still in beta testing, and we've had clients who wanted to be in App Stores. That's a big range and a big difference.
Offline mode is what people typically think about when they think about progressive web apps, but it's just one piece of it, and I think it's often times like too confused. People spend a lot of time thinking about offline usage as opposed to thinking about the fact that they're really the most common use for the offline capabilities of service workers I actually dealing with network fluctuations and network resiliency, but we can do some neat stuff with offline. We can cache for performance and provide an offline fallback.
So these are examples of offline fallback pages of varying levels of complexity.
Sometimes it's just Like articles that you might be interested in.
Other times it's favourite stuff that you can't watch while you're offline.
Trivago does this really cool thing where there's a maze, where you can do the maze while you're offline, and they find that more people come back because they now have the maze.
They return once they're online.
They distract themselves for a little bit, and then they're back online.
You could cache content, recently viewed content for use offline.
So this is what we do on our site.
We don't know what people are going to want to read. So as people navigate through our site, we cache pages.
And then if they go offline and they visit a page that they were previously on, they can still interact with it because it's cached. And then if they go to page that they haven't visited, we will show an offline indicator.
I really like a lot of what Trivago does.
I think they do a really good job with their PWA. So they also have this idea that it's not just like whole pages that are offline versus online.
So you can be in search results and actually go from tab to tab, and they go and download that content dynamically so that the page isn't weighed down by all that data. But if you're offline, they'll just show an offline indicator just in that section. They'll show you, hey, you could get this information, but it's not available anymore.
Financial times is a really good job of preaching content, and they also do a good job of allowing users control. And I think this is the most important thing when it comes to offline behaviour, is transparency and control so that users know what their caching and have the ability and option to say, "No, we don't want that." Because people are on metered data connections, they might have a limited storage on their device, whatever that is.
So, we wanna allow them to have that option. I think of like the Holy Grail of offline is the ability to have something that allows you to do interactivity offline, like editing a document offline and then somehow syncing it up, and then maybe having distribute all three in offline, and then dealing with all the merge conflict. Doesn't that sound like fun? That's like a hard computer science problem, right? So, the minimum, we could do what Slack does, which is if you're starting to write a document and you're offline or you're in the middle of the document and you lose the connectivity, Slack detects that you're offline and basically says, "Hey, you should stop writing now in this space, "so you're gonna lose your work." That's the bare minimum, because otherwise we end up with stuff like Remy Sharp who wrote recently about how he had a 600-word blog post that he'd written on his phone in a hospital, and then he lost it.
He lost it all.
Now, in the past, this would just be like, this is just writing on the web.
This is just what we deal with.
The web got connectivity issues.
Sometimes we lose stuff.
Probably a lot of us has gotten in the habit of copy and pasting things out of forms we're filling out, if we're starting to get long, just to make sure we don't lose it if we lose connectivity.
But the reality is if this happens today, it means that the developers haven't done their job, because we can prevent this from happening. We can detect if people are offline here's one of, say, briefly, Workbox is a JavaScript library that the folks at Google have put together. It's actually been really, really helpful, and it address a lot of the edge cases that you don't realise are important until you actually bump into them.
There's an article on our site about how when opaque responses cause a seven k file to be seven megs in storage.
And you know, that's something that Workbox handles right off the bat.
Because we're using Workbox, we actually had the pleasure of discovering on our own. So, I recommend taking a look at it.
So, for offline, we could do stuff that's just like caching for performance all the way to having something that's interactive offline. Push notifications, the fourth option.
Push notifications are interesting, because if you're, particularly for using sort of like a push notification service and a lot of companies will because they don't want to sort of like reinvent analytics and everything else for their websites, push notifications are actually relatively easy from a JavaScript perspective. If you're gonna build it all from scratch, it gets more complicated, but can be easy, but there's a tonne of hidden challenges in push notifications.
For example, we know that push notifications that are personalised have three times higher conversion rates.
It makes a lot of sense.
We just don't wanna receive random junk on our phones. We want stuff that's like, "Oh, I'm following this team, "and this is the sports score for that team, "or this is a topic I'm interested in, "or my order has shipped." Things of that nature actually useful to us. But the thing is that once you get into that, once you start integrating with backend systems or personal profiles, it becomes really complicated to figure out when you should send push notifications. This is a flowchart for Slack, and this is old.
I'm sure it's changed, but this is how much logic they have to go through to figure out whether to send a notification. And I'm not saying that this is what you should do or that you should pay attention to this.
I'm just saying the moment you start thinking, "Oh, I wanna send notifications "when an order is going through its process of shipping," all of a sudden you're like, "Oh, that sounds great. "Wait, that means we need to talk "to the order processing team.
"Oh, that means that we need to talk to the shippers "and get their APIs and do a bunch of work." All of a sudden, it gets a lot more complicated. The other thing to keep in mind is that while push notifications are new for the web, people already have opinions about them, because they've been using them in native apps for a while, and they hate them.
People dislike push notifications, so we should very careful and make sure that we do a good job of asking for permission and sort of providing value in that space.
So you don't wanna do what YouTube and other websites do, which is you immediately hit their homepage and they ask to send you push notifications. That's a little presumptuous, right? It's kind of like going on a first date and asking for somebody's hand in marriage. I don't know you.
Can't we get to know each other a little bit before we start this kind of relationship? Instead, the sort of best practise is very similar to what we did on our website, which is...
Sorry, I skipped ahead.
So, on our site, when you get to the bottom of an article, maybe you found it interesting, maybe not.
Hopefully you found it interesting.
But then there's a button that says, "Hey, would you like to receive notifications "about other articles?"A and if you press that button, then we do the browser permission prompt.
And then if the person says yes, then they get a notification that says thank you, and they can actually turn off the notifications from that same interface.
That's very similar actually to what Twitter does, and Twitter does this very good as well.
If you go to the notifications tab, they provide this whole screen that says, "Hey, do you wanna turn on notifications?" If you do that, then you do the browser prompt, and then they provide confirmation, and you can customise what notifications you receive. This is important because browsers have implemented kill switches.
So if somebody does not like your notifications and they get annoyed with them and they decide to turn of the notifications via the browser, it's over.
You will never get to send them another notification. You will not get to ask them again, like it is a done deal.
And browsers have made changes.
So, for example, Chrome on Android use to allow people to dismiss permission prompts by clicking the X or clicking, just like tapping on other areas of the screen.
They found that 90% of users were just dismissing the model without making a choice, which meant that there was no incentive for websites to not ask you again.
They could just ask, and ask, and ask.
And so they changed to this situation where users now have to either block or allow. There is no other option, which means that if you ask, like some site do, on the homepage for permission to send push notifications and the person hasn't even had a chance to figure out what this site is or what it does, they're gonna hit block and you're never going to get ask them again. Browsers are also talking about like measuring websites and seeing how often people accept them.
And then if websites have really low acceptance rates, basically not allowing them to ask until they work on that. So there's a lot of work done because they understand that push notifications really irritate people.
Push notifications aren't required.
Your progressive web doesn't have to have them. So the simplest version of push notificationS is no push notifications.
And then there's complex ones that are fully integrated with backend systems. The fifth thing are things that are beyond progressive web apps, and I'm not gonna spend a lot of time on this. But basically, we've got things like what Pinterest does with the credential management API which allows people to automatically get logged in when they relaunched the application/ or, you could do stuff with web Web Authen which was talked about yesterday, which is a really, really exciting way to log people in quickly.
Or, you could do stuff with the payment request API, because I mean maybe you want people to accidentally buy socks.
That's really, really fast and powerful.
I can vouch for it.
So there are bunch of things that aren't actually technically part of PWAs, but that people often times talk about in the same breath. And that you may look at your PWA as an opportunity to do these things.
So let's finally go back to that project manager and ask how we create a plan for this.
When we built our website, we started with the idea that it was going to be a progressive web app. And so, when we launch the redesign, we also move to HTTPS.
We also added a manifest file just for basic bookmarking.
And then a bit later, we add a service worker and a fallback page.
Then we made that fallback page better, and we added some faster experience.
Then we added push notifications.
And then a few weeks after that, after I got off my lazy bum, I wrote an article saying, "Hey, we've got a progressive web app." And then we continue to make improvements.
And the reason that I think this matters is that that each step along the way, each one of those dots, we were actually making the website better. We didn't have to wait to bundle it up as a big binary and then ship it to the App Store and hope that the App Store gatekeepers approved it. So I think organisations could do something very similar. We start with some planning and definition work where we define what our ideal progressive web app would be. And say for an e-commerce company, they might decide that they really care about how much it feels like native or it feels like an app, but they don't really wanted installed because they already have a native application. They don't want things cached offline as much because prices fluctuate.
But wow, personalization for push and using payment request API would make a big difference. Each organisation will be different.
Whatever you do though, benchmark and measure. So that as you see improvement, you start building up evidence to support the more advanced work that you're going to need to do in your organisation. Use the data, because there's nothing that will get people more excited and support the more, the advance things you wanna do, more than showing like, "Hey, we implemented this, "and our conversions went up." Next, after you do that, you need to do, often times you need to do a technical debt assessment. And this is where you have to be honest with yourself about your website.
We've had a couple of clients come to us who have websites that take 30 seconds to load on fast 3G.
Progressive web apps can make things faster. They cannot solve that problem.
First, your site is just too slow, like we can take a site that's reasonably fast and make it fast.
We can't take a site that's dog slow and make it fast. Secondly, service workers, as I mentioned, installed at the end of the first page load which means that your first page is still going to be as slow as it ever was. They may never get to the second page.
So think, is it usable? We've had a few clients who have had websites that don't account for touch well, that basically manage to sort of hack together responsive versions over time. And like this was the moment we're like, "Okay, look, "you've got 10 years of technical debt.
"We just need to grip it out and start over." HOPefully that won't be you, but you need to ask that question.
Once you've got that out of the way, then you can do just a baseline progressive web app where you add things like a manifest and like cache for performance, maybe do a a fallback page.
Then the next thing I think make some sense for organisations would be to do front end editions.
And this is just based on me watching organisations and coming to the conclusion that the more teams that are involved, the harder things get.
So let's just do things that don't have to require multiple teams.
And then once you've shown the benefits of all those things, now you can start doing things like payment request API, and push notification integration, and things of that nature.
The great thing about this is, again, after that initial planning stage, every step, you're providing value, you're making your website better.
And that's a great thing about a PWA, is that each step on the path to progressive web app makes sense on its own.
We don't have to get to the end state to actually make things better.
All we have to do is start.
So, there are more details in the book that I wrote about progressive web apps.
I just wanna thank you all for a great conference and for the great time in Melbourne.
Thank you.
(audience applauding) (playful music)
