Desktop Progressive Web Apps

A note on working offline

There are plenty of discoverability, usability, and capability advantages simply by making your app installable. Making your PWA installable does not mean your whole experience must work offline. In order for an installed web app to feel like a traditional app, though, it should have some form of offline functionality. A basic custom offline page is enough to get started; users expect that installed apps don’t crash when connection status changes. Just as a traditional app never shows a blank page when it is offline, PWAs should never show the browser default offline page. Custom offline pages can range from a message letting the user know they need a connection to a game to let them pass the time until they’re connected again. Providing this custom offline experience for uncached pages or features that require a connection helps to bridge the user experience app gap.

You can create a simple offline page during a service worker’s install event by precaching the desired page for later use and responding with it if a user is offline. You can follow our custom offline page sample⁠ to see an example of this in action and learn how to implement it yourself.

If you want to provide a more robust experience, in addition to the Cache Storage API⁠, you can use features like IndexedDB⁠ for in-browser NoSQL storage and background sync⁠ to allow users to take actions while offline and defer server communication until the user has a stable connection again. You can also implement patterns like safe, long-lived sessions⁠ to keep users authenticated and skeleton screens⁠ to quickly let users know you’re loading content that can fall back to cached content or an offline indicator if needed.

Smooth drawing on the web

If you’re building an app that has users drawing with their fingers or styluses, keeping latency between their input and your output fast enough to feel fluid has historically been difficult. When building these kinds of Canvas API⁠ powered apps for ChromeOS, we recommend using the desynchronized hint for canvas.getContext() to provide low-latency rendering⁠. To use the desynchronized hint for a canvas, do the following:

const canvas = document.createElement('canvas'); // or select one from the DOM
const ctx = canvas.getContext('2d', {
  desynchronized: true,
  // Other options here…
});

if (ctx.getContextAttributes().desynchronized) {
  // Low-latency supported! Do something awesome with it.
} else {
  // Low-latency not supported! Fall back to less awesome stuff
}

Design considerations for touch

It is important to take touch and stylus support into consideration when designing your web apps. Interactions that you may take for granted, like hover, don’t work well, if at all, for other input methods. Here are some best practices to keep in mind when designing touch and stylus friendly interfaces:

• Don’t make input assumptions based on screen size. Instead, use feature detection⁠, ideally at input time, to determine how to respond. Remember, on ChromeOS, users can and do seamlessly swap between mouse, touch, and stylus all within one session.
• Ensure that elements you expect a user to touch have a minimum target size⁠ large enough so surrounding elements aren’t accidentally hit instead.
• Treat hover as progressive enhancement⁠ and ensure the interaction can be accomplished through other means for touch and stylus (a long press or a tap, for example).
• Touch users expect to be able to directly interact with on-screen elements, for instance pinch-to-zoom on maps instead of using zoom in/out buttons. Adding common touch gestures⁠, where appropriate, can go a long way to making your app feel natural.