How PWAs deliver a different user-experience when browsed than when installed
Calling a PWA a hybrid of a website and a native app falls short as a definition because it leaves the impression of an application with a single set of characteristics. That’s not exactly right.
The real magic of a PWA is that it takes on different characteristics to match the context and expectations of the audience.
In this article, I will describe the user-experience (UX) basics of PWAs and review what elements of the experience are left up to the designer. I will focus on the browser vs. standalone modes of operation and caching strategy.
Browser vs. Standalone
PWAs have two common modes of operation:
“browser-mode,” where users engage a PWA from their browser like they would a website.
“standalone-mode,” where users launch an installed PWA from an icon on their home screen as with an app.
Browser-Mode
Thanks to the browser-mode of operation, PWAs have little to no engagement friction. A user taps a link to launch a PWA from any major browser. When engaged, they experience the application with the familiar navigation controls of their browser.
Mobile
Using the Red Letter Day conference app as an example below is a PWA in browser-mode on an iOS device in the Safari browser:
This example shows the Safari URL bar with a refresh button at the top and the navigation bar, which includes the “back” and “share” buttons, at the bottom.
Sharability is a superpower that elevates PWAs above native apps. The ease with which a user can text, email, and social share a PWA is what enables PWAs to spread virally.
To speed its UX, a PWA in browser-mode leverages service workers. These are background processes that continue loading content after the initial page-load so that it will be immediately available if called.
One can set a PWA to operate only in browser-mode. It will not remain installed on the user’s phone, but will still take advantage of data caching for a speedier UX and offline operation. Offline operation means that you can launch a browsed PWA, place your device in airplane mode, and continue to navigate through its pages.
Desktop
A derivative of the browser-mode is that PWAs also serve desktop and tablet audiences. Below is a view of the Red Letter Day PWA on a desktop.
PWAs are mobile-first, so designers must implement a strategy for displaying content on a tablet or desktop. Traditional responsive design takes a desktop design and organizes it for mobile, whereas PWAs begin with content optimized for a smaller screen and then expand it to desktop.
All major browsers support PWAs. Other than managing different screen sizes, PWA operation for browser-mode is straightforward.
Standalone mode
A PWA in standalone-mode will show an install prompt that invites the user to add the app to their home screen. Below are examples:
Android devices will detect a PWA and automatically generate an install prompt. This prompt is the current Android prompt.
Apple does not generate a PWA install prompt. One has to implement an install prompt for iOS devices and decide when to display it. The prompt shown to the left is generated by the Tapps PWA platform.
In both instances, an installed PWA adds the app’s icon and short name to the home screen, as is shown below. To a user, it’s just like a native app.
Once installed, the PWA will launch from the icon, but unlike a bookmarked website, it can be opened without internet access.
The user experience will also change from the browser-mode experience. A PWA in standalone mode feels more app-like. It runs in its own window and hides the browser’s URL and navigation bars so it can use a device’s full screen.
Below is the Red Letter Day PWA when operating in standalone mode. Shown are the main page and one subpage.
Notice that this PWA does have a navigation bar, but it’s different than one from a browser because it was added by the PWA. This app omits the URL, history, and tab icons because they are not relevant to the application. The refresh, share, and back buttons have been added.
PWAs in standalone mode begin with swipe navigation, but not much else. One must implement navigation buttons, sharing, a menu, or other UI elements to a standalone PWA.
It is important to note that a browsed PWA in standalone-mode will continue to operate normally when accessed from a link. Nothing is lost from the standard browser and desktop experiences.
Caching and Offline Operation
The second major UX element to consider when building a PWA is caching. PWAs take advantage of service workers to store app-shells, applications, and content on the user’s device.
Caching is another PWA superpower that serves several different purposes. It:
Enables an installed PWA to launch immediately.
Makes a browsed PWA snappier by preloading content.
Enables offline operation of both browsed and standalone PWAs. (Even a browsed PWA will work without internet after the initial load.)
Allows a video to start immediately if the initial few seconds are cached
Stores user preferences
Stores metrics so that offline user interactions can be accurately measured.
A PWA designer must decide which elements of a PWA to cache and when to check for updates, which involves a lot of little decisions.
Caching makes content available offline, but it will also impact the PWAs initial load time. For example, it might be necessary to cache a large PDF in a conference app when one expects poor internet, whereas it might not make sense otherwise.
There is also a UX tradeoff in loading a PWA immediately from the cache or first checking for updated content before loading.
Caching Strategy
As a PWA platform provider, we must make or assist in making caching decisions for hosted PWAs. For reference, following are the approaches we take with the Tapps platform. We:
Automatically cache all main screen content and the text and images of subpages.
Allow the user to choose on a per-file basis whether or not PDFs, videos, and other file types should be cached.
Create and manage service workers for scheduling for situations such as the Red Letter Day App where selected content (i.e., survey results) only appears during a set time of the event.
Enable special handling for PDFs to allow printing and sharing, which are not supported by most browsers when in standalone mode.
Automatically cache and record offline engagement metrics. (Over a few weeks, one can track the Red Letter Day app creation, two email distributions, heavy usage during the event and residual use.)
Load a PWA immediately from the cache and then make updates if needed. This approach ensures the fastest time to engagement.
Automatically implement standalone install prompts, a share button, a refresh button, and navigation controls.
Automatically manage content updates.
Key Takeaways
All major browsers support the core functionality for the browser and standalone modes of PWA operation. However, a PWA designer must still add capabilities and make decisions if their PWA is going to deliver the best user experience for both of these audiences.
The fundamental capabilities that must be handled by a PWA designer are standalone navigation, iOS install prompts, and caching strategies. Many more capabilities can be added after the basics.
PWAs can simultaneously serve casual users that browse their content and loyal users that install the PWA for a return engagement. For both audiences, they deliver a familiar and engaging user experience, and by doing so, they expand engagement and increase conversions.