Dion Almaer

Software, Development, Products

Web Platform

Delight developers in ecosystem-enhancing, easy to copy ways

Gibson Biddle came to give a product leadership talk at Google and one section really stuck with me. He mentioned how he came up with a simple statement that packs into it the role of product, while he was VP of Product at Netflix:

“Delight customers in margin-enhancing, hard to copy ways.”

– Gib

So short. So simple. Yet, much to unpack. For example:

  • Delight customers: The Kano model discusses the role of delight and how “Users don’t expect features that delight them. Consequently, if these features are not there, customers will not be dissatisfied. However, if they are present, they can easily have the biggest influence on the customers’ level of satisfaction.“
  • Margin-enhancing: A ha. The business side that reminds us that we live in the real-world, and life isn’t solely about thinking through what the user wants….. as that won’t matter if you can’t survive or thrive, which is necessary to fund more delight. I now look out for the obvious bits here…. E.g. when you can’t just buy a book on the Kindle app on iOS. That restriction isn’t in place due to user-centric reasons.
  • Hard to copy: show me the moats!

I work on a developer platform, and a very open one at that, so I got to thinking about how a version of the statement would make sense for the Web Developer Ecosystem team, and came up with:

“Delight developers in ecosystem-enhancing, easy to copy ways”

– me

How does this unpack?

Delight developers

A platform needs to bring a supply of users to the table, for developers to have an opportunity to reach.

ASIDE: One of my kids asked me the good ole chicken and egg question, so I showed him:

And then for fun, I asked:

It was fun chatting through the birth of computing, and how the first users kinda were developers too, etc. It was also interesting thinking through various platforms and the stage at which third party developers were allowed on, and how it often depended on how valuable the host of the platform was as-is.

For example, the iPhone started first party, with Safari running the back catalog. The radio on the other hand….. I don’t remember it having any saved content that you could listen too if nothing was on the waves!

Anyway, back to delighting developers….. it’s important that we bring the meat of ROI (lowest cost to build your best experience for a large supply of users) but also the delight. Features such as this:

Value attracts, quality drives loyalty, and innovation differentiates.

Ecosystem Enhancing

Whatever we invest in should be enhancing the ecosystem. This means that we shouldn’t be thinking short-term. It means we should be thinking about the diversity in the ecosystem. One of the beauties of the Web is how anyone can make a home there. Grab a domain, and bob’s your uncle.

As a platform, yes you are a match maker of sorts (users and developers), but the long term aspect means that you aren’t just measuring hook ups, but family and societal growth that comes of the matches.

How do you notice weeds in an open ecosystem? You see silos that go over the top, and there are pure winners in verticals that stomp out competition. If you aren’t measuring and looking for the right things, it can look like engagement is going up and all is good…. when in fact the diversity is rotting away. We don’t want walls that keep people in and out, and even when we see people really enjoying a set of flowers, who knows how long that will last. Fashion’s change, and flowers can die out, so it is vital to not be all in on tulips.

In a healthy ecosystem, different parts interact in complex ways. You can mashup content, and someone can use an extension that makes something work better for them. The platform should be watching out for new patterns and work to bake them in so many can benefit.

Easy to copy

Rather than building first party competition that is zero sum game, we want to inspire the ecosystem and do so in a way that anyone can easily build on what we do.

We want to share building blocks, and help any sub communities throughout the stack. Open source enables us to not only share our own work in a well known way, but it also means we can participate and help other projects.

We see this in so many ways. From Chromium, to our guidance, libraries, and tools (DevTools, AMP, Lit, Lighthouse, workbox, you name it!), and with communities such as WordPress.

It’s incredibly fortunate that we can work in a way where we legitimately want sharing and copying, as we work together to garden the ecosystem, and make it the best destination to draw in more humans to play with us.

And thank you, Web community, for all of the creation and curation that you do.

Becoming a better Pacesetter for Web Developers in 2019

Leave a Comment

Roger Bannister breaking the 4 minute mile barrier

When you work on a platform, you quickly feel how you are one part of the overall ecosystem. The Web is a huge ecosystem with diversity galore. Web standards, multiple browsers, a huge number and variety of devices, a plethora of tools and services available. It can be quite overwhelming at times!

Over the holiday break, I was naturally noodling on our role, and how to help improve the Web. As is cliche for this time of year, I jumped aggressively into the desire for healthy habits, and went on (short!) daily runs, often with my dog, or 9 year old son. When running with Josh, I started to think about the role of a Pacesetter:

“A runner who leads a distance running event to ensure a fast time and avoid excessive tactical racing.”

I want 2019 to be a year in which we will run to where the Web community is today, and do all we can to train to get in shape for where we all need to be.

We want developers to be successful on the Web by shipping great experiences for our (collective) users. Part of this success revolves around us setting up the environment (the meet) to have as many users available as possible, setting up the rules of the game, and helping developers train and get better.

The Goldilocks Pacesetter

What does it take to be a good pacesetter? You need to make sure that you aren’t on either end of these extremes:

  • If you are too far ahead of the runner then you are no longer making pace for them. They can’t reasonably keep up, and thus you may as well not exist and they will go back to their natural pace.
  • If you are running alongside them, even cheering them along as you do so, you are also not doing your job, and they won’t improve as much as they could.
  • If you win the race you are not doing your job, you need the runners to trust that you are going to do the job you agreed: to make the race fast and competitive and let the racers race.

We need a balance, pushing the pace in a way that is achievable, yet naturally will contain stress (in a good “the only way to improve” way).

How are we reaching developers where they are today?

At Chrome Dev Summit, we shared how we understand that we partner with frameworks, to deliver the surface area that developers use to program for the Web, and how we want to work closely with them:

  1. Include frameworks in the Chrome Intent to Implement process
  2. $200,000 of funding for improving performance best practices in frameworks.
  3. Increased collaboration with frameworks from the Chrome team.

We also know that we need bring the APIs that you need, to make the Web more capable, allowing you to bring your best experiences to the Web. This also includes enhancements to the UI toolkit of the Web, allowing you to build rich, fluid, UI.

We all know there is work to be done there, but we also have more tools available to deliver high quality UIs than ever before. The stack is changing. Salesforce posted on the change they have seen between 2014 and today, and how it enables them to take a very different approach using Web Components. This standard, shared API, gives us interoperability across frameworks. They can invest in fast, accessible, <killer-components>, that work with all. These components could even progressively change under the hood, allowing features such as various Worklets, and a scheduler to improve the experience.

Where do we need to be?

If we work together, we can break the four minute mile equivalent for the Web, which is delivering an instant, responsive, jank-free experience for our users.

There are many types of Web applications, with a variety of trade offs. A tool such as Squoosh is a different beast compared to a content site, or an e-commerce store. We want to deliver a platform that can work well for the variety of use cases we see on the Web, and collectively learn from each other on patterns to build such experiences.

Now we have a challenging goal, it’s time to jump into the New Year, and put in the work to achieve it!

p.s. As always, I am always very interested to hear your thoughts on what you need from the Web platform and ecosystem, and what you would want from a Pacesetter!

It’s time the Web did some Undergrounding

Leave a Comment


I live in a simple neighborhood in Palo Alto, California. My street is fortunate to have some nice old trees. We have small houses that the wealthy are slowly purchasing, tearing down, and then filling up the entire lot with house. From most vantage points it looks quaint, but then you get the wrong angle, or you go into someones back yard, and an ugly face is shown: a hodge podge of cables and wires are strung up from old pole to old pole.

I have asked neighbors why this is still the case, and I hear a variety of stories. Some believe that everyone has to come together to pay the city to underground this all, and no one has been able to get everyone on board. A hefty storm that knocks out power, or god forbid… Internet, will surely be the trick? Nope. It’s been long enough that surely it’s time to underground this infrastructure.

This is how I feel about the Web right now

We have had many successful undergrounding stories in the Web’s history. That is somewhat obvious, as the mere act of standardization is a key part of the process. It is long known that innovation in new and rapidly changing areas isn’t for the standards process (see Alex Russell’s amazing series on how that world works best). It’s too hard to “get it right, first time”, so basic risk management would suggest that you allow innovation to happen in a few branches and once you have enough data to suggest a decent (you don’t need to fall for the nirvana fallacy!) path, get enough consensus to drive the implementations that beget a true standard.

We see innovation happening all around us. Sometimes we look to other platforms to learn from (e.g. looking at iOS and Android to give us solid clues for how to bring mobile capabilities to the Web), and one other strong source is user space and the Web community. How are web developers solving their problems with various libraries and frameworks? In fact, as we push more capabilities into the platform, allowing a more Extensible Web, we should see even more of an ability for experiments in user land.

If we don’t come around and look for areas where we can take the experimentation and bake it into the platform, we will fail users when it comes to performance and the potential for richer user experiences.

Why will we fail?

The Web is an amazing streaming platform that allows for ephemeral applications that can be controlled, to a large degree, on the server. This is incredibly powerful, and we shouldn’t lose sight of this massive benefit.

However, a trade off like this doesn’t come with zero cost, and we should look at how to balance any cost. We have been doing some of this with stronger caching primitives, service workers, etc. That’s great, but until we can contort the law’s of physics, it will be true that shipping capabilities comes with a large cost. In an ideal world, a website that delivers a shopping experience for users will only send down capabilities tied strongly to said experience. It is less than ideal to also send down large infrastructure (affecting both load and runtime).

When we standardize and put something into the Web platform itself, we get the benefit of a shared core that user space can progressively rely on, and we are able to use a couple more tools as we do so. The platform in the browser has access to the native platform below it, in a way that you just don’t have working on top of the standard Web.

We see the benefits time and time again. With recent Observers, we can get away from the jank-ridden experiences that we have all felt from being on websites that take over scrolling and try to be too clever.

One of the largest undergrounding projects of late has been taking the great ideas in jQuery and bringing them to the platform via querySelector(s), fetch, classList and more. jQuery itself learned from the likes of Prototype, MooTools, Dojo, and others, and offered a slightly different approach. As we in turn learn from this corpus, it is important to realize that we didn’t just “take jQuery and bake it in”. We are often asked to do this, and it’s alluring. I instigated the Google Ajax CDN project back in the day, to answer “can we just cache things so we aren’t downloading the same darn APIs all day long?”

Caching is good, but it isn’t enough. There are tactical issues (how developers bundle, versioning) but there is also the fact that you need to do things differently when you bake something in.

Looking at cabling in my neighborhood again, when a city does this, they don’t just take the same cables and dig a quick hole to shove them in. Once those cables are underground you have new constraints. It’s hard to get to them when something goes wrong, so you want to protect them in a more rigorous manner. The same is true when you standardize something in the Web, as once it’s there you will be maintaining it for ~forever. You can learn, add the new constraints, as well as the new capabilities that the core platform gives you…. and the outcome should be *better* than before.

Ok, so what should we underground?

The details matter. What are the areas that are ripe for undergrounding in 2018? Let’s take a look at the landscape. Capabilities are unbundling across a diverse set of form factors, with new modalities and we are moving past the world of:

  • mobile == certain size screen, touch, camera, and location
  • desktop == keyboard, mouse, another size screen.

If you heard about the recent “Made By Google” event, you would have seen how these things are blurring (touch on laptops, voice and screens together, etc) and we haven’t even gotten to the world of mixed reality and friends.

What are the “jQuery of today” fashions around us? The world of React and Vue add to Web Components to show a world of strong componentization. We can also see other point solutions that many of us are using, e.g. fonts (google fonts and typekit), analytics (google analytics and friends), and adtech (has a huge impact on performance).

There is a lot of fertile ground, and I have been reflecting on:

UI Components


We have a series of components baked into the Web, but as we opened up the ability to create your own with custom elements, we slowed down any that just come with the platform. We started with a myriad of document related tags (including many that we rarely use…. <aside> etc). Then we had form controls, and shoved a universe into type=”mwhaha” on input. I think it would be worth spending more time on the UX of these form controls. It often feels like we get a lowest common denominator out there (which maybe works when we wire it to the native platform) and the user has to do something custom, from scratch, if they want it to differ in any real way. Now, I am looking at type=date, and the type=number where I picture users seeing tiny up and down arrows. We should allow developers the ability to style form controls easier, which would also help a lot with accessibility. This isn’t easy to change, for sure, and the edges are rough.

Left shows the old version, right shows Chrome 64 (thanks Henry!)

In other areas, we did keep iterating. For example, the first image picker on Android had an incredibly weak UI, with a simple file picker, compared to native apps that would show you recent photos that you quickly tap on to be done.

Then we had the need for application UI controls, going beyond documents and forms. How often have I heard:

“Just give me a UITableView that works!!!!!!

Often.

And you can say the same for many other common components. Surely, a developer can hunt around and maybe find a Web Component, or a component tied to a framework, but for many of these the platform could do more heavy lifting AND not require the download and runtime costs.

NOTE: Giving everyone the ability to build components in the platform is a huge win in my book. I am excited that I can build a leaf component that I know will be reusable for a long time to come, no matter which set of libraries of framework I am using in the future. In larger companies, you almost always see multiple frameworks in use (*takes a peak in google3…. oh my!*), so why not at least have the capability to share. This doesn’t mean that you leave your framework of choice behind, far from it. You will see some great examples at the upcoming Chrome DevSummit that marry custom elements with frameworks!

App Architecture

It’s not just about visual components. There are common app architecture patterns that we drag around with us. I would love the platform to offer me a rich state machine with a reactive data flow. For the devices that we run on, and for the multi-modal world, we need to think about how to offload work from the main UI thread. The browser continues to do more and more of this (e.g. compilation of JS, image decoding) but we also need to do more for developers to give us units of work that we can decide where to run. We are seeing good work here via APIs such as Workers (Comlink, WorkerDOM), and Worklets:

I start to get really excited about this world. If we put it all together, we can get a Web that finally has truly reliable jank free fluid UIs, with fantastic components, and needed architecture pieces, allowing the frameworks to up level and work on the next key areas of exploration.

The Web is all about collaboration. I am enjoying working with the community and especially the framework world. But what about yourself? What would you like to see?

I am enjoying Paul Lewis and Surma chatting about some of the possibilities, and how to keep a clean main thread, so you may too:

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