Progressive Web Applications & High-Fidelity UX Prototyping

By Anthony Topper and Ryan Compton

The Various Lenses

This story is part of a series of posts.

• Introduction
• The User Story
• The Prototyping Story — this story
• The Research Story

In this post we’re going to:

• Briefly lay out one of our prototyping processes.
• Outline crafting a progressive Web app.
• Highlight guidelines for developing high-fidelity PWA prototypes.

A subtext to this piece is the belief that combining lean engineering practices, modern systems infrastructure, and design systems with progressive Web applications has the potential to be an exciting way to create new native-like digital experiences for mobile devices relatively quickly.

One goal of your initial design process should be to look to the world around you to find solutions and innovations. Then use prototyping as a means to get that into reality. Through the process of progressing a prototype to high-fidelity we gain insights. These insights are then used to determine our next iteration. This should sound a lot like an agile development method. But unlike agile development methods, which can of course be used on a “prototype”, the iterations in the method above could encompass extremely short bursts of work by a team or an individual.

These bursts of progress bring an idea closer to fruition where it can be further tested by evaluative research and then iterated some more. Hence placing prototyping as a conduit between formative and evaluative research.

The chief caveat of this process is time. It is often more costly in terms of time to produce prototypes that are close to a real solution so other means can, and probably should, be explored first. Good design systems, component-driven development, and limiting scope can be ways to accelerate the process. Formative research and low-fidelity prototypes may be explored first to insure you are aiming in the right direction. In some cases, depending on your team structure, timelines, risk tolerance, and available skill-sets, you can just start building something in code right away.

High-fidelity prototyping and progressive Web apps should seem like a natural pair. PWAs are touted as reliable, fast, and engaging. Examining Google’s definition of a PWA makes this more clear. With the philosophy of progressive enhancement ingrained early within a prototype, it should be able to have further reach to users. When considering some components of a PWA, such as being responsive, installable, and linkable, this is apparent. Additionally with having the focus of being more app-like and re-engage-able you are already considering the usability aspects of your app before getting to user testing. Getting such features as early as possible into the prototyping process propels the case that their design can be an important tenant of an experience.

Building a PWA Prototype

HTML, CSS, and JavaScript can be an appropriate medium for high-fidelity prototyping. Prototyping in the medium your user will be using has obvious benefits. Especially when dealing with relatively newer technologies. Even though the definition of a PWA carries lots of possibilities, the number of newer pieces you actually need to begin the PWA prototyping process is rather small.

This is where we get just a little technical, if that’s not for you skip down to “Guidelines”.

In addition to a core set of front-end Web technologies, we recommend starting with these two PWA-related technologies, Web app manifest and Service Worker.

Web App Manifest

The Wep app manfest is on it’s way to becoming a W3C standard. The manifest is used to define application information for the browser. This in turn allows the browser to build some necessary features of a native-like experience. Put simply, you can create a manifest.json file that contains a set of configurations.

Worth noting, neither Safari nor Chrome on iOS support these manifests. It’s officially under consideration for webkit though, which powers both of those browsers on iOS. However, some of the features of a Web app manifest are currently available in iOS by using meta tags.

What goes into manifest?

The manifest is where the Web app gets some of its native-like feel. Here are some of the configurations available:

• name
• short_name
• start_url
• scope
• display
• orientation
• theme_color
• background_color
• icons

The W3C is calling these configuration attributes “members”.

Some of these members are associated with your app’s brand: name, theme, icons. Some have usability aspects to them that should be considered. For instance, display, orientation, and scope all deal with when and what’s rendered to the screen. Use these features carefully.

The “display” member controls, generally , whether the experience is full screen or within the conventional browser. Which should have obvious navigation repercussions to be cautious about.

"display": "fullscreen"

Orientation which can, primarily, be used to control whether your PWA is locked to portrait or landscape, or not locked at all.

"orientation": "portrait"

Identifying your app’s intended interactions and what you wish to display goes along with how you decide to configure these parameters. Additionally, many tutorials don’t bring up the range of icon sizes that are appropriate. They often stop at 192 x 192, but larger sizes of 256 x 256, 384 x 384, and 512 x 512 are necessary to include for high pixel-density screens.

For the low-down on all the configurations see, The Web App Manifest.

Service Worker

Service worker is a JavaScript API. It handles some features for making the app load quickly and can even make the app work offline. It does this by giving you tools to make a more intelligent caching system than your typical mobile website. A good place to start for us was the sw-precache npm module, which handled the framework of a service worker. As well, ready to go service worker recipes are available at https://serviceworke.rs

For a service worker to work outside of when you are on your localhost, your app needs to be served over HTTPS. The browser enforces this restriction for security reasons.

What Needs to be Cached?

As we said earlier, the work of a PWA prototype can be handled mostly with traditional front-end skills. While your service worker may not need to be fleshed-out entirely in a prototype, the architecture below should inform some of your potential methods.

This is where decisions are to be made about which content needs to stay fresh and which content can remain cached. From a UX perspective, establishing an app shell makes it easier to differentiate types of content. I say, “from a UX perspective”, because an app shell is where a component-driven design system can play a very important role. It greatly affects how an offline experience would be as well.

Put another way, an app shell can hold much of the HTML, CSS, and JavaScript for the app. You can think of this bundle as the resources used within the app; therefore, it is the app shell that gets cached primarily. The shell gets stored on the client so this makes it quick to load and allows it to work offline. Users will see something being drawn to the screen quicker. Dynamic content will need to be loaded into the app shell. Even the dynamic content can be cached, so that it can be used as a fallback for the offline experience. Through service worker PWAs are blurring the line between caching and installing.

PWAs are blurring the line between caching and installing.

Simple caching strategies:

• Network Only
• Cache Only
• Cache-First then Network

To put it simply, by using network only you are saying content needs to be very timely. Whereas, by using cache-first then network you are choosing speed over the most up-to-date content. As always, keep in mind the user and what their needs are.

For more advanced caching strategies visit https://serviceworke.rs. But the basic strategies above will get you started. The library sw-precache will get you covered in setting up a service worker to handle these. And it is probably good enough for prototyping your first PWA. Just start building.

When you are ready to progress your caching strategy you might ask these questions:

• Where can I get the largest performance improvement?
• What actually needs to be up-to-date for the user?
• How important is the timeliness of this content?
• How advanced do you really need your caching strategy to be?
• Are you creating a Web app that needs to work offline?

Don’t forget, caching strategies allow for stronger performance in low bandwidth areas as well as the possibility of offline interactions. Lastly, support for service workers in all browsers is not quite there, but progress is being made; service worker is under development for webkit.

Tutorials

• A beginner’s guide to making Progressive Web Apps
• Build your first progressive web app with React
• Add Your Web App to a User’s Home Screen
• Build Your First Progressive Web Application with Angular and Spring Boot

Guidelines

Let’s bring our focus back to the user a little bit more. We’ve used PWAs to get prototypes out into the wild and tested quicker. From this we know that building a PWA can get you considering user goals during its creation.

Design Using Fluid Layouts

You might be able to say responsive design and development was the herald for progressive Web applications. PWAs focus on working across all browsers and devices and it’s a no-brainer to have responsive elements. So, think in terms of proportion not necessarily pixels. A high-fidelity responsive prototypes can be really useful in seeing what a design will look like on a myriad of different devices with different dimensions and pixel densities.

Optimize the Visual Assets

Use SVGs. SVGs can be easily resized and some aspects can even be restyled via CSS. This makes them highly flexible, which is useful when prototyping your way to figuring out the best design. Oh and the no-brainer here, keep you image sizes low. But don’t forget to think about screen pixel density.

Appropriate Fidelity

Consider things like business logic, conditional navigation, and real data. These things all make your prototypes more real, which in turn generate more trustworthy insights into your experience as you are prototyping.

Be Cautious When Migrating from a Mobile Website to a PWA

PWAs are evolving towards having the experiences of Web pages and native apps merged, to a degree. This is something that has user experience impact. You will need to account for how users flow through your experience. There are a few examples of not accounting for the navigational flow of a user that doesn’t have the OS and browser-level controls, which can cause deadlock.

Use Lighthouse

PWAs have a few good resources to check how well they are performing. Google has the Progressive Web App Checklist. However, the best tool at the moment is probably Lighthouse. Following this tool gets your app in a good place for users who have low connectivity. It also points out places where you can reduce excess bytes of data.

Consider “Add to Home Screen”

This is a crux of the PWA world in our opinion. Like we said, PWAs are blurring the line between caching and installing. “Add to Home Screen” is the install.

Having instructions about adding to home screen did create some additional work while doing user testing. To get as close as we could to the natural experience was our goal, but the technology just didn’t allow it.

In Android Chrome, there is a restriction that the user must visit the site twice with at least five minutes in between each visit before showing the “Add to Home Screen” banner. This restriction is a good decision for a live website, but when prototyping and testing it gets in the way. There is a way around this in Chrome on Android. Within chrome://flags, you can enable “Bypass user engagement checks”, which will cause banners to fire once you enter the page. This was very helpful in testing the banner while developing the app, but those instructions are a big burden on the test user if you just want feedback on a prototype. We found instructing them about the Add to Home screen option within Chrome settings to be much simpler.

In Conclusion

We could write more about prototyping PWAs. For now, we are using it for what we can and learning what we can to see where things could be going. It does seem to have some potential for crafting new user experiences. And it is evolving quickly and the technology is appearing to spread across platforms.

The Various Lenses

This story is part of a series of posts.

• Introduction
• The User Story
• The Prototyping Story — this story
• The Research Story

About the Authors

Anthony Topper

Tony has been designing and developing on the Web for over 20 years. He started out as a “webmaster”, aka full-stack developer and designer. Over the years he has touched nearly every aspect of producing for the Web, from sysadmin and database design to user-experience research and visual design. He’s now a design leader at eBay.

Ryan Compton

Ryan is a PhD student studying large-scale computer supported cooperative work. He originated within the field of psychology which lead to exploring computer science by working on citizen science and crowdsourcing technologies. He now focuses on utilizing quantitative methods to understand and improve human social and collaborative systems.