 It's great to be here. Thank you so much. It's a great turnout, and it's a fantastic venue. And thanks so much to Google for inviting me to speak here. So today, I'll be talking a little bit about Opera's perspective on progressive web apps. My name is Andreas Bovens, and I'm a product manager of Opera for Android. And I'm also heading up Opera's Developer Relations team. And so last year has been a really fantastic year for us because we had the pleasure to implement, with every release, adding more features to our support for progressive web apps. So we've added support for add to home screen. And the prompt you get at the bottom to suggest that you add a site to the home screen if it qualifies for us being a progressive web app and if the user positively engages with it. We've also, of course, have support for service workers and offering a great offline experience. We've just, last week, released a support for push notifications. So this is brand new. And there is also some internal labs built already with that support background sync. They haven't been out yet. We still need to test a little bit more. But I expect this to land very soon in Opera for Android as well. I want to, in this talk, I don't want to go again through the various APIs and the things you can do. So it will not be a very code heavy talk. But I want to look more at some UX patterns. I want to look at some questions you may have around emerging markets, Opera Mini, and then also some of the challenges we face with progressive web apps and potential solutions. So let's get started. First of all, I want to look a little bit at some of the UX patterns that we've seen coming up in relation to home screen, add to home screen. So first of all, the first pattern I want to cover is channeling users to install banners. And so you probably know this. If a user engages frequently with a site that is a progressive web app, the browser shows an add to home screen install banner. And so it pops up from the bottom, looks a little bit different depending on the browser you're on. But the basic mechanism is the same. It suggests, hey, do you want to add the site to your home screen? The user can then pick no thanks or to add it. And maybe it's shown again at a later point in time. However, it's also possible to prevent this banner from just popping up all by itself and do something else with it. You can tie it to an alternative trigger, like for instance an install button. And here on airhorner.com, you can see that when the page is loaded initially, there's this install button that pops up at the bottom. When you press it, the native install banner of the browser's install banner comes up and the user can choose to install the application or to add it to the home screen. And Flipkart does something similar. It's quite interesting. If you haven't tried it yet, definitely check it out. What happens is when you load the Flipkart website a couple of times, you will feel that it vibrates a little bit. And then there's this little cross at the bottom that sort of wiggles a bit. And it suggests, OK, do you want to install this web app to your phone? If you click it, only then the install banner shows up at the bottom. And this is quite interesting, because it allows Flipkart to only channel users to this install banner who are really engaged. So only engaged users get to see this, because they first have to click this little button and so that Flipkart is certain, like, yes, they're going to press Add to Home Screen and sort of they keep more control over the user flow and user funnel. So this is quite interesting, something to consider if you're building a progressive web app. Another pattern I want to look at is that what I find quite exciting is that now the more and more progressive web apps are popping up all over the place. We see that progressive web apps are using display modes other than sort of the standalone display mode. And so I want to look here at two simple examples. I recently was browsing the Guardian and suddenly an install banner popped up and said, hey, do you want to add this side to your home screen? So I did. When I launched it, I actually noticed that today using this Play Browser, which pops the side back up into the browser so it doesn't go standalone or full screen or something like that. And so you can still use the URLs and sort of use that as a navigation aid or maybe for sharing and things like that, which is, of course, is quite important for a newspaper if it wants to build social media engagement around its content. So that was kind of interesting to see. This is another app. It's called Flick Play. You can find it on flickplayapp.io. It's made by Chinese developers, and I've been talking with them. And so they're really excited about the potential of progressive web apps. And they're using this Play Full Screen and orientation portrait. So they lock this game in portrait mode because it would make sense to sort of reorient it if you go in landscape mode. And so you can see that they can offer a really immersive experience. It's also really smooth. So it's barely noticeable or not at all noticeable that you're using this game inside a web browser. It feels like a totally native app. So do check it out. And then let's talk about offline, some of the UX patterns we see there. One of the things you have to wonder about is, OK, do I want to save specific content units or do something else? For instance, a sound slice offers a save offline option for specific content units. In this case, it's not articles, but it's lessons with musical notation. And so what happens is, if you click the Save Offline button there at the bottom, the musical notation and the audio is downloaded. And then afterwards it says, OK, offline mode is enabled. And you can play it back even if you're offline. So the interesting thing with sound slices, if you access it while being offline, it just shows you a special UI that lists all the lessons you've downloaded. And so you don't have to hunt around and try to figure out in the UI of the site, OK, what did I download and what didn't I download and where can I find it. But it just gives you a nice list. And you can interact with it and play it back. So it's a quite nice experience. But here, so user interaction is required. The user says, I want to keep this, this, and that. And then later on you can get back to it. Another type of approach is to try to save almost all site content. This might also be right for your particular use case. For instance, if you look at the Washington Post, this is the online experience, normally very, very beautiful layout, really snappy experience. If you go offline and you refresh, this is what it looks like. It's exactly the same. The only thing that's changed is a little airplane icon in the top right corner. When you click on articles in offline mode, so let's look at that first article there. You see that you can read the full text of the articles. The text is a bit more at the bottom, but believe me, it's there. But images, they're not prefetched. So the text is prefetched, and it's all there in the background. But the images are not there. And I found this kind of funny, actually, particularly for this image, which it's actually not offline. That's why it's not shown. The user is offline. The image is online. And that's why nothing's shown. But I found this kind of a funny quirk. Anyways, and so when you refresh the page, you actually, this is what the article looks like when we reconnect and refresh. And then when you go back offline, the article stays. So all the content you've interacted with actually stays, including images, this time. So this is a really nice and smooth experience. And it just balances, rightly, the text is cheap to download. So it's nice to have that cash. This is probably what the user is interested in, whereas images are more expensive to download. And you only want to do that when there is specific user intent to load that image and get the full content of the article. The Google I.O. Progressive Web App also does something similar. What it does is it downloads the full site in the background, which is not so heavy. There's a few images, a bit of text, a schedule, and so on. And it doesn't do this with videos because that would be a bit too much. Users would incur significant bandwidth costs otherwise. And it also informs the user, hey, the site will work offline. So it says caching complete. Future visits will work offline. Also quite nice. So this is a similar approach on a different site. And there's many other sites. So it's been quite interesting, actually, to see how all of this stuff is surfaced and explored by various sites. Then another pattern I wanted to look at real briefly is how sites indicate that the user is offline. And let's go back to our Google I.O. site. So when you go into offline mode, let's just turn on airplane mode in this case, there's a banner at the bottom pointing out that you're offline, but that editing will work. So this is quite nice. It tells me, hey, you're offline, but you can still use the site and interact with it. And if you look at Flipkart, it also, all the way at the bottom, it says, hey, you're offline. Currently, you may still browse previously viewed items, though. And what you also see is that they've grayed out the whole content. And there's another site, geo.tv, that also grays out its images when it's offline. Personally, I'm not a big fan of this, but it might work as an indication of, hey, this content is stale, it's not so fresh using this filter on top, but it might also be UX pattern that we see more commonly popping up, and maybe that users might like or make sense to them, especially as these offline experiences are still very new. OK, let's have a look at Push. We implemented Push recently, and this is a funny story. I was looking around for sites that support Push notifications in Opera. And to my surprise, actually, a number of them do browser sniffing, so stuff wasn't working. We had implemented the API, but we had to sort of work with a number of sites to get things to work. But anyways, New Scientist was a happy exception. It worked out of the box. And this was the very first Push notification I got. I was like, yay, a Push notification. And then, unfortunately, it was to say that the Great Barrier Reef Rat is the first mammal wiped out by global warming. So that was kind of sad at the same time. So here's a picture of this rodent too bad. But yes, so that was my first Received Push notification on Opera for Android. So what I want to look at is how we can use notifications for re-engagement of users. I don't have much of a demo here or an example, but I'd like you to think a little bit about the idea that Push notifications allow web apps, basically, to list visitors for re-engagement in a really low friction manner without requiring them to download an app or sign up to receive emails with the latest news, or things like that. It's just enough if the user goes to the site, flicks the switch and accepts a notification permission prompt. And from then on, you can reach this user. The user can forget about the site, can remove it completely. And still, you will be able to reach this user at some point in the future. This is, for instance, very interesting for, let's say, a concert ticket site or something like that where you don't, if a lot of sites ask you to convert by using their app to download their app or by signing up for future news, but Push notifications make this unnecessary, basically. You can just, with the flip of a switch, you can get the users to sign up. And later on, you can reach them, unless they clear permissions, of course. So Celio, which is a site that, a service that created a progressive web app, they also pointed this out. And they said in their document, I really recommend looking at it. It's a really great presentation about progressive web apps. They say that web Push is a killer communication channel. It's more reliable than native app Push. And we can send push messages even when the user doesn't have the app. So that was for them eye-opening. And it allows you to build an experience, get users on board in a really low-friction way, and later on, reach them in a much more pervasive way, actually, maybe longer-term way, let's say, than you can with a native app or other sign-up methods. Another pattern I wanted to look at is how sites contextualize why they need permission to send notifications. So this is something you as a web developer should look at. OK, how do I want to do this? And so on weather.com, it does also push notifications that work out of the box here. And so you have to go to a specific section in the settings. And you have to go there to configure your notifications. And they really explain very well why you'd want to click Allow on the Push Notification permission prompt that comes up next. So they say, OK, you can activate your alerts right here, and so on, and so on. The user has to flick a switch, and then this comes up, and then you can choose and save your settings. So they really try to give a good story as to why the user should accept this permission request. And I find this a quite interesting experience. So this is one way to approach it. Another way to approach it is to just ask up front, almost on first load, hey, give us permission. And you may say that, well, this is terrible design, but in some cases, it might also work. So for instance, if you look at Facebook, you could argue that, well, once the user signs in to Facebook, this maybe is enough in sufficient intent to indicate, like, yeah, I want to engage with the Facebook side of the mobile browser. And of course, I want to get push notifications on, say, a native app you would expect as much. So maybe on the web, it's fine to just ask it up front before they start even using the site just to get as many people on board as possible. There is also, for instance, a new scientist also asks this on first load of the page. This is there, it's maybe a little bit too fast because you haven't even read anything. There's no intent yet, do you want to sign in or something like that, or come back and immediately push notification request is asked. So there's different schools of thought. Some of them say, OK, it's better to ask these kind of difficult questions as early on in the process as possible. Because if you sort of leave them for later, very few people will find them. Few people go to the settings and try to enable it there. So you have to think very well where you want to ask this. So I think best practices will emerge over time. I don't know if there is a golden bullet, probably a silver bullet. It probably will evolve and it depends very much on the experience you're building. So to summarize, these are the things you should consider, some of the things we looked at. Channel add to home screen prompts or not. Is the display mode and orientation of your site optimal? What type of content do we want to save offline? Do we want to save this content after user action or automatically in the background? How do we indicate that the user is offline? And do we want to ask him to sign up or are push notifications better? And when do we want to ask users to accept notifications so that we can interact further with them? These are some of the things we've looked at and some of the questions you should ask yourself when you build a progressive web app. Let's have a look at emerging markets as the next topic. So over the last couple of years, millions of mobile-first and mobile-only users have come online. And if you were here yesterday, you also saw Tal Oppenheimer's talk, which also went quite into detail about this topic. And so these users have specific needs and concerns. A real quick background story. We found that a subset of active, opera-frandered users was not updating to the latest version. They were stuck on an old version that we released last year or a couple of other versions. And they were active users using it daily or weekly, but they were not upgrading to the latest version. So we sent them a survey and we asked, why are you not upgrading? Why don't you want to get on the latest version? And this is what they told us. In many cases, their data package was so limited that they were afraid to run out of data by updating the app. They said, we only want to do this if it's really needed, if it's really necessary. And just an upgrade with some tiny feature was not enough for them to spend X amount of megabytes to update to the latest version. And also, interestingly, a lot of these phones are underpowered phones that are being used in emerging markets. And a number of users had run out of storage space, so they couldn't. Their operating system told them, well, you cannot upgrade. And maybe they didn't want or it wasn't obvious to them that they had to delete pictures to save up more or pictures or other data or other apps to save up space to upgrade. So this was quite eye-opening. And recently, I followed some conversations on Twitter around progressive web apps. And I saw a few web developers from Africa talking with each other and interacting and discussing progressive web apps. So I reached out to two of them. On the right, you see Eugene. He's from Nairobi in Kenya. And on the left, there is Constance. And he works in Nigeria for Konga. And so I asked him some questions. And this sort of confirmed what we found earlier also in our user survey. So the article is on developer. If you want to check it out, I'll just feature a couple of quotes. So this was mostly Constance here that I'm quoting. And he said, Nigerians are extremely data sensitive. The same is true for people in Kenya and probably a lot of other African countries. And he said, people side load apps and other content from third parties. So they go with somebody with a computer with a lot of APKs on it, plug in USB, and then transfer apps like that. So what could possibly go wrong, right? So they side load apps and other content from third parties and also via extender. I think that's how you pronounce it. It's a peer-to-peer sort of app that is being used for local file sharing. And with progressive web apps, without the download overhead of native apps, developers in Nigeria can now give a great and up-to-date experience to their users. Because it's just really low threshold, really low friction to load a website. It's very light. And of course, these updates are instantly. And he continues, if I were to pick just one feature of progressive web apps, I'm super excited about is the ability to detect and handle offline, unreliable network conditions with service workers. So this is very interesting. And that's probably also why you see early adopters of progressive web apps. It's not wire.com when CSS came around. Wired.com was one of the first sites to adopt CSS for its layout. Or if you remember Boston Globe, which was one of the first major sites using responsive web design. But instead, we see a lot of these apps, web apps or web services in Asia and Africa, jumping on progressive web apps and building really interesting experiences. And so this is very exciting. And it sort of shows a little bit the direction. And really why this whole idea around progressive web apps matters so much, because it allows them to create a great low friction experience on any kind of device, basically. Let's talk a little bit about Mini, because we're talking about emerging markets. And a lot of people in emerging markets and all around the globe are using Opera Mini every day. So actually about 250 million people every month use Opera Mini. And the number is still growing. And so if you didn't know, Opera Mini is a proxy browser. But over the last year, actually, it has evolved quite a bit. And if you haven't looked at it lately, I recommend you to try it out. This is a preview of the latest beta on Android. And Opera Mini now has multiple rendering modes on Android. So it's not only the classic view anymore. It's still there, the presto-based server-side rendering, but there's other views as well. And so when you use data, it uses the built-in WebView component with compression. So it uses our servers to compress content. But it uses the built-in WebView renderer, which means you will get great compatibility and a lot of standard support. On Wi-Fi, it uses built-in WebView without compression. And unless you turn it on, so this is also using WebView. So it's really a great experience as well. And there is also an extreme mode, which is also known as OBML, or the classic presto-based compression mode that maybe you know if you've looked at Opera Mini in the past. And it results in really large data savings because we compress the pages to something really small. But it also, we incur some breakage along the way because JavaScript is somewhat supported, but not to a great extent. And so there's much more limited page interaction. We're in the process of moving users as much as possible over to the WebView-based powered modes, the WebView-powered modes. Sometimes we even switch this dynamically when we detect the site is better off using a WebView-powered mode. We switch to it in the background, and then we switch back to extreme mode if the user continues surfing. But many of our users are still using extreme mode. The reason is because they like it, because they've gotten used to it, or maybe because of a handset like a Java phone or a Windows phone, where these other WebView modes are not supported. So it might be that they're one of those devices and they don't have a way to switch back. But you'd be surprised, actually, a lot of people really use extreme mode. And they prefer this experience over what we would think would be preferential, which is like the full package with full web standard support. A lot of users actually really like and are concerned about this extreme mode, because it allows them to save so much data. So what about progressive web app support? This is sort of a difficult question. And so in the WebView-powered modes, they have solid standard support, as I said, including service worker support. So sites will work pretty nicely. We work together with Flipkart to get their site to work well there. And you've got full interaction and so on. It's really nice. You don't have to add to home screen or push notifications, but the service worker's part works really nice. And of course, all the rest of the page interactions. The extreme mode does not support progressive web apps features and comes with limited JavaScript support. So you have to watch out a little bit there. It's a bit more complicated. So before this reason, I want to go back to this is sort of about putting the progressive and progressive web apps and things like that. It's important to build your apps carefully balancing content, presentation, and client-side scripting. And you follow this progressive enhancement principles as much as possible to build up an experience that works well on lowering devices or proxy browsers like Opera Mini all the way up to the latest browser, the latest bells and whistles on really powerful devices. And so, of course, there are certain experiences. Let's say you built a camera app that has a progressive web app, that will be very hard to support in Opera Mini simply because all the necessary APIs are not available. But if you have, for instance, a site that is very content heavy, it makes a lot of sense to serve this content as HTML and then sprinkle some scripting and so on on top, but still have a usable experience with HTML only. And so this is quite important to consider because these users, they matter, and they can also be users of your service. So why not? To paraphrase or to quote Paul Kinlan yesterday, he was talking about this. And he said, don't start with the technology. Start with the experience that you want to build and sort of think of it like that and then build up the site around that experience to make that experience possible. This is a good approach, I think. Because in the end of the day, what we want to build is a worldwide web, another wealthy Western web where only people with powerful cell phones can access content, but it should work for everyone. So coming to the last point, some issues and ideas that we've had. I think, personally, that you are offline. Telling users that is a bit outdated. It's maybe OK if it's the first time they visit the page and they happen to be offline and there's just no way that the browser can know what to serve or that anything can be served at all. So then that's fine. But if you visited the site before and you try to reach it again, but you happen to be offline at that point, maybe this is what we should say. This site doesn't work offline. It seems like you're offline, but this site hasn't been built for offline use. So we blame the site instead of the user. And I think it's sort of time to start thinking about how we can tell users as a browser vendor, hey, you're offline, that's great. The site doesn't work, it's not because of you, but because the site just doesn't cater for offline use. And sort of to nudge site owners a little bit to provide an offline experience which should be part of the package. You serve as workers and so on to do this. Then something about ambient badging. And Alex has been talking about this. He said a couple of weeks ago, wouldn't it be great if there was a button in the URL bar that appeared whenever you landed on a progressive web app that you could always tap to save it to your home screen? And so we also thought that that would be great. So we implemented something. If you go to Washington Post, for instance, or any other progressive web app, you see here, I don't know, do you see what is different? Some of you maybe? Yeah, there's a little icon there. It's a little phone icon, sort of indicates add to home screen so that you can add the site to the home screen. It's just there. It doesn't require user engagement or anything like that. But it indicates like, hey, this is a bit special. There's this mode you can add it to the home screen. And it will provide a very nice experience for you. So this is something that is in a lab's build that will come out later on today. Just after this talk, have to finish writing the blog post and we'll put it on def.upper.com. So do check it out. And then another thing that we looked at is to pop a site, a progressive, sorry, how to pop a progressive web app back into the browser. And also a couple of weeks ago, Jeremy Keith, who'll be moderating the panel later on, said, I want people to be able to copy URLs. I want people to be able to hack URLs. I'm not ashamed of my URLs. I'm downright proud. And we also think URLs, of course, are a very basic fundamental part, architectural part of the internet and how we use the internet. So we also saw, OK, when you're in a progressive web app that goes in standalone mode and full screen mode, how do you get back to the URL? How can you retrieve the original URL? Maybe because you just want to continue using the site in the browser or because you want to share it, pass it on to a friend, and things like that. So this is what we built. It's also in the same labs built. And if I click here on an article, load this article in the Washington Post, and then I pull down to refresh, but I go to the right, then suddenly the site, the progressive web app, pops back up into the browser. And you can continue interacting with it right there. You can look at it one more time. So this is the pull to refresh, and then you go to the right or to the left if you want, if you're left-handed. And then it opens back up into the browser. So this will be in the labs built. It will be released later on this afternoon on dev.oper.com. So do check it out. And also, worth mentioning, if you are interested in seeing more examples, great examples of progressive web apps, there's a site, pwa.rocks. We try to update it as much as possible with new progressive web apps that pop up in the wild. We fully realize that this is not scalable, but for now it's quite fun to say, hey, there's a new site. Let's put it on and you can discover it and play around with it. And so yeah, so if you have a site that you want to see featured there, feel free to do a pull request, all the codes on GitHub, and we'll be happy to include it. So that's it for me. Thank you very much.