Mustafa Kurtuldu on web.dev

Patterns for promoting PWA installation

2019-06-04T00:00:00Z

Installing your Progressive Web App (PWA) can make it easier for users to find and use. Even with browser promotion, some users don't realize that they can install a PWA, so it can be helpful to provide an in-app experience that you can use to promote and enable installation of your PWA.

A simple install button provided within your PWA.

This article is by no means exhaustive, but offers a starting point for different ways to promote the installation of your PWA. Regardless of which pattern, or patterns you use, they all lead to the same code that triggers the install flow, documented in How to provide your own in-app install experience.

Best practices #

There are some best practices that apply no matter which promotional patterns you're using on your site.

Keep promotions outside of the flow of your user journeys. For example, in a PWA login page, put the call to action below the login form and submit button. Disruptive use of promotional patterns reduces the usability of your PWA and negatively impacts your engagement metrics.
Include the ability to dismiss or decline the promotion. Remember the user's preference if they do this and only re-prompt if there's a change in the user's relationship with your content such as if they signed in or completed a purchase.
Combine techniques in different parts of your PWA, but be careful not to overwhelm or annoy your user with install promotion.
Only show the promotion after the beforeinstallprompt event has fired.

Automatic browser promotion #

When certain criteria are met, most browsers automatically indicate to the user that your Progressive Web App is installable. For example, desktop Chrome shows an install button in the omnibox.

Browser-provided install promotion (mobile).

Chrome for Android shows a mini infobar to the user, though this can be prevented by calling preventDefault() on the beforeinstallprompt event. If you do not call preventDefault(), the banner will be shown the first time a user visits your site and meets the installability criteria on Android, and then again after approximately 90 days.

User interface promotional patterns #

User interface promotional patterns can be used for almost any kind of PWA and appear in places such as site navigation and banners. As with any other type of promotional pattern, it's important to be aware of the user's context to minimize disruption of the user's journey.

Sites which are thoughtful about when they trigger promotion UI achieve a larger number of installs and avoid interfering with the journeys of users who aren't interested in installation.

Simple install button #

The simplest possible UX is to include an 'Install' or 'Get app' button at an appropriate location in your web content. Ensure the button doesn't block other important functionality and is out of the way of the user's journey through your application.

Simple install button.

This is an install button that is part of the header of your site. Other header content often includes site branding such as a logo and the hamburger menu. Headers may be position:fixed or not depending on your site's functionality and user needs.

Custom install button in header.

When used appropriately, promoting PWA installation from the header of your site is a great way to make it easier for your most loyal customers to return to your experience. Pixels in your PWA header are precious, so make sure your installation call to action is appropriately sized, of greater importance than other possible header content, and unintrusive.

Custom install button in header

Make sure you:

Do not show the install button unless the beforeinstallprompt has been fired.
Evaluate the value of your installed use case for your users. Consider selective targeting to only present your promotion for users that are likely to benefit from it.
Use precious header space efficiently. Consider what else would be helpful to offer your user in the header, and weigh the priority of the install promotion relative to other options.

Navigation menu #

Add an install button/promotion in a slide out navigation menu.

The navigation menu is a great place for promoting the installation of your app since users who open the menu are signaling engagement with your experience.

Make sure you:

Avoid disrupting important navigational content. Put the PWA install promotion below other menu items.
Offer a short, relevant pitch for why the user would benefit from installing your PWA.

Landing page #

The purpose of a landing page is to promote your products and services, so this is one place where it is appropriate to go large when promoting the benefits of installing your PWA.

Custom install prompt on a landing page.

First, explain your site's value proposition, then let visitors know what they'll get from installation.

Make sure you:

Appeal to features that matter most to your visitors and emphasize keywords that might have brought them to your landing page.
Make your install promotion and call to action eye catching, but only after you've made your value proposition clear. This is your landing page, after all.
Consider adding an install promotion in the part of your app where users spend most of their time.

Most users have encountered installation banners in mobile experiences and are familiar with the interactions offered by a banner. Banners should be used carefully because they can disrupt the user.

A dismissible banner at the top of the page.

Make sure you:

Wait until the user has demonstrated interest in your site before showing a banner. If the user dismisses your banner, don't show it again unless the user triggers a conversion event that indicates a higher level of engagement with your content such as a purchase on an e‑commerce site or signing up for an account.
Provide a brief explanation of the value of installing your PWA in the banner. For example, you can differentiate the install of a PWA from an iOS/Android app by mentioning that it uses almost no storage on the user's device or that it will install instantly without a store redirect.

Temporary UI #

Temporary UI, such as the Snackbar design pattern, notifies the user, and allows them to easily complete an action, in this case, installing the app. When used properly, these kinds of UI patterns don't interrupt the user flow, and are typically automatically dismissed if ignored by the user.

A dismissible snackbar indicating the PWA is installable.

Show the snackbar after a few interactions with your app. If it appears on page load, or out of context, it can be easily missed, or lead to cognitive overload. When this happens, users will simply dismiss everything they see. Remember, new users to your site may not be ready to install your PWA. Therefore, it's best to wait until you have strong interest signals from the user before using this pattern, for example, repeat visits, a user sign in, or similar conversion event.

A dismissible snackbar indicating the PWA is installable.

Make sure you:

Show the snackbar for between 4 and 7 seconds to give users enough time to see and react to it, and without getting in the way.
Avoid showing it over other temporary UI such as banners, etc.
Wait until you have strong interest signals from the user before using this pattern, for example, repeat visits, a user sign in, or similar conversion event.

After conversion #

Immediately after a user conversion event, for example after a purchase on an e‑commerce site, is an excellent opportunity to promote the installation of your PWA. The user is clearly engaged with your content, and a conversion often signals that the user will engage with your services again.

An install promotion after a user has completed a purchase.

Booking or checkout journey #

Show an install promotion during or after a sequential journey such as after booking or checkout flows. If you're displaying the promotion after the user has completed the journey, you can often make it more prominent since the journey is completed.

An install promotion after a user journey.

Make sure you:

Include a relevant call to action. Which users will benefit from installing your app and why? How is it relevant to the journey they are currently on?
If your brand has unique offers for installed app users, mention them.
Keep the promotion out of the way of next steps in your journey or you can negatively affect journey completion rates. In the e‑commerce example above, notice how the key call to action to checkout is above the app install promotion.

This promotion is a special case of the journey promotional pattern where the promotion card can be more prominent.

A custom install button on the sign up page.

These pages are usually only viewed by engaged users, where the value proposition of your PWA has already been established. There's also often not a lot of other useful content to place on these pages. As a result, it's less disruptive to make a larger call-to-action as long as it's not in the way.

Make sure you:

Avoid disrupting the user's journey inside the sign up form. If it's a multi-step process, you might want to wait until the user has completed the journey.
Promote features most relevant to a signed-up user.
Consider adding an additional install promotion within the signed-in areas of your app.

Inline promotional patterns #

Inline promotional techniques interweave promotions with site content. This is often more subtle than promotion in the user interface, which has tradeoffs. You want your promotion to stand out enough that interested users will notice it, but not so much that it detracts from the quality of your user experience.

In-feed #

An in-feed install promotion appears between news articles or other lists of information cards in your PWA.

An install promotion within a content feed.

Your goal is to show users how to access the content they're enjoying more conveniently. Focus on promoting features and functionality that will be helpful to your users.

Make sure you:

Limit the frequency of the promotions to avoid annoying users.
Give your users the ability to dismiss the promotions.
Remember your user's choice to dismiss.

Introduction to variable fonts on the web

2018-02-19T00:00:00Z

In this article, we will look at what variable fonts are, the benefits they offer, and how we can use them in our work. First, let's review how typography works on the web, and what innovations variable fonts bring.

Browser compatibility #

As of May 2020 variable fonts are supported in most browsers. See Can I use variable fonts? and Fallbacks.

Introduction #

The terms font and typeface are often used interchangeably by developers. However there is a difference: A typeface is the underlying visual design that can exist in many different typesetting technologies, and a font is one of these implementations, in a digital file format. In other words, a typeface is what you see, and the font is what you use.

Another concept that is often overlooked is the distinction between a style, and a family. A style is a single and specific typeface, such as Bold Italic, and a family is the complete set of styles.

Before variable fonts, each style was implemented as a separate font file. With variable fonts, all styles can be contained in a single file.

Left: a specimen of the Roboto typeface family. Right: named styles within the family.

Challenges for the designer and developer #

When a designer creates a print project they face some constraints, such as the physical size of the page layout, the number of colors they can use (which is determined by the kind of printing press that will be used), and so on. But they can use as many typeface styles as they like. This means that the typography of print media is often rich and sophisticated, so that the reading experience is truly delightful. Think of the last time you enjoyed browsing an excellent magazine.

Web designers and developers have different constraints than print designers, and an important one is the associated bandwidth costs of our designs. This has been a sticking point for richer typographic experiences, as they come at a cost. With traditional web fonts, each style used in our designs requires users to download a separate font file, which increases latency and page rendering time. Only including the Regular and Bold styles, plus their italic counterparts, can amount to 500 KB or more of font data. This is even before we have dealt with how the fonts are rendered, the fallback patterns we need to use, or undesirable side-effects such as FOIT and FOUT.

Many font families offer a much wider range of styles, from Thin to Black weights, narrow and wide widths, a variety of stylistic details, and even size-specific designs (optimized for large or small text sizes.) Since you'd have to load a new font file for every style (or combinations of styles), many web developers choose not to use these capabilities, reducing the reading experience of their users.

Anatomy of a variable font #

Variable fonts address these challenges, by packing styles into a single file.

This works by starting with a central or 'default' style, usually the 'Regular'–an upright roman design with the most typical weight and width that is most suitable for plain text. This is then connected to other styles in a continuous range, called an 'axis.' The most common axis is Weight, which can connect the default style through to a Bold style. Any individual style can be located along an axis, and is called an 'instance' of the variable font. Some instances are named by the font developer, for example Weight axis location 600 is called SemiBold.

The variable font Roboto Flex has three styles for its Weight axis. The Regular style is at the center, and there are two styles at the opposite ends of the axis, one lighter and the other heavier. Between these, you can choose from 900 instances:

Above: Illustrated anatomy of the Weight axis for the typeface Roboto.

The font developer can offer a set of different axes. You can combine them because they all share the same default styles. Roboto has three styles in a Width axis: the Regular is at the center of the axis, and two styles, narrower and wider, are at each end. These provide all the widths of the Regular style, and combine with the Weight axis to provide all the widths for every weight.

Roboto Flex in random combinations of Width and Weight

This means there are thousands of styles! This may seem like massive overkill, but the quality of the reading experience can be remarkably enhanced by this diversity of type styles. And, if it is without performance penalty, web developers can use a few or as many styles as they wish–it's up to their design.

Italics #

The way that Italics are handled in variable fonts is interesting, as there are two difference approaches. Typefaces like Helvetica or Roboto have interpolation compatible contours, so their Roman and Italic styles can be interpolated between and the Slant axis can be used to get from Roman to Italic.

Other typefaces (such as Garamond, Baskerville, or Bodoni) have Roman and Italic glyph contours that are not interpolation compatible. For example, the contours that typically define a Roman lowercase "n" do not match the contours used to define an Italic lowercase "n". Instead of interpolating one contour to the other, the Italic axis toggles from Roman to Italic contours.

Amstelvar's "n" contours in Italic (12 point, regular weight, normal width), and in Roman. Image supplied by David Berlow, type designer and typographer at Font Bureau.

After the switch to Italic, the axes available to the user should be the same as those for the Roman, just as the character set should be the same.

A glyph substitution capability can also be seen for individual glyphs, and used anywhere in the design space of a variable font. For example, a dollar sign design with two vertical bars works best at larger point sizes, but at smaller point sizes a design with only one bar is better. When we have fewer pixels for rendering the glyph, a two bar design can become illegible. To combat this, much like the Italic axis, a glyph substitution of one glyph for another can occur along the Optical Size axis at a point decided by the type designer.

In summary, where the contours allow for it, type designers can create fonts that interpolate between various styles in a multi-dimensional design space. This gives you granular control over your typography, and a great deal of power.

Axes definitions #

There are five registered axes, which control known, predictable features of the font: weight, width, optical size, slant and italics. Besides those, a font can contain custom axes. These can control any design aspect of the font the type designer wishes: the size of serifs, the length of swashes, the height of ascenders or the size of the dot on the i.

Even though axes can control the same feature, they might use different values. For example, in the Oswald and Hepta Slab variable fonts there is only one axis available, Weight, but the ranges are different–Oswald has the same range as before it was upgraded to be variable, 200 to 700, but Hepta Slab has an extreme hairline weight at 1 that goes all the up to 900.

The five registered axes have 4-character lowercase tags that are used to set their values in CSS:

Axis names and CSS values
Weight	`wght`
Width	`wdth`
Slant	`slnt`
Optical Size	`opsz`
Italics	`ital`

Since the font developer defines which axes are available in a variable font, and which values they can have, it is essential to find out what each font offers. The font's documentation should provide this, or you can inspect the font using a tool like Wakamai Fondue.

Use cases and benefits #

Setting the axes values comes down to personal taste and applying typographic best practices. The danger with any new technology is possible misuse, and settings that are overly artistic or exploratory could also decrease legibility of the actual text. For titles, exploring different axes to create great artistic designs are exciting, but for body copy this risks making the text illegible.

Exciting expression #

One great example of artistic expression is shown above, an exploration of the typeface Decovar by Mandy Michael.

You can view the working example and source code for the above sample here.

Animation #

Typeface Zycon, designed for animation by David Berlow, type designer and typographer at Font Bureau.

There is also a possibility to explore animating characters with variable fonts. Above is an example of different axes being used with the typeface Zycon. See the live animation example on Axis Praxis.

Anicons is the world's first animated color icon font, based on Material Design Icons. Anicons is an experiment that combines two cutting edge font technologies: variable fonts and color fonts.

A few examples of hover animations from Anicon's color icon font

Finesse #

Amstelvar using little bits of XTRA in opposite directions so the words' widths are evened out

Roboto Flex and Amstelvar offer a set of "Parametric Axes." In these axes, the letters are deconstructed into 4 fundamental aspects of form: black or positive shapes, white or negative shapes, and the x and y dimensions. In the same way that primary colors can be blended with any other color to adjust it, these 4 aspects can be used to fine tune any other axis.

The XTRA axis in Amstelvar allows you to adjust the "white" per mille value, as shown above. Using little bits of XTRA in opposite directions, the words' widths are evened out.

Variable fonts in CSS #

Loading variable font files #

Variable fonts are loaded though the same @font-face mechanism as traditional static web fonts, but with two new enhancements:

@font-face {
	font-family: 'Roboto Flex';
	src: url('RobotoFlex-VF.woff2') format('woff2') tech('variations'),
	     url('RobotoFlex-VF.woff2') format('woff2-variations');
	font-weight: 100 1000;
	font-stretch: 25% 151%;
}

1. Source Formats: We don't want the browser to download the font if it doesn't support variable fonts, so we add format and tech descriptions: once in the future syntax (format('woff2') tech('variations')), once in the deprecated but supported among browsers syntax (format('woff2-variations')). If the browser supports variable fonts and supports the upcoming syntax, it will use the first declaration. If it supports variable fonts and the current syntax, it will use the second declaration. They both point to the same font file.

2. Style Ranges: You'll notice we're supplying two values for font-weight and font-stretch. Instead of telling the browser which specific weight this font provides (for example font-weight: 500;), we now give it the range of weights supported by the font. For Roboto Flex, the Weight axis ranges from 100 to 1000, and CSS directly maps the axis range to the font-weight style property. By specifying the range in @font-face, any value outside this range will be "capped" to the nearest valid value. The Width axis range is mapped in the same way to the font-stretch property.

If you're using the Google Fonts API, this will all be taken care of. Not only will the CSS contain the proper source formats and ranges, Google Fonts will also send static fallback fonts in case variable fonts aren't supported.

Using weights and widths #

Currently, the axes you can reliably set from CSS are the wght axis through font-weight, and the wdth axis through font-stretch.

Traditionally, you would set font-weight as a keyword (light, bold) or as a numerical value between 100 and 900, in steps of 100. With variable fonts, you can set any value within the font's Width range:

.kinda-light {
  font-weight: 125;
}

.super-heavy {
  font-weight: 1000;
}

Roboto Flex' Weight axis being changed from its minimum to its maximum.

Likewise, we can set font-stretch with keywords (condensed, ultra-expanded) or with percentage values:

.kinda-narrow {
  font-stretch: 33.3%;
}

.super-wide {
  font-stretch: 151%;
}

Roboto Flex' Width axis being changed from its minimum to its maximum.

Using italics and obliques #

The ital axis is intended for fonts that contain both a regular style, and an italic style. The axis is meant to be an on/off switch: value 0 is off and will show the regular style, value 1 will show the italics. Unlike other axes, there's no transition. A value of 0.5 won't give you "half italics".

The slnt axis is different from italics in that it's not a new style, but just slants the regular style. By default its value is 0, which means the default upright letter shapes. Roboto Flex has a maximum slant of -10 degrees, meaning the letters will lean to the right when going from 0 to -10.

It would be intuitive to set these axis through the font-style property, but as of April 2020, how to exactly do this is still being worked out. So for now, you should treat these as custom axes, and set them through font-variation-settings:

i, em, .italic {
	/* Should be font-style: italic; */
	font-variation-settings: 'ital' 1;
}

.slanted {
	/* Should be font-style: oblique 10deg; */
	font-variation-settings: 'slnt' 10;
}

Roboto Flex' Slant axis being changed from its minimum to its maximum.

Using optical sizes #

A typeface can be rendered very small (a 12px footnote) or very large (a 80px headline). Fonts can respond to these size changes by changing its letter shapes to better suit its size. A small size might be better off without fine details, while a large size might benefit from more details and thinner strokes.

The letter 'a' in Roboto Flex at different pixel sizes, then scaled to be the same size, shows the differences in design. Try it yourself on Codepen

A new CSS property has been introduced for this axis: font-optical-sizing. By default it's set to auto, which makes the browser set the axis value based on the font-size. This means the browser will pick the best optical size automatically, but if you wish to turn this off you can set font-optical-sizing to none.

You can also set a custom value for the opsz axis, if you deliberately want an optical size that doesn't match the font size. The following CSS would cause text to be displayed at a large size, but at an optical size as if it were printed in 8pt:

.small-yet-large {
  font-size: 100px;
  font-variation-settings: 'opsz' 8;
}

Using custom axes #

Unlike registered axes, custom axes will not be mapped to an existing CSS property, so you will always have to set them through font-variation-settings. Tags for custom axes are always in uppercase, to distinguish them from registered axes.

Roboto Flex offers a few custom axes, and the most important is Grade (GRAD). A Grade axis is interesting as it changes the weight of the font without changing the widths, so line breaks do not change. By playing with a Grade axis, you can avoid being forced to fiddle with changes to Weight axis that affects the overall width, and then changes to the Width axis that affect the overall weight.

Roboto Flex' Grade axis being changed from its minimum to its maximum.

As GRAD is a custom axis, with a range of -200 to 150 in Roboto Flex. We need to address it with font-variation-settings:

.grade-light {
	font-variation-settings: `GRAD` -200;
}

.grade-normal {
	font-variation-settings: `GRAD` 0;
}

.grade-heavy {
	font-variation-settings: `GRAD` 150;
}

Variable fonts on Google Fonts #

Google Fonts has expanded their catalog with variable fonts, and adding new ones regularly. The interface is currently aimed at picking single instances from the font: you select the variation you want, click "Select this style", and it will be added to the <link> element that fetches the CSS and fonts from Google Fonts.

To use all the available axes, or ranges of values, you will have to manually compose the URL to the Google Fonts API. The variable fonts overview lists all axes and values.

The Google Variable Fonts Links tool can also give you the latest URLs for the full variable fonts.

Font-variation-settings inheritance #

While all registered axes will soon be supported through existing CSS properties, for the time being you might need to rely on font-variation-settings as a fallback. And if your font has custom axes, you'll need font-variation-settings too.

However, here's a little gotcha with font-variation-settings. Every property you don't explicitly set will automatically be reset to its default. Previously set values aren't inherited! This means the following will not work as expected:

<span class="slanted grade-light">
	I should be slanted and have a light grade
</span>

First the browser will apply font-variation-settings: 'slnt' 10 from the .slanted class. Then it will apply font-variation-settings: 'GRAD' -200 from the .grade-light class. But this will reset the slnt back to its default of 0! The result will be text in a light grade, but not slanted.

Luckily, we can work around this by using CSS variables:

/* Set the default values */
:root {
	--slnt: 0;
	--GRAD: 0;
}

/* Change value for these elements and their children */
.slanted {
	--slnt: 10;
}

.grade-light {
	--GRAD: -200;
}

.grade-normal {
	--GRAD: 0;
}

.grade-heavy {
	--GRAD: 150;
}

/* Apply whatever value is kept in the CSS variables */
.slanted,
.grade-light,
.grade-normal,
.grade-heavy {
	font-variation-settings: 'slnt' var(--slnt), 'GRAD' var(--GRAD);
}

CSS variables will cascade, so if an element (or one of its parents) will have set the slnt to 10, it will keep that value, even if you set GRAD to something else. See Fixing variable font inheritance for an in-depth explanation of this technique.

Note that animating CSS variables doesn't work (by design), so something like this doesn't work:

@keyframes width-animation {
   from { --wdth: 25; }
   to   { --wdth: 151; }
}

These animations will have to happen directly on font-variation-settings.

Performance gains #

OpenType variable fonts allow us to store multiple variations of a type family into a single font file. Monotype ran an experiment by combining 12 input fonts to generate eight weights, across three widths, across both the Italic and Roman styles. Storing 48 individual fonts in a single variable font file meant a 88% reduction in file size.

However, if you are using a single font such as Roboto Regular and nothing else, you might not see a net gain in font size if you were to switch to a variable font with many axes. As always, it depends on your use-case.

On the flip side, animating the font between settings may cause performance issues. Although this will improve once variable font support in browsers gets more mature, the problem can be reduced somewhat by only animating fonts that are currently on screen. This handy snippet by Dinamo pauses animations in elements with the class vf-animation, when they're not on screen:

var observer = new IntersectionObserver(function(entries, observer) {
  entries.forEach(function(entry) {
    // Pause/Play the animation
    if (entry.isIntersecting) entry.target.style.animationPlayState = "running"
    else entry.target.style.animationPlayState = "paused"
  });
});

var variableTexts = document.querySelectorAll(".vf-animation");
variableTexts.forEach(function(el) { observer.observe(el); });

If your font responds to user interaction, it's a good idea to throttle or debounce input events. This will prevent the browser from rendering instances of the variable font that changed so little from the previous instance the human eye wouldn't see the difference.

If you're using Google Fonts, it's a good idea to preconnect to https://fonts.gstatic.com, the domain where Google's fonts are hosted. This will make sure the browser knows early on where to get the fonts when it comes across them in the CSS:

<link rel="preconnect" href="https://fonts.gstatic.com" />

This tip works for other CDNs as well: the sooner you let the browser set up a network connection, the sooner it can download your fonts.

Find more performance tips for loading Google Fonts in The Fastest Google Fonts.

Fallbacks and browser support #

All modern browsers support variable fonts. In case you need to support older browsers, you can choose to build your site with static fonts, and use variable fonts as progressive enhancement:

/* Set up Roboto for old browsers, only regular + bold */
@supports not (font-variation-settings: normal) {
  @font-face {
    font-family: Roboto;
    src: url('Roboto-Regular.woff2');
    font-weight: normal;
  }

  @font-face {
    font-family: Roboto;
    src: url('Roboto-Bold.woff2');
    font-weight: bold;
  }

  body {
    font-family: Roboto;
  }

  .super-bold {
    font-weight: bold;
  }
}

/* Set up Roboto for modern browsers, all weights */
@supports (font-variation-settings: normal) {
  @font-face {
    font-family: 'Roboto';
    src: url('RobotoFlex-VF.woff2') format('woff2') tech('variations'),
         url('RobotoFlex-VF.woff2') format('woff2-variations');
    font-weight: 100 1000;
    font-stretch: 25% 151%;
  }

  .super-bold {
    font-weight: 1000;
  }
}

For older browsers, text with the class .super-bold will get rendered in the normal bold, as that's the only bold font we have available. When variable fonts are supported, we can actually use the heaviest weight of 1000.

The @supports rule is not supported by Internet Explorer, so this browser would not show any styling. If this is a problem, you could always use one of the oldschool hacks to target relevant older browsers.

If you are using the Google Fonts API, it will take care of loading the proper fonts for your visitor's browsers. Say you request the font Oswald in weight range 200 to 700, like so:

<link href="https://fonts.googleapis.com/css2?family=Oswald:wght@200..700&display=swap" rel="stylesheet">

Modern browsers that can handle variable fonts will get the variable font, and will have every weight between 200 and 700 available. Older browsers will get served individual static fonts for every weight. In this case, this means they'll download 6 font files: one for weight 200, one for weight 300, and so on.

Thanks #

This article would have only been made possible with the help of the following people:

Mustafa Kurtuldu, UX designer and design advocate at Google
Roel Nieskens, UX designer/developer and typography expert at Kabisa
Dave Crossland, Program Manager, Google Fonts
David Berlow, type designer and typographer at Font Bureau
Laurence Penney, developer of axis-praxis.org
Mandy Michael, developer of variablefonts.dev

Hero image by Bruno Martins on Unsplash.

Offline UX design guidelines

2016-11-10T00:00:00Z

This article provides design guidelines on how to create a great experience on both slow networks and offline.

The quality of a network connection can be affected by a number of factors such as:

Poor coverage of a provider.
Extreme weather conditions.
Power outages.
Entering into permanent "dead zones" such as in buildings with walls that block network connections.
Entering into temporary "dead zones" such as when traveling on a train and going through a tunnel.
Time-boxed internet connections such as those in airports or hotels.
Cultural practices that require limited or no internet access at specific times or days.

Your goal is to provide a good experience that lessens the impact of changes in connectivity.

Decide what to show your users when they have a bad network connection #

The first question that must be asked is what does success and failure of a network connection look like? A successful connection is your app's normal online experience. The failure of a connection, however, can be both the offline state of your app as well how the app behaves when there is a laggy network.

When thinking about the success or failure of a network connection you need to ask yourself these important UX questions:

How long do you wait to determine the success or failure of a connection?
What can you do while success or failure is being determined?
What should you do in the event of failure?
How do you inform the user of the above?

Inform users of their current state and change of state #

Inform the user of both the actions they can still take when they have a network failure and the current state of the application. For example, a notification could say:

You seem to have a bad network connection. Not to worry! Messages will be sent when the network is restored.

Clearly inform the user when a change in state occurs as soon as possible.

The Google I/O app used a "toast" to let the user know when they were offline.

Inform users when the network connection improves or is restored #

How you inform the user that their network connection has improved depends on your application. Apps such as a stock market app that prioritize current information should auto-update and notify the user as soon as possible.

It is recommended that you let the user know that your web app has been updated "in the background" by using a visual cue such as, for example, a material design toast element. This involves detecting both the the presence of a service worker and an update to its managed content. You can see a code example of this function at work here.

One example of this would be Chrome Platform Status which posts a note to the user when the app has been updated.

Some apps, such as the weather app, need to auto-update because old data is not useful.

Apps such as Chrome Status let the user know when content has been updated via a toast.

You may also show the last time the app was updated at all times in a prominent space. This would be useful for a currency converter app, for example.

Material Money caches rates…

…and notifies the user when the app has been updated.

Applications such as news apps could show a simple tap-to-update notification informing the user of new content. Auto-updating would cause users to lose their place.

Tailpiece, an online newspaper, will auto-download the latest news…

…but allow users to refresh manually so they do not lose their place in an article.

Update the UI to reflect the current contextual state #

Each bit of UI may have its own context and functionality that will change depending on if it requires a successful connection. One example would be an e‑commerce site that can be browsed offline. The Buy button and pricing would be disabled until a connection is reestablished.

Other forms of contextual states could include data. For example, the financial application Robinhood allows users to buy stock and uses color and graphics to notify the user when the market is open. The whole interface turns white and then grays out when the market closes. When the value of stock increases or decreases, each individual stock widget turns green or red depending on its state.

Educate the user so they understand what the offline model is #

Offline is a new mental model for everyone. You need to educate your users about what changes will occur when they don't have a connection. Inform them of where large data is saved and give them settings to change the default behavior. Make sure you use multiple UI design components such as informative language, icons, notifications, color, and imagery to convey these ideas collectively rather than relying on a single design choice, such as an icon on its own, to tell the whole story.

Provide an offline experience by default #

If your app doesn't require much data, then cache that data by default. Users can become increasingly frustrated if they can only access their data with a network connection. Try to make the experience as stable as possible. An unstable connection will make your app feel untrustworthy, where an app that lessens the impact of a network failure will feel magical to the user.

News sites could benefit from auto-downloading and auto-saving the latest news so a user could read today's news without a connection, perhaps downloading the text without the article images. Also, adapt to the user's behavior. For example, if the sports section is what they typically view, make that the priority download.

If the device is offline, Tailpiece will notify the user with a status message…

…letting them know that they can at least partially still use the app.

Inform the user when the app is ready for offline consumption #

When a web app first loads you need to indicate to the user if it is ready for offline use. Do this with a widget that provides brief feedback about an operation through a message at the bottom of the screen such as, for example, when a section has been synced or a data file has downloaded.

Again think of the language you are using to make sure it is fit for your audience. Ensure the messaging is the same in all instances where it's used. The term offline is generally misunderstood by a non-technical audience so use action-based language that your audience can relate to.

The Google I/O 2016 app notified the user when the app is ready for offline use…

…and so does the Chrome Platform Status site, which includes information about the occupied storage.

Make 'save for offline' an obvious part of the interface for data-heavy apps #

If an application uses large amounts of data, make sure that there is a switch or pin to add an item for offline use rather than auto-downloading, unless a user has specifically asked for this behavior via a settings menu. Make sure that the pin or download UI is not obscured by other UI elements and that the feature is obvious to the user.

One example would be a music player that requires large data files. The user is aware of the associated data cost, but may also want to use the player offline. Downloading music for later use requires the user to plan ahead, so education about this may be required during onboarding.

Clarify what is available offline #

Be clear as to the option you are providing. You may need to show a tab or setting that shows an "offline library" or content index, so the user can easily see what they have stored on their phone and what needs to be saved. Make sure the settings are concise and be clear where the data will be stored and who has access to it.

Show the actual cost of an action #

Many users equate offline capability with 'downloading'. Users in countries where network connections regularly fail or aren't available often share content with other users, or save content for offline use when they have connectivity.

Users on data plans may avoid downloading large files for fear of cost, so you may also want to display an associated cost so users can make an active comparison for a specific file or task. For example, if the music app above could detect if the user is on a data plan and show the file size so that users can see the cost of a file.

Help prevent hacked experiences #

Often users hack an experience without realizing they are doing it. For example before cloud-based file sharing web apps, it was common for users to save large files and attach them to emails so they could carry on editing from a different device. It is important not to be pulled into their hacked experience but rather look at what they are trying to achieve. In other words instead of thinking of how you can make attaching a large file more user-friendly, solve the problem of sharing large files across multiple devices.

Make experiences transferable from one device to another #

When building for flaky networks, try to sync as soon as the connection improves so that the experience is transferable. For example, imagine a travel app losing a network connection mid-way through a booking. When the connection is reestablished, the app syncs with the user's account allowing them to continue their booking on their desktop device. Not being able to transfer experiences can be incredibly jarring to users.

Inform the user of the current state of their data. For example, you could show whether the app has synced. Educate them where possible but try not to overburden them with messaging.

Create inclusive design experiences #

When designing seek to be inclusive by providing meaningful design devices, simple language, standard iconography, and meaningful imagery that will guide the user to complete the action or task rather than hinder their progress.

Use simple, concise language #

Good UX is not just about a well designed interface. It includes the path a user takes as well as the words used in the app. Avoid tech jargon when explaining the state of the app or individual UI components. Consider that the phrase "app offline" might not convey to the user the current state of the app.

Don't

Avoid terms that aren't intelligible to non-technical users.

Use language and imagery that describe the action.

Use multiple design devices to create accessible user experiences #

Use language, color, and visual components to demonstrate a change of state or current status. Solely using color to demonstrate state may not be noticed by the user and may be inaccessible to users with visual disabilities. Also, the instinct for designers is to use grayed UI to represent offline, but this can have a loaded meaning on the web. Grayed UI such as input elements on a form also means that an element is disabled. This can cause confusion if you only use color to depict state.

To prevent misunderstandings, express different states to the user in multiple ways, for example with color, labels, and UI components.

Don't

Avoid using color as the sole means to describe what is happening.

Use a mixture of design elements to convey meaning.

Use icons that convey meaning #

Make sure that information is conveyed correctly with meaningful text labels as well as icons. Icons alone can be problematic, since the concept of offline on the web is relatively new. Users may misunderstand icons used on their own. For example, using a floppy disc for save makes sense to an older generation but young users who have never seen a floppy disc may be confused by the metaphor. Likewise, the 'hamburger' menu icon has been known to confuse users when presented without a label.

When introducing an offline icon try to remain consistent with industry standard visuals (when they exist) as well as providing a text label and description. For example, saving for offline might be a typical download icon or perhaps if the action involves syncing it could be a syncing icon. Some actions may be interpreted as saving for offline rather than demonstrating a network's status. Think of the action you are trying to convey rather than presenting the user with an abstract concept. For example, save or download data would be action-based.

Offline can mean a number of things depending on the context, such as download, export, pin, etc. For more inspiration checkout the Material Design icon set.

Use skeleton layouts with other feedback mechanisms #

A skeleton layout is essentially a wireframe version of your app that displays while content is being loaded. This helps demonstrate to the user that content is about to be loaded. Consider also using a preloader UI as well, with a text label informing the user that the app is loading. One example would be to pulsate the wireframe content giving the app the feeling that it is alive and loading. This reassures the user that something is happening and helps prevent resubmissions or refreshes of your app.

A skeleton placeholder layout is shown during the download of the article…

…that gets replaced with the real contents once the download finishes.

Don't block content #

In some applications, a user might trigger an action such as creating a new document. Some apps will try to connect to a server in order to sync the new document and to demonstrate this they display an intrusive loading modal dialog that covers the entire screen. This may work fine if the user has a stable network connection, but if the network is unstable they won't be able to escape from this action and the UI effectively blocks them from doing anything else. Network requests that block content should be avoided. Allow the user to continue to browse your app and queue tasks that will be performed and synced once the connection has improved.

Demonstrate the state of an action by providing your users with feedback. For example, if a user is editing a doc, consider changing the feedback design so it is visibly different from when they are online but still shows that their file was "saved" and will sync when they have a network connection. This will educate the user about the different states available and reassure them that their task or action has been stored. This has the added benefit of the user growing more confident using your application.

Design for the next billion #

In many regions, low-end devices are commonplace, connectivity is unreliable and, for many users, data is unaffordable. You will need to earn user trust by being transparent and frugal with data. Think about ways to help users on poor connections and simplify the interface to help speed up tasks. Always try to ask users before downloading data-heavy content.

Offer low bandwidth options for users on laggy connections. So if the network connection is slow, provide small assets. Offer an option to choose high or low quality assets.

Conclusion #

Education is key to offline UX as users are unfamiliar with these concepts. Try to create associations with things that are familiar, e.g downloading for later use is the same as offlining data.

When designing for unstable network connections, remember these guidelines:

Design for the success, failure, and instability of a network connection.
Data may be expensive, so be considerate to the user.
For most users globally, the tech environment is almost exclusively mobile.
Low-end devices are commonplace, with limited storage, memory, and processing power, and small displays and lower touchscreen quality. Make sure performance is a part of your design process.
Allow users to browse your application when they are offline.
Inform users of their current state and of changes in states.
Try to provide offline by default if your app doesn't require much data.
If the app is data-heavy, educate users about how they can download for offline use.
Make experiences transferable between devices.
Use language, icons, imagery, typography, and color together to express ideas to the user.
Provide reassurance and feedback to help the user.

Mustafa Kurtuldu on web.dev

Patterns for promoting PWA installation

Best practices #

Automatic browser promotion #

User interface promotional patterns #

Simple install button #

Fixed header #

Navigation menu #

Landing page #

Install banner #

Temporary UI #

After conversion #

Booking or checkout journey #

Sign up, sign in, or sign out flow #

Inline promotional patterns #

In-feed #

Introduction to variable fonts on the web

Browser compatibility #

Introduction #

Challenges for the designer and developer #

Anatomy of a variable font #

Italics #

Axes definitions #

Use cases and benefits #

Exciting expression #

Animation #

Finesse #

Variable fonts in CSS #

Loading variable font files #

Using weights and widths #

Using italics and obliques #

Using optical sizes #

Using custom axes #

Variable fonts on Google Fonts #

Font-variation-settings inheritance #

Performance gains #

Fallbacks and browser support #

Thanks #

Offline UX design guidelines

Decide what to show your users when they have a bad network connection #

Inform users of their current state and change of state #

Inform users when the network connection improves or is restored #

Update the UI to reflect the current contextual state #

Educate the user so they understand what the offline model is #

Provide an offline experience by default #

Inform the user when the app is ready for offline consumption #

Make 'save for offline' an obvious part of the interface for data-heavy apps #

Clarify what is available offline #

Show the actual cost of an action #

Help prevent hacked experiences #

Make experiences transferable from one device to another #

Create inclusive design experiences #

Use simple, concise language #

Use multiple design devices to create accessible user experiences #

Use icons that convey meaning #

Use skeleton layouts with other feedback mechanisms #

Don't block content #

Design for the next billion #

Conclusion #