Chris Wilson offered an excellent introduction to Progressive Web Applications, «Progressive Web Apps are the new AJAX» at View Source Berlin. Chris showed a slide where, after applying PWA principles to a web site, conversions increased even on iOS (by a not negligible 82%), a platform where neither Service Workers, Web Push or Application Manifest are supported.
During his talk, Chris put the emphasis on user experience, saying PWAs are all about UX, not technologies and this is precisely one of the most fascinating things PWAs are doing, changing the developer mindset about prioritizing UX.
Some days before, Alex Russell published an article titled “What, Exactly, Makes Something A Progressive Web App?”. However, the first half of the post is all about getting the “Add To Home Screen” dialog to be shown.
In his post, Alex highlights the importance of meeting some baseline criteria for your app to become an A+ progressive web app and do Chrome show the “Add to Home Screen” dialog. As you probably know, these constraints require the usage of certain technologies in an specific way: the developer must serve the page on HTTPS, use a Service Worker and link a manifest providing a minimal set of keys and specific values. All three are necessary (although not sufficient) for a web app to be reliable, to offer an offline experience and to be integrated with the mobile OS. Ultimately, all three characteristics contribute to a better user experience.
Reliability aside, like it or not, offline experience and platform integration can be achieved by using non-PWA-related technologies such as App Cache (ugly but still a standard and a cross platform one at that) and OS-proprietary meta-tags. Fortunately, high performance best practices, techniques and patterns are vendor-independent.
Although I can see the good intention behind technology requirements –the dialog is acting as a reward for developers minding UX–, in my opinion, Chrome is going too far not only guessing when users are deeply engaged with a web app, but determining what specific kind of web apps users can engage with. Notice that only if technical requirements are met, user engagement heuristics come into play. User engagement is measured but performance isn’t, performance is expected as a result of using specific technology.
Compare with app stores. We rant at Apple or Google for deciding which kind of content is appropriate and what is not but at least, once developers observe content policies and the app gets published, the install button is there for anyone finding their application. Targeting the Web now means that in Chrome, even if the developers figured out how to leverage user engagement, the users will never see the install button unless the app meets the technical constraints.
Don’t misunderstand me. I really think that Home Screen launchers / shortcuts / bookmarks / whatever are a good idea but if browsers are going to demand UX excellence from developers, they should do by measuring performance during user interaction, not by tying development to a trendy technology stack. Regardless of impositions, the ultimate indicator about engagement will come from the user. Browsers should focus on leveraging UX for users’ interests and not deciding what users should engage with.
I would love to see Mozilla, in its role of user advocate, taking a strong position on this matter by providing its own user-centric alternative.
Uno + uno = diez 