Apr 10 2019
Progressive Web Design (PWD), or Progressive Enhancement, is a way of designing web pages so that they will work for 100% of users, no matter what browser they are using or in what manner they are interacting with the page. It’s a contentious topic for some people – usually designers. For marketers, it’s an important method for ensuring every possible audience encounters an experience that leads to conversions.
Progressive Versus Responsive
Progressive Web Design is not the same thing as Responsive Web Design.
It is a core fundamental of web development that the design must be elastic and be appealing at all viewport aspect ratios. However, it’s not an either or decision between Progressive and Responsive. Both standards should be used together to ensure an optimal experience for all users.
Responsive Web Design uses design elements that respond to changes in the size of the viewport – desktop, tablet or mobile phone. This is done by rearranging the components of the page, changing the top nav into a “hamburger menu,” and other techniques. The motto of Responsive Web Design is “mobile-first”, meaning that if a site works on mobile, it will work on desktop but not vice-versa.
Why Is This Important for Designing Websites?
From the beginning, the Web was designed to be platform-agnostic, which is a fancy way to say that a page will work on any computer and in any browser that implements the HTML standard. Progressive Web Design embraces this goal of accessibility by ensuring that a page is functional in any context.
Some common contexts in which a user may be interacting with a site are:
The Whole Enchilada – Using the latest desktop version of Chrome, Edge or Safari with all features enabled.
The Smart Phone – Using a touch interface on a modern smartphone with the latest version of a major browser and fully enabled.
The Snail – A user is in a rural setting where broadband is not available.
Speech Mode – Screen readers for the visually-impaired and voice-interactive devices like Alexa, Google Home, etc.
What Design Features Are Actually Used?
Current analysis shows that the following features are available for the percentage of audience shown. This is only a small portion of features listed as an example. A full reference for the use of features can be found at https://CanIUse.com.
- Grid Layout: 91.54%
- Sticky (prefixed) – Header stays at top: 90.36%
- Sticky (not-prefixed): 76.74%
- Shapes: 89.23%
- Filter Effects: 93.19%
- Scroll Positioning: 86.73%
- CSS Calc: 95.83%
- Rounded Corners: 96.48%
- Audio: 96.46%
- Canvas Blend Modes: 92.86%
- Custom Tags: 86.59%
- Dialog Element: 72.22%
- HTML Imports: 72.17%
- PNG Favicons: 85.07%
- Accelerometer: 62.22%
- Promises: 92.74%
- Push API: 78.06%
- ECMAScript6 Classes: 90.83%
- WAI-ARIA Accessibility: 94.20%
- WebP Image Format: 78.13%
- Ogg Audio Format: 79.79%
- FLAC Audio Format: 89.97%
- WebAssembly (wasm): 84.62%
- Animated PNG: 84.42%
- theme-color Meta Tag: 36.42%
Know your user. Site audiences will skew toward more or less feature availability depending on the site’s user base. A site made for techies will likely have The Whole Enchilada, whereas less technical users who tend to live in rural areas will have less functionality.
Check usage. Each property should be checked for usage. Many firms elect to consider 98% and above as global and ignore those users who don’t have the feature. Although that seems to cover most or all of the bases, it could very well leave out important segments of your customer base.
CSS overrides. This is a simple technique of writing CSS code that is geared toward all browsers and then adding on code for more sophisticated browsers to the end of the CSS. This method replaces the previously declared code if the browser supports the new feature. Otherwise, it’s ignored.
CSS feature queries. This is a tool in CSS to check to see if a feature is available and only parse the designated code if it is.
Fail gracefully. Manage feature failures proactively.
Write for tests. Design code with functionality to easily test the site in less-advanced contexts.
Test by touch and by click. Interaction on touchscreens may be very different for the user than by clicking with a mouse. Be sure the page works easily for both contexts.
Think about content-only. Knowing that your page may be read by a screen-reader or in reader mode, layout the code with the intention of feeding content to these readers in a logical order and omitting elements that do not apply in that context.
Need a full-service team to take your business to the next level? Contact us today. We’re here to help.