The Road To PWA - Part 1

s1hofmann

Simon Hofmann

Posted on May 6, 2018

The Road To PWA - Part 1

This post has initially been posted on my personal blog

As I said in my last post,
I've built a PWA for my wedding.
In this post I also promised to write a more in-depth post about the technical details of my PWA.

So ...

Promise.resolve(writeBlogPost()).then(post => readBlog(post));
Enter fullscreen mode Exit fullscreen mode

The Road To PWA

PWAs are (hopefully) here to stay.
As I mentioned in my previous post, the problem with native apps is that they are supposed to be distributed via a dedicated app store. To be able to distribute apps via these stores requires you to sign up for a developer account, which requires a one time or regular payment.
(I do know about open-source app stores like F-Droid for Android, but I do assume that the largest portion of smartphone users does not.)

That's exactly where PWA's come into play!

Ok, sounds cool, but what exactly IS a PWA?

The most important thing about PWAs is that it's possible to enhance any existing web application with progressive features. PWA features integrate seamlessly into existing applications, when added carefully they will be available in supporting browsers, but also not cause any differences or errors on browsers which do not (yet) support them.

In my opinion the three core building blocks which make up a PWA are the following:

  1. Responsive, engaging Design
  2. Modern JavaScript APIs
  3. Service Workers
  4. HTTPS

The thing I want to talk about in this post is regarding the design of PWAs, but more posts will follow.
(Except for HTTPS. Here you only have to know that full-featured PWAs require HTTPS. You'll see why in the post on service workers. If you do not yet have a valid TLS certificate, I can only recommend Let's Encrypt - Free SSL/TLS Certificates. As an alternative, GitHub Pages are also served via HTTPS and allow for custom domains.)

Responsive Design

Over the course of years certain UI / UX patterns established in smartphone apps.
The two most notable styles are certainly the iOS interface guidelines and Google's Material Design.

These two style guides contain detailed information on how to design user interfaces for the respective platform, as well as guidelines on how to handle user interaction. Taking these guidelines into account gives new users an easier onboarding to your app, since the overall look and feel already seems "familiar".

These guidelines are also of interest for progressive web apps. Since a PWA could be used as a light-weight alternative to the full web page (Twitter lite for example), or even serve as a full replacement to native apps, users of your PWA should still feel at home, no matter whether they are using a native app or visiting the web app.

Mobile First

The oldschool approach when designing a webpage was to make it look good on desktop browsers and later on make it look ok on mobile browsers. The mobile first approach takes the other way round by designing webpages with mobile devices in mind. Design for smartphones but also apply techniques to make the webpage look good when accessed via desktop browser.

To make this possible one could rely on a CSS framework like Twitter's Bootstrap or Material Design Lite, but it certainly does no harm to read up on CSS Media Queries [1, 2].

With mobile first UIs in place, another major point which distinguishes web apps from native apps is the fact, that web apps are still running in a browser.

One of the cool things about PWAs is that they can be "installed" to a device (well, currently it's an Android device, to be precise) like a native app.
The requirement for this is a so called "app manifest".

Web App Manifest

The web app manifest contains meta data about a web application. It's actually a simple JSON file, but it's also common to name the file

manifest.webmanifest
Enter fullscreen mode Exit fullscreen mode

The manifest file allows to configure things like application name, icons, display style, color schemes and much more.

The following listing shows the content of wddng's manifest:

{
  "name": "wddng",
  "short_name": "wddng",
  "start_url": "./index.html",
  "scope": ".",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#fff",
  "description": "Keine Hochzeit ohne Technik!",
  "dir": "ltr",
  "lang": "en-US",
  "orientation": "any",
  "icons": [
    {
      "src": "./src/images/icons/app-icon-48x48.png",
      "type": "image/png",
      "sizes": "48x48"
    },
    {
      "src": "./src/images/icons/app-icon-96x96.png",
      "type": "image/png",
      "sizes": "96x96"
    },
    {
      "src": "./src/images/icons/app-icon-144x144.png",
      "type": "image/png",
      "sizes": "144x144"
    },
    {
      "src": "./src/images/icons/app-icon-192x192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "./src/images/icons/app-icon-256x256.png",
      "type": "image/png",
      "sizes": "256x256"
    },
    {
      "src": "./src/images/icons/app-icon-384x384.png",
      "type": "image/png",
      "sizes": "384x384"
    },
    {
      "src": "./src/images/icons/app-icon-512x512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

name and short_name should be pretty self-explanatory. name contains the full application name and will be shown on e.g. the startup splash-screen.short_name will be used on application icons.

The start_url configures which URL is loaded on application start, via an optional application scope one could configure for which scopes the PWA manifest should apply. When navigating outside the scope, the web app would be served as regular webpage.
Setting "display": "standalone" will display the web app like a native app including a launcher icon, hidden URL bar, hidden navigation elements etc.

There are a lot of available options and the application manifest spec is still in active development. According to the latest draft it will also be possible to install service workers via manifest option.

I won't go in on details on all available values, for an explanatory overview you can check the resources provided at the end of the post.

Including a manifest

A manifest file is included using a <link ...> tag with relationship set to "manifest".

<link rel="manifest" href="/manifest.webmanifest">
Enter fullscreen mode Exit fullscreen mode

Side note: Packaging using parcel.js

At the time of writing, parcel.js would only package manifest files with *.webmanifest ending correctly.

Useful resources

Summary

Using responsive design combined with an application manifest makes your web app mobile device friendly and installable.
It's also possible to partially customize the app theme via manifest file.

Adding a manifest to a web application is our first step to a full-featured progressive web app.

Stay tuned for more!

So long

Simon

💖 💪 🙅 🚩
s1hofmann
Simon Hofmann

Posted on May 6, 2018

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related