Dion Almaer

Software, Development, Products

Web Development

Progressive Web-First Apps

Leave a Comment

You have a cool idea, and you don’t think “there is an app for that” yet. The path is clear, right? Build an iOS app, because the VC you are pitching has one in their pocket, and you want high ARPU customers.

When we were in the early gold rush years of mobile, this may have been the best path. There were a few things in your favor:

  • People were enjoying the novelty, and would go to the app store to checking out the cool apps of the day (akin to going to Yahoo! for cool new web sites)
  • There were a lot of popular services without polished mobile apps, so great developers had room to come in with amazing third party clients (e.g. Tweetie, which became the official Twitter client… a pretty common pattern)
  • The mobile Web wasn’t the greatest experience on early mobile
  • Graphs were up and to the right, so funding was highly available. I saw this first hand. For example, after launching the mobile apps at Walmart, if you projected forward, they would eat everything….. but the reality is that there are plateaus when you consider the time spent across various platforms, and there is room for the overall pie to still be growing fast!

Today, the opportunity to have impact is still very much there, and the world continues to keep jumping online, so the user base for your experience may still be growing, but the landscape has new challenges.

  • Many users aren’t going to the app store for discovery, are happy with the apps they have, and aren’t downloading many new ones.
  • The barrier of an app store may hurt your funnel, so the cost of acquisition for new customers may not be in your favor.
  • The reach of one platform is naturally much smaller than the meta reach of something like the Web.
  • We are moving past the “easy” years of only having to worry about 320×480, or desktop websites. Computing is going through much more unbundling, with many more form factors joining ecosystems. We need a way to build for a diverse-computing world.

What if there is another way? Progressive Web-First Apps.

Why would it ever make sense to start with a PWA experience for your new idea?

  • If you want to cast a net to reach as many people to prove out your product, the Web offers the reach. Once someone taps on a link you can get them into the experience to try without an install, and you can iterate quickly with simple A/B testing and the ability to make changes that don’t ever require an [UPDATE].
  • Chances are, you have some level of sharing. Now, no matter how a URL gets to someone, they can participate easily, and this can happen across desktop as well as mobile (and beyond). Other than some simple utilities, a huge number of my apps are getting and sending URLs out, and some are basically app browsers.
  • Speaking of desktop, while we have moved into a mobile world, many ideas can come to life in new ways on desktop and you have the ability to expand in that direction. Even today I have worked on products that have 80%+ desktop usage. Why limit yourself?

Progressive enhancement doesn’t even have to stop on the Web. If you prove things out and get to the point where you need to reach for native applications, you can! The beauty of doing things this way around though, is that you always have a funnel of new people who can access your service no matter what they are on, and for some customers they can go native if that is what they and you need.

But, starting a native app from scratch at that point sounds like a lot of work doesn’t it? You have options here too. Basecamp developers in a way that lets you bring your web investment along with you:

“We just launched a major revamp of the schedule in Basecamp 3. New calendar grid, new day drill-down, new navigation across months. It’s a big change, and we rolled it out simultaneously across five platforms: Web, Windows Desktop, OS X Desktop, iOS, and Android.

Three people did the work in less than six weeks.”

This strategy gives you control when you need to truly go native, and not waste time and effort when it isn’t needed. The features that are still in Web land continue to benefit from A/B testing and releases outside of the store. Not too shabby!

There are many other ways that you can play a similar game. For example, Ionic’s latest products are a great example of leaning into the Web. Stencil allows you to future proof yourself with Web Components all the way down, giving you a fast path on the Web, but you can take that to the native land with the backing of years of plugins.

But, let’s say you didn’t start this way, and you have ignored the potential broad Web users for your product, you are probably blind to the impact falling onto the floor.

Don’t worry, it’s not too late. In fact, there is no better example of turning this around than Pinterest.

We often hear about a new launch, but how did things really play out? Zack Argyle shares his one year retrospective.

The results stunned me:

“Now for the part you’ve all been waiting for: the numbers. Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board.

Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups.

And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).”

Those numbers are not only impressive, they once again show the synergy with the native apps, bringing in users who may end up being happy in the web experience (including those who add to home screen) or may end up with a native app. Either way, happy customers!

ASIDE: Addy Osmani put together a detailed case study with the Pinterest team, to help you understand the work that went into this.

If you think about it, Pinterest is a great use case for this. It’s the type of experience that is on the board of content and commerce. You want to share this around, and for those who catch the URLs to join in, even if they aren’t members.

Just like Henrik, I hope we see much more of this trend. I want new ideas to spring up on the web, reaching users all over the world and giving you as much of a chance as possible to click with an audience. I am reminded of a friend, who built a learning platform that spiked in traffic. It turned out that the spike was because the Philippines ministry of education had decided to go all in on his software. He found his viability through the global reach of the Web.

And, I want existing companies to realize the low hanging fruit that is: making their website modern. On the one hand you can invision new features for your existing users, but on the other you can bring a new seamless funnel that will capture many new users from the Web.

So, crack open Lighthouse. Time for you to be the next Pinterest!

Mission: Improve the Web Ecosystem for Developers

Leave a Comment

Once the dust settled on Google I/O 2018, it was time for me to find a new adventure. I wanted to share where I ended up because I am quite excited about it!

A few teams within Google have joined forces inside Chrome to focus on improving the Web ecosystem, focused on those who build experiences, and create on the Web. I am incredibly excited to be working side by side with Ben once again, and take on a new mission:

“We want to make high quality experiences easy to build as that will enable more meaningful engagement on the Web for users and developers alike.”

What is meaningful engagement?

We have to be careful what we measure. If we only cared about the amount of time that was spent on the Web, it would be tempting to do things that addict and actually cause harm….. just to get a number further up and to the right. We have all experienced sites and apps that seem to do just that, and it goes against our goals for humanity. Google wants to “organize the world’s information and make it universally accessible and useful.” Useful, not wasteful. We want to be a force for good.

Some of the core attributes that show the nuance of what we really want are:

  • We are not striving to get humans to spend more time on devices. This is a strong non-goal, and we care about digital wellbeing.
  • When someone spends time on a device, we would love their time on the Web to be with a great experience.
  • When someone wants to get a task done, we would love to streamline the effort which will result in less time spent on that activity, which is great!
  • We aren’t here to judge the type of activity. E.g. entertainment is meaningful for our users.
  • High performing experiences enable engagement because: Poor performing experiences result in abandonment, frustration, and platform switches; Each good experience results in myelination for reengagement
  • We want all users (reach) to be able to engage with the best possible experience (capabilities) for them.

There is a ton of nuance, and it is fun to spend time as a team thinking about what we want the world to look like, and drive for that reality.

How is the ecosystem doing?


While we have a fantastic, creative, community, it is clear that the Web that you experience daily does not map to the current capabilities of the Web. We are looking to work together to make changes that help close the gap, as when we see great modern experiencecs ship they see huge upside.

tl;dr Pinterest’s example here is the prototype turn around situation. Once a team focused on making their experience great it “became the top platform for new signups and in less than 6 months already have 800 thousand weekly users using our PWA like a native app from their homescreen”).

The future is already here — it’s just not very evenly distributed

One of the core issues at hand is shortening the time from “idea that makes the Web better” to “developers can use this idea and it is better for users”. There are a huge number of steps in between, and we need to shorten each of them. For example:

WEB PLATFORM LAYER

Web standards: Alex Russell recently posted two articles on the world of standards and lessons for becoming more effective. WICG and friends have both brought more web dev practitioners into the fold, and also streamlined the work. Getting consensus takes time, as it kinda should when adding something to the Web platform at this stage of its evolution, but that community is getting better at it over time.

Web compatibility: it is one thing to have a standard, it is another to have compatible implementations for developers. The Web Platform Tests effort has been huge here, and we see continued convergence across the browsers, which results in predictability for developers and users.

Web runtime: it is one thing to have implementations, it is another to have them be the implementations that are used. Chrome started the charge with rolling 6 week release cycles, and pushing continuous updates to users so they are running on the latest and greatest Web. Other browsers have also gotten better here. Being able to update here is critical. Time and time again we have seen situations where users are left on a device that isn’t getting updates and they are left in the past.

WEB APPLICATION LAYER

We see many pieces at play at the Web application layer:

Polyfills: One way to keep working towards the future is to be able to code to it’s interfaces even if all browsers in the wild aren’t there yet. This is where polyfills come in, as without them you either leave users out in the cold, or you are stuck back in time yourself. Getting your loading strategy working up front is important here. We still see, time and time again, web applications service polyfills to browsers that support the features natively. This eats up precious network and CPU, for no reason. It is important that a plan is in place for progressive enhancement that allows you to reach everyone, but deliver the best possible experience when capabilities match.

Frameworks: How do you keep up to date with the versions of frameworks? It can be tedious to keep upgrading, especially with large API changes. What is your strategy for keeping up to date here? For many, the “frameworks” are CMSes such as WordPress and Drupal. It was a huge win for the Web when WordPress supported updates inside of the admin panel. If you have a CMS that requires you to download zip files and do manual work to update…. you are probably spending more time in an unsecure past.

Libraries: We all know how those npm installs can blow up our dependency tree of libraries, so it is important to keep a watchful eye on these and once again have a plan for staying up to date. The nature of this work is tricky, and it is easy to be working with older versions of libraries based on transitive dependencies.

Your App Code: Oh right, you have to write the app itself! Hopefully you have A/B/release infrastructure in place that allows you to roll out the future to some users so you can see if that future is bright or not. With service workers, you have even more control of your application code, but that control means you need to make sure you have bulletproof infrastructure in place so you don’t lose users in the past as they get stuck in a historic cache.

CLOUD / OS LAYER

I remember the days where you had to keep your kernel up to date with the latest in security and performance patches. Fortunately, for many of us, those days are somewhat behind us, which is going to be important for future proofing.

The infrastructure that I would love to see in place, would allow for changes such as a new image format is introduced that is waaaaay smaller and faster:

  • Some browsers implement support and users get the capability in their hands
  • A WASM implementation is made available for browsers that don’t have native support
  • The browser and server are smart enough to negotiate and serve the new format in an optimal way.

Ditto for new networking solutions (as we rolled out QUIC et al). One of the fantastic things about AMP is how this world is available. A developer only needs to create AMP documents, and the rest is taken care of for you. And, with the AMP team constantly improving the runtime and the components, the same AMP page can keep getting better without you lifting a finger. With Web Packaging and the like, it would be great to do more of this outside of AMP.

One of the key notions of the progressive web, is that we are continuously improving. It is one thing to get the processes and platform chain of improvement working, and it is another to …

Make high quality experiences easy to build

You will notice “high quality” and “easy” are both in the sentence above.

Paul Calvano’s great piece on page weight

HIGH QUALITY

We harp on performance a lot, and the cost of JavaScript in particular, these days. We have taken a medium that was designed for streaming content and fast progressive loading and chopped it at the knees. Web development should offer you a pit of success but instead many stacks deliver a poor experience by default. If we could come together to fix one thing, it would be this.

It is one thing to run Lighthouse on an old legacy site and see a low score. You sigh, and know that you need to slog through a slew of work to bring it back to snuff. However, it is another thing to build a brand new app and run Lighthouse on it and …. also see a really poor score. The future we need starts you off high, and keeps nudging you to stay there. It has constraints and a mental model that allows you to scale your application. If you keep adding functionality, the first time to load can’t keep getting longer. At runtime, we can’t end up with a DOM with a million nodes, where the browser can’t keep up on layout, even if you are actually just making changes in one “view”.

Quality isn’t solely about performance though. We all want a Web that is also: capable, reliable, delightful, discoverable, and accessible.

I often think about this when I am on a website that offers the opposite. I had two such experiences in the last couple days:

Commerce experience: I was asked to purchase a gift card from a well known retailer. I first tried to grab one quick on a mobile device. The UI kept jumping around and the form controls actively stopped me from doing correct selections. I then jumped to the desktop version, and it was equally bad, giving me bizarre error messages that made no sense (and were different to those that surfaced on mobile). I then turned to the mobile application to make the purchase and pictured the data folks looking at these types of experiences and thinking “ah, so users of the app have better conversion!” No!

Push the app experience: I was looking to answer a question and ended up on a website that did everything possible to get me to download the app. There are plenty of reasons that I may want an app on my phone, but the “frustrate the user to do so” drives me insane. I buggered off to the next search result to get what I needed. I also picture data folks there looking at engagement and doing comparisons that don’t take into account that they are measuring different user segments. I have run into this time and time again, where the app users are those who waded through everything to get the app and are thus the loyal customers who put up with it. However, how about also opening the funnel to convert “not loyal yet” customers to the next level over time.

EASY

It’s too hard to build a great web experience. I made my own case here when you read through the infrastructure that you need to setup to build an engine that delivers up to date experiences. We have a paradox of choice, and it is easy to second guess yourself all day long (React or Vue? Web Components? Redux or MobX? Webpack or Parcel? etc etc etc).

Once you have made your choices, you have to make sure that they deliver a flow that is productive, and also delivers solid experiences (the PWA starter kit is an example of putting together the pieces that will keep you in the lane). The Web has plenty of footguns, so your experience can quickly become janky. To help us keep on the path we are improving the platform and also setting up Feature Policies that aim to guide. If you are able to policy up, the browser can optimize and users will benefit.

With all this being said, it is easy to miss out on the fact that the Web is still the best way to build experiences that reach users across form factors, and it has key principles that can’t be beat. Being able to fully control deployment on one end, and be able to make live changes in development on the other, is an amazing combination. If we can push through and have a nice native setup that allows for the best of these worlds without making developers live in config hell, we will be in a great place, and with recent changes we are able to get there.

We need a power assistant to help make this all happen. We have so many of the pieces already:

  • Lighthouse as a way to continuously understand how your development, staging, and production are looking in the lab
  • Chrome User Experience Report, Page Speed Insights, and friends to get you data from the field
  • Chrome DevTools is there to help you inspect, develop, and debug your applications
  • There are a few great editors, that are able to tie into the ecosystem
  • Community efforts to guide you down the path.

But we need more. We need to give developers better guidance and help them along. We need the tools to give more insights and give you greater help. You should be able to do more development and design work in DevTools. We need to help frameworks and ecosystems such as CMSes (e.g. WordPress PWA) and Commerce deliver great experiences to a huge part of the Web.

Guess what? We are hiring. If you would like to help us take everything to the next level and light the way to the pit of success, please let me know! We have positions across Product Management, Engineering, DevRel, and more. If you want to help the ecosystem and platform, we are all ears. Please join me on the new journey, one that will help the developers of today, and help us get to the future of a Web across new modes and form factors.

Gearing up the Web for 2018

Leave a Comment

It’s the time of year when you reflect and refocus. With the recent news of Edge and WebKit bringing service workers to their people, it is hard not to reflect on the long journey of bringing rich, some may say app-like, capabilities to the Web.

With 2017 sunsetting (in some ways: good riddance!), I thought back ten years to 2007. You may remember the simpler times where Arnold was the Governator in California, Mad Men and Flight of the Conchords were on the scene, and Steve Jobs showed us his new phone.

In the world of the Web, I was working on Google Gears.

Any excuse to get the zipper image back!

This was a pre-Chrome world where developers who were trying to bring bleeding edge desktop web apps (Gmail, Google Docs, etc) often reached to a browser plugin to deliver the functionality that they needed (Flash and Silverlight). We were seeing a resurgence in using HTML/CSS/ and JS to power the UI, using plugins to get access to some native capabilities — Remember XMLHTTPRequest was born as an IE ActiveX component.

Picture yourself with a Gmail that nailed spam and search so well that Eudora was tossed aside. One restriction though was the reliance of a tether to the Internet. A next obvious step was to take Gmail offline (including that great search!) and improve all of the perf (always an issue ;).

Gears brought us the modules to do just this, and it is fascinating to see which primitives we ended up with:

  • A Database module (powered by SQLite), which could store data locally
  • A WorkerPool module, which provided parallel execution of JavaScript code
  • A LocalServer module, which cached and served application resources (HTML, JavaScript, images, etc.)
  • A Desktop module, which let web applications interact more naturally with the desktop
  • A Geolocation module, which let web applications detect the geographical location of their users (Google Maps any one!!!)

How many of these are still needed to pull off a great web experience, worthy of the home screen addition from a loyal user, even as we have moved to mobile and beyond?

But a browser plugin wasn’t the ideal solution. You want the platform itself to grab onto good ideas and bake them in (hopefully learning from the implementations to come up with something much better). Also, 2007 remember….. with Safari on iPhone, and Jobs said “nope” to the plugin world (and thus the fall of Flash and Silverlight).

Let’s take a peak at the problems we were solving and what the solutions we now have available, with the new context of mobile, and where we can be heading in 2018!

Dealing with data

The Gmail team dealt with much pain on the bleeding edge as everyone worked out how to store (sometimes large amounts of) data correctly locally and sync it with the backend.

We quickly codified SQLite into the platform via WebSQL, which didn’t quite stick. There were issues with baking in an implementation into a standard, but I also wonder how much gas was lost from the effort because the world jumped into a “NoSQL” bandwagon. The many benefits of SQL have held the test of time, and with new innovations such as Spanner, I do sometimes wonder if it wouldn’t be kinda great to have SQL back in the client toolbox?

Instead we got the likes of DOMStorage and IndexedDB, as well as many solutions on top of our primitives. Today we see a lot of usage of Firebase (including the new Firestore which has offline support on the Web!) and there is also large mindshare in the GraphQL space, with great clients such as Apollo.

So, we have a lot of work going on with respect to data, both on the client and how to sync back to the backend, but I think we will see new patterns emerge in 2018 that will put everything together.

Working off thread

As we constructed richer applications through JavaScript, and accessing local capabilities like databases, we needed to be able to do this work away from the UI thread, else the apps became unresponsive. Thus, Gears brought us WorkerPool, which was morphed into the Web Workers standard.

Doing less work on the main thread continues to very much be a key bottleneck, especially in a world of low power CPUs! Phil Walton just posted on this from the vantage point of interactivity, and the lack thereof, and we have exciting work landing and in process.

Browser vendors are hitting this head on in their implementations, with large architecture changes (e.g. Quantum has a lot of this baked in) as well as tactical upgrades (e.g. image decoding happening elsewhere).

We are also seeing new standards that bake new abilities, from tweaks such as img decoding, and large additions such as the awesome Animation Worket that will truly change the game.

When it comes to new capabilities, we often follow the pattern of:

  • Step one: make it possible.
  • Step two: make it easier.
  • Step three: make it perform.

This is one reason I got excited about Surma’s exploration: COMlink, that gives you the same API across windows, iframes, Web Workers and Service Workers — speaking of which….

A Local Serv…ice

The browser was built as a client desktop application that sat on a nice fat university pipe. I remember that world fondly, where I had an Sun Ultra as my workstation, and I could also login to any machine on campus and have my X windows show up just they were.

The network was never perfect, but as it diversified, and our devices walked around with us, we needed to handle the lack of network progressively. The Gears LocalServer module came with a couple of cool features. One of them was the Gears JSON manifest file, somewhat akin to AppCache, that allowed for a declarative approach. Declarative APIs are great until you need to break out of the box. In that case you long for an imperative API that the declarative one builds on. LocalServer gave you a programatic API too, but it was much more restrictive than what we have today in the powerful Service Worker, where you get to fully own the networking layer. With this power comes great responsibility and is one that you need to think through up front, making sure that you have the correct kill switches in place, and processes to fully test.

Service Workers were a perfect example of the Extended Web in action. A powerful building block for us all to build on top of, including the web platform itself, as we have seen with Web Push and friends.

Native capabilities

When the Web is at its best, it allows you to reach the broadest set of users, but also allows them to experience it on their terms. This is why a UI change to make image picking better (often feeling more akin to other image picking on that particular device) can have a large impact. It is also why I have been a fan of extensions, allowing users to customize to break out of the A/B optimizing machines.

Gears had a Desktop module that allowed you to drop an icon for your web application that could now serve locally and store data via SQLite.

Home screen access is even more important in the world of mobile, so that is where we first saw this support via the Add To Home Screen API. This doesn’t mean that I don’t want it on my desktop too though, and I look forward to great desktop PWA support in 2018!

Gears drove some of these native capabilities, and in general I like to see developers being able to push the boundaries, and having the platform standardize the good ones later. This is one reason that I keen to see how developers use Trusted Web Activities, which gives you the ability to bridge native and Web in a new way.

Now we have seen how the specific Gears modules have baked themselves into the core platform. It is also interesting to look at the areas that weren’t a focus then, and how we are now going well beyond the issues of the day.

The Google Apps of the day were large codebases. Throngs of JavaScript were being flung, and Closure was the weapon of choice to keep the codebase sane. We got through the ES4 detour, and I am happy to see that with ES2015 we have put our requirements into the language versus comments.

Layout wasn’t as much fun back then. Without Flexbox, we had to result in a lot of tricks that required JavaScript, and we had to manually (read: use a lot of resources :/) check on what was in view versus using APIs from the Observer family (Check out Eric’s examples of the new ResizeObserver addition!).

These days we not only have Flexbox in the toolbox, but we also have the fantastic CSS Grid, and one fun way to master it is by “playing” with Dave’s Grid Critters.

https://mobile.twitter.com/trueadm/status/944908776896978946

When it comes to bringing capabilities wrapped up in native code, we now have WebAssembly at our finger-tips. I am particularly curious to see what gets wrapped and made available for the masses.

And what better way to do the wrapping that via Web Components. We have long dreamt of the ability to reuse rich UI components that were fully tested and had high quality accessibility support. It used to be frustrating to see an amazing YUI widget, that you couldn’t bring into Closure land. We are finally getting to the point where this is no longer an issue, and with SkateJS, Stencil, and Svelte joining Polymer and friends, we can share and compile like never before, and it is starting to feel like 2018 is the year of the Template Literal Libraries.

When you put this together, we can have the semantics of <something-cool> that could be wrapping rich UI and WebAssembly code under the hood.

We still have much to do, but the pieces are coming together to deliver rich experiences that can be constructed and combined by creators. In a world where we seem to spend more time consuming, I sincerely hope for 2018 to be a turning point for more of a read/write Web, and world.

Not only are we seeing the features come to light, we are seeing browser vendors coming together to implement them with haste, a huge difference from the time of Gears and ChromeFrame.

So, here’s to more green in 2018, something that I was excited about in the Chrome DevSummit keynote that I got to give with Ben:

I am curious to hear what you are looking for in 2018. It has been a lot of fun to read existing thoughts from the various end of year countdowns, and a big thanks to Mariko for inviting me to write this for http://web.advent.today/!

The right thing to do, is the right thing to do.