THE BLUE PWANET

[Music] Well good afternoon everyone.

I know that in those comfy chairs with the ambient sound of like underwater music and after lunch it can be a bit dangerous.

But thank you for being here to listen to my presentation, The Blue Planet.

This is something I remember from the blue planet when I was a kid that my mom used to put us to sleep with watching the blue planet so hopefully it doesn't go the same here.

I am thrilled to be here at state of the browser to discuss about PWAs.

Yes they're still a thing, yes they still exist and yes we're going stronger than ever.

I regret to inform you though that due to me not starting the slides on time.

I wasn't able to get David Attenborough to come and speak at the event.

So you'll have to settle with me, slightly less white man to narrate for you all.

But yay diversity in tech.

So my name is Diego, I am a senior product manager working for Microsoft on the Edge team.

I've noted all the comments from Microsoft that have been going on the conference, so thank you Thank you for that as well.

And specifically looking at PWA features that are coming to the web platform itself.

And I just ask, even though you know of my association, please do not take any information that I will share in this presentation as an official statement from my employer.

I come here as a person, hopefully with some informed opinion, willing to shed some light on the life of and around PWAs and more importantly about the state of the browser regarding PWAs.

So let's get it on now.

It is hard to pinpoint when the dawn of applications on the web started.

There have been many iterations of technologies, frameworks, plugins and concepts that have gotten us to the very special point in time where we are right now.

Ajax introduced the ability to change parts of a web page without having to reload the entire document and this opened a new world of possibilities.

We've come a long way since then and I want to go through some of the little things that have been going on in this blue planet of web apps.

But my journey with PWA started in a very different planet, a purple one.

It was already some years into the technology itself and there was a big push to allow applications to be present in the home screen of a mobile device.

This was known as the add to home screen capabilities.

Now the add to home screen capabilities, the novelty was that the PWA, if it included a service worker and a manifest file, then the browser would be able to signal to you that this was a higher quality application.

This would basically integrate with your mobile device.

But this integration basically consisted on having an icon on your home screen.

There was nothing more than a glorified link.

There was no presence in the app drawer in Android, there was no presence in settings, and there was no sign whatsoever of integration into the operating system.

These were the humble beginnings that paved the way for the evolution of progressive web apps.

In the past, different browsers would allow you to display, would allow the PWA to display a UX affordance that would get your application into the main screen of the device.

So this prime real estate was once only reachable for a few, but the web is constantly adapting and reaching every corner and capability of their platform-specific counterparts.

Much has happened since the days of the Add to Home Screen.

But let's take a step back and ask ourselves, what is APWA?

That's a pretty good question back when it was defined by Francis and my friend Alex.

The list was more or less the following.

It needed to be something responsive that would adapt to different layouts.

Connectivity independent because we were able to cache and get the application working offline.

And it would be a website that took the right vitamins, citing Alex.

With app-like interactions, something that can remain fresh, easily updated via the service worker, safe, delivered by HTTPS, discoverable and identifiable as an application through a manifest file, re-engageable with APIs such as push notifications, installable, and probably the most important one of all, linkable, which is the superpower of the web that no other platform-specific app had.

But what does all of this mean?

How does a PWA look like?

Thanks to AI, we can have a better picture about one of the more deeply misunderstood technologies of the web.

And I'm not talking about WebRTC.

They look harmless, but they are very, very powerful.

Legend has this.

Legend says that a red panda once tried to eat a distant relative of a PWA, and it got so sick that it ran away and never wanted to try them again.

So the tale that's sold this time, there are three different technologies that compose the concept of what a PWA is.

HTTPS, having a manifest file to be able to identify itself as an application, and a service worker to tap into advanced capabilities like resource caching and push notifications.

For many years in the Chromium ecosystem, these three technologies served as the Trinity for installing progressive web apps.

And this was a huge part of how the installability criteria was defined.

So I want you to think right now to yourselves, are these technologies associated with quality of a resulting application in your own developer experience?

How many of you here develop applications for the web?

So keep your hands up.

And from the hands that are app, service worker, yay or nay, That explains a lot.

So as with many other species and technologies, survival is not guaranteed.

Apps must adapt and evolve to ensure their continued existence.

And in the case of web apps, connecting into the unique strengths of the platforms they are running in can be the difference between life and death.

I'm trying to channel my inner David Attenborough.

The web platform continued to expand its capabilities, working on enabling new scenarios requested by developers to bring newer, more capable use cases to the web.

The Web Capabilities Project, also known as Project Fugu, kept pushing the boundaries of what was possible for the web, while at the same time, PWAs were finding a breath of fresh air in a new ecosystem.

the desktop.

This synergy of apps and web and a new ecosystem resulted in deeper integrations with the host operating system, infinite new ideas for advanced applications, and the realization that web technologies allowed to have the same app, same code, and they could be running on a new platform, all thanks to responsive design.

Additionally, there was the idea that a PWA didn't have to be a lesser experience.

A PWA didn't have to be a light or go, as it used to be back in the day of mobile PWAs.

This was starting to fade, and Fugu Collaboration started creating exciting capabilities for developers.

Now, regarding Fugu and Web Capabilities API, the Web Capabilities Project, as I mentioned, commonly known as Project Fugu, is a joint effort between companies like Google, Microsoft, Intel, Samsung, and others, the drives to bring powerful APIs to the web platform.

Very much like the Fugu fish itself, the puffer fish, which you can see here in the image.

It can be delicious if it's prepared correctly, but it can be deadly if not.

And that is kind of like the fine line that we're generally walking when we are designing new APIs.

Every new feature that is developed under this initiative undergoes strict privacy and security revisions to make sure that they are as webby as possible.

And these are powerful APIs that aim to satisfy developer needs.

While the end goal of the web is not necessarily to be a native app replacement, I believe that we need to push forward with new use cases that will elevate the platform.

Some of the capabilities that are relevant to the entire web platform, like the ones that you have right now on screen, for example, access to hardware devices or access to certain type of system resources like font or clipboard.

And some other very powerful capabilities are gated behind installation.

For example, window controls overlay, file handling, shortcuts, web share target, run an OS login, protocol and link handling, it makes sense to have them gated behind installation because they only work in the context of an installed application.

There is also an extensive work in aligning what a PWA is to the mental model that a user has of what an application should be.

We decided at Microsoft to get heavily involved making the desktop platform the absolute best ecosystem for PWAs.

And I am not here to discuss partners, but I can tell you that ever since we started on our mission to make sure that Windows is the best place for web apps, we've seen that the biggest fish that are coming to the Microsoft Store are all PWAs.

Also it makes sense to say here that every single feature that we are developing for the Windows platform, we are making sure that it's equally supported on macOS and on Linux counterparts.

Among the fish a wave, we see hundreds of millions of minutes spent every day on PWAs with a steady year-over-year growth only on the desktop platform.

So let's take a quick look at a small example of how we are making the desktop platforms the best place for applications created with web technology.

What do we mean by deep integration into the operating system?

You might have noticed that when you go into certain applications, the browser itself will will prompt you into installing this application.

On Edge, on Windows, and with the default language set to Italian for some reason, this is how the experience would look.

Once you actually install the application, you get access to a specific set of features.

One of them is window control silverlight.

You can see here on the area on the screen that's behind the red rectangle, that this area is a area that generally would be used by the title bar on a desktop operating system, Windows, Linux, and Mac OS.

We've enabled the developer to put arbitrary web content to create a more modern UI.

Native applications have been doing this in the past, and we thought it makes sense to give this capability to the users.

There is a display override value and new CSS that makes this easy to control.

And don't worry, Kilian, we are making sure that if there is a JavaScript API for that, then you can do it as well with CSS and HTML.

Developers can now create applications that include search boxes, profile icons, and advanced menus in their applications.

But deep integration with the host operating system goes beyond just allowing applications to look right at home.

When the application asks the host operating system to register as a file handler, for example, this means that it needs to appear in settings and other relevant user experience.

For example, if you add in the manifest file a file handlers registration, then once the application is installed, it will appear on the operating system prompt to handle the specified file type.

You could even make your web application the default handler for a specific type of file.

Another good example of deep integration into the application, deep integration of the application into the operating system, is shortcuts.

And these will vary depending on the platform where you're running your application.

On Windows, Android, Linux, and Mac OS, They will all surface either on the dock by holding on the application icon on the home screen or on the Windows taskbar.

And these offer a surface where you can deep link into your application.

And again, notice that the common denominator here about gating something behind the installation is using the manifest file.

Finally, WebShare target.

This is another prime example of an application appearing in native operating system UX.

You can press share from anywhere on the operating system and if your application is a shared target then it will show to the end user.

Now the web is powerful, the web is very very powerful.

These are only a subset of things that a web app can do on desktop ecosystems at the moment.

This works consistently across Windows, Linux, and Mac OS if it's supported on these platforms.

So yeah, the web is very powerful and more parties are jumping on board.

Turns out that the planet is big enough for new whales to push their way in and notify everyone that it's better to be slightly late than to never arrive at all.

And this is where the waters are starting to warm up.

There's a possible change coming to the planet.

What this means in general can be very positive, but at the same time we need to be cautious as to what we want for the platform and what we are building for the platform in general.

You might have heard of a debate between terminology.

PWAs, web apps, home screen maps.

What is going on?

How many, I'm going to ask again, how many of you build applications?

How many of you consider those apps to be web apps?

How many of you consider those apps to be PWAs?

Okay, so how many of you consider installation of a web app a benefit?

Okay, that's good.

And how important are features that have deep integration with the host operating system for your application?

OK.

So basically, it tends to go down in number.

But that is what we are seeing.

And I'll open a parenthesis here.

This is a personal hot take.

The point it is warming up, after all.

But I believe that every PWA is a web app, but not every web app is a PWA.

And I know I'm probably gonna get a couple of angry tweets and I'm probably gonna get some, yeah, people that do not agree here, but there are many fishes in the sea and some of them are web apps that can access certain web capabilities, yet do not have a service worker, yet they do not work offline.

Hence, they are not a PWA by definition.

And this is OK.

It is perfectly all right to have a web app that is not installable.

It's just not a PWA.

Does this imply, though, that we should deny its installation?

Does this imply that the browser should not be asking for the user to be installable?

That is the big debate that we're currently having right now.

I personally envision PWAs as a gold standard for web app experiences on all devices.

The core three technologies that we mentioned at the beginning of this talk allow for installation and offline use capabilities.

And that is the, that would be the equivalent to a compiled app that you would have on a native platform.

So this is the beginning of a whole set of features that we can enable to make sure that the web experience is equal to the best class experience that you can have on a native platform.

I'd like to think of PWA as a badge of honor that ensures quality of the application itself.

But at the same time, I believe that as browser vendors, we have failed to provide sufficient incentives to make sure that developers care about quality in apps.

And I'm not saying that most of the apps are not good quality.

I'm just saying that we need to be doing more to make sure that you care about providing these type of advanced capabilities.

And we have failed at making developers, developers, developers, developers want to make their web app a PWA.

And this is concerning for us, for me.

We've come short at even making developers aware of PWAs.

It is incredible the amount of conferences that you go and talk about PWAs.

And while people have heard about the concept, they are not really sure what it is, what does it mean, what should a PWA even do?

So empty service workers to pass installability criteria checks are a reality.

And we can see from the data that we have on screen, this is from a chapter that I authored in the HTTP Almanac last year.

It's not a nice picture.

Installability criteria, which pretty much means that you would have to have both a manifest file and a service worker.

It's the minority of websites in the web platform.

So the questions here are for us browser vendors, are we talking to the right people?

Are we missing out on fixing the biggest grievances that developers have with technologies such as service worker?

Are we ready to open the floodgates to lesser quality apps?

Spoiler alert, it already happened.

But there are clearly things that need to change.

And this is something that is on the minds of us browser folks.

On this topic, what is the state of the browser regarding apps?

And I'm not talking PWAs.

I'm talking about general applications, apart from PWA.

The consensus seems to be that everything should be installable.

And I followed up conversations that were held last week in Seville in Spain, which main topic gravitated around web applications and installation.

There seems to be the consensus that, first of all, the user should be in control and that they should be able to install everything that they want.

But this is already happening.

For transparency in Edge, we have a site as an app concept, which allows you to install any website that you're using as an application.

Chrome has exactly the same thing.

I think they call it shortcuts.

And then you click on Open as a window.

And Safari just recently added an Add to Doc option on the Share menu.

So this kind of begs the question, should the installability criteria change?

And probably Alex Russell is going to be mad at me for saying this.

But I think this is a really interesting thought.

We should be thinking change for whom or change for what.

Not all applications are created the same.

And it is not in a specification what the behavior for leveraging a browser affordance is.

So Chrome has already dropped the service worker requirement to be able to prompt for installation of applications.

And this pretty much means that any web application gets the same treatment as a full-blown high-quality PWA.

Is that all right?

Is that wrong?

We're going to have to find out because we're experimenting.

You can rest assured, though, that browser vendors are looking into what this means for applications and for users.

This is definitely a pressing issue that's on my day-to-day.

So where are we heading?

The landscape keeps changing.

Installation is a hot topic at the moment, and there seems to be some sort of consensus around a new API that can enable this capability for applications.

So, hot off the presses, I'm talking here about the Web Install API.

This is an idea that has been floating around for several years now.

It's a simple, very simple, yet very powerful API that would allow a website to install another website.

That's profound.

It can have profound implications for the web platform.

You can see the explainer at ak.

ms/webinstall.

With the Web Install API, a website would gain the ability to install other websites or web applications.

This is something that we're still debating.

This would allow the platform to distribute applications without the need for proprietary workarounds that's happening at the moment.

like custom protocols or redirections to platform specific app stores.

So we would be enabling the platform to distribute applications.

It would be a capability that would be baked into the web.

The API ends at simplifying same and cross domain installs.

This would see a more ergonomic way of installing same domain applications.

So if you're not a fan of before install prompt, this might be your lucky day.

And the challenges here are that we want to do this in a way that preserves the privacy of users and avoids installation prompt spam.

We don't want the mess that notifications were to happen all over just sites prompting to install different applications.

So who gets to install an application?

Do we need a denomination of an application or a website as a store?

Should this be gated behind installation?

I don't have the answer yet.

But independently, imagine if you could just install an application by referencing its manifest ID.

How cool and elegant would be to just have this capability baked into the web platform?

We're also looking at checking if the application has been installed and changing a site's UX based on the installed site of an app.

Therefore, you should be able to go into your favorite online repo, and if the application is already installed in the browser, it should be able to say, hey, open instead of install.

Moreover, do we require or enforce installability criteria?

And this is one of the other hot topics that currently certain browser vendors want to remove all installability criteria.

Others want to keep some of them.

Others do not want to remove them.

What does this installability criteria look like?

Pretty much every browser has a different concept of what defines an app to be installable, or what is an app anyway.

How will the higher quality of PWAs come into play with this API?

Now, it's looking very likely that the work will be split in two.

And we will have different levels of support on the API between different engines.

And yes, you've actually heard correct.

I said engines and not vendors.

So this is an exciting time for web apps on the platform.

And I've just asked from you to stay tuned, because I'm particularly interested in your feedback.

Please come and find me and chat to me about your opinions, rants, or other when it comes to installation.

If this is a use case or something that you've been looking into then.

We're looking to define an API that works for your use cases as the end of the parenthesis.

I can go now to my very poor David Attenborough imitation.

As the concept of apps diversifies, the planet also expands.

Ecosystems grow and leaving the philosophical depths of application classification, we arrive at the shoreline where new surfaces for apps to be installed appear and new hybrid creatures have appeared.

Two new areas for PWAs to expand are widgets and the sidebar.

Widgets allow a PWA to have a companion experience as a widget.

On Windows 11, widgets appear on the left side of the desktop But with Mac OS, Android, and iOS supporting similar widget UX, it might be an interesting area to look into further standardization.

It is noteworthy to say that it is not the full PWA that is running on the widget.

This is more a companion app.

The developer cannot render HTML or CSS yet-- and this is something that we are looking into-- on the widget itself.

It is basically using adaptive card templates that can be bound to data and actions, hence serving as I mentioned companion UX for your application.

And all of this would be defined through the manifest file.

The other new surface for PWAs is the sidebar.

And this is an area that is in the browser that appears on the side of the window and it can host applications.

Our current proposal looks at being able to define the preferred installation place for a PWA and preferred size.

If any of these are of interest to you, you can have the links there, aka.

ms/sidebarapps or aka.

ms/pwa-widgets.

For the sidebar apps, we are adding a new display override value, the same way that we did for window control overlay, the same way that it's working currently for tapped PWAs, it will be a new display override value, which means that it can be detected in CSS, there's going to be even media queries that will allow you to change the layout of your application if it's running on the sidebar.

And you will be able to specify the preferred width to which the sidebar will open once you click on the icon that will appear on browser.

Now these are for now edge only initiatives.

We are looking for interest from other browsers that might have similar surfaces to implement this.

And while fish in the sea have their nomenclature and identity crisis going on, niche use cases continue fostering the evolution of new types of apps.

Creatures that can live disconnected from the water in their isolated safe environments are starting to appear.

Packaged in web bundles signed by the developer and distributed in ways that differ from the traditional web model these new habitants of the planet prove that life or apps always finds a way.

Thank you very much.

[ Applause ]