Create guidance for Progressive Web Apps

[PaulKinlan]

Goals

The developers will learn:

• What progressive web apps are and the core concepts behind them
  • It should be clear that these experiences work everywhere but are accelerated in modern browsers.
• Examples of what we believe are great progressive web apps that they can use as a starting reference
  • Expand on the case studies with deep technical dives.
• The best ways to think about structuring my app to be a progressive web app.
  • There are several valid ways of building a prog-web-app, we should enumerate them and present the best practice for each.
• How to start apps from a complete, working scaffold and evolve it as needed.
• How to create a bespoke App/Shell application from scratch.
• How to layer on more advanced experiences
  • Push Notifications, BLE, Physical Web etc.
• How to add progressive web app capabilities to my existing codebase.

Tasks

This is bit below is being worked on.

• Create a landing page:
  • A clear definition of progressive web app’s
  • Point to live examples.
  • An overview of all of the platform pieces involved in a progressive web app. What they provide, what their browser support looks like, and how they fit together.
    • Guidance for Service Worker and Offline
      • Udacity Course
      • Web Fundamentals explainer (it never landed)
    • Guidance for Add to Homescreen and installability
      • Udacity Course
      • Web Fundamentals explainer (it needs to be tidied)
    • Guidance for Server Rendering
    • Guidance for Progressive Enhancement
      • What is progressive enhancement and why it is important
      • You don't need the exact same experience + data
      • Best practice and guidance
    • Guidance for RAIL - weave existing docs and guidance in.
    • Guidance for Native Interactions (Sharing for example)
      • Udacity Course
      • Web Fundamentals explainer
    • Guidance for TLS - this already exists on /web/fundamentals to an extent, needs to be updated and referenced
• Create a Your First Progressive Web Apps guide (Create Your First Progressive Web App guide #2375)
• Create Canonical Apps and case studies
  • A handful of case-studies with different verticals and use-cases.
  • A complete demo applications that people can play with on a mobile device.
  • A walkthrough that points out each of the progressive web app-specific features of this demo.
• Create a section on How to structure your app to be a progressive web app.
  • An overview of what the goals of the app-shell architecture are, and how it relates to SW & progressive web app. (strongly highlight the progressive nature).
  • A few specific examples of App/Shell-compliant structures, and their strengths/weaknesses.
    Learn what my options are for getting started.
  • Testing strategies locally and in staging environments
  • Complete list of tools, templates, and examples available to me, and what they provide. Should call out a clear starting point.
• Create 5 minutes starter pack and guide: Start building from a complete, working scaffold and evolve it as needed. (App Shell project + Guidance)
  • A codelab/step-by-step docs that arrive at a basic set of components/boilerplate for a working Progressive Web App.
  • A complete, out-of-the-box working kit that I can download and get something visible in 5 mins, that looks kind of like the thing I want to build.
  • Examples and Guidance for verticals:
    • E-Commerce - a shopping app a la Flipkart
    • Publishing? - a blog/news type app
    • Media? - a Podcast player / video player?
    • Gaming? - lots of web games, they need push, offline etc.
  • UI components that come with the toolkit that I can use to customize by app’s UI, that work seamlessly with the SW architecture.
• Create a guide for UI Performance
  • Applying FLIP and RAIL to Progressive Web Apps
  • Create a library of 60fps UI patterns, e.g. pinch-zoom, fling, pull-to-refresh(?).
• Create a how to build a more bespoke App/Shell application from scratch guide.
  • Common challenges in building with this model. What big issues am I going to run into? How can I get through them?
  • Libraries to help smooth over the rough edges identified above.
  • Template(s) to serve as jumping-off points for how to leverage the libraries.
• Create a section on upgrading an existing codebase to be a progressive web app
  • App Cache to Service Worker
    • Library
    • Rationale, Guidance and best practice
  • Best practice guidance on how to do it for React, Polymer, MDL etc. Hints and tips of things that we have found that work well.
  • Case studies from developers who have already done this step.
  • Create Blog posts or annotated pull requests showing what changes were made to an existing React, Angular, Polymer, MDL, etc. site to restructure it into a progressive web app.

[kenchris]

I think that developers would love to experiment with these things themselves, so maybe some info on how to get it working on appengine etc would be useful.

I recently ported my Web NFC demo to appengine and added http2 support, auto-selection of images based on DPR and an app shell: https://weneed-1147.appspot.com/

Talking to people working as front end developers, their hard problem is being able to convince their clients that there is a value in all this, because their clients just want something which works 100% the same way across common browsers (incl IE9 etc) and they want it fast. We need to explain how to make progressive web apps, which even progresses from old browsers into newers ones, then onto the launchers etc. and we need to have simple clear presentations that these developers can reuse themselves to convince their clients of the value in doing all these things.

This here is a very good presto explaining some of the issues from the frontend developers side: http://www.slideshare.net/cheilmann/the-state-of-the-web-helsinki-meetup

The above should also discuss responsive design, as it is important that the app shell is also responsive if the main content is. Also you may want to mention screen orientation lock which can be very useful for games

Btw, I wish we could stop calling what Reach does for server rendering - it is not really rendering anything on the server but doing DOM diffing, at least AFAIK

[jpmedley]

"Questions a developer will ask: What is the set of technologies involved? How can I get some background in each of these?"

Should it say, "what set of technologies and techniques?" Responsiveness, app-shell construction, and linkability are more about how than what.

[PaulKinlan]

@jpmedley good point, this was originally copied from the internal doc and I have been re-jigging it as I go, I think they are mostly captured in the following bullet points.

[deanhume]

Hey @PaulKinlan - this looks great!

I'm sure this will get covered in the starter pack, but it would be good to see a walkthrough for debugging Progressive Web Apps added to the guide.

[PaulKinlan]

@kenchris - great feedback, will add some of these in. One quick question, in terms of convincing clients, what presentation and data do you think is needed? Is it data about why mobile and web is important or is it why this architecture is useful?

[PaulKinlan]

@deanhume great feedback. Silly question, is debugging a prog-web-app any different from debugging a normal web? Or is it now we have SW we have to manage that as well? Or is it more?

Regardless, I think we are missing a huge swath of testing guidance in our work.

[kenchris]

@PaulKinlan From what I've heard, companies often order a website as one thing, and demands the required features and where it should be supported. This often leads to developers having to choose the lowest denominator and/or add extra code (performance penalty) to make it seem to work the same way across browsers.

I think it would be useful with a presto explaining why you don't need to offer exactly the same experience across all browsers (new and old) - what the penalty is when you try doing so, and what you gain if you instead progressively enhancing the experience.

Many companies believe that they must offer the same experience everywhere and that they need to support all browsers out there in order to reach as many people as possible, but often they do not understand the cost of attempting to do so.

Last I interviewed a new GDE, we were talking about Service Worker, and he mentioned that they tried pitching that to their clients, but there first questions were always "does it work everywhere?" and when the answer is "no, currently in Chrome", they don't care, because they don't really understand how catering for specific platforms/browsers helps them. Maybe it is also because they see it as "one browser" thing, instead of a feature that with time will just work everywhere and benefit their other platforms as well.

[hemanth]

"does it work everywhere?" and when the answer is "no, currently in Chrome", they don't care, because they don't really understand how catering for specific platforms/browsers helps them.

I second that strongly!

People will give a positive response once they see a sample PWA but after they hear about the partial support they backup...hoping that the situation will change soon.

[paullewis]

Note from an offline convo with @PaulKinlan, we should aim to include 60fps UI patterns, e.g. pinch-zoom, fling, pull-to-refresh(?).

[jaisanth]

+1 to @paullewis

Talking about RAIL, FLIP, etc. would really help people realize how slick your PWA can get.

[PaulKinlan]

@paullewis will add this in. @jaisanth agreed. will add it into task list and assign to @paullewis to work out what to do. :)

[PaulKinlan]

@paullewis @jaisanth I have created a section of tasks for this - super highlevel, but we can start to work from there.

[PaulKinlan]

@kenchris I am putting the lowest common denominator piece in now as a task.