PWA - Turn any Site into a Progressive Web App

Transcript

Hello everyone, hope you all have been having an exciting developers conference so far and thank you for joining us today into this session on turning any site into a progressive web app. My name is Kalyana Raman Balasubramanian Krishnan, you can call me Kalyan. I am a senior computer scientist working with the sites and screens team in AEM. I’ll be joined by Gabriel Wald, the product manager for this solution and Patrick Fauche, who’s the engineering manager. So progressive web apps, this seems to be the new wave that is going through the web industry and let’s just see why there is so much excitement around progressive web apps, what are progressive web apps and why they would matter to your business. All of us are very familiar with this conversation about native and web apps. So native apps are those apps that you build that are specific to a particular operating system. So for example, your iPhone apps, iOS apps, your Android apps, for your Windows apps or other specific applications. But then the challenges that we had with the native apps was that they are not necessarily cross platform. There were challenges around the distribution and the cost of development and having to develop for each specific platform became more expensive. So people turn to web apps and you have the great advantage that it’s easy to distribute to anybody with a browser can just point to your website. You now even have push notifications for web apps. They’re cross platform and as such reduce the cost of development for your solution. But they do come with some limitations. Most users today are using their mobile devices to access your website. The days where people used to sit on their computers or on their laptops to access your website are being heavily replaced by people using their mobile devices. In fact, there was a recent survey that was done that more mobile phones are sold than toothbrushes. So think about your own home. How many mobile phones do you have in your own home? And if that is the case, then these mobile users are not looking at the old fashioned web experience they used to have on a browser, on their laptop or a desktop. We are looking for that app experience that native apps give them. Certainly there are some websites that you would browse and you would just go to that address and type it in and then you can look at it. But having that app experience makes it easy to access. It encourages greater engagement and it also results in greater turnover. For example, how often do you just go to Amazon and buy something using the Amazon app versus say just browsing to the site on your phone. So what has happened is that the industry came together and said, can we combine the best of both worlds? Can we give all the advantages that the native apps have and combine them with the advantages that web apps have and the result of that was progressive web apps. Progressive web apps add the installation experience. They add offline capability. They add background sync capability to web apps which you already did not have. Let’s say that you are on your morning commute. Do you remember those days where you still had a commute and let’s say that you are reading this news website and then you clicked on this really exciting headline and then your train entered a tunnel and you lost your network and it was ending up in a circling wheel then imagine how frustrated that the user could be. Now what if you had an offline experience and provided that offline experience to that user. So that’s what progressive web apps can give you. So the industry has quickly embraced the progressive web apps and there are a large number of progressive apps that are coming out with new ones coming out almost every day. A popular PWA is YouTube and YouTube TV and almost all applications in the Google suite of applications are becoming progressive web apps. This includes Gmail even and you now have Uber, Starbucks, Twitter, Washington Post, pinterest, Forbes, Flipkart, MakeMyTrip, Spotify, Hulu and Grubhub among just a few of the popular web apps out there. Google is a major driver of this technology and they are really using Chrome as a foundation for delivering progressive web app technology to the industry. And the question is how soon can you and your customer be next. So almost all businesses have a website today. Almost everyone has to have an e-commerce platform. And what if I told you that you can convert your existing website into a progressive web app with just configuration and no code. There is no need to do any complex coding or development for all this and with just a point and click and a few configurations you can convert your existing site into a progressive web app and join this new wave. And that’s what we are going to talk about today. And rather than talking about it, I thought the best way is to have a demo and see it actually working live. So the way that we are doing this is we are using the power of Adobe Experience Manager sites. And we are having this structure, for example, this was an angular website that was built. And this user interface should be very familiar with those who are involved in development. And what we did is we want you to select a page that will be the starting page of your site solution and click properties. And when you go to the properties of your page, you should see a new tab showing up called Progressive Web App. So I click on the Progressive Web App tab and it gives you a bunch of properties that you configure and you can convert your site into a progressive web app. The first thing is whether you want to enable the out of the box progressive web app capabilities or you want to provide your own. Now I’m a major believer in doing the least amount of work and adding the most amount of value and preferably make the most amount of money as well. So I want to take the out of the box approach. So I select the enable PWA checkbox. Then I have to configure what is the starting point of my application. And then there are various configuration items that allow you to show how the app should look like and behave for the end user. The most common preferences are already defaulted. So you want your web app to look and feel like a native app. You can also choose to have a browser like experience where you have a minimal UI with minimal navigation browser controls or a full browser window or a full screen mode for gaming and other such applications. For example Hulu could be taking up a full screen mode. You can talk about the screen orientation. This can be useful for phone and tablet deployments as well as for digital signage. Then you can specify the theme color. What are the colors that the address bar should look like. You can configure the background color. You can choose the icon of your app from assets. And then we come to the cache management. What is it that you want to enable for offline capability. Again the most common preferences are already chosen for you. So this asks you a simple question. How often does your content change? Does it change moderately? Does it change frequently or does it change rarely? So based on that you can ask your application to look locally in its cache before it goes to the network or look at the network first before it looks into the cache. And then you configure what are those resources that your application should pre-cache. That is it should have downloaded and kept offline as a basic skeleton. Now here are some thoughts. Let’s say you are trying to take the Amazon website offline. You don’t want to necessarily take its entire data and entire product or entire advertising and all the content offline. We are going to really take over the user’s content. I mean this space and that’s not going to be very popular. So instead you should take what is the basic skeleton or structure that is required for your application to work and then the rest can be fixed on demand. So we also include something called a path inclusion. This is cache on first use. So you could be using some third party fonts. You could be using some third party data. So we can even allow that to be cached on first use. Now assume that you have taken this offline. And now I click save and close and my PWA is now configured and ready to go. It’s as simple as that. So now I go and access my site and you will see an interesting icon that shows up that allows me to install this application offline. And this application has installed offline and now has a look and feel of my native operating system. So for all purposes, this looks like my native application on my particular operating system. So what I’ll do is I will close this application as a user would close it. But before that, take a look at this. Let’s say I’m a content author. I am actually testing this on my local to make sure that this look and feel is exactly how I want this for the user. I see that this address bar is yellow and it blends in too much with the content. Maybe I just want a little bit of a differentiation. So I close the app. I go back to my properties and I want to make some changes. Now I ask my audience, can you please suggest a color? Can anyone in the audience please suggest a color that we could apply for this web app? Red it is. And we save and close. And now we now assume that the user has come back and then now they are launching the app. The application launches as you can see with the stored information, but then you get a notification that a new version of this app is available. So I click that message and there the latest changes from the author has reached your app. Now let us also test out the offline capability. So I have all these pages, page one, two, and three in this app, and I haven’t browsed to any of them yet. So I’m going to inspect and this is a developer conference. So I hope you are not all scared by the developer tools. I’m going to the network tab and I’m going to simulate offline. So I’m going to switch the network from online to offline. I do this because I still want to be able to share my screen while demonstrating offline capabilities. And now when I’m completely offline, I’m going to the first page and the first page works offline. And then I go to the second page and the second page works offline. I go to the third page, the third page works offline as well. And that ladies and gentlemen is the offline capability of the Progressive Web App. And if you look at what I had configured here for offline, I had taken that page one, page two and page three, and I had configured them to be offline and available offline. I also took my JavaScript files and a few other files that are required for the application to work and made them available offline. And now you see how my application works offline and provides an installable experience. And we are looking at bringing more and more capabilities of Progressive Web Apps as they come out to you without you having to write a single line of code. So that’s it, ladies and gentlemen. That’s the feature of how you can convert your existing site into a Progressive Web App and make it work offline or online and configure it to your needs. So now I’m opening up the questions and please do feel free to share your questions and we hope to answer them as possible. Will this work on web, iOS and Android? This will definitely work on iOS and Android. So both Safari as well as Chrome support Progressive Web Apps. We must remember that there are certain nuances and limitations on both of them. One of them is the disk space. On most mobile devices, especially Safari, it gives you only around about 50 MB as your local storage on that particular device for any one particular domain, especially for iOS. Android, especially if you are using it for digital signage, they may be able to unlock these capabilities. But you can also use IndexedDB as offline storage if you want to expand the usage. And that takes up around about 32 percent of the available data. Thank you very much. Next question. What is the size of the app generated? So here you can maybe slightly elaborate. Is there any overhead with the solution that we are talking about here and anything related to size and packaging? Yes. So that’s a very good question. What is the addition that we are adding? So let me take you to the inspector and show you what are the resources that we add on top of your website. So the vast majority of what reaches the actual end user is still your website, your JavaScript, your CSS, your HTML, your assets. We add only two resources to this to turn this into a progressive data. One is called the manifest. It’s a simple JSON file and that contains the same configuration that you had in the user interface. This is a very, very small JSON file. It follows the standard PWA specification. And it’s probably not more than a few bytes. Then the other one is a service worker. This is a JavaScript file that contains all your configurations as a JSON and then a very little bit amount of code to be able to give you all that messaging, saying a new app is available, being able to route requests to look into the cache rather than online first. And we make use of Workbox, which contains all the best practices of progressive web apps and delivered by Google. So as you can see, the whole service worker is not more than 80 lines of code. So again, just a few bytes. I would say not even more than one kilobyte is added to your website to turn it into a progressive web app. I mean, can’t get better than that. All right, thank you very much. Next question. How long will assets remain on the user device? That is a very good question. So most browsers have an internal mechanism that they do not publish. It’s an implementation detail on their side as when they will clear their local cache, when there is a lot of disk pressure on your device. So browsers can and will remove your cache if and only if there is very little disk space left on the particular device. And so your application, from what I have heard from Google as well as Apple, is that the vast majority of the time they won’t touch your app at all unless the user goes and does a clear browser cache manually. It’s all going to stay there. And also on a mobile device, it’s going to stay there unless and until there is a lot of disk pressure saying that the system will not be able to operate unless it cleans up some disk space. The same thing is also applicable to native apps. If you are building an iOS native app, for example, you can lose your local data if the operating system decides that there is not enough disk space for continued operations. But given the fact that progressive web apps are themselves very lightweight and the browser vendors claim that they will not touch your local cache, this should not be an issue. For digital signage, this again should not be an issue because we are using it as a kiosk application, single purpose application. This means nothing else runs on your device. So you’ll never face this disk space pressure issue. All right, thank you very much. Next question. Does this configuration need to be done on a page by page basis? Turn the whole site into a PWA? I think I touched upon that point earlier. You really don’t want to turn your whole site into a PWA. Think of it from a consumer’s perspective. Do I want Amazon to download all their content onto my phone? Do I want every website that I install starting to download their entire website? The answer is no. Instead, what I would expect them to download is a basic skeleton with some basic content and then the others should be fetched on demand. So I would say think of it as an occasionally connected device rather than a fully offline device. Most of the time you are still going to have network connectivity. There are some cases where you will not have the network connectivity. So download what really matters. As an example, if I’m a news website, I may want to download the top 10 headlines of the day, but I don’t want to download my entire website onto your local device. So I would say that even though you are going to convert your site into a progressive web app, your design thinking still has to be around how will that mobile experience or how will that occasionally connected experience look like for a website. Thank you. Next question. What happens when you reach a page that is offline? Very good question. So if a page is offline, then that page will show a network error or it will show a blank screen depending on how you have built your website. And you can debug that when you are building this content and testing it out on your author instance. You can check for these word box messages and you will see that if you have properly configured the page, it will say that it found the cached response and that work box is responding to that request. On the other hand, if you did not cache a particular page, then it will say no root was found for this particular page. So based on this, you can very easily debug and find out what are the pages that you have left out that is being accessed on this launch. And then you can just copy this and paste it into your configuration. I’ll try to answer at least two the next two questions. This will work on SP editor mode. So the SP SDK and SP editor and the PWA functionality that got presented to you today are independent and complementary. So you can pick and choose between the two. Next. Will the PWA option also be available for regular sites or only for SP sites? Same question, same answer. Here we are. Next question. I joined late, but that was quite intriguing. Is there any plan on making AN itself a PWA? I don’t think it’s the purpose so far. It’s mostly to help you create your or make your sites and SBA in some cases PWA. Didn’t he turn off his network? So that’s probably something live. Does it include configuration for push notification? This one for you, Kadian. Yes. So push notification is a feature that is coming. We fully intend to add support for push notifications. We are working with our vendors, Apple and Google, to try and see how we can achieve that through configuration for you. Obviously, there are certain processes that you will need to follow to get that push notifications. And we will have more information on that in the roadmap soon. Thank you very much. Next question. Will all the Adobe Analytics event be sent? Use click tracking. So if we zoom out, Kadian, does the feature support analytics? Yes. So I can say that with analytics, it is not just a point of what you read from outside or what you download. It is the fact that the application is trying to send analytics to Adobe Analytics. So if your network is down, then you would still rely on the analytics SDK to be able to provide you that particular functionality. So if you are asking that, OK, outbound requests, that so far we are only allowing for caching for inbound requests, that is the client requesting a resource. But if your app is trying to send out some requests and that endpoint is not available because of a lack of network, that will still create an issue. We have not yet created a generic player to be able to cache and send those requests later when the network comes back up. There are just a little too many complexities around that, but we will definitely address that in the roadmap. Thank you. I do want to say that we did add support for offline analytics for digital signage in AEM screens. What it does is that when a request is made, it is cached inside index DB and then it will keep on periodically checking every few minutes. Is my connectivity available to the endpoint? And if that endpoint access is available, then it will send that data in chunks. That’s already available for the digital signage use case. But for general website scenarios, we will definitely put it in the roadmap. So next question, can you use a rig expression for the page you want to cache offline instead of a one by one or a path? I wish, I wish. Oh, my God, I wish. So this is this is some of the limitations on the precaching capability. So there are two types of caching. Pre caching is the exact resources you want to cache when the application launches for the first time. And then there is cache on first use. So the answer is you just have to specify the folder path. You don’t. It’s not regex. Just have to give the containing folder. And if that particular URL starts with that string, then it’s automatically cached on first use. So that will work for you for precaching. Unfortunately, each resource has to be given a revision number. So I can’t unfortunately give you a capability where, OK, just giving a regex will automatically find out all those requests and cache them for prefixing. So cache on first use. Yes. Pre caching. No. So we’ll quickly answer the next question. Does it work with single page application, for example, using a Vue.js? The answer is yes. Even the URL you saw in this demo and session has been built with Angular. I was wondering how the same PWA might look and work on a mobile device. Is there anything that you would like to say on that aspect, Kalyan? It will look and feel exactly like a standard native application on that particular operating system. So you will let’s take the example of iOS, for example. You take Safari, you go to this URL, it will ask you to install it, and then install it, it will become like a Web clip. So if you’re familiar with iOS, I’m sure you know what Web clips are. And it will save it as an icon. The PWA icon will show up on the home screen of your device. And then you touch that icon and then your application launches as if it’s like a native iOS application. Same case for Android. When you go to this URL on your Android browser, preferably Chrome, it will show that install button. It will ask you, this is installable, do you want to install? Then you click install, then the app will install. It will show up as an icon on the home screen and it will look and feel just like any other app on that device. And that’s how it will work. Thank you. So and last question, because I will have to move to the next session. How will you be able to leverage and extend on native app capabilities within this PWA context targeted at specific devices? So pretty much, I suppose that it’s about how can you use the hardware capabilities of your app in the PWA on a mobile device? Right. So in general, progressive web apps are meant to be 100% web technology oriented solution. And Google is saying that rather than leveraging these native APIs, they are increasingly bringing more and more of them to the web directly. So most of what you can do natively is now available through Web APIs itself. If you still do not have access to the native APIs, you may need to rely on solutions like Cordova to be able to give you a bridge to that native layer. So the next question I am inviting you to ask, copy paste your question in the link you got that is associated to this event so that we can be sure to answer them asynchronously. On that, I wish you great sessions following this one and great events. And see you in the next session. Have a great day. Thank you everyone for joining today. And I really appreciate your participation and your active questions. It really helps us really encourages us. Thank you very much.