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:
Include frameworks in the Chrome Intent to Implement process
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!
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 amazingseries 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. WithrecentObservers, 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:
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.
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!!!!!!
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!
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:
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.
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.
“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.
“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!