Progressive Web App

Separating Concerns through Service Worker Helpers

July 25, 2016 Leave a Comment

I am enjoying a new pattern emerge as we do more work with service workers, and that is wrapping a libraries usage, or some functionality, with a service worker that improves a particular concern: e.g. reliability. This reminds me of a past life in which I enjoyed aspect oriented programming techniques to keep the core business logic clean, but add other concerns separate from that codebase.

Let’s take a look at two examples of this technique that popped up in the last couple of days.

Case One: Offline Google Analytics

As soon as you start considering how your app will work offline, you think about many side effects. How will I track the offline usage is one. You may naturally take an analytics library and start flushing out the cases for checking for network access and doing the right thing. The problem though is now you may have a lot of logic that is dealing with offline usage tied into business logic, and you also may be looking at how to funnel all usage through this library.

Instead, you can add this functionality through a service worker that is able to intercept access to particular URLs, which is exactly what sw-offline-google-analytics does:

“sw-offline-google-analytics sets up a new fetch event handler in your service worker, which responds to requests made to the Google Analytics domain. (The library ignores non-Google Analytics requests, giving your service worker’s other fetch event handlers a chance to implement appropriate strategies for those resources.) It will first attempt to fulfill the request against the network. If the user is offline, that will proceed as normal.

If the network request fails, the library will automatically store information about the request to IndexedDB, along with a timestamp indicating when the request was initially made. Each time your service worker starts up, the library will check for queued requests and attempt to resend them, along with some additional Google Analytics parameters”

Case Two: Keeping Users Logged In

“Why does my app never ask me to re-login, but the website seems to force me to every now and then?”

There is no reason to not offer safe long sessions on the web, and we can piggy back on the age old two-token pattern to refresh tokens at appropriate times.

The example code shows a service worker that does the refresh work based on the expiration date, by wrapping calls to the backend.

Helpful Workers

Service workers are powerful and as such there are many things that you can do. It is interesting to see people come up with patterns to make common uses simpler. We are pushing on this with our own sw-helpers and I am curious to see what others come up with.

We need to remember to scope the work that is done there appropriately, because you obviously can’t rely on the user having a service worker, but there are so many cases where you can drop in useful functionality in a progressive way.

Our Web Obesity Epidemic

June 8, 2016 Leave a Comment

We have a digital obesity epidemic that is mirroring the real-world obesity issue facing many of our civilizations around the world.

These things creep up, and a subtle misalignment in the balance of the force lets one side run away. In the case of our diets there are arguments over the cause: sugar? carbs in general? The science seems pretty clear that the “fat” boogey man was just that. It had a poor name and Ancel Keys happened to do too good of a job selling it as the enemy.

On the Web our page weights keep growing. With more pixels on our screens we use larger assets. With richer applications we throw down more JavaScript. Business threw in more JS SDKs to show more ads.

We looked at South Korea and their fiber lines, and kept eating away thinking that the network and desktop machines were such that our pants were stretchy and we would be AOK.

But then mobile happened and we found ourselves trying to squeeze into our wedding dress or tux from 10 years ago. Oops. It doesn’t work.

Now we find ourselves as a population looking to get back to a stable healthy midpoint. Now, we aren’t all in the same camp, and it is important to empathize with the fact that every person is on their own stage of the journey to their ideal weight, optimized for their health.

For those who are obese and are ready to make a change, they are looking for the right path. So many of us look for a quick fix when it comes to weight and a pill to save you.

AMP is a prescription drug and vitamin all in one. It does give you a quick path for certain use cases. You will have real constraints, but it can be a great choice to get going. Start taking the pill and you will have content that is bonafide fast. Chances are that you will want to add a richer experience for engagement, and that is where you will want to go beyond AMP. Fortunately, Alex Rusell laid out the connection on how to put AMP and PWA together.

If AMP is the pill, PWA is the path to a healthy web lifestyle.

Whether you take the pill or not, today is the day to start a healthy lifestyle, making sure that your entire experience is fast, safe, resilient, and engaging.

When someone is on this journey it is important to encourage and support them. This is another reason why we set a bar with PWA and Lighthouse, but we cheer on every step in the right direction. We cheer Flipkart for coming back to the Web, making a great experience that has fantastic business metrics, and they keep going by growing the reach. Was it ideal that the first version didn’t support iOS? Sure. But they came through and supported UC, then Safari, and we will soon see support added for Firefox and Edge.

If someone stops on the journey, that is the time that we need to step in and keep pushing them. If they finish up with a pwa.foo.com side that only works on mobile, we push them. But if they are still moving and progressing, we shouldn’t pre-judge.

That being said, if we see someone taking the wrong path, such as going all in on a low-fat diet that we know is a hoax, we should step in. We should do everything we can to educate people and help them make the right choices.

The best way to fight this is to start early. If we can get our youth on the right path from day one, they won’t have to go through the legacy pain to get back on track. To this end we need to setup the green field projects so they are fully responsive, on http2, and follow the best practices that we have to offer. There is still a lot of work to do here.

When a developer starts a new project, which diet do they choose? Which one is The Right One?

There will always be choices, which makes it more important to use data. We need to set the bar and hold choices accountable. If your framework choice ends up with something that passes lighthouses tests, GREAT! These diets and frameworks are a means to an end, not the end itself.

The measures that you choose are then very powerful and important. Is BMI the perfect metric? No. But it may be a nice general measurement for the masses, and for the individual you should go deeper. Once you get to a decent BMI you can then go deeper and get more measurements that tie to yourself. These will be very different depending on your goals. Are you looking to be good at a certain sport or lift heavy weights? Or are you a long distance runner? Are you looking to be a high engagement entertainment site, or a transactional market that wants to help users get in and out as fast as possible? Measure what is right for you.

We are in interesting times. I think we all acknowledge that we have a serious problem. Fortunately, we have the capabilities in the platform to be healthy, the masses just aren’t there yet.

As someone who has been on the literal health journey, and is still fighting that fight, I know that it isn’t easy…. but it is life and death. Let’s do this.

The Ideal Web Experience

May 25, 2016 Leave a Comment

When you name something you need to define it. Once you do that it is natural to have the definition poked at, and you run examples through those definitions. “What is different between a cat and a dog?”.

I am seeing some robust discussions about progressive web apps. What makes foo.com a progressive web app? What if it didn’t have this feature or that feature?

You tend to start with the definition, which leads you to Alex Russell’s original post and look through the attributes of a progressive web app:

Responsive: to fit any form factor
Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
Fresh: Transparently always up-to-date thanks to the Service Worker update process
Safe: Served via TLS (a Service Worker requirement) to prevent snooping
Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.

It is more important to look at the motivation and the outcomes that you are really looking for though.

I will talk a lil about the past, and then talk about the journey from about:blank to what I think would be the Ideal Web Experience.

AJAX to Ajax

When Ajax first came along it was talked about as an acronym, but we quickly saw that this wasn’t what we actually meant:

If you used JSON instead of XML do I have an Ajax app?
The killer feature of Google Maps was the panning and loading of tiles, which wasn’t about Ajax

What mattered was that we had enough tools to deliver a great desktop web experience, and that people were on the journey to build these. And, it was a journey. People talked about the various states of ajax adoption, and often the path was ugly.

We had to deal with legacy systems and you would often see a app.foo.com approach until that experience could eat http://www.foo.com. We also see the regression of behavior, when people would focus on the new shiny and leave behind some of the great features of the web (accessibility, progressive enhancement, etc). Evolution is messy, but many got through to the other side.

We are starting the same journey again. This time around we are dealing with constrained mobile devices and networks, and new great capabilities due to sensors and context. The browsers had to quickly optimize themselves for this new world. We are seeing some early success stories where we finally see proof that this is worthwhile, for users and businesses.

The Journey

It has helped me to think about the Web experiences that I look forward too. Those that reach the ideal. What do they look like?

They are predictably fast (all across RAIL, all the time, all devices, via any deep link entry point)
They are secure (https all the things, CORS, CSP)
They are accessible (everyone in the world can experience them)
They have low friction (if I want to get to one from my home screen I can. If I want to easily pay without filling out forms AGAIN I can. If I want to be notified to re-engage, I can, …. etc etc)
They are resilient (shit happens, they deal with it)
They are adaptable (responsive across the board, from screens to inputs to context)
They are progressive (they are always the best they can be given the constraints of their environment. no lowest common denominator, they keep getting better and better and they use ever capabilities that makes sense)

Now, let’s get back to reality from my idealistic view, and put the “is it a progressive web app if….” questions to the test.

These answers are my opinionated ones:

My experience is kinda slow, but it has all of the cool new features, is that good enough?
No. Performance on mobile at the center of this. Sorry.

If you deliver an experience that focuses on mobile is that a PWA? Yes. It is far from ideal though. We cracked the progressive nut and it is a huge advantage of the Web, so please keep going on the journey! Other form factors such as desktop and tablets are still huge, and I often see some a-ha moments when talking about how you can use a feature such as push to reach your users on the desktop!

If your experience only works with service workers is it a PWA?
No. Come on, Service Workers are designed to be progressive enhancement, please don’t mess with that!

If your experience only works on Chrome is it a PWA?
No. We went through the “best viewed on X” era. It’s not good enough. I know that all of the browsers aren’t fully shipping everything yet but they are doing pretty well. Being a Web developer means that you write to the platform across implementations

If you don’t want to hide the URL bar is it not a PWA?
No. This can be a choice. The important part is that you have the possibility to go full screen / immersive.

If you don’t support $BROWSER yet is it a PWA?
Yes. Flipkart went down this path. While I would have loved for them to ship to more browsers, they decided to ship earlier and iterate and the important point is that they HAVE kept going on the journey and they now support browsers such as Safari and UC Browser

Is it OK to ship pwa.foo.com first?
It’s your choice! If that is the best way to ship and learn, go ahead. Just please keep going and reach for the ideal of One URL across desktop, mobile, etc etc.

Is it OK to ship on http?
Nope, sorry. Safety is too important. I know that it takes effort to get over to HTTPS but it has never been easier, so get on that journey

Is it OK to not be that accessible?
No. I know it takes effort here too, but it is much easier to start with accessibility in mind (and security, and performance) so try to get that habit going.

Is it OK to require JavaScript?
This is another type of “accessibility”. It’s business importance may differ depending on the demographic and what you are building, but…. remember the BILLIONS of people coming online that use browsers such as Opera Mini? This is an age old debate that will come and go, but the context is important.

What if I don’t support Add To Homescreen?
Really? Is that so much work? I get it…. this isn’t the part that MAKES it a PWA, but why not allow that option for your users?

What if I don’t use push notifications?
If there isn’t a valid use case for you or your users, then THANK YOU for not needlessly sending push messages.

What if I am building “websites” not “webapps”
All good! Just don’t ignore the capabilities that can make the website fantastic.

What if I don’t have an app shell architecture?
All good! That is just one option than people are exploring, especially for certain types of experiences.

For me when I go through this thinking, I land right where I was back in the days of Ajax. I want the browsers, frameworks, and developers to be pushing each other in the right direction, evolving so that we can deliver amazing web experiences.

We aren’t yet at the ideal web experience, but I think that we are at least poised better with the technology and thinking around progressive web apps. It is all well and good to expect every development team behind a website to be craftsmen with infinite time to build the perfect experience, but the world isn’t like that. There are a slew of problems, a ton of legacy, and piles of work to do. All we can hope for is that this work is prioritized.

The PWA term itself is also useful as it was with Ajax. It gives you something to talk about with your clients, or with your business partner.

“We really need to prioritize some of these new capabilities, have you seen the results companies are getting? And the types of experiences? There may be some tech debt to pay off as we get the foundations cleaned up, but now is the time.”

Chances are you may be a lil sick of the term already. That’s OK…. but it has its uses.

We are right in the middle of some messy evolution, but I am so excited with the direction and enjoy working with the chaotic and passionate web community to keep on trucking.

« Previous Page