In his The Case for Progressive Web Apps presentation at An Event Apart in Chicago, Jason Grigsby walked through the process of building Progressive Web Apps for your Web experiences and how to go about it. Here's my notes from his talk:
- Progressive Web Apps (PWAs) are getting a lot of attention and positive stories about their impact are coming out.
- A PWA is a set of technologies designed to make faster, more capable Web sites. They load fast, are available online, are secure, can be accessed from your home screen, have push notifications, and more.
- But how can we define Progressive Web Apps? PWAs are Web sites enhanced by three things: https, service worker, and a manifest file.
- HTTPS is increasingly required for browsers and APIs. Eventually Chrome will highlight sites that are not on https as "insecure".
- Service Workers allow Web sites to declare how network requests and the cache are handled. This ability to cache things allows us to build sites that are much faster. With service workers we can deliver near instant and offline experiences.
- A Web manifest is a JSON file that delivers some attributes about a Web site. Browsers use these files to make decisions on what to do with your site (like add to home page).
- Are PWAs any different than well-built Web sites? Not really, but the term helps get people excited and build toward best practices on the Web.
- PWAs are often trojan horses for performance. They help enforce fast experiences.
Feels Like a Native App
- Does your organization have a Web site? Do you make money off your Web site? If so, you probably need a Progressive Web Site.
- Not every customer will have your native app installed. A better Web experience will help you reach people who don't. For many people this will be their first experience with your company, so you should make it as good as possible.
- Getting people to install and keep using native apps is difficult. App stores can also change their policies and interfaces which could negatively impact your native app.
- The Web can do much more than we think, the Web has APIs to access location, do fast payments using fingerprint identification, push notifications, and more.
- What should we use to design PWAs? Native app styles or Web styles? How much does your design match the platform? You can set up PWAs to use different system fonts for iOS and Android, should you? For now, we should define our own design and be consistent across different OSs.
- What impact does going "chrome-less" have on our PWAs? You loose back buttons, menu controls, system controls. Browsers provide us with a lot of useful features and adding them back is difficult. Especially navigation via the back button is complex. So in most cases, you should avoid going full screen.
- While not every person will add your PWA to their home screen, every person will "install" your PWA via the service worker.
- An app shell model allows you put your common UI (header, footer, nav, etc.) into the app cache. This makes the first loading experience feel a lot faster. Should you app shell or not? If you have architected as a single page app, this is possible but otherwise might not be worth the effort.
- Animating transitions can help with way-finding and polish on the Web. This gives Web sites even more personality.
Installation and Discovery
- Using a Web manifest file, allows you specify a number of declarations for your app. In addition to name, icon, and even theme colors.
- Once you have a PWA built and a manifest file, browsers will being prompting people to install your Web site. Some Browsers have subtle "add" actions. Other use more explicit banner prompts. "Add to home screen" banners are only displayed when they make sense (certain level of use).
- Developers can request these banners to come up when appropriate. You'll want to trigger these where people are mostly likely to install. (like checkout)
- Microsoft is putting (explicitly and implicitly) PWAs within their app store. Search results may also start highlighting PWAs.
- You can use Trusted Web Activity or PhoneGap to wrap native shells around your PWA to put them into Android and iOS app stores.
Offline Mode
- Your Web site would benefit from offline support. Service Workers enable you to cache assets on your device to load PWAs quickly and to decide what should be available offline.
- You can develop offline pages and/or cache pages people viewed before.
- If you do cache pages, make it clear what data hasn't been updated because it is not available offline.
- You can give people control over what gets cached and what doesn't. So they can decide what they want available for offline viewing.
- If you enable offline interactions, be explicit what interactivity is available and what isn't.
Push Notifications
- Push notifications can help you increase engagement. You can send notifications via a Web browser using PWAs.
- Personal push notifications work best but are difficult to do right. Generic notifications won't be as effective.
- Don't immediately ask people for push notification permissions. Find the right time and place to ask people to turn them on. Make sure you give people control, if you'd don't they can kill them using browser controls.
- In the next version of Chrome, Google will make push notification dialogs blocking (can't be dismissed) so people have to decide if they want notifications on or off. This also requires you to ask for permissions at the right time.
Beyond Progressive Web Apps
- Auto-login with credential management APIs allows you to sign into a site using stored credentials. This streamlines the login process.
- Apple Pay on the Web converged with the Web Payment API so there's one way to use stored payment info on the Web.
- These next gen capabilities are not part of PWAs but make sense within PWAs.
How to Implement PWAs
- Building PWAs is a progressive process, it can be a series of incremental updates that all make sense on their own. As a result, you can have an iterative roadmap.
- Benchmark and measure your improvements so you can use that data to get buy-in for further projects.
- Assess your current Web site's technology. If things aren't reasonably fast to begin with, you need to address that first. If your site is not usable on mobile, start there first.
- Begin by building a baseline PWA (manifest, https, etc.) and then add front-end additions and larger initiatives like payment request and credential api later.
- Every step on the path toward a PWAS make sense on their own. You should encrypt your Web sites. You should make your Web site fast. These are all just steps along the way.