Mobile

Resilient: able to withstand / recover from difficult conditions.
Reliable: consistently good in quality or performance; able to be trusted.

— Dion Almaer (@dalmaer) May 4, 2016

Providing a reliable experience to a user requires resilient software, and this is something that we don’t often discuss, even though I think it warrants the same attention as security and performance.

It is hard to develop truly resilient software as it requires thinking and iterating though the edge cases, similar to the extra mile that you need to go through to make sure that 60 fps is standard, or those attack vectors are mostly covered, across a large range of devices.

We have all seen examples of when the user experience falters. One of the reasons this topic popped back into my mind was watching one of my sons dealing with a poor experience (that is actually a feature in my book, as you will see!). Let me share the story….

I have seen many applications get into a bad state when it comes to in-app purchasing. My son wanted to take real money and convert it to “gems” in Clash Royale, but once the payment went through the gems never showed up. Even worse than that, the gems became greyed out and when tapped said “Transaction is in progress”. The game has been stuck in this state for weeks, which is a bummer for Sam. After searching online I see that SuperCell is losing out on a lot of money as this doesn’t seem to be a unique case at all. If the game was resilient it would be aware of such edge cases and would be able to revert to a state when they could take money again.

Visibility

The first step in building resilient software is being able to see what is going on in the system. You need to build a resilient mechanism to get errors back to you, and a way for you to be alerted to the velocity of errors, as well as critical ones. It is common to get to a new release and think “oh right, I guess we need to get some analytics tags in there quick!” vs. having that thinking occur at the beginning. You really want to be thinking “what outcomes am I looking for with this release?” very early on indeed, as a tool to help you decide what to even build, as well as flushing out the various scenarios.

It is also easy to get flooded and conflate true errors in the system with “valid” logging. I remember joining one company that had millions of exceptions flooding into their system and a large percentage were SocketException’s which were waved away as “just networking issues”.

It just so happened that we put a new orchestration tier in front of the existing backend, and one side effect of this was that this new tier was acting like a client that we controlled. Suddenly we could see the systemic problems in the backend that were causing real issues and costing millions of dollars. On the orchestration tier we were able to play with some timeouts, some retries, and worked around the backend (while that team worked to fix those issues). These hacks are always tricky, as if you aren’t careful the retries can add more stress to the system and you end up causing more problems! You have probably ran into this type of issue when dealing with account login systems, and making sure that you slowly add latency to the response to slow the system down.

Client Control and Service Workers

One of the reasons I was so excited about Service Workers, was being able to take the orchestration tier approach directly to the client where it can actually do the most good. Once you track what is going on there, and see how many errors happen (due to flaky networks) you will be shocked. This isn’t just about making your app work for Wendy on a plane. This is about working around the systemic networking issues (especially on mobile, but very much beyond with cruddy WiFi and networking in between you and the endpoints).

When Alex Russell first shared what he thinks makes up a Progressive Web Application, the notion of “connectivity independent” was the term he used to convey one of the key features of service workers. He purposefully didn’t use the word offline here, yet too many make the assumption that service workers are just for offline, when this sells them short.

In fact, as I was about to publish this article Alex wrote a new piece arguing this very point: It’s About Reliable Performance, Not “Offline”.

With the low level control that service workers give you, you are able to race on networks vs. caches and validate your state along the way. You also have other tools beyond service workers, such as the page visibility API, which you can use to throttle and batch so you aren’t using resources when the user isn’t there.

Service Workers aren’t “a new AppCache for offline”. They are building blocks for a new resilient Web, and one that can deliver game changing features such as push notifications.

Whenever a new term joins the lexicon it is interesting to see people wrestle with it. I have had plenty folk question “Why Progressive Web Apps?”, relating to the term rather than the features.

As the conversation goes deeper I have found you end up talking about a series of questions that include:

Do we really need a new term? Won’t this become “the web” again?

Yes! We don’t talk about Ajax apps any more, unless we are talking about historical context. We also don’t say “color tv” anymore. I don’t think the term “mobile web” will stick around in the same way for too much longer too, as you almost assume that the “web” at least includes mobile.

Apps? What about web sites?

I feel like this is the most confusing piece for people. It is easy to self-select out of the conversation by thinking “well, I have a website, so I guess I don’t care about progressive web apps?”

No. We are all working to make the web more capable and the menu of capabilities very much matters to websites.

The web has always been fantastic for content, and it continues to be so. There is a reason why there are so many WebViews out there. Actually there are several, but one of them is that the web does a great job at laying out content, and the engine that does this is on every computing platform.

If you think of yourself as building websites, then you are just as much a part of this and can use the new capabilities to make those sites as fast and delicious as possible.

ASIDE: Progressive rendering is something to look into here!

But we need to be able to build apps and not only be locked into WebViews. The ability to progressively add value when the user wants it allows for nuanced usage where your experience can morph for your loyal users. We think the web has advantages here.

So, when you see “apps” don’t think “only for things that my mental model thinks of as an app” and instead substitute it with “have the capabilities that apps have available to me”.

We already have the terms we need: responsive and adaptable

Responsive is a key component of the progression of the Web, allowing us to not just cater mobile and desktop, but all of the screens, however it is normally focused on design.

Adaptable captures more for me, since it invokes more capabilities than design (modalities etc), even though the roots were also in design. The word isn’t that inspiring though, and instead is much more practical.

When you look at the definition of progressive you see descriptions such as:

favoring or advocating progress, change, improvement, or reform, as opposed to wishing to maintain things as they are.

and:

making progress toward better conditions; employing or advocating more enlightened or liberal ideas, new or experimental methods, etc.

I love that. It is future looking without leaving people behind today. We want to make things better for devs and users and this is the path. I would rather progress than purely adapt. One feels like we have some control and are part of the solution vs. moving to find some cheese.

It may be easier to sit back and adapt, but I would rather we pull together to progress. The more diverse we are, the better the results for all.

The mobile explosion came, and many of us focused on the new native app capabilities. Now we have these capabilities on the web it’s time to really take charge of your web experience.

That is why I like using the word “Progressive”, and why I want to help the web progress. I see the huge difference between the web experiences that we are capable of, and the web that I browse around on each day, and I want to narrow the gap between what is possible and what is available.