I was lucky enough to attend the Progressive Web App Summit hosted by Google at the Theatre Amsterdam with two of my SitePen Colleagues. I was blown away by the quality of the talks, the speakers, the content and of course the venue and hospitality.
Progressive Web Applications take advantage of new technologies to bring the best of mobile sites and native applications to users. They are instant loading, offline capable, installable, secure, responsive and addable to the home screen. More information is available on the Progressive Web Apps website.
There was a full day of talks which cleverly led on from one another to create a seamless conference experience. I’ll share some of the highlights.
Opening keynote: Alex Russell
The conference opened with a keynote talk from Alex Russell and Thao Tran outlining the journey that has led us to progressive web apps and some of the problems they try to solve: Installing to the home screen, creating a responsive experience via web technologies and providing an offline experience amongst others. Impressive statistics were provided to back the need for this progression. For example, most users spend 80% of their time in their top three apps, meaning that we need to make it simpler to get to the home screen and highly visible. Alex talked about how frustrating it can be when you try to load a web app on a bad connection and are faced with the chrome T-rex offline screen. This led nicely onto Jake’s talk on offline-first.
Instant-loading offline-first web apps: Jake Archibald
Jake Archibald followed Alex with his energetic talk covering progressions in offline-first and the reasons for needing this approach. He cleverly uses the term Lie-Fi to describe when your mobile phone thinks it has service, but it really doesn’t, a frustrating problem we’ve all come across at some point. He advocates solving these problems with service workers and local caching, both of which are implemented in Chrome and Firefox, with Edge and Safari following behind. Jake took us through the journey of using Service Workers to front load and cache his Emojoy chat application as well as adding push notifications. Jake used a Street Fighter style ‘VS’ screen to show how the apps compared to one another before and after the optimisations. The end result was a UI that loads instantly on consecutive loads and notifies users of chat updates even after the tab is closed. He also shared with us some impressive use cases for using streaming including an example where he performed a search against the whatwg html spec using streams and the Fetch API, two APIs which will be supported in Dojo 2. This was able to scan a bytestream for search text as it is received rather than waiting for the entire file to downloaded first. In this case, a large 8MB file provided near instant search results.
UI elements at 60fps: Paul Lewis
One of my favourite afternoon sessions was led by Paul Lewis who gave a talk on UI elements at 60fps (frames per second). He started by going over the concept of giving different weights and importance to Response, Animation, Idle and Load times (RAIL). People often put too much emphasis on the wrong parts of this list. In order to make a web app behave as expediently as a native app, we need to ensure it performs the same and is responsive and animated appropriately. Paul explained that load time is not as important as previously thought, as once the app is installed, future loads are inevitably smaller.
Paul covered the use of the relatively new ‘Will-Change’ CSS property that promotes elements to layers to speed up transitions. This is one of the first techniques he employs to create fast responsive animations. However, he stressed that it should not be blanket applied to every element as this will have a detrimental effect of performance. The second key approach to performing more complex animations at 60fps is to follow the concept of ‘FLIP’. He used this technique to animate clicking and zooming into a UI component with an expand animation, something you often see in a UI built using Google Material.
The process has four stages:
- First: The starting position of the element
- Last: The end position of the element
- Invert: Apply transforms to move the element back to its starting position, i.e. if it is doubling in size, you scale it 50%. This makes it appear as though it is not moved at all
- Play: Add transitions to the properties you’ve changed and remove any transforms that have been applied. The element will then animate into its last position and only one layout will have been applied (sneaky!)
Progressive web apps in any context: Rob Dodson
The following talk on accessibility and UX given by Rob Dodson cleverly used a slide in menu component from the previous talk to illustrate accessibility. Rob showed how
tab-index can be cleverly used to assign focus and direct users who may be using screen readers or other accessibility software to active areas of the UI (an age old technique, but still an effective one). The key message here was that accessibility and good user experience go hand in hand.
Late afternoon and closing keynote
The late afternoon talks covered tooling for progressive apps and Lighthouse (currently Alpha), which helps to identify areas of improvement for your progressive app.
Finally, the closing keynote covered new features such as the Credentials API and the Payment API, making logging into progressive apps and making transactions simpler. Both are still under development and sadly are still different across mobile operating systems.
Progressive Web Apps appear to be a great step forward for mobile first web applications. For Android-based phones, this offers a means to install web based apps to the home screen and reduce barriers for end users to access a web app. Service Workers are also a great addition, much better than previous app-cache and manifest style offline approaches. It will be great to see if they are adopted by iOS and Safari in the future.
The entire conference is available online, I highly recommend checking it out the website for the Progressive Web Apps summit.
Thank you to Google for having us.