Code is Once more streaming to you from a place now called Sydney.

And I would like to begin by acknowledging the Gadigal people of the Eora nation, the traditional custodians of the land from which we are streaming and pay my respects to their elders past and present in the spirit of reconciliation.

We acknowledge the traditional custodians of country throughout Australia and their connections to land sea and community.

We pay our respect to their elders past and present and extend that respect to all Aboriginal and Torres Strait Islander peoples and all first nation peoples to.

Welcome back to day two of code.

I hope you've got the chance to take our trivia quiz after last week session.

But if not, there's still time just click the puzzle icon in the sidebar, which will take you straight there.

And remember there's another round this week.

So play close attention to every presentation.

You never know what question.

Hi, I'm Rosemary from Web Directions here at Web Directions.

We've long worked hard to create inclusive, welcoming, respectful environments for everyone involved-speakers attendees, and partners.

That's why we adopted our code of conduct many years ago, and why we ask everyone involved-ourselves our speakers, our partners, and our attendees to adhere to this code of conduct.

If you have any concerns about the behavior during the conference or any questions at all, don't hesitate to contact me at the front desk, which is available from the sidebar.

I'll be there the entire time.

And I'll get back to you immediately to open day two of code.

I can't think of anyone better than Alex.

Russell As I, and others have already mentioned during the conference, Alex and his partner, Frances Berriman coined the term PWA in 2015.

And for many years now, Alex has been hugely involved in helping the web become the powerful platform.

It is through his work as co-founder of the highly influential dojo, toolkit years on the Google Chrome team.

And now at Microsoft working on Edge As well as through his extensive writing and work at TC 39 and the W3C Alex has genuinely done as much as anyone to help the web become the platform it is.

It is our privilege to have Alex Russell open day, two of code.

Hello, I'm Alex Russell.

I'm a program manager on the Edge team here at Microsoft.

My pronouns are he and him.

Before joining Microsoft recently, I spent a dozen years on the Chrome team.

And I want to talk to you today about some of the work that we started there and are continuing on Edge.

It's exciting to be able to kick off the second half of Web Directions Code with you.

Day one was a whole week ago, but I'm still thinking about some of the lessons of platform evolution from Brian's talk.

And the day left me optimistic about PWAs.

WebXR, web components and advanced APIs like the file system access API.

Today's talks are just as jam packed too.

My colleague Diego is going to catch us up on the state of desktop PWAs.

Penny's talk is going to help us understand how to drive installs effectively.

And Max always brings the details.

So I can't wait to hear from him about how to think about PWAs in stores.

In addition to the currently possible, Léoni is going to walk us through opportunities for conversational UI, that the web is only just scratching the surface of today.

I don't have that much to add to that incredible lineup at a tactical level, at least.

But when John asked me to come back to Code, I couldn't say no.

After all, this is the conference that sparked the name "Progressive Web Apps" in the first place.

So, what can I add?

Well, maybe I could explain why we started down the parallel tracks of PWAs and project Fugu in the first place.

To get there, we need a stylized model of where a platform like the web fits in the computing landscape.

Computers tend to get more features over time and the ones that become commonplace start as very rare birds.

We can use those facts to construct a description of how things progress.

It won't be accurate, but maybe it'll help us understand things.

So on the left hand side, we have time zero and over time features that begin life on a single vendor's hardware and software eventually become more broadly available.

If we're lucky, those features become standardized the OS level, expanding the market for hardware and software that can exploit them.

And over time, most operating systems and devices might gain access to them.

Now, some of those features might become so pervasive that they begin to become supported by meta platforms, that is platforms that live on top of multiple operating systems and abstract away their differences.

You can probably think of a few of those off the top of your head-Java, Flash, Silverlight and the web were classic examples.

More modern versions might include things like Flutter, Electron or React Native.

So to the extent that these meta platforms can do most of the things that programmers on the far left hand side need them to do most of the time and are widely distributed.

They have a chance of delivering portability and reach.

That reach is helpful because it holds the promise of building services fewer times and at lower cost, potentially also at a faster iteration rate.

All the while the press is invariably focused on the stuff at the ultimate proprietary leading edge, but that's not where the action is necessarily.

Again, the left-hand side of our chart.

Things look pretty good for team betting on a meta platform.

But what about the right-hand side?

As time passes if our meta platform doesn't keep up a gap grows, I call this the relevance gap.

An interesting consequence of that little model is that it implies that there won't be a moment at which a meta platform is fully caught up with a bleeding edge of computing.

Indeed.

It suggests that the set of features that make sense to add to a meta platform is capped by the things that are commodities.

New and exotic stuff that's only on a single OS or a single bit of hardware-think the Mac touch bar, for example-make very bad candidates for inclusion in meta platforms.

So there's always going to be this tension between what our meta platforms will do and were high end applications are.

And if you think back to the classic web, it had a pile of features.

It could do some things like limited networking over HTTP.

It could lay out texttechs pretty well.

It could show images.

In some cases it could play video.

And by the early 2000s developers could drive all of that with little scripts.

Usually in JavaScript, this was easily enough capability to handle certain applications.

News and weather were early services that made a lot of sense on the web because what they needed to convey fit pretty well within the platform's capabilities.

Email, meanwhile was a bit of a heavier lift, you might remember, but it was still possible to use forms and scripts and the things that the web could do very well in the early days to make email services possible.

And the word "service" there is doing a lot of work.

Instead of finding a native application on a CD or maybe downloading it if you had the bandwidth, you could just point a web browser at hotmail.com or yahoo.com or aol.com.

And suddenly you could communicate from any computer from anywhere and you could talk to anyone more or less.

Those experiences didn't achieve full fidelity with native apps.

Web mail services didn't use the native OS UI toolkit.

And they didn't speak IMAP and they never were able to talk to POP or SMTP, but it turned out it didn't matter.

HTTP and the incredibly powerful and liberating shift away from a single device where you invested all of your state, to instead, replacing it with a cloud, turned out to be a big enough model change to make it irrelevant.

Microsoft's Outlook web access, pushed things a little bit further.

Pioneering Ajax which closed some of the gaps in the user experience at the time, bringing us ever closer to full fidelity.

That turned into something of a trend.

And before you knew it, those features were widespread enough and computers had gotten fast enough to make incredibly sophisticated web only email, not just reality, but the primary way that hundreds of millions of folks kept in touch.

A similar dynamic has played out with video conferencing.

That early set of web features.

Wasn't nearly enough to begin to support remote meetings use cases.

Computers weren't fast enough.

And the hardware wasn't quite there.

But over time, hardware networks got faster.

Cameras and microphones went from being expensive add-ons to expected features of every new computer.

And browser vendors got busy, adding a pile of new features to the web platform itself.

Now you might rightly say that browsers still don't do everything that you might possibly want to make the best possible video conferencing experiences.

But over the past couple of years, web based video conferencing has absolutely exploded.

Once the web can do most of what a developer needs, the reduced friction of not having to install software becomes an incredible asset.

As the web platform opens up new capabilities, new combinations of features become possible, and they open up categories of applications that are adjacent to what the web could do before, but they combine to tackle a whole new categories.

I often say that no application's best feature is drawing boxes.

Right?

But that's what most of the web platform does most of the time.

We just draw boxes on screen.

It's the thing you add to drawing boxes, the adjacent possible that makes something an application.

For instance, what happens if we have a box drawing system, but we add webRTC to it?

Suddenly we can do video conferencing maybe.

And if we add the gamepad and pointerlock APIs, and the fullscreen API those things have been hanging out in browsers since about 2013 or so.

What do we get?

Suddenly it's a revolution in game streaming: Nvidia's G-Force now, or Google Stadia and Amazon's Luna or X-Box game pass streaming have all had a moment in the past year.

Not because the web was built for game streaming, but because being able to access your games from anywhere, at no friction, across all of the form factors that you might want to get to it from is just a better model for a lot of users.

Who wants to manage a bunch of huge downloads and a game library and worry about which graphics card and CPU are going to work with which games.

The Web is enabling a shift to the cloud in the same way that we changed our email habits.

And when we open up access to just enough hardware capability, great things can happen for users and for end-users something else I should probably mention about our stylized model is that developers don't experience the progress of platforms in a straight line.

Instead they make coarse grained bets at far apart moments without much more than the recent past and some rough trend lines to go on.

It's expensive to switch platforms and most systems have an endless set of features and bugs to add.

So reconsidering platform choices that are underlying an existing system is a rare opportunity.

It doesn't come around very often and it's expensive to change horses.

So imagine a developer who builds an app on our meta platform at time zero.

For most of the graph as if they were going to reevaluate that choice, it would look like a pretty good bet.

Assuming the platform continues to reach all of the users the developer wants to serve.

But if the team comes up for air, say two thirds of the way through our timeline, the situation may appear to be dramatically changed.

What once seemed like a sure bet is suddenly an albatross, a system that hasn't been keeping up for many years and suddenly looks like a liability for the systems built on top of it.

Particularly if they want to attract new users who expect more modern features from other systems.

But what if our plucky meta platform has a growth spurt?

What if it starts to catch up to the trend line of underlying commodity operating systems and hardware?

In this scenario, even though there may have been an incredibly long stagnant period, a team coming up for air and re-evaluating its choices probably won't have reason to jump ship.

Or certainly not a large one.

Tricking the relevance gap keeps developers and their users attached to the products and systems that provide access to the meta platform.

This little story is a microcosm of a dynamic that plays out over and over and over again, across thousands of teams each day.

Developers on the left begin by starting to think about what kinds of services they want to deliver.

Their options are of course, limited by the platforms available to them at that moment.

And when they commit to a platform, the service that they then build adds to the platform's user base.

This is because it's the applications that developers make that create most of the value in products that include the platforms.

No OS vendor, for instance, has enough engineers on staff to build all the killer apps that will make people want to go grab the product that includes the operating system.

All of that factors in the last step to choices by products and platforms that they host to expand and mediate the behavior of the apps and services that run on top of them.

Those choices create the inputs to the next turn around the cycle and so on and so forth, a larger market falling out of one turn of the cycle makes it even easier to convince the next set of developers to try their hand on top of our platform.

You can think of it like a flywheel, each developer that brings a valuable service to the platform adds momentum.

While those that leave create drag.

All software platforms I submit have a loop like this at their core.

And what underpins those loops is trust.

Trust that the platforms will be secure, that there'll be stable, that they'll reach everywhere developers want to be, or that they won't extract ruinous taxes because the terms were changed later on.

Trust and governance at the end of the day, wind up being critical factors as these loops spin.

At this point, it's received wisdom in the product management class of major companies that betting on the web is not a great idea because quote unquote standards are slow.

Governance structures that help ensure trust many turns of the loop later have turned into a massive perceived barrier to building trust with developers, looking to build new services.

So it's worth asking a hard question: is a fast catch-up moment even possible on a platform like the Web?

When we started down the path of designing service workers in 2012, the idea of upgrading the web into an application platform was very much top of mind.

The Chrome team after all had just rejected the web is plan A for chromeOS and had instead built a proprietary Chrome apps platform.

Could we retrofit the web with the properties that needed to compete?

I had a hope, some lessons that we had learned from mistakes that we made in the web components era and an inkling of a plan.

But what we needed to build out was pretty daunting.

Service workers were just the start of what we needed.

Making web apps installable wasn't technically challenging per se, but they needed to earn their spot on the user's launcher.

And that meant giving them properties that most websites didn't have like reliability.

And to become relevant we also heard loud and clear from developers that not being able to be in the notification tray was a death knell for folks considering the web as a platform for their next project.

So many partners told us about projects that had gotten canned because bosses didn't believe their services could compete for re-engagement either because they weren't on the home screen or they weren't able to be in the notification tray.

Winning the business back to the platform was going to require that we engineer a fast catch-up moment.

Luckily, we were able to build an initial version of the Android home screen adding experience, and launch it in Chrome for Android back in early 2014, making it easier for users to come back to the sites that they were already heavily engaged with.

That work built on the service worker design that underpins user trust and an experience's reliability.

Sites like Flipkart were great ambassadors for this new technology, helping us to demonstrate to users in flaky or occasionally connected scenarios that the web wasn't going to necessarily forget who they were every time they tap on the icon.

And we were able to launch features like push notifications for the web at roughly the same time, helping brands like Twitter, reach their users, even when their pages weren't open, which on mobile, because of background tab killing is most of the time.

Even if the activity happens to be up.

Fast, catch up, it seems was possible, assuming we listened to customers and designed intentionally to solve those market problems that were developer mediated.

I'm happy to say that Microsoft was an early supporter of this work, participating in the design of service workers and push notifications and bringing them to Edge.

Jeff Burtoft even sort of schemed with me to make sure that we could get the manifest thing going to make sure that we can make PWAs a possibility in the first place.

By 2017, Microsoft had begun bringing progressive web apps to the desktop, ahead of any other browsers too.

Those efforts did something really special, because developers like Twitter and Starbucks could bring a code base that they had built as PWAs for mobile to their desktop users through responsive design.

Which meant that the web's, incredible reach helped make a larger market for them.

Apps like Spotify's web player have now evolved from lightweight discovery services to seamlessly upgrading desktop applications.

In fact, it's how I use Spotify across all my desktops now, because I don't have to think hard about downloading an app or finding my login credentials.

The browser remembers all of that.

And I'm back into my music wherever I happen to.

Even though I was a Google for most of this journey, it was pretty clear to me that Microsoft understood the potential, which was pretty heartening.

What we've been trying to do industry-wide is to expand the reach of web developers by reducing the set of reasons that their services and apps are cited against in terms of not being credible future platforms for the businesses that they serve.

Nobody wants to hear from their boss, that the stack that they've invested most of their career in simply can't do it anymore, and that they're going to have to investigate alternatives.

When we make it possible for powerful apps to reach more places safely, the value businesses get from a single investment in the web also goes up dramatically.

It's not just about developers continuing to have relevant skills.

We make it possible for businesses to benefit too.

Google Santa tracker application is now a progressive web app across every form factor, scaling up and down fluidly and allowing a tiny team to manage a huge reach on a tight deadline every year.

The same thing goes for Google's Web Maps team, which is now powering Google Maps Go on low and Android devices from the same code base that makes maps on desktop work.

More than once I've even seen teams accidentally launch desktop PWAs because they upgrade their mobile experiences to be PWAs and become installable.

Suddenly someone reports to them that they've installed the desktop app when they didn't know that they even had a desktop app, it's kind of entertaining when that happens.

All of that brings us to Project Fugu.

Fugu is a follow on to the work our team did in the open from 2012 to 2017 to make reliable, offline, capable web apps, a first class citizen in modern operating systems.

If PWAs were an upgrade to the web's delivery vehicle that allows it to reach heavily engaged users in all of the places that they want to be and pluck them from the sea of tabs in the top level experiences, then Fugu is an effort to upgrade the capabilities of those applications at the same time.

Uniquely Fugu is being run as an open collaboration within the Chromium project, Samsung, Intel, Microsoft, Google, and others who contribute to Blink are all participating in a process to add frequently requested capabilities to the web across a wide surface of the platform.

In case that sounds potentially proprietary, trust me, it's not.

Everything we develop is built in the open and we solicit developer feedback at the earliest possible moments.

The goal here with explainers and origin trials and flags and other mechanisms that let you try out features or redesigns early, is to help us make sure that what we deliver eventually in a formal specification is fit for purpose and solving your problems.

We learned from earlier efforts like the work we did to make ES6 a reality and develop components and build service workers that the value of designing in the open is incredibly high.

Particularly when it's coupled to lower barriers to participation by web developers.

After all it's developers and their users who are going to be stuck with this stuff-if it doesn't work for y'all, that means it just doesn't work.

As you may have guessed, the project is named Fugu because we're intensely aware of how important security and privacy are as we work to expand capability, access.

One wrong cut, and our customers may be in grave danger.

So a vast amount of effort goes into ensuring that all the designs we put forward have many layers of safety wrapping them.

From an ability to block list dangerous devices without needing to push new versions of a browser, to careful consideration of the permissions models that we use, to collaboration and co-designing with our colleagues in privacy and security.

The goal of Fugu is to respect danger without shying away from the benefits that increased access can provide.

That approach allow us to ship some really cool stuff, that's opening up brand new possibilities for the web.

For instance this is the thermal printer that speaks Bluetooth.

It might've needed a custom application once upon a time, but now that WebBluetooth is available developers can just make websites that can upload images to these printers without having to go build a separate exe for each platform and convince their users to download it and handle support requests and permissions issues.

Just point a browser at the webpage connected over WebBluetooth.

Even if it wasn't designed to work with the web, we've devised a protocol that's safe.

And so now you can do things like printing out your fish [laughs].

Safe Bluetooth access from the web opens up all sorts of custom hardware and educational projects to a much wider audience.

This is a motion controlled web based 3d globe connected over Bluetooth.

Obviously graphing the results of the pandemic.

This kind of hobbyist project previously involved significantly more difficulty in connecting devices together.

WebNFC, for instance, a project built and sponsored by Intel makes it possible to safely read and write to devices around us in the physical world too.

Games like the ones in this tweet are just the start.

Think how many IOT devices in your life want you to download an app to configure them when all they really need is NFC for pairing.

What if all of that got a lot easier?

Well, it shifts.

So it's time to start doing it.

And what if serial devices didn't need us to download unsafe executable is to work with them.

What if we could just grant access to them safely in a browser and make cool new things to control our digital lives.

WebSerial's potential for hobbyists indie hardware vendors, and education is hard to overstate, in my opinion.

What if you didn't have to know a ton of C [women's voice says] "Hey, this is a circuit playground express, and it's sending light and temperature data over the serial port.

And I'd like to plot it.

And normally I'd use the Arduino ID plotter or the Moo plotter, but now I'm going to be using a web serial plotter that we wrote and it's up on glitch.

It's still under development.

So it's kind of exciting, but we can connect if you're on Chrome, select the comm port, the serial port that matches, and now it's plotting data from the light and temperature sensor.

It's also got the accelerometer sensor.

We're going to work on that next.

You can see there's a serial port output for debugging in this case, it's in JSON format and then..." [Alex continues] ...light, temperatures, serial output for debugging.

It's pretty great.

Thomas's talk on file systems last week probably might have very deleted little too well.

I'm massively excited about the Fugu, work on things like web codecs, and the breakout box API for video manipulation, periodic background synch for keeping apps up to date, respectfully of power and data barcode scanning APIs, so that you can read barcodes in a few lines of JavaScript, which has gotten incredibly relevant in my life recently.

Signing into banks with webOTP without needing to dig out little six digit codes from my text messages and all the other cool PWA feature additions that Fugu is adding along with webHID demo.

And the web serial and the web USB demos you know, I love it all, but the webHID demos are kind of the most fun because they finally let us connect input devices that might have some low level support for instance, through the gamepad API, but we're explicitly mapped out with drivers.

We can still support them through HID and here's, Thomas' demo for the Joy Con.

webUSP is also getting used at scale.

This is Google's Android.

From this page, you can download beta versions of the Android OS and install them to devices.

No drivers needed.

I don't mean you download a file and you put it on your device.

I mean, you attach your device to a USB cable.

You go to this page, you click the right button and it installs the new version of your operating system onto open devices.

It's a revolution in simplicity for firmware software delivery.

No more downloading dodgy driver install apps or a finding that they aren't supported in your operating system.

You just pick the device connect to, and it's clearly attached to only the website you gave it permission to.

And this now powers how Google delivers betas of Android.

And last but not least, of course, the file system access API is making it possible for the web to safely inter-operate with our desktop files, read and write to them and build PWAs that aren't locked out of basic operating system conventions.

The work that's going on now to make PWAs handlers for file types like, and protocols is going to radically expand this potential over the next year or two.

If you've got an Electron App today and it mostly just reads and writes, writes files.

It might be worth thinking about whether or not you're going to continue to need that in the future.

The list of features we've tackled and have in flight is also massive.

You can learn more about the project at the feature tracker: that's fubu-tracker.web.app.

And there you'll find status for all of the features that we're working on links to more detail on each of them and links to being able to request missing capabilities too.

We, we want to know what you want in the backlog so that we can prioritize them.

And lastly, if you're interested in trying out some of these bleeding edge features, we crave your feedback.

You can help shape how these APIs evolve by reading and commenting on explainers onGitHun.

Or you can try APIs that are further along through origin trials or in dev trials.

There are even some origin trials that are exclusive to Edge like the dual screen APIs, and Haptic Feedback APIs, and we'd love to hear from you about those designs too, if you get some time.

So, can we go from this, to this?

I think so.

Open interoperable standards based platforms don't often have fast catch-up phases, and there's absolutely no guarantee that they will.

Lots of platforms have fallen entirely by the wayside because they failed to keep up with the overall rate of change and support their developers into the next era.

But we're showing here, I think, that there's life in this here web yet.Teams, Google, Intel, Samsung, Microsoft, and across the Chromium project have put their careers on the line.

And I can't thank the leaders, engineers, designers, product managers, and security folks who've come together to make all of this possible enough.

Thanks for listening.

And I can't wait to find out what incredible things you'll end up building with the building blocks that we've had the pleasure I love making available.

Conversational interfaces in our cars and homes and on our devices are and everyday part of our lives now.

But where does the web fit in this story?

Today Léoni Watson, director of Tetralogical, a member of the W3C advisory board, co-chair of the W3C web applications working group, and much more will look at the state of the technologies in our browsers and show us how much we can do with conversational interfaces today.

Hello.

We, that is to say humans have been trying to talk to things other than ourselves for a remarkably long time.

As far back as the 1700s, we were working on mechanical devices designed to mimic the human anatomy-our lungs, vocal tract, vocal chords and such.

And we kept up with this analog experimentation until about midway through the 20th century.

When the clever people at bell laboratories gave us this.

and with it, of course they gave Stanley Kubrick much to be thankful for.

An interesting thing about conversational interfaces is that they are inextricably linked to text speech recognition, captures what we say and converts it into text for forward processing.

In a reverse of that, when we create synthetic speech, we supply text to a text to speech engine, which then duly converts it into the synthetic speech output that we want.

One of the most basic forms of TTS is known as a "Formant TTS".

It's based on a set of rules that let us manipulate very simple characteristics of human speech, like frequency or pitch or amplitude, volume.

The results are intelligible, but they do sound quite robotic.

For millions of years, humans live just like the animals.

Then something happened that unleashed the power of our imagination.

We learned to talk.

The limitations of formant TTS mean that to all intents and purposes, there is only one voice and we can change it within certain constraints, but really not very much.

For example, the most common way that a female gender voice is created is simply by doubling the pitch of a male sounding.

"For millions of years, humans live just like the animals.

Then something happened that unleash the power of our imagination.

We learned to talk." Then along came concatenative TTS, which was intended to overcome some of the problems with formant TTS.

And to do this, it starts off by many hours of prerecorded human speech.

The recordings are then broken down into tiny little segments, often as small as individual phonemes or even phones, then when synthetic speech is created, it's done by re sequencing those tiny segments until they form the words and sentences that we want.

The results are something of an improvement over formant TTS, if not by much.

"For millions of years, humans live just like the animals.

Then something happened that unleashed the power of our imagination.

We learned to talk." One good thing about concatenative TTS is that because it's based on recordings of real people, it becomes more possible to have voices that have different characters, different genders even some aspect of age and accent.

"For millions of years, humans lived just like the animals.

Then something happened to that unleash the power of our imagination.

We learned to talk." Concatenative TTS is not without its problems, though.

It takes many, many hours of recorded speech to create a concatenative TTS voice.

And it simply isn't possible to record enough hours of original data for the synthetic speech to be able to be as expressive and as nuanced as real human speech is.

The other problem is that it's not terribly performant.

It takes time to search a database for all the little tiny segments of sound that are needed and time to re sequence them.

And that means that although concatenative TTS sounds a bit more human than formant TTS, it definitely isn't as responsive.

I'm going to take a brief moment here to talk about a subject that's important to text to speech and synthetic speech output.

In the two examples of TTS engines I've mentioned so far, I've already talked about gender.

But there's a bit of a problem.

Most, if not all of the text-to-speech engines out there at the moment, assume binary genders, there are male voices and there are female voices and that's pretty much it.

Obviously that's not truly representative of the different types of gender identity that are out there.

So I would like now to introduce you to Q.

"Hi, I'm Q, the world's first genderless voice assistant.

I'm created for a future where we are no longer defined by a gender, but rather how we define ourselves.

My voice was recorded by people who neither identify as male, nor female, and then altered to sound gender neutral, putting my voice between 145 and 175 Hertz.

But for me to become a third option for voice assistants, I need your help.

Share my voice with Apple, Amazon, Google, and Microsoft, and together we can ensure that technology recognizes us all.

Thanks for listening.

Q." Meanwhile, back on text to speech engines, parametric TTS was intended to solve the shortcomings of both formant TTS and concatenative TTS, or to put it another way to utilize the best of both of them.

Like concatenative TTS, parametric TTS is based on a recorded human speech, but instead of breaking it down for resequencing, it's converted into a set of rules or parameters that can be used to model that voice again.

And they're processed by something known as a vocoder.

There is a distinct improvement in the human quality sounding of the speech produced in this way.

"For millions of years, humans live just like the animals.

Then something happened that unleashed the power of our imagination.

We learned to talk".

And with it, we get a much richer ability to express different voices.

Again, genders and ages and accents.

"For millions of years, humans lived just like the animals.

Then something happened that unleashed the power of our imagination.

We learned to talk." But there is still an oddly, flat quality to the speech produced by parametric TTS, that makes it still very clear that you're listening to something synthetic.

If you're building conversational interfaces in the browser, most likely it will be concatenative or parametric voices that you have at your disposal.

But more on that later.

The answer to the still slightly unnatural sound of parametric TTS, comes in the form of neural text-to-speech engines.

These are essentially based on the same model as parametric TTS, but there's one big difference.

They are supplied by truly vast amounts of data.

If you take Google's Wavenet, neural TTS, as an example, it is trained with data taken from the voices of people who've used Google's voice services.

If you opt out, this won't be the case, but if you've ever used one of Google's voice services, like voice for search, for example, there's every possibility that your voice is one of the many that has gone into training its Wavenet neural TTS.

And the difference is remarkable.

The quality of speech is so much more human sounding than any other form of TTS.

"For millions of years, humans lived just like the animals.

Then something happened that unleashed the power of our imagination.

We learned to talk" and even with voices of the same gender and approximately the same age, the ability to create subtle distinctions, like the difference between two English language accents is also really quite astonishing.

" For millions of years, humans lived just like the animals.

Then something happened that unleashed the power of our imagination.

We learn to talk." And if you didn't know better, you'd often be hard pressed to know whether that was a real human or synthetic speech and that's progress I think.

What of conversational interfaces in the browser?

Well, apart from a brief moment of excitement, back in 1997, when Microsoft introduced MSAgent, and momentarily made it possible to embed synthetic speech output in Internet Explorer.

There wasn't much to report until about a decade or so ago.

Google proposed an API that they then implemented and along with other browser engines worked on what is now known as the web speech API.

It was produced as a W3C community report back in 2012, moved into the web incubator community group in 2017.

And there has been periodic activity in moving it forward since then, most recently, last year in 2020.

The Web speech API has two interfaces, speech recognition or capturing speech input, in other words, letting you talk to your web application and speech synthesis or producing speech output, or having your web application say something back to you.

The component parts of a conversation.

We'll start with the speech recognition interface.

This is where the speech we'll start with the speech recognition interface.

We'll begin by creating a speech recognition object.

The line of code on screen shows that we are actually creating a web kit speech recognition object.

And you might well wonder why.

The answer is that the original intent was that each of the browser engines would experiment with their own implementation.

And that the best of the ideas would be drawn from each of the experiments to standardize what will then become the universally adopted feature.

Reality never quite works out the way we think it's going to though, and what has actually emerged is that webkitSpeechRecognition is essentially the only implementation we've got to play with.

On the one hand it's a good implementation, but on the other, of course, it means that we're restricted to using this interface only in browsers that support WebKit.

Let's go on and take a look at what else it contains.

There are 11 events in the webSpeech API speech recognition interface.

And some of the most commonly used include audiostart and end when audio starts and ends soundstart and soundend when the service first becomes aware that sound is being produced and when it ends.

And then simply start and end, when the service begins, capturing that sound for the purposes of the speech recognition and equally when it stops doing that.

There are also events for results, when the results of speech recognition have been captured and error for a number of different ways of error handling, of course.

There are three methods in the webspeech, API speech recognition interface start, abort and stop.

If you're wondering what the difference between the last two is, it's simply that stop means that speech recognition will stop, but data processing will continue and abort is the nuclear option.

It brings everything to a grinding halt.

Permissions or something to give careful thought to when you're using the speech recognition interface.

Necessarily when you're capturing speech, you need to use the microphone.

When you use this browsers will automatically pop up a permission's dialogue, but if someone doesn't accept the use of their microphone or misses it, or inadvertently hits the wrong button, it's a good idea to build in some error handling just as a belt and braces approach.

So again, listening out for a not allowed error event and producing a suitable message to let the user know why speech recognition isn't working, it's just a good touch from a UX point of view.

Transcript is the thing that's created when results are captured.

It's just an array of all the words that were spoken during the speech recognition phase and as an array, it means of course, that we can get to any or all of the content inside it and utilize it for any number of different reasons.

The most likely being to reprint it on screen as this demo shows.

" Open the pod bay doors Hal." So what of the speech synthesis interface?

Well, here things in terms of support, definitely look up.

The basic features of the speech synthesis interface are supported by all of the browser engines.

So there's a really good base for using this particular part of the specification.

And we begin by the most simple of actions.

Creating a speech synthesis object and giving it something to say, it's simply as simple as creating the object and using the text method to supply the text that we want to be spoken.

The example on screen would produce speech, something like this [Synthesized voice saying "This must be Thursday.

I never could get the hang of Thursdays"] With the web speech API, we can also manipulate the quality of the speech to a certain extent.

We can change the pitch.

We can make the voice sound higher or lower than the default.

We can change the rate, the speed that someone, we can also change the rate, the speed at which the voice speaks again, making it faster or slower than the default.

And similarly, we can change the volume.

We can make it louder or softer than the default.

Something that's worth remembering about all of these settings is that they are relative to the user's default.

It isn't possible to suddenly crank up the volume of synthetic speech output so that it would be distressingly loud or uncomfortable for the users.

There are limitations put in place on all of these things from a UX point of view, as much as anything.

And we can hear the differences for all three of these kinds of voice configurations.

In this following example.

[synthetic voice speaks] "One tequila, two tequila, three tequila, floor".

The speech synthesis interface works on the basis of a queue.

In that previous example, what we did was we sent four different speech objects into the queue, the slide on screen now has a simplified representation of that without any of the changes to pitch, rate, and volume.

And as things are sent to the queue, that's the order that they're spoken in [synthetic voice speaks] "one tequila.

Two tequila, three tequila, floor." You might reasonably think that once a speech object has been sent to the queue, that it is immutable, that there's nothing you can do to change its characteristics.

And you'd be wrong about that I'm afraid.

It turns out that in pretty much every browser, if you send an object through the queue and then change its characteristics those changes get acknowledged [synthetic voice speaks] "One tequila, two tequila".

My general recommendation is that once you've sent a speech object to the queue, don't muck around with it.

Yes, you can.

It doesn't mean to say that you should, and generally speaking, you'll keep yourself out of trouble by sticking to that really simple rule.

You can also change the voice with the speech synthesis interface.

On the screen at the moment, we've got an example that shows the voice that will be assigned is Hazel.

It's a UK voice provided by Microsoft.

[female sounding synthesized voice say] "Alice had begun to think that very few things indeed were really impossible." Voice selection is one of the areas where the speech synthesis interface gets a little bit complicated.

There is a method getVoices that will return an array of all of the voices that happen to be available on the platform or user agent.

And that's exactly where the problems start to begin.

On Windows, for example, Firefox will return three or four voice.

Edge a few more, perhaps 10 or 11.

Chrome, a few more again, 14 or 15 or so.

And the only voices that they have in common are the three or four that are default to Windows as a platform, which is great.

You could therefore choose one of the Windows default voices as your safe bet.

Except of course users aren't all using Windows.

They're using Mac OS, iOS, Android, and such.

So choosing a voice that is available on the given platform and the given user agent takes a little bit of logistical thinking and planning in your code.

We've talked a bit about choosing a voice and then even configuring it slightly for pitch and rate and volume, but really what about some proper expression in the voices?

It's really important to good conversational design.

The webspeech API says that it supports SSML speech synthesis, markup language, something that first became a W3C recommendation in 2004, and it was updated in 2010.

SSML is incredibly powerful.

It's really well supported by different home assistant platforms.

And with just a few SSML elements like prosody and attributes like voice and lang we can change Alexa from sounding like this.

[a largely affectless female synthesized voice says] "Hello, my name is Inigo Montoya.

You killed my father.

Prepare to die" to something far more enjoyable like this.

[A Spanish accented synthesized male voice says] "Hello, my name is Inigo Montoya.

You killed my father." Unfortunately, browsers don't support SSML in any meaningful sense.

Happily, the web speech API specification deals with this by saying that if the user agent doesn't support SSML, the elements should just be stripped out from the string that's sent by the text method, and the text itself should be processed as usual.

Sadly with the exception of Edge, every other browser, does this: [synthesized femal voice says] "XML version equals 1.0 speak version equals 1.0 XMLNS equals H..." and before you get too excited about Edge not doing that, all Edge does is strip out the SSML and proceed with the text as though the SSML weren't present.

So SSML doesn't give us a way to choose the expressiveness or design the way the voice sounds for different types of content.

Another possibility might be something called emotion, markup language.

It's a recommendation that was produced by the W3C in 2014.

And it's designed to mark up content to indicate that synthetic speech should render it in a way that is particularly emotive.

For example, something that sounds a little bit surprised or disappointed or happy.

This is an example of the Watson IBM voice that is very emotive indeed.

[female synthesized voice says]"Wow.

I was getting tired of not being able to express myself.

The future looks really exciting." Emotion ML, unfortunately is only supported by text to speech engines.

And as far as I'm aware, none of those that are available on platforms like Windows, Mac OS and such.

But how wonderful would it be as authors if, when we're producing content for consumption on the web, we could mark it up to say if synthetci speech is responsible for the output or the rendering of this content, then make it sound happy or disgusted or surprised or whatever the emotion may be.

But that's one for the future I'm afraid.

A really interesting thing about the lack of ability to design good voice output in browsers is that it's browsers where we find one of the most strong use cases for doing so.

An interesting thing about the lack of ability in browsers to style voice output is that it's in the browsers we find one of the most compelling use cases for doing so.

Lots of browsers now have reader mode.

And as part of that, the option to listen to the content of the page instead of reading.

For example, this is a recent post on my blog.

[synheized female voice says] "I've been thinking about conversational interfaces for some time and about the importance of voice quality as a part of user experience.

I use a screen reader and it sounds the same, whatever I'm doing".

That was Firefox reading that, and like other browsers Firefox gives me as a user, the ability to change the voice that's being used and the volume and the rate it speaks at.

But from an authoring point of view, there's nothing I can do to have any sway over how that content is read aloud.

If I were to ask you to look at this partial screenshot of the same page on my website and ask you what's wrong with it, you mostly would probably say it lacks styling and you're right.

I've disabled style sheets and what's left behind is just the basic structure of the content.

We have ways for styling visual content in the browser.

But what we don't have right now is a way to style sound or speech output from the same browser.

The good news is that the answer exists in the form of the CSS speech module.

Bad news.

It'll come as almost no surprise to you.

Is that nothing supports it yet.

It is a candidate recommendation at the W3C and it has been that way for a year or so now, but it's history goes back quite a lot further than that.

In CSS2 to an aural media type was introduced.

It was then replaced in CSS 2.1 by the speech media type, which still exists to this day, even though it has no support.

At the same time a number of properties were introduced and those properties today exist as the CSS speech module, as we take a look at them, you'll start to get a sense of deja VU.

There is a speak property, which is really closely related to the visual display property.

In fact, the two can be entirely reflective of each other.

The speak property essentially indicates whether the piece of content should be spoken or not.

But, the clever trick is that you can set it to auto and it will mirror the state of the display property.

So if display is set to none, then speak will be set to none and vice versa.

So a nice relationship there, if something isn't intended to be displayed visually may well be intended not to be spoken either.

And then we have properties for manipulating the familiar characteristics that we've already seen in other techniques.

Pitch this time using a word properties rather than numerical properties, but exactly the same idea.

The [unclear] one for rate, changing the rate, the content is spoken at and also volume.

And like previous examples these are also [curtailed].

You can't take any of them to extremes in either direction.

CSS would also give us the ability to introduce pauses into speech.

Pauses are a remarkably important part of human sounding speech.

Some people like Harold Pinter are even famous for their pauses because they were that dramatic and effective.

So having the ability to say to synthetic speech, pause a little while here, make a slightly longer pause for effect here is a really useful capability.

There's also voice family, which works a lot like font family in visual stylesheets.

You can design a number of characteristics.

You can define a number of characteristics or the voice that will be used.

You can select its character by name and also other characteristics like its age or gender.

The voice family property is intended to work a lot like font-family in the sense that you can choose a different number of choices and have each one be applicable to a different platform.

So it overcomes the constraints or at least the logistical complexities of getVoices in the web speech API.

And the nice thing is that once you've done all of this, the language of the content will also be selected.

So for a voice family that calls itself, McFly is a male of a young age.

We can only assume that the content in question would have to be that of American English.

So although none of this is supported at the moment in browsers, I did want to share with you a possibility demo because I think the possibilities of being able to style the speech output of our content in the same way that we style the visual output of it is something that's really missing on the web platform today.

And with just a little bit of imagination and some of those CSS properties, we could change the earlier example of speech output of that blog post to something like this.

[more expressive female synthesized voice says]"I've been thinking about conversational interfaces for some time, and about the importance of voice quality as a part of user experience.

I use a screen reader and it sounds the same, whatever I'm doing, reading an email from a friend, reading news of a global disaster ..." And so, without any dramatic changes with no sudden surprises, we can produce speech output in the browser that is styled.

It may be styled to match our brand.

It may be styled to produce certain emotional reactions or any number of reasons.

Good reasons why we should have the ability to style speech output.

So although CSS speech is not supported in the browser at the moment.

I did want to share with you a possibility demo because I think, well, the possibilities are really just amazing.

With just a few CSS properties and the little bit of imagination we can change the earlier example of speech output reading that blog post is something that sounds like this.

"I've been thinking about conversational interfaces for some time and about the importance of voice quality as a part of user experience, I use a screen reader and it sounds the same, whatever I'm doing, reading an email from a friend reading news of a global design." And how amazing would it be to be able to do that as we start to see more and more conversation happening in the browser, more speech output, the more we're going to want to be able to represent our brand design intentions, the more we're going to be able to want to express certain emotions or put nuances into the speech.

All of the things we currently do with visual design, through spacing, layout, color choice, shading, and all the rest of the creative ideas that we have around the visual design.

So I hope one day, perhaps with your help, if we make enough noise about it, we'll start to see support for the web speech API improve.

We'll start to see support for the CSS speech module and maybe even emotion ML in due course.

Because conversational interfaces are everywhere.

They're on every device and every platform that we use in some fashion or another.

And at the moment, the web platform is kind of missing a trick, I think, but I hope that the possibility will one day become actuality.

Thank you for listening.

And if you are interested in this topic, I thoroughly recommend you take a look at these articles by Brian Kadell.

He's done a great deal of research and investigation into the web speech API, including some of the gnarly bits and how to solve them.

Thanks once more to Alex and Léoni for opening this week.

We'll take a short break of around 20 minutes now.

Make sure if you haven't already to give the REA challenge a go and to grab some swag from platform sh.

And why not see who you'll bump into in the hallway and join one of the conversations taking place there.

All right, we'll take that 20 minutes break now.

So keep your eye on the countdown clock and we'll see you shortly for our second session of today.

Welcome back.

In this middle bracket we have three presentations that focus on PWAs.

We'll hear how they can be closely integrated into your user's desktop experience.

How we can do our best to have users install our apps on their devices and about the state of play with PWAs and app stores.

Since the significant majority the time users spends on desktops and laptops is now in their browser, more closely integrating PWAs and the desktop makes a lot of sense.

Today Diego Gonzalez, program manager for Microsoft Edge, takes us through cutting edge features and APIs that allow a PWA to integrate seamlessly with a desktop OS.

I am thrilled to be able to spend some time with you talking about the future of web apps.

You see, this is something I've been curious about for a long time.

So get comfy, grab a drink and join me.

Over the years I've thought about how stereoscopic 3D can change the way we use the website or an app.

Or how VR can revolutionize the core experiences of the web.

Or how to bring a design language from native to web in order to create a unified flow for web apps.

Or even how new form factors like foldable devices can impact our experiences.

This has been all really enlightening and the capabilities nowadays for the platform are mind blowing.

But I personally think that one of the most important things that plays a key role right now for the future of the platform are web apps themselves.

For many reasons.

We are now at a crossroads where we must continue to push the limit of what is capable with the web in order to create a democratic and capable platform that works for everyone.

With the appearance of PWAs some years ago, it felt like the start of something magical, of something truly new.

Millions of developers could leverage their existing skills to deliver their experiences to even more devices in a way that millions of users would expect based on the look, feel and behavior of native applications.

We've come a long way in web development in a very short time, back from when the good practice was to have a web for mobile and web for desktop up to now where it's possible to have one code base that will cover mobile, desktop and even installed applications.

The more time I spend around the web, the more I convince myself that when it comes to the future, what matters is the platform's ability to permeate current widespread paradigms and cement itself as the default medium.

The paradigm at hand is that of apps and the app economy.

By medium, I am referring to development, consumption and distribution.

The benefits are openness, safety and accessibility.

After all, those are some of the main tenets of the web that keep it going strong, even after some other platforms rise, fall, or try to displace it with walled gardens.

Overall, there is an interesting opportunity for the web to set itself as an attractive platform for a strong app ecosystem.

So-apps they've certainly changed the way we consume content and even what we expect from a software user experience perspective.

All of this is scoped by the applications that we use on a daily basis.

But apps can be expensive and have limited reach.

And as I've mentioned before, the web platform can commoditize, modernize and create a better and more accessible user experience in the end.

So let's focus on PWS, a set of technologies that allow the web platform to engage into the future by bridging the so-called native app gap into oblivion.

We mostly know the drill-secure browsing context, plus manifest files, plus a service worker is going to give us a PWA.

And I am old enough to remember the add to home screen.

This was pretty much what these three things that I've just mentioned got us.

And only in some mobile browsers.

You would get prompted that you can install the web app or PWA that you were using.

And this generally meant that you would only have an icon on the home screen.

It was the beginning of web apps gaining more and more parity with their native counterparts.

Fast forward a couple of years.

And now that same add-to-homescreen concept is incomplete, and to be frank quite obsolete.

Now PWAs can properly integrate with the operating system.

We're talking App Drawer, System Settings and access to specialized hardware.

The whole mobile package.

It's about time that we get deeper integration with desktop platforms.

And this is where I can provide you with great insights about how installed web applications can really shine.

I will give you a glimpse into the future of PWAs on desktop platforms, albeit a very close proximity future.

Since everything that I will be showing you is cutting-edge experimental technology that is shipping in either Canary, Beta, or Dev channels of Microsoft Edge and has support in other browsers as well.

Now here you can see the list of cutting-edge features that we will examine today.

Responsive design, OS theme support, custom titlebars, shortcuts, sharing from the app, sharing to the app, handling schemes, links, files, and access to the file system itself.

There are another two things that we won't be covering in the demo, but they're still important to mention for an accurate talk about desktop PWAs, which is Badging and Push Notifications, but they've been already in the market a bit, so we won't be talking about them today.

Now the demo app we will be using has a bit of history behind it.

Many moons ago, the term 'progressive web app' was coined and there was interest among the developer community to have a way of visually gathering around the novel concept.

We needed an icon, a logo, a beacon of hope, some sort of banner on which we can all gather behind-kind of like the concept of why Batman uses a secret identity, but a bit more geekier and, uh, with less black rubber.

At the time Maxime Salnikov the leader of the Rebel Alliance, set his tasks to open up submissions for this noble task.

Long story short, the PWA lettermark was born and it didn't take long for it to appear on stage at Google I/O and Microsoft Build.

Now, one of the ideas behind said lettermark was that like the concept it represented of progressive web apps, it would blend and adapt to the different marketing and branding ideas that the community was looking into.

So while there was some official recommended, you know, color scheme, the, kind of like, better recommendation was to make it your own and have fun with it.

The PWA logo printer, or 'PWinter' as I like to call it, was born.

And as the logo designer, it drastically reduced the amount of custom logo requests that I was getting on my inbox.

And that pretty much rocked.

The app we will be using to showcase these features is a reimagination or rejuvenation of the first version of the printer from several years ago.

Kind of like, I guess what The Matrix 4 is trying to do at the moment.

Mostly because I lost access to the GitHub account where it was hosted and the fact that it wasn't really well-documented.

So let's take a quick look at the application itself to understand what it does.

It's as simple and straightforward application that provides an easy way to showcase these features.

We're going to go to the website, we're going to install it.

And then we're going to get a glimpse of where and how the magic starts.

I am opening the website at the moment.

And as you can see, okay, full screen, as you can see, you can pretty much create a custom colored logo.

The way that's coded is that every single time you go into the application or you reload, it's just going to create some random combination for these colors.

Once you design, or you know, decide that you want a color and let's just change this maybe to something that will contrast better with a dark background.

There you go.

You can preview it in light or dark backgrounds and you can, you know, start from a neutral blank logo.

If you wanted, by clicking here and new logo, you can save the logo or you can share this logo.

Okay.

So we're going to proceed to install this application.

Let's take a look at the app itself to understand what it does.

It's a simple and straightforward application that provides an easy way to showcase all the features that we're going to be talking about today.

We're going to go to the website, install it and get a glimpse at what the application does.

As you can see, we have three controls that allow me to change the colors of the logo in order to create my custom logo.

Once I'm happy with it, I can preview this logo both in light or dark backgrounds, and I can start a new logo from scratch.

Save this logo or exported, and this is pretty much it.

Now the website itself is prompting me that there is an application available and that I can install it if I want it.

So I get this prompt and I proceed to install this application.

What we're going to see now is that the application itself is coming outside of the browser.

And it's telling me that it's, you know, that it's been installed and that it can safely run in its own window.

It'll integrate with other windows features and I can launch it pretty much from the start menu from the Windows task bar or from the desktop.

I also get additionally a way to directly pin it to task bar, start, create a shortcut or allow it to run once I log in to my computer.

So in this case, I'm even going to create a desktop shortcut and I'm going to allow this, and there you go.

We can see, now that it's running in this window, I'm going to close here the browser window.

I'm going to quickly open the start menu.

We can see that it's integrated here with its own entry, and I can also have it on the taskbar.

So back into the topic, we're going to start by getting the pretty visual stuff out of the way.

Responsive design.

It might seem as an obvious thing.

And rightfully so, we are in 2021, but yet this year there are still photo sharing, social networks that when you install them on tablets, they just display as a zoomed in version of their mobile counterpart with black borders.

And this is kind of like going into an IMAX cinema to watch a 16:9 movie, but worse because it's on your tablet.

So, be sure to use your media queries appropriately and rejoice that, you know, advanced layout systems are already baked into the platform with CSS Flexbox and Grid.

I, for one love CSS, but sadly I do not have the time, nor is it the scope of our chat today to praise CSS.

Second on our list is support for the OS theme, a trend that is more and more common in modern operating systems.

That generally means that the whole system can have a light or a dark aesthetic.

And, the one feature that I, as a remote work in London with the team based in Seattle are very grateful for, since it keeps my retinas from burning when I'm working late at night.

Now the way we achieve this is with the 'prefers-color-scheme' media query, and in our application, we can see how we are using this query to load the appropriate styles, which for now it pretty much will only change one of the stops of the gradient color that is set as the background.

This is a very subtle change.

But you might notice mostly when you are using the application maximized, and, you know, in the end, it's these sort of subtle details the one that delight the user and the web is certainly not short on ways to delight the user.

While we are on the topic of subtle details..

third on our list is custom title bars, or as the feature is properly called, Window Controls Overlay.

This feature allows an installed web application to extend the area that normally would be occupied by the title bar itself.

To achieve this, you have new CSS environmental variables that define the area that encompasses title bar, and only the window controls are left in the corner.

You also need to set the display_override property of your manifest file to `window-controls-overlay`.

Let's take a look at what this enables and at the effect of the theme of OS and responsive design at play.

Now, when you install the application, it is showing the default title bar, and you can toggle this feature on and off by clicking into the chevron.

I'm going to open here the application itself.

Okay.

And here we go.

As we saw before we have light/dark, but this is not the seeming support that we get on the operating system.

So I'm going to maximize just so you can notice the change that's going to happen.

And I'm going to bring in the settings.

I'm going to change the theme of the operating system itself, and probably you noticed that the first thing, one of the first thing that changed was the background of the application.

So again, if I were to let's say, reload, this application, bring it.

You can see now that it's themed to start in a dark environment.

In a similar way, you know, it's a responsive design.

So if I were to put this application in a landscape or portrait type of way, it will respond appropriately.

And even if I'm viewing it in full screen way, I am getting the application displaying properly.

So we're going to go back just for the sake of seeing the change here, back to a light mode and what I want to show you now, now we can close the settings, what I'm going to show you now is, now that the application is installed this is the default view that we are getting.

And you can see that in the title bar, we get the name of the application that's registered on the manifest file and the chevron here.

Now, this chevron allows me to hide the title bar itself and just the web content will, will take this area that was previously occupied by the title bar.

So I'm going to hide it and you can see how now we have the title and the custom controls that we built into the application seemingly into the title bar itself.

So just so you can see again, this is how the application is installed, and this is with the `window-controls-overlay` enabled.

If I close this application and I open the application again - I'm going to open it here from the start menu - you can see that it pretty much remembers the state on which you saved it.

And we're now always going to have our custom control.

You can also specify which elements in the title bar are draggable surfaces in order to move the window.

In this case, I don't want the buttons here to be able to drag it, but an expected behavior of title bar says that I should be able to grab this and just drag it and move the window along.

So this is something that you can do as we can see here in the CSS by defining the `app-region` as, `drag`.

Pretty pretty dope.

Following, we will focus on capabilities that allow the installed web application to integrate deeper with the operating system, by enabling different entry points to the app, cross-application communication, and even better ways to interact with files - all things that we take for granted when we are developing native apps and that, you know, make a huge difference when it comes to the subtle details that make, and these are actions or jump lists, sharing from and to the app.

And the APIs that we will be discussing are manifest, - the shortcuts field in the manifest, webshare and webshare target.

So the first and most simple of them is shortcuts.

These have been around for a bit, they're already on mobile and now in desktop and provide an easy way to launch or deeplink into your PWA.

These are set on the manifest file and once the app is installed, they displace the deep links to the app formatted with the name and icon specified.

For our example, we are enabling the user to directly launch into a blank or random colored logo, because sometimes we need the extra inspiration.

So we're going to bring the task bar and I'm going to click on the menu where you can see here that you can create a blank logo or you can create a random logo.

And these, and these actually are the same options that you are getting in the shortcuts manifest entry that you've got.

Now, we're going to also check here in the start menu entry for the PWinter.

We can double click and you can see that we are getting as well the two shortcuts or jump lists options here directly from the list of applications.

We all know that sharing is caring.

And when you've worked so hard in designing that perfectly branded lettermark, you want to share your creation with the world or the marketing team that's asking for the logo.

The webshare API allows for content to be shared and in their application, we are sharing both the app itself, because remember in the land of walled gardens, frictionless discovery is king, and more importantly, the work of art itself.

To do so we use the `navigator.share` promised-based method and pass an object, which includes URLs, text or files that we want to share.

So I'm going to open the application here.

And we're going to see how to share.

The application is going to just load a randomly created logo.

Uh, let's say I like this one looks well in dark.

Equally okay in bright.

So what I'm going to do is that I am going to, first of all, click here on "share logo".

And what we see here is that there's an item that's attached, which is the SVG file that's generated that contains the logo itself.

In this case.

Um, yeah, I want to share this and I think it would be interesting...let's see what other options- this is piggybacking on the operating system share.

So in this case, I want to create a new email.

I'm going to send it from this email and we can see here that we have okay, 'custom PWA logos', so, um, 'send'.

Now we've actually sent the logo from, uh, the application itself.

Now, another thing that we can do is pretty much to share a link to the application itself.

So there we go - we've just got the email.

If I click this icon, I'm going to be sharing the link itself.

So in this case, I am sharing the link, which just has the URL, title and text, and we can actually - in this case I'm also going to - actually I'm going to post it in Twitter.

I think that might be interesting.

So it's creating that tweet, a "PWinter design, your own PWA logo", and it has the link to the app itself.

Now if I tweet this, there you go.

It is live now.

I'm going to close Twitter for the moment, cause I don't want to get distracted.

But what's interesting here is that, uh, there's what we just saw, which is a way of sharing links by just calling `navigator.share` and the other way, which is sharing files.

In order to share files, notice that in this code, I am checking if the call would be successful with files through the `canshare` method, this is a way to test if file sharing is supported in the browser, and if that specific file that you are sharing would work.

Now, this integrates with the native OS dialog and allows you to easily share through Bluetooth, email or other applications that can act as a target for the type of content you are sharing.

Which let's be honest, you're already thinking, can our PWA be one of those acting targets?

Interesting question.

Bingo!, You know, through the manifest file, your wildest sharing dreams can come true.

You need to specify the `share_target` field, which will tell the operating system what type of content it is registering to be a target for say, if you want to be an incoming target for texts or links or images, for example, and the action, which is pretty much the URL that will process said activation.

Now, let me show you the power of share and hopefully share my enthusiasm for what you might be already seeing is indeed a brilliant feature for apps.

So I'm going to just quickly open, uh, a, you know, a repo of colors because there might be a color that I might want to use as inspiration for the PWA logo that I'm about to create.

And I specifically think that these sort of peach colors, papaya colors are really, really nice.

So something, you know, like this, I think this is really interesting.

So I'm just going to go ahead and click share and look at, at the moment this share is bringing up the browser's sharing prompt.

But if I bring the native OS sharing prompt, it's interesting to see that I can share with the application that I've just installed.

So I'm going to click this and look, what's going to happen.

I've just created a PWA logo that's based on the color that is on this page.

So closing, and let's see this again.

I'm going to go and choose another color I think that is interesting.

This is...this kind of like mint color is kind of nice.

So again, I'm going to share with our application and voila.

Now I'm going to preview it in dark.

Uh, maybe I want to create some sort of distinction here in the w and you know, it looks really, really nice.

So again, this is how we've seen to create a logo that's based on something that the application is receiving and to share.

Again, if I wanted, I can just share this and it'll send it on an email.

So, again, very powerful functionalities that are already incorporated into the web platform themselves.

I will close now this and we can continue then our recommendations.

Now I'll jump now to tell you about scheme and URL handling.

These are slightly more advanced and possibly less common yet their potential to enhance the user experience of your application is huge.

And to be fair, depending on the type of application that you are developing, say, if you're developing a web based email client for example, these might actually be your bread and butter.

I'll start with scheme or protocol handlers.

As its name implies it allows your application to be registered through the manifest file again, when installed, to handle a specific scheme.

The easiest way for me to explain this to you is with an example.

And this example is the mailto://.

When you click on a mailto:// URI, you generally expect the email client to pop up and get you ready to compose an email.

Now imagine that, but in this case, the client is a PWA.

There are several safe listed schemes that you can handle.

Among the most known are mailto, magnet for torrents, MMS, SMS, and tel to name a few, but the fun doesn't stop there and you can create your own custom scheme to handle, and that's quite priceless.

It's like having your own set of links that you can activate through your incredible PWA.

I've registered a custom protocol that defines color palettes and published on a website, a bunch of these pallettes.

Now the magic happens when you open one of these links, as you can see, they trigger the associated PWA or provide a disambiguation link if several apps can be handled by the same protocol.

So, we will see this in action through the PWA palette repo in the upcoming demo.

And again, I am linking here - I'm just opening this website- it says "welcome to the PWA logo pallette", and you can find a nice array of, you know, color combinations.

So we are going to click first on the official PWA logo.

It's asking me, it's prompting permission to say that, you know, "this website wants to open this application".

And once I click on open, then it's telling me, "how do you want to use this application?" I'm going to select in this case, the PWA PWinter.

Now this is important because if we had several PWAs that do handle the same protocol - for example, you might have Outlook, you might have your custom email, a client that all handle the same mailto protocol - then you might want to choose which is the one that you want to select.

So in this case, we only have the PWinter and once I click it, voila.

We have the application that is being opened with the official PWA color.

So let's close this and try another one.

These are some browser inspired combinations.

So in this case, what I'm going to do is that I'm going to open an edgy ocean wave.

And voila!

We have another protocol that's being invoked.

Now, just so you can understand what's going on, I'm going to make the browser window here a bit smaller, and to finish - here it says "much flag approve" , we have the "bratwurst und bier", and you can see that the link that's going to be triggered as a web + pwinter, and it has certain color combinations that are the ones that are going to be received by, in this case, the action that is defined by the URL in the protocol handler that we are registering.

So I'm going to click here "open".

I'm going to select - and we can see here that now I have a PWA logo that is with a certain combination that's coming directly from a protocol handler.

Let's close here and let's close here.

And that's pretty much protocol handling explained.

Moving on to URL handlers.

This is a feature that will enable your installed web app to register to open links that are inside its scope.

This requires again, a field in the manifest file and a web-app-origin-association file in the domain that links to the PWA's manifest file.

This is as a way to approve it to open its links inside of the installed web app.

This is a nifty trick that some music or video streaming apps do.

When you get a link to a song or to a movie, for example, and when you click on this link, it opens the PWA instead of opening that link in the browser.

It's the small details that matter, and it's noteworthy to state that URL handlers can expand the scope of an application through its origin associations.

So potentially you could allow the installed web application to handle URLs from different domains.

Let's see how this works and how it is enabled again from the manifest file.

We have an entry called `url_handlers` that states all the origins that the PWA will try to handle the links for.

In this case, we have `origin`, which is the same origin of the pwinter.

We can have different origins as well.

And then in the domain itself, we have the web app origin association file that defines a link to the manifest, kind of like as a key to the applications that is granting permission to hand its links.

So what I'm going to do here, and this is kind of like very meta, because what we're doing here is that PowerPoint is linking to the app itself.

And I've actually been doing it throughout the whole presentation.

When, when I click on this link, you can actually see, let me see if I can hover here.

You can actually see that this case I am opening the website.

And here we have the website itself.

Now I am purposely did not make it navigate to a secure location because I wanted it to open the website.

But I have another image here embedded that is actually pointing and linking to the to the PWA from the secure location.

So once I click here, it's asking me if I want to open it in the browser, or if I want to open it with the installed PWA and I can actually tell it to remember my choice.

So when I click the PWA and I click open, voila!, I'm actually getting the PWA opening links that are meant to be in the scope of the application.

So it's a pretty cool trick.

It's very subtle and it's definitely very, very elegant.

Let's close this round of features with the ones that are related to files.

We will see file handling in action and accessing the file system to save a copy of our custom logo, which is pretty much the only thing that we haven't done.

Let's learn how to open a specific file and then save a file to the file system by defining our PWA as a handler for CSV files.

I believe this is a fairly straightforward way of demonstrating this feature.

Hence, I will create a file that contains the hex values for each of the letters, and we will open it through the context menu of the operating system.

Now you can see how the file will be read and simply we'll apply each of the colors to the P, the W and the A, and, you know, it's kind of nice and easy integration of our application with windows.

I am linking in this case to this file.

And in this file, I just have three hex colors that I will apply to each one of, of our letters.

So just as an example, I've clicked on it to see that it's - the default way of opening is with Excel, but I am quickly going to go into the browser.

This is the file itself again, opening, so you can see that it's exactly the same file.

But if you notice, if I right click on the file, I can go into "open with", and now the Pwinter is actually listed as one of the default file handlers.

So if I click this, it's telling me that, you know, it wants to open this file.

I can actually, I need to grant permission for the PWA to, to get access to the files.

And once I allow it, it loaded the colors and it painted the logo in those colors.

So these are the colors that are defined in the CSV file.

And I can now just open CSV files with my installed PWA.

And think that this could be JPEG files, this could be text files, any type of file...pretty much that is textual or image or video, you should be able to handle with your PWA.

Again, you know, I like this logo, so now we're going to go through the next step, which is pretty much just saving it to the file system itself.

We want the logo as an SVG - we want that SVG file.

Through JavaScript APIs we can now request to get an open or save file dialog.

Once we get the file handle, then it's just a matter of reading or writing to disk the data that we want.

For our application and considering that we are writing to disk, then we are configuring the OS dialog to start in the pictures folder, suggesting a default name to use and setting the file type to SVG.

And this is the options object that you can see here, where we are telling it to start in pictures, we are giving it a suggested name of custom PWA logo dot SVG, and we're specifying the type as an SVG file.

So with this, I am going to open the PWA again, and I'm going to click on "save logo".

Now, what you see here is that indeed we are starting, we are - actually let me close this so I can move the window and let's do it a bit like this.

Okay.

So you can see here that when I click "save" it's opening the dialogue on the Pictures folder.

It's setting the custom PWA logo as the name - suggested name, and it's telling me that I'm going to save it as an SVG file.

So I'm going to take this and I'm going to save it on my desktop.

Save.

And we should have gray pink and some sort of green.

So I'm going to go again to the desktop.

And I see here that I have a custom PWA logo one, and I'm going to open it.

In this case - let's actually see what's the default way of opening this logo.

Hmm.

So I'm just going to open this logo with Microsoft Edge.

And as we can see, we have the logo that we just created.

Oh, there you go.

It was Inkscape, but basically, yeah, you can see how the logo is being opened.

The logo, you can see how the logo that we just saved is being opened by Inkscape by Microsoft Edge or by, you know, any other app that can handle SVG files.

Now there's a full session by uncle Thomas dedicated to files and PWAs.

So I won't dive into many more details right now.

What I can tell you is that apart from the method being used here, which is `showSaveFile` Picker, you can also call, `showOpenFilePicker` and `showDirectoryPicker`, depending on if you are reading, writing, or enumerating files.

We've seen in a small app how many of these capabilities enhance the feel of being integrated into the operating system.

There are two other functionalities that are not demoed in this presentation that have been available for a while now, and that also help enhance the experience.

These are the ability to set or remove badges on your app's icon on the task bar or home screen, and the ability to send push notifications.

And yes.

Please please be responsible with side notifications.

Ever since the capability was available, many apps have abused their use, and it has started to create notification fatigue.

So similar to the other features discussed here: with great power comes great responsibility, and some haven't understood that asking for permission to send notifications as soon as you load a website without any proof of interest or utility makes your website feel and look like spam.

So the point of all these features is to provide a good user experience.

Now the point of all these features is to provide a good user experience just because you can doesn't mean that you should.

Be mindful of your users and create experiences that delight them.

All these are capabilities that we hope will allow your web code base to feel more refined.

We've seen how many of them allow for patterns that are akin to that of native apps.

We are doing this because we believe that by empowering the web platform, we all win.

This is our responsibility to ensure that we commoditize development, but also distribution and UX.

I think that the time will come when speaking about the term PWA for web or app development will be like speaking about responsive design, it'll become a commodity where having an app or a website that doesn't integrate with the platform where it is running will be just considered a web - a bad web or a bad application.

All of the capabilities that I have shown you today are available in Edge Canary.

If you want to try them out yourself I encourage you to download an insider version of the browser and get hands-on.

It is surprisingly easy to incorporate most of these features into your existing web apps and with progressive enhancement, you can make sure that no one is left behind.

Now, most of these features are behind flags and you can access these flags by going to about://flags on your browser.

They generally appear while searching for the term PWA.

You're welcome.

And look at the time!

I've got carried away with all the cool stuff coming to install web apps on desktops that I forgot to emphasize on the four things that I consider to be really, really important.

First, I would recommend to register to an origin trial, to test a feature appropriately.

This is useful as it guarantees that users with compatible browsers won't have to be switching flags on and off to experience these benefits.

Second.

You might have noticed that the majority of these characteristics are enabled on your platform in the manifest file.

This file is becoming an essential part of any modern website, as it encompasses, not only all the information about your application in order to be included in application repositories, but it also includes now ways of enabling advanced features.

So be mindful of your manifest file.

Third, I've talked about great new features being developed and tested for PWA's in the desktop platform.

And once you have your web app ready, you can go and submit to application stores and maximize distribution and discovery.

I recommend for the next step in your PWA journey, taking a look at PWAbuilder.com.

It's a great open source project that helps you making sure that your application is ready for prime time.

And fourth, I'm all ears seriously.

And we, the folks behind your favorite browser, are all ears.

These APIs are being built in the open, discussed in community groups, accessible to everyone.

So if you have any questions, comments, or suggestions, don't be shy about letting us know.

If you're keen on getting involved, then by all means be our guests.

Nobody knows how the technology can help you better than yourself.

And if there's something that we are overlooking while creating the tech, then it's important for us to know.

If I can be of any help, either answering questions or redirecting you to the right person to answer your questions, then by all means, send me a message and I'll be happy to jump in.

I hope you're as excited about the future of the platform as I am and sincerely, I hope these features help you in enabling the best experience for your users.

This is just the beginning of what I am sure will be an exciting journey for PWAs.

We've started seeing changes that allow for a more open, rich and healthy app ecosystem that provides equal opportunities to any experience.

And that empowers an already great platform that keeps on getting more capable and useful and accessible to all.

So stay safe and see you around soon.

One of the promises of PWAs is installability.

But how can developers best ensure users install their PWA and manage that installation process?

In this presentation, Penny McLachlan, product manager for Chrome will cover how we can best and when perhaps we shouldn't, take advantage of PWA installability.

Hi, everyone.

Thanks for watching.

The session today is on web app installs-the why the when and the how.

If you haven't been completely deafened by the buzz of apps over the past decade, I would love a pair of your noise-canceling headphones.

The word app is now a standard lexicon for all users, both technical, and non-technical almost everywhere in the world.

For the multi-touch generation, apps are basically synonymous with a digital experience.

But what fundamentally our apps, it might seem obvious, but is it really?

What is the distinction between a website and an app?

This won't be a shock, but there isn't really an authority for what an app really is.

All we can do is try and list out some of the common properties.

So here's a few properties of a website.

You might notice that these are all pretty desirable properties in the right circumstances.

And there are also some of these properties that are true some of the time, but not all the time.

And these are marked in gray.

So for example, the web can run on pretty much any device quick to open and use.

Hopefully if you're designing your website well.

It can open from the browser.

Or of course it can run as a standalone window.

It might work offline if you've done some extra work to make it do that, or it might not in most cases still not, unfortunately.

We hope more website support offline soon.

And, it may not be specifically optimized for the layout of the device.

So it will, might have break points, but they're fairly generic.

It's not saying, you know, this is the screen is laid out in this exact aspect ratio.

And finally, a website is linkable.

Let's compare that to an app.

Usually these are ecosystem specific.

Of course you can use cross-platform frameworks.

Typically apps are downloaded and installed.

Although instant apps are a thing.

Apps can be opened from launchers and files.

It feels like it runs independently.

It doesn't need like some server somewhere to work.

Typically has its own window, works offline and it often has powerful capabilities, the system access.

And it may or may not be linkable.

Let me touch back on that offline common [unclear] for a moment because like many apps just have a very simple offline, you know, this app needs connectivity in order to work and that's fine.

That counts as offline.

So there's one more thing I want to add here.

Which is how our user feels about these two different types of experiences.

I believe that users tend to feel that they are just visitors on a website and we reinforce this perception with the words we use.

On a website, you are a visitor, but on the other hand, you "get" an app.

Getting implies that it belongs to you.

Now, I think we all understand that data in an app can also live in the cloud.

Just like data in a website can live in the cloud.

And data in the website could also be local and data in an app can also be local.

But the words we choose has implications for how users think about these things.

And I really do think that users think about a website as something that they use and an app is something that they own or possess.

Let's talk for a moment about web apps.

Some of you might be old enough to remember this little beta app called Gmail.

So why are we taking this trip down memory lane?

Well, because it illustrates a point really nicely.

When Gmail came out, there were lots of other email clients.

In fact, pretty much everyone who had a computer had an client already installed on it.

This was the internet's first real killer app.

In fact, not only were there lots of other email apps out there, but most of them had honestly more and better features than the first release of Gmail.

So why was it that Gmail and other web-based email clients that came out at the time able to get so much market share.

And the answer is that because it was universally linkable, shareable.

It was nearly instant to load.

It was safe and relatively private.

That means that even if you had a shared computer inthe household for example, everyone could have their own private email account.

Email's come a pretty long way since then.

But 20 years ago it had what it took to win market share from extremely popular and common email clients.

So how does that apply to progressive web apps and how we think about this app versus web stackup?

A Progressive Web App is an installable web application.

It uses modern APIs and as an installed application, it can appear on the device's launching services, including the activity switcher, content sharing surfaces, et cetera.

And it can also work offline.

It can run services in the background and it can access device hardware such as Bluetooth or the file system.

So what my team and I are trying to accomplish is to increase the power of web apps, pushing into capabilities that were previously reserved for native apps.

Coming back to the Gmail example.

There's this question of, can we ever achieve parity?

And I get asked this a lot and the answer is probably not.

There is a law of diminishing returns to consider.

We get into more and more esoteric functionality that gets more and more expensive to manage and maintain, but here's the thing: does parity really matter?

G-mail didn't need to be exactly the same as those desktop based email clients in order to compete.

It was able to compete just fine with its own merits.

It just needed enough capabilities such as webXHR in order to be able to do dynamic loading.

And like once it had those capabilities, it was able to do a job that was competitive, even though the benefits of using it implied trade-offs.

I'll be the first to admit it's been a bit of a strange journey getting us here, Apple bet big on web apps with the launch of the iPhone.

I mean, there were no native apps on early iPhone models.

Now a native App preference might be strategic for them.

There are undoubtedly cases where a native app is the right choice, but is this really the case for all, or even most apps?

Does a parking app or a finance app really benefit from being native?

I think what we want to do is get to a world where you can get the best of everything.

And that's really what PWAs are here to give us.

We want to bridge these gaps into a seamless experience that can work in a browser tab and an ephemeral linkable universal way, and then it can be installed and it can take advantage of operating system UI affordances, like sharing the activity switcher and launching surfaces such as the home screener or the start menu.

So let's talk about one incredibly powerful capability of web apps that works almost everywhere.

Yes.

I know it's a little early for Christmas, but I do love this animation.

The fact is you really can install a web app now on all of your devices.

Go ahead and give it a try.

If you'd like: YouTube and Reddit are both installable.

For example, on Windows, Mac, and Linux devices.

Web Install offers users access to web apps from familiar discovery launch surfaces on the device.

And of course these apps can be standalone.

So they're totally separate from the browser.

They use the native task switcher and, you know, this may be more familiar to some users or more suitable than tabs for some types of activities.

Web Install integrates Web apps with device services that expect an installed app.

Here's the important thing to remember when you're asking your users to install your PWA.

With an installed app, you are telling your users that this is an experience that was meant for their device.

And that does mean that you need to live up to those expectations.

So you want to follow design patterns that are going to give not just an installable app, but an installable app with a UX that's going to look and feel like it belongs on the device the user is running it in.

Your basic requirements for supporting the installable web are to have both a web manifest and a service worker.

These are actually in the year 2021 are pretty well-documented now.

These are the same requirements to be classified as a PWA.

I'm going to be covering mostly the manifest.

For the service workers, the requirement for install is that you do load offline.

And if the user opens your app while disconnected, they need to be able to see something.

You're going to find some amazing content and code labs from Google and around the web on this topic.

The manifest is a simple JSON file, which informs you how your site acts when it's installed.

You need one per app and it needs to be linked from every page of your site.

So the user can tap "install: pretty much anywhere.

Pretty much all modern browsers have some level of support for the manifest.

Here's how you include a manifest on every page.

In case the user hits install there.

The actual manifest is pretty boring, but here's a complete manifest.

It's small and extnsible.

I'm not going to cover every field today.

There's lots of information out there on the web if you want more details on any particular field type.

But let me just touch on a couple of the most important ones.

So first there's the start URL.

This is where your users begin their journey.

When they launch your app on their own OS.

And you can use this query string parameter to capture session launches in your analytics.

A second, this screenshot section is what is going to give you your users a better install experience.

This is already available on mobile, and it's going to be coming soon on desktop.

So here's a, an example of the upgraded install UI.

And so if you have the screenshots in your manifest, then, for example, on Android, you're going to get install UI that looks more like this, as opposed to an info bar and a confirmation dialogue that didn't give the user a good idea of how your app was going to look and feel before.

Finally, let's talk for a moment about how window, windowing is going to work via the display mode JSON field.

So there's a few different options here.

For games, you might prefer a full screen display mode.

This is the example there with Santa.

And for anything app-like you're probably going to want to use standalone which doesn't completely fill the screen from headset.

This is more a standard app-like UI on, especially on a mobile device, websites in any mode can be installed and still run in the browser.

So you can use display mode browser, and there's a few other options like minimal UI, but you can read more about those online.

So now that you know how to make apps installable, I'm going to show you how and when to promote a web app install.

Please just promote web app install when it makes sense.

So I'm going to show you some examples of that, but the focus should be on the user.

How are you helping the user get their job done?

If asking the user to install at this particular moment, isn't helping them get their job done, then you shouldn't be doing it.

So where should you promote app install?

First, the header can be a good place, but you should be careful here.

Especially on a phone.

These are super precious pixels.

So you want to use information architecture, techniques and AB testing to determine whether it really makes sense to have a permanent install button here.

It's going to depend on your use case.

Like you probably have other information here, like your logo, a hamburger menu, maybe other shortcut items, like for example, a shopping cart shortcut on an e-commerce site.

These are all really important use cases for the user, and they might be more important than installing your, your, your app.

So consider carefully before using this space, but it is an option.

Here's an example of adding an install promotion through the hamburger menu.

The really great thing about using the menu for promoting your web app is users browsing your menu.

That means they're looking for something.

You don't want to block any important information, by promoting this, like, for example, the very top of your hamburger, you might want to put it a little bit further down.

So the users, you know, again, use information architecture, techniques, AB testing, to understand what your user is most likely looking for.

But the menu is a great place to put it because it's a menu it's there to fulfill the user's needs and it's there to fulfill needs that they need a little bit less frequently than things that are are up in the header.

Here's an example of promoting install on a landing page.

And I mean, landing pages are basically all about marketing your site.

So just go crazy here, keep in mind that the usual best practices for a landing page to tell the user about your content or your product or your service.

And if the user doesn't understand what your site does or why they would want to install it, they're probably not going to.

So just make sure that you get that up front.

Now a lot of sites have feeds whether that's news or photos or recipes, and that feed pattern can be a great option for promoting PWA install.

You can just essentially insert feed cards that are like, you know, they look and feel like most of the other cards in the feed.

Next up, they promote the installer of your app.

It's great for news apps can be good for e-commerce sites for things like the product listing page and anywhere, there's a lot of vertical scrolling and information chunking.

You probably don't want to show this promotion too often, and you might want to include a dismiss option so that the user can get rid of the card if they are never going to want to install your app.

And so you don't keep annoying them.

Keep in mind that every app use case is a little bit different and there will always be key moments of engagement in the journey, when you know, the user is interested in your offer and understands it effectively.

That's a great moment to see if they want to connect with you again soon.

So the usual rules apply here.

Focus on the benefit to the user.

Use the context of those key moments.

Like in this example where we can let the user know that they can install instantly and then play the game again, by tapping off the launching surface of their screen.

Here's some basic principles for promoting PWA install.

Start with a good rule of thumb, please.

Don't be annoying.

Your users came to your site to get something done.

Don't interrupt their flow and make it harder for them to get that task done by asking them to install.

Just keep in mind.

It's really easy for them to leave.

So if you're annoying them with stuff, they're just going to ax it.

They're going to go somewhere else to your competitor's site, for example, and get their job done there.

The user's not benefiting, you shouldn't be promoting the install to them.

Finally do use context in advanced-help the user understand what they're really going to get from installing their app.

Like, what are they going to get out of that install?

What additional services or functionality are you offering?

Or like, why would they want to come back and visit your site more frequently because they've put it on their home screen?

Now, after you've got a user who's installed your app, you're gonna want to understand what's different about the behavior of installed users versus users who are viewing your site in a tab.

So don't forget the analytics.

There's really three important events in the install prompt flow.

First is an event called `beforeinstallprompt`.

And this happens when the site is qualified for install.

Second, when the prompt actually gets triggered.

So you can just listen, for example, for a click event on an install button on your site.

And then finally, when the install complete successfully, you will receive an `appinstalled` event and you can listen for this too, and you can tag it in your analytics, no matter which analytics package you're using, you can set this information as a custom event or you know, add the state as a custom variable.

You may be wondering, well, what about iOS?

And the great news is that iOS Safari has really good support for the essential PWA ingredients, like a service worker and a manifest.

And it's had these ingredients for quite some time now it's.

It's easier than ever to install PWAs on Safari.

And the other home screen option, which installs the app on Safari is a first level menu option.

So what you want to do is show up a promotional pattern for iOS.

Hey, here's an example of one we use for the Santa tracker.

And as you can see, when the Santa tracker install pops up, it just helps teach the user how to use Safari to perform the install.

Now, a lot of organizations do have native apps and they worry about accidentally promoting web install to users who already have that app.

You're going to want to promote your PWA to users of the website, but just the ones that don't already have the native app installed.

Keep in mind that there's all kinds of reasons that a user may not have, or want your native app, but might still want your web app.

So storage is one example since you know, storage is one of the number one reasons that users remove apps from their device and many apps use 10 to 50 megabytes of space.

Most web apps are comparatively tiny, just a few hundred kilobytes.

And like any of the dynamic storage, like the cache gets purged automatically by the browser in response to storage pressure.

So we may want to let users know that the option of the web app exists.

To avoid promoting your PWA install to native app users you want to use get installed related apps, and that API will let you see in JavaScript if the user has your native app installed.

Most PWA installs today are happening from the mini info bar or from the richer install UI.

This was the mini info bar is really not intended to completely replace your own browser promotion.

So you're going to want to you know, you may want to hide it completely and only trigger install from a promotion that you're running inside of your site.

If this is the case, what you want to do is you want to listen to the `beforeinstallprompt` event, and then you want to call `preventDefault` on that.

So that you will prevent either the richer install UI or the mini info bar from appearing on the screen unsolicited.

So that will basically stop Chrome from promoting the installability of your site to the user.

So here's the details really quickly.

We're adding an event listener for `beforeinstallprompt`.

And then all we do is we call `preventDefault` on that event.

And we might want to show an install button at the same time.

So we give a little example of doing that.

So in this case, you can see, we set `the installButton.hidden` to false, and Bob's your uncle.

Finally, you might want to capture a reference to the install event so that you can use it to prompt the user for an install later.

Here's an example of how to use that save reference.

So let's imagine you want to wait until the user has completed a critical part of their journey before prompting them about installing your app.

When you're ready, you can just call the `prompt` method on the saved event reference.

That's the talk for now, just a reminder of what we hope to accomplish here.

I want developers to have the capabilities they need to build amazing web apps.

And I want those users to be able to choose whether to experience that in the browser or in a standalone installed app window, whichever is better suited for their needs.

And the web is in this extremely unique position of being able to do that.

Installability is essential in enabling this.

And I hope this talk gave you all the basics that you would need in order to make your app installable, to promote it and to measure your success.

Thanks so much for listening.

You can reach me on Twitter.

If you have any follow-up questions.

If you didn't know already the major app stores accept PWAs, but just what is involved in getting our apps on them?

Today Maximiliano Firtman, author, educator and independent developer shows us how to take a PWA for browsers and make everything available in stores.

Hello, welcome to the journey of polishing a PWA to the app stores.

My name is Maximiliano and I will give you a journey into publishing a progressive web app to app stores.

That's our goal.

So you do have a PWA, you have a progressive web app that is already published and we actually want to get into app stores.

That's the goal.

So the first station and we are going to have a couple of steps to actually get to the final station, the first station is the PWA.

So you should have already that PWA published in a web server.

So you have a service worker, you have a web app manifest and you do have a good UX, and performance.

Something that we want to keep from progressive web apps, when we are going to the stores is easy deployment, single code base.

We don't want to change that.

Silent updates.

So actually updating the PWA is just changing the files on the server, that's all, and open web standards.

So we don't want to get out of HTML, CSS, JavaScript, and all of the standards that we love.

So the next station, after we have the PWA is the Plan.

We actually need to make a plan to actually get to the store.

So before actually doing the plan, we need to understand the actual app stores that are actually compatible with progressive web apps.

Today we have PWA support on Google Play-Google Play is the store for Android that's of course phones and tablets, but it's also the store for ChromeOS or Chromebooks.

We have support also on the Apple app store.

That includes iOS, iPad OS, and Mac OS.

And finally, we have PWA support also on the Microsoft store.

That's for Windows 10 and Windows 11.

What about other stores?

There are other stores available that are not actually the mainstream stores.

We have, for example, the Samsung Galaxy store that accepts actually publishing a PWA just by, by submitting the URL.

We have Amazon app store for Fire devices.

Kaios store for feature phones and Huawei app gallery for Huawei devices.

In these stores, we have some hacks to actually publish PWAs, but it's not so straightforward.

So we're going to focus only on the three more important stores that we mentioned before.

That's Play AppStore and the Microsoft Store.

First it's important to understand during our plan, that stores is not for all the Progressive web apps out there because the PWA needs to actually comply with store rules.

So some apps will never be accepted in the store.

So there are some user interface guidelines that sometimes we need to follow.

And when we have a PWA, we may be accepting those guidelines or not.

We might be following those guidelines or not.

And if not, maybe we need to make some changes.

Also, when you have premium content and you want to charge for that content, we need to follow the app store business model that that store has.

And because of the nature of the web and the nature means that you can actually change the contents of your app from the server, there might be additional restrictions.

For example, on the Play store, you cannot publish using a PWA content for children.

So there are restrictions on that.

So we need to read all these guidelines, to actually understand what's possible and what's not.

And we also need to do some homework.

Part of the plan is to do some homework.

We need to do and plan these with time.

So first we to register ourself as a publisher or we need to register our company or organization as a publisher, sometimes that involves paying a fee.

On Apple it's US$99 or different amounts of different currencies for different countries.

That's per year.

On play, it's, $US25 dollars, just a one time payment.

But that registration might take time.

The process can take days or even weeks, mostly when we're talking about organizations or companies, because the store needs to be need to have some kind of security or guarantee that we have the rights to publish apps under the name of that company.

After we have that account, we need to prepare a privacy policy URL.

So we need to have a document, an online document with the privacy policy, something that is not always mandatory when you have a PWA that is just published for the browser you need to pick a package ID.

That's a string that is typically a reverse DNS.

So for example, if your PWA is publshed under myPWA.com, you use com.myPWA as your ID, and on some stores you need to register or reserve that package ID.

You need to prepare a demo account for reviewers.

That's in case you have a login in, within your PWA.

So you need to log in and registering an account.

You need to prepare a demo account for reviewers and you need to prepare a lot of metadata from text descriptions categories of your PWA to icons, screenshots and a lot of promotional banners.

And of course on each store, the resolution that you need and the places where these promotional banners will appear differ.

So you need to read a lot of documentation on all the metadata that you need.

Something that is not necessary when you are polishing a PWA for the browser, or at least you need just one or two, a screenshots.

And that's all.

So after we have the plan, we have the PWA we have started the plan.

The next station is launchers.

We need to create and focused on PWA launchers.

Let's try to understand what this is.

So when we are talking about app packages, so whenn we are going to the store we're uploading packages.

This is like a ZIP file, a package an archive.

So there are a couple of packages.

We can create a native app package.

When you you're doing Kotlin aps or Swift applications you have within the package, you have all the assets, all the resources of the app, including the compiled code.

You can have hybrid packages, such as the ones that you publish with a Apache Cordova or a PhoneGap or Ionic.

In this case, you will have your web up embedded within the package.

So the package will actually have the web app inside.

And finally, we have PWA launchers.

And what's the main difference?

The PWA launcher is a package that is empty.

It doesn't contain actually the actual web app inside the package.

So the PWA launcher is a native app.

It's a native shell that launches a PWA and it just contains the app's icon, the app's name, the start URL-so the URL of your PW-and other metadata, that is actually different per platform.

But it doesn't contain the assets.

No resources are actually shipped with a PWA Launcher.

The service worker, is still in charge of downloading all the assets that we need, like HTML, CSS, JavaScript, images, web fonts, and all the, the rest of the assets.

It's also responsible for caching those assets and for serving those assets on the next load as with a browser installation.

So when you're installing a PWA from the browser, it's actually the same behavior.

So now let's talk about the three platforms and how to create these PWA launchers.

Let's start with Windows.

For Windows 10 and Windows 11 we need to create an APPX launcher.

The APPX launcher today is using the Chromium-based Edge runtime.

So it's going to use the actual Edge browser that the user has on that Windows PC.

And to create this package, we need to use Visual Studio in case you want to do it manually, or you can use PWAbuilder.com.

PWAbuilder it's an open source free tool available on the web where you can actually type the URL of your PWA.

Remember, our PWA must be published before going to the store.

So we type the URL.

And after a quick test, PWAbuilder will offer us a Windows package that we can download and then upload to their store later.

So what about Android with Play?

And when we are talking about Android with Play, I'm mostly talking about Chromebooks and the Play services on Chromebooks.

In this case, we need to use, we need to create, an Android App bundle.

It's an AEB file.

Android App Bundle.

That bundle will include inside a TWA or trusted web activity.

In short words, the way that we have today to publish a PWA in the app store.

And this is only available for public PWA.

So your PWA must be published within the public internet.

So if it's under a VPN or an intranet, it's not going to work.

Also, we need to verify that we own the PWA.

So there is a verification link process.

So we need to link the PWA, so our web server content, with the Android package.

So they, it's a process that we need to, we need to create the signature file, JSON file, and then we need to publish in our server.

And that's all.

For, for creating these packages.

We can use Android studio in case you have experienced creating Android apps with Kotlin or Java.

Bubble-wrap, bubblewrap is a free CLI comma line tool created by the Chrome team to actually create these packages or even PWAbuilder.

So I'm talking about bubblewrap it's available on NPM.

So you just need node JS and with bubble wrap, you will be able to create these PWA launchers for Android.

So you just use NPM to install, bubble wrap, then using the URL of your public manifest.

You create the project.

You build the project and you're done.

You don't need to have experience creating Android applications if you use bubble wrap.

And if you don't want to mess with command line tools and you prefer a graphical user interface, you can also use PWAbuilder.

The same tool that I mentioned for Windows.

It's also suitable for Android.

PWAbuilder today it's using the same CLI bubblewrap, but in the cloud.

So actually we'll compile your package, you would create your AAB, your Android app bundle in the cloud, and it will be ready for you in case you don't want to install anything in your computer.

And then finally we have Apple, iOS, iPad OS and Mac OS.

So the App Store.

And we know that Apple's relationship with PWAs is typically weird, so Apple doesn't officially say a word about PWAs in the store.

So if you go and try to find some documentation about how to publish a PWA in the app store, you're not going to find anything.

However Apple has something known as WKWebView.

WKWebView is a WebKit engine that you can embed directly in a native application.

And from last year we have from iOS 14, we have something, known as App Bound domains.

Actually an App can include the list of up to 10 domains-so myPWA dot com and over those domains, the web view will have full support of a PWA, including service workers.

So meaning that we have a technical solution today to have service workers in a WKWebView, which means at the end that we can publish a PWA to the App Store.

There are many PWAs already published using these techniques.

For that, you need to use XCode and you type some Swift or Objective-C code.

Now, unfortunately we don't have any CLI or online tool today that will help us with this.

And if you want, I have some code samples on a course "Publishing Progressive Web Apps" that it's actually available in my website, firt.dev/learn, if you want to get more information about how to use X code to create these PWA launcher for iOS.

So now we have the PWA, the plan, we have the launcher.

The next step is to talk about extensions.

So can we extend the web platform with native code when we are going to the store?

So let's talk a little bit about that.

Because now on the extensions we have, like, we are crossing with another line.

With a native line and yeah, we can connect with Android native code, with iOS or iPad OS native code or with Windows code.

So let's try to cover briefly if this is possible or not today.

So can we extend the web platform?

So this is actually necessary.

So let's write to the fan and first make a difference between the chromium universe and the webcam universe.

So we know that today on Android, ChromeOS and also on Windows, we have Chromium as the engine.

And chromium today has a lot of APIs available.

The Fugu project for example.

So we have access to Bluetooth, NFC, and a lot of stuff.

And on the WebKit side, we are more restricted in terms of what we can do with the Web platform.

So let's try to analyze if we can extend this web APIs with native code.

On the Playstore using trust web activities, it's kind of limited.

So you can ship with your PWA launcher, also Android components, native components, but those components are actually not connected directly with your PWA.

So it's not so simple to make that connection.

And something similar happens on Windows today.

So it's actually not so simple.

So it's actually better to stay within the, the web umbrella, the web platform umbrella.

But on iOS that the web platform is more limited.

Fortunately, we have a way to have a bridge so we can create the bridge to native code.

So Swift can execute JavaScript and JavaScript can execute Swift.

So we can extend the WebKit engine with native code for our PWA.

So some integration examples, for example, push notifications.

Do we need to integrate native push with a PWA while on Play?

For example, on the Play store, we have automatic notification delegation.

So when a notification appears the system automatically delegates that into your service worker, into your PWA.

Andon iOS, well, we can bridge to native.

So we write Swift code or Objective-C code, and we connect that with our PWA using app bound domains.

And another example is in app billing,in case you want to charge for additional content within your app.

On Play, we have digital goods API, so we can stay within the web umbrella because we do have an API today on Chromium-based browsers, digital goods that will let us charge for subscriptions or for items within our App.

And on app store the same as with push notifications, we need to write our own native code and call it, using this bridge.

From JavaScript we're going to call Swift code.

Okay.

So remember to use the P in PWA.

So the first letter is for progressive enhancement.

So remember to use this pattern to keep a single code base within different stores.

So we have extensions now.

It seems like we are reaching App Stores, but before actually reaching the final station, I want to take a shortcut to the enterprise world.

Just a minute.

Today you can deploy your PWA into employees' devices.

Incorporate the stores, both on iOS and Android.

On IOS and iPad iOS it's actually pretty simple.

It's a mobile config file.

So the file can be deployed through the web or through email.

So you can send emails to your employees, and if the user accepts, that file, the PWA icons will appear automatically in users' homescreens.

Automatically.

So you just create this file, this mobile config file using a tool, a free tool.

It's called Apple Configurator.

You type the URL, you select the icon and then you deploy the file.

That's all pretty simple, straightforward.

On Android we have Managed Google Play iframe.

That's the name of the tool.

You can push PWAs using the enterprise Android console.

In this case your users, the users of your enterprise account, will see those PWAs under work apps within the store, within the play store.

So this is how it looks like.

And in case you want to create or ship a new web app, a new PWA, you type a URL and you select some metadata, pretty similar to iOS, and then users will find that app within work apps in Google Play.

Remember, this is a parenthesis and this is only available for enterprise users, not for end users.

Okay.

So now we are finally reaching our final stations, app stores for end users.

So we are approaching that final station and our PWA is ready for the app store because we have a publisher account ready.

We have all the metadata and we have created the PWA launcher.

So the final step is to go to the app store connect.

That's the Apple portal to upload our apps.

To the Google Play console, the same portal, but for Google Play for Android and ChromeOS and the Microsoft partner center, where you're going to publish your PWA launcher for Windows 10 and Windows 11.

And the final step is to brace yourself for rejection and or for making changes in your UI.

So prepare for this.

So some stores will ask you for changes in your user interface to get a final approval.

And that's actually the final station.

So we have arrived at our destination.

You have now a PWA published in the app store.

So that's all that the journey to publishing a PWA ijyo app stores.

Thank you.

And good luck with your PWAs.

Thanks again to Diego, Penelope and Maximiliano.

You've got 20 minutes to absorb all that and perhaps some coffee, tea, water, or a snack before we return for the final session of Code.

It's also your one last chance to start the REA challenge or grab some swag.

And we'll see you back here in 20 minutes.

Welcome back for the final session of Code.

We begin with a session rescheduled from last week and close with a rather different kind of presentation, but perhaps the most important of the conference.

A few weeks back at our JavaScript conference Global Scope, we took a first look at Temporal, a new JavaScript language feature for managing date and time.

Today, Ujjwal Sharma a compiler hacker at Igalia and editor of the JavaScript internationalization API, will show us how to harness the power of this delightful API in order to build powerful JavaScript applications that handle dates and times like we always wished we could.

Hello and welcome to my presentation.

I'm Ujjwal and I am one of the champions of the Temporal proposal.

And today I'm going to talk about Temporal.

So let's start.

First of all, just to give a quick recap about the stuff that I've already talked about, about Temporal in the wild.

What is Temporal?

Why do we need it?

Well, as you might know, the Date object in JavaScript is very severely outdated.

There's serious issues.

And people don't really like writing code using that.

There are popular third party libraries, like moment JS or Luxon for handling these things, but they have quite a few problems.

And something needs to be done and something needed to be done.

So we decided to create Temporal.

Temporal is a state of the art date/time handling library in JavaScript.

It is special to me because it tries to combine these two things.

It has an ergonomic API with a special focus on common use cases.

So some simple things like adding a month to a date becomes super easy.

And then it also combines that with a powerful feature set that can accommodate very complex use cases with the likes of local calendar support or custom time zones and calendars.

So you might have a custom calendar and time zone for Mars and you can run JavaScript on Mars.

I have a talk about this, so.

I suppose you can watch this talk on YouTube.

And this goes into much greater detail about these small points that I mentioned.

But without further ado, let's talk about where we are now.

So now Temporal is stage 3.

What does this mean?

It means that all the tiny details have been discussed.

We in TC 39, realized that we had done all the discussing we could in our cushy chairs.

And now it's time to actually push this and it's time to actually implement it in a browser and see what people think and have them use it.

The specification text has been approved by the committee.

So the committee is now satisfied with the design of the proposal that I'm going to introduce you to.

Now it's time for us to start implementing and using Temporal, which is why I'm here.

I want you to start using it and start thinking about it.

They, there have been polyfill implementations.

So when I'll talk to you about one of the sort of canonical polyfills that me and my colleagues have developed and you can use it immediately and there have been ongoing browser implementations.

So we're going to talk about that as well.

This is a quick chart that gives you a quick overview of all the different classes that we have in Temporal.

Actually, it's one of the biggest proposals that one of the biggest proposals that we've had in TC 39, it just look at the API surface.

That's so many classes the classes are more or less divided into two categories.

There's exact time types, which is instant.

And there are calendar or "wall clock" time types, which are fuzzy time types, so to say.

And there's PlainDateTime, PlainDate, PlaintTime, and so on.

There are specific cases.

There's three helper classes, TimeZone, Calendars, and Durations.

Durations for actually doing all sorts of arithmetic on, on these different classes.

And then there's ZoneDateTime, which is just sort of the Superman, which, which sort of combines both of these together.

And you can use that.

Just to give a quick summary of the API.

There is instant, instant represents an absolute point in time.

It's an exact point in time.

It is represented via nanoseconds that have passed since the Epoch There are plain types.

So plain foo so to say, which deal with regular wall clock time and calendar date.

So you can say, okay, well, At 8:00 AM.

And it doesn't matter if you're in St.

Petersburg or in Victoria.

And that's why they're great.

There are calendars which refer to human calendars, calendars, like the Gregorian, the, the Hijri Islamic calendar, or the Persian calendar, for example.

And there are times zones that refer to an offset.

Which could be, you know, plus five plus six 30, so on or a human time zone, like your Moscow or, or, you know, Australia, Sydney.

ZoneDateTime is a combination of instant and time zone.

So it takes an instant, it takes a time zone and then it can project that instant in that time zone to give you actually a ... something that resembles a date time, but then you know, it does refer to an instant in time.

All arithmetic operations are done using durations as I've mentioned.

So there is a serialization format for Temporal basically when we started out with Temporal, we were using ISO 8601, which if you might, if you know, it is the sort of canonical timestamp format, it's very prevalent.

There's RFC 3339, which is it's IETF counterpart.

And it's severely old and limited.

Just to give you an idea.

It was created before I was more so a bunch of things need to be done.

There's a number of ad hoc formats with additional time zone that are just floating in the wild.

If you write Java, you might've noticed one of them and we needed to build on top of that.

So we needed to also add calendars to the mix and, this, this made me realize this made us realize that there is the need for a standardized generalize extension format.

Something that can have time-zones, which is the past, calendars, which are all present and anything which can come up in the future.

There's there should be a generalized way of doing these things and not sort of ad hoc, just pushing things into each other.

And so we came up with a draft.

I've written a draft and actually this draft has now been adopted.

So there's a new title, but you can find this it's the title of the repository, which it's on.

And it's a new draft that adds things to the timestamp to make it a more modern.

So to say, so we're working through the standards process and hopefully by the end of this year, maybe it would be published or definitely in the next year.

So just to give you a quick overview, this is what the what this looks like.

It is the standard sort of, if you see the green box, there is the standard timestamp, then there's the time zone extension that I was talking about, which is used in the Java ecosystem, for example, but it is not completely standardized.

And then there's the calendar extension that we added to that.

So, and these are the different types that can accept sort of subsets.

So now that boring stuff is done, let's make an invoice calculator.

Let's see how you could practically use this API and judge for yourselves.

Let's like if, if you know, if it even makes your life better in any way.

So step one is pick a date-time picker.

We need to pick a picker.

You need to pick a date, time picker that fits your rendering strategy.

I'm not a person who does front end, but If I I've been told by friends who do front end, that people usually pick libraries that, that work with their sort of rendering strategy with whatever framework they're working on.

The only important part when it comes to Temporal is that it should return an ISO-8601 string, which are accepted by Temporal.

Should it return a Temporal type?

Well, these are JavaScript libraries and Temporal is supposed to be the sort of canonical way of doing dates and times in JavaScript.

So it makes sense and because Temporal is fairly new this doesn't happen right now, but it should, and maybe you should fork some of these libraries to make that happen.

But talking about date-time pickers that return ISO-8601 strings there are already many you can pick from.

So there's react-picker.

I just went on NPM and found a few for you.

There's react-picker if you like React and datetimepicker, if you like jQuery or just nothing at all.

So once you had this ISO-8601 string, you can call Temporal.

PlainDateTime.from().

And so from here being a static method, that returns, it's a static factory function so to say, and this patttern must be familiar if you are familiar with the Rust ecosystem, for example, which uses it extensively.

And I think Ruby as well, but I'm not sure about that.

So you can throw this string in there, and that would construct a PlainDateTime from the string that was returned by the picker.

And that would just work.

So now you can have a start date, time and end date time.

And now you have two date times.

Now you find you need to find the difference between them, right?

Because you're, you're building an invoicing application.

And then you have the start and the end.

So when you have a start point and end point, you can find the difference.

Durations can be both positive and negative.

So, the direction is important.

Keep that in mind.

You need to keep that in mind, especially when you're adding durations and especially when you're dealing with money.

So we have, we're going to have a list of durations here and you're going to add them all up.

If one or, or some of them are negative, then it's just going to completely change your, your results.

So keep that in mind.

You can check the sign of any duration by calling the duration.sign accessor on, on the duration object, you can also find the absolute value of a duration by calling duration.abs.

It's a function like math.abs for absolute value.

So that would make your life easier.

Let's say.

So we have earlier the, the early date, the sort of date time instance.

So this as you can see from the, from the string there it is midnight.

And then there's later, which is the same day, but at 4:00 AM.

So it's earlier and later, and then you can get the result as, and this is the fun part.

There's two methods to do this for difference, right?

There's since.

And, and for since, keep that in mind later comes before earlier, so later since, right.

Because it's since later.

And, and until comes with earlier first.

So if you keep these two in the correct order, you're just getting positive durations as a result, as you might see.

If you're not you're going to get a negative duration and you can check that as I said, by signing over, or just find out the absolute value.

What is this output of this?

It's the string serialization of durations that we are going to talk about in just a second, but let's find out how much you worked.

So you have all these durations, you have an array of durations, so to say, and you can add them all together.

If you're a happy functional programmer, you might like something like that.

So you can call reduce on the.

Durations array.

And if you're like me you might just do forEach and I, I find that much more convenient.

Remember to call absolute here if, if any of the durations might be negative, it might be the better way to do this, actually.

Talking about the duration serialization format that I was telling you about.

So as you might see, you can create a duration from one years, two months, three weeks and so on.

And the format is P one Y so P for period.

And that's the sort of it denotes that it's the duration one, Y means one year, two M two months, three W so on until days.

And then after days you have T so that it's now time minutes and then there's five H for five hours and so on.

You can use fractions here, so you can use 1.5 Y 1.5 years, but be careful about that.

So, so first of all, fractions only make sense within the context they're in.

So the value of 2M two months and the 3d three days is, is kind of fixed.

It's mostly fixed, right.

But 2.5.

M the, the number of days in this now depend on which month you're adding to.

So, so half a month, like, what does that mean?

Is that is it February or is it July?

So be careful also because in the polyfill, the polyfill is implemented in JavaScript and I implemented this in the polyfill actually, and the JavaScript implementation has a lot of issues because it it's doing all this math and it cannot handle some factions carefully.

So if you're doing fractions, maybe don't use this serialization format, maybe use the object format that we're showing here.

So now all the boring stuff is done.

Let's charge money by the hour.

You have depending on the contract, you might want to charge per day or per hour or.

Whatever works for you.

The math is easy.

In fact, the math for doing this is so easy.

It's built into temporal.

It's actually, not easy, but it's something that we wanted to support for big bringing things.

So you have a big duration.

It might have a lot of units, right?

And, and for bringing things to just a single unit, use the total method.

So the total method, super simple, you can have a duration let'ssay here I, I worked a million seconds.

And so how many 24 hour days did I work?

Because I'm charging per day.

And, and if you do total with unit hours, you may see that I have worked 2277 point many sevens hours actually, oh, no.

24 hour days, but I did hours.

Okay.

Nevermind.

But yeah, these many hours of work, so I'm charging per hour.

Step five B it says relativity is important.

Now what does this mean?

Is that when you are adding two durations and you're finding all these things relativity is important.

If you add a one month, as I was saying to, to today's date the final result depends on which month it is today.

Right?

I remember this anecdote from, from a friend who was saying that.

Well, they earn the same amount of money every month, but then when they take a PTO the a,ount that is sort of no, not a PTO unpaid day off, right?

The, the amount that is sort of reduced from their salary, is a fraction of like how many days they're already in a month.

So a unpaid vacation in February would cost you much larger than in August, let's say, which sounds fun.

Probably not.

So anyway, in this case we have a duration, it has 200, 2,756 hours.

And if you find the total, relative to this thing, right?

Midnight at 1st of January, but with the time zone.

So here you have Europe slash Rome and you find the number of months here, then the number of months, which it's 3.79 something is more than if you do not take the timezone into account.

And why does this happen?

This happens because there is a DSD shift during this time.

So, so do keep that in mind when, when you're doing anything at the boundaries of months and DST shifts and all these things can impact what the result is going to be.

Now, once that's done, sometimes total is not what you can use.

So you might need rounding.

A final value can be the final value that you get can be rounded down or up depending on the contract.

Sometimes you don't charge by it.

So the problem with duration is that not everybody charges by like a single unit, right?

Yeah.

And I was telling you about charging per day.

But when, even if you do charge for a day, that doesn't mean 24 hour days, right.

Each day must be, say eight hours or seven hours.

And so you don't charge by hour or days, but by eight hours and so on.

And so for this round comes to the rescue.

So round is a sort of lower level function that can help you do some of these fun math things.

So for example, let's say you're visiting an immigration lawyer and they charge per five minutes.

If you visit them for six minutes, you can round that to the nearest five minutes and ceiling because they always charge extra.

Anyhoo.

That's that's our invoice app.

And I, I hope you found that interesting and engaging.

There is an assignment here.

So if you can scan this QR code you'll find an assignment in this link, and there's a bunch of examples there, which are written.

In using the date object, using moment, using Luxon.

So, and you can rewrite all of those using Temporal there's links to their Temporal API docs, and we are pushing Temporal to MDN and the polyfill is up.

So I'm going to talk about that in just a bit, but try that out.

Tweet to me I'm at @ryzokuken, as I said, the beginning And, and let us know what you think and hopefully all of those examples you can see when you write code using temporal, that is hopefully simpler to write and for about links to the future and to the present.

We have a link here to the polyfill.

I will, you can check my slides and just click through these links.

There is a link to the V8 tracking issue where you can track.

How long it's going to take for this to land in chromium in, in Chrome V8 also used in Edge for example.

And I recommend refreshing this page, like every five minutes.

There is a spider monkey tracking issue for Firefox.

There is JavaScriptCore which some of my colleagues are working on.

So I hope fingers crossed that that's Safari might be the first browser to get Temporal.

There is temporal V2, which is a repository that we set up for discussing ideas that weren't included in this version of the proposal, but might be interesting to explore in the future.

And I just have to give special thanks to a few people.

So we have the Temporal champions.

We have the moment JS maintainers.

Thank you so much for your support.

We have the organizers and program committee of the conference.

Thank you for inviting me.

It's so nice to be able to present at this conference.

There's Olga Kovets by the way, helped me.

Set up the playground thing I'm a grandfather when it comes to some of these things.

So thank you.

And thank you all.

If you had asked me a decade ago, what the role of the web would be in the event of a global pandemic, I would have instantly, and unequivocally said that that role would be profoundly important.

Indeed pivotal.

Allowing researchers to share information far more quickly than would have been possible before the web, allowing the general public to be informed more quickly and deeply about what's happening and how they could best minimize the risk of transmission.

Of course reality has shown that this position is laughably naive, but it's not just here where the kind of techno optimism indeed techno utopianism that has underpinned the rise of personal computing and the web the last 40 years has been wrong, and dangerously so.

We've seen state actors weaponize social media to devastating, personal and social effect.

COVID disinformation taking hold in significant minorities of many communities via social media with the attendant sickness and loss of life.

And so many products that aim to improve our lives are weaponized by abusers against their victims.

While individual contributors, particularly in engineering don't necessarily devise these features the nature of our industry and the kinds of products and features it delivers is everyone's responsibility.

Eva PenzyMoog is a designer and author of the recently published Design for Safety.

I recommend everyone working in technology regardless of their role or seniority read it.

Her work brings together expertise in domestic violence and technology, helping technologists understand how our creations facilitate interpersonal harm and how to prevent it through intentionally prioritizing the most vulnerable users.

These aren't necessarily easy conversations to have, but they are vital, if technology is to start delivering on the promise, we naive optimists once had and start undoing some of the harms it has visited on our societies and in particular, their most vulnerable members.

So to close code for 2021, please welcome Eva PenzyMoog.

Hi, I am so excited to be here at Web Directions Code.

The talk I'm about to do is safety, justice, compassion contributing to the ethical tech paradigm shift.

My name is Eva PenzyMoog.

I'm the founder of the Inclusive Safety Project.

I'm also a Principal Designer at 8th Light, which is a software consultancy and my pronouns are she and her.

So before getting into how we can contribute to the ethical tech paradigm shift.

I want everyone to just think for a second about what do we even mean when we say the term "ethical tech", what does that actually mean for us as technologists in a practical way?

What does it even mean to be ethical?

Because there are so many different things that are going on, right now.

So to understand how to contribute meaningfully to the ethical tech paradigm shift.

I want to first talk a little bit about paradigm shifts actually happen using a real life example.

And then I'll talk a little bit more about what it means to be ethical.

To talk about a real life example, I'm going to take us back to 1956 back to a time when cars looked a lot like this, they looked super cool.

There's one big thing missing that all cars have now, which is seat belts.

We all know that seat belts are really important, but the actual statistic is that they reduce serious injuries and car crashes by half.

So a really big deal.

But back when they were introduced in the 1950s, no one really wanted them.

And this was despite the fact that automobile injuries and deaths were at an all-time high.

And this was a really big problem.

Part of the reason that people didn't want them was because of the cost.

They were an add on feature that you had to pay extra for, and in today's equivalent, they were hundreds of extra dollars.

Also fun fact, this is what a child's seat looks like in the 1950s, or you had the option to, sort of ,tie your child down in the seat while in a standing position, or you could let them right up front with you on a little booster seat again, without a seatbelt.

There were basically no rules.

Auto safety has come a long way since 1956, when only 2% of customers were purchasing seatbelts for their cars.

And we don't actually know how many of those 2% were even actually using them regularly.

Let's skip ahead to 1965, along comes a young man by the name of Ralph Nader.

And some people in the audience might think this name is familiar, especially if you're in the U S and yes, this is the same Ralph Nader who has run for president of the United States multiple times through the Green Party.

I didn't know this, but he's actually a really amazing activist, and he basically set the groundwork in the United States for modern consumer protection.

He wrote this expose called Unsafe At Any Speed.

And it was all about how car manufacturers were prioritizing profits over the safety of their users.

This might sound familiar because tech is doing the exact same thing, right now.

The book covered, not just the absurdity of not including seatbelts in cars as a standard, but also things like how tire pressure was actually calibrated to prioritize comfort over safety.

He talked about how some cars had tires that could not even properly bear the weight of a fully loaded vehicle.

He talked about dashboards that had bright chrome displays that would reflect the sunlight directly into the driver's side.

There was also a lack of a standard shifting gear pattern.

So this meant that if you borrowed someone's car, or maybe you let someone else drive yours, and it was from a different manufacturer, you would shift into what you think is Reverse, but it had a different shifting pattern.

So you might actually be in Drive and you would shoot forward, instead of back.

Ralph Nader also wrote about the fact that car designers ignored existing crash science, which did exist back then, but they didn't really have to do anything with it.

He also wrote about the negative impact that cars were already starting to have on the environment.

If there's anyone here from Los Angeles, that's the city he focuses on because smog from pollution from cars was already a big problem in the 1960s.

Nadir also criticized automotive company leaders for refusing to prioritize safety over the fear of making cars more expensive and alienating users.

That was the term they used.

He also pointed out that the industry was running marketing campaigns to shift responsibility of safety from themselves as the automobile makers and onto the drivers, as well as the designers of roads.

Insisting that they bore no responsibility for the enormous amount of totally preventable car related harm and death happening, they were basically saying, "Hey, this is not our problem.

This is actually just a problem of user education and users need to understand things better and people just need to be better drivers.

And then this won't happen, but it's not our fault." Lastly, he had this call to action, which was at the federal government regulate the automotive industry and basically force them to do a better job at preventing all of this harm.

So this book became a bestseller in the United States.

And what followed was one of the most successful public health campaigns of all time in this country.

Nadar's Investigation contributed to the growing public outrage on this issue, and it led to Congress creating the National Highway Traffic Safety Administration, which is a part of government that we still have today.

That's responsible for things like reducing automobile, death, and injury; promoting the use of seatbelts, child seats and airbags; helping states reduce drunk driving; setting, and enforcing safety standards; investigating safety defects, in Automobiles.

So let's move on to 1968.

It is three years since Ralph Nader's expose came out and it's 12 years since seat belts first became available.

In this year, the National Highway Traffic Safety Administration created a law that all vehicles, except for buses needed to be fitted with seatbelts as a standard feature and not something that came at an extra cost.

This was a really huge victory.

And you might think that this is where the story ends, but it isn't.

People were still just against the idea of seatbelts because of the supposed inconvenience.

They thought that they would trap you in your car if you drove it into a lake and that they might do internal damage to your organs, when they prevented you from flying out of the car during a crash.

Some people even thought that it was safer to be launched at a high speed away from the vehicle during a crash than to have the seatbelt, keep you in your car.

This was despite the fact that scientists had done research, basically disproving all of these worries.

But even back then, a lot of people were choosing not to follow the science and medicine.

And it's important to note that car companies were required to have seat belts in the cars as a standard, but there was no law saying that people had to actually use them.

In fact, a lot of people responded to seat belts back then, the way that people are responding to masks today, at least some people, who claim that they're this incredibly awful thing, who's mild inconveniences far outweigh their life-saving benefits.

By 1983, not much had changed.

Just under 15% of Americans reported consistently buckling up.

New York state decided that they wanted to do something about this and in 1984, they passed the country's first law that required that everyone in the car wear seatbelts.

Auto fatalities decreased drastically in New York and the rest of the states decided that they were going to pass their own laws and did so throughout the 1980s and 1990s.

Almost every state that is.

There is still one state in the U S that does not require adults to wear seatbelts only children and that state is New Hampshire.

And it's really sad because a lot of people choose not to wear seat belts and they have a higher percentage of people there who died during traffic accidents.

But even with New Hampshire aside, every state drastically increased the percentage of people who were wearing seatbelts after the seatbelt laws passed.

With the result that by 2019 in the U S the national use rate for seatbelts was just over 90%.

This is at the point where I think we can say that the paradigm shift is complete.

From car manufacturers in 1956, charging extra for seatbelts and being allowed to self-regulate when it came to safety and only 2% of people using seatbelts; to now, when seat belts are a standard feature, the government forces the auto industry to comply with all sorts of safety standards, and the majority of people wear seatbelts without even thinking about it.

And just to recap, seatbelts were introduced in 1956, activism around them started in 1965, 1997 is when the last state passed the last seatbelt law and marks the end of the legal paradigm shift.

Although the cultural paradigm shift, I think continued for much longer, well kids who grew up in the eighties and nineties with seatbelts as the norm became today's young adults who wear seatbelt without even thinking about it.

All told though, that is three decades of activists, academics, regular people, and politicians working together to make this paradigm shift happen.

So what does this have to do with us and the tech industry?

I'm sure that you've already drawn a lot of conclusions and made a lot of connections between the auto industry before 1968 and the tech industry today.

But I want to address some specific parallels in our quest to understand more about the ethical tech paradigm shift so that we can then understand how to plug into it.

In both instances, we have massively powerful industries choosing to prioritize profits over the safety of their users.

With the automotive industry, eventually public outrage and activism led the government to create new regulations and force them to comply.

With tech we have company leaders prioritizing profits over the safety of their users also.

And there is a growing public outrage in a healthy amount of activism, but the government has yet to pass meaningful laws.

Second in both cases, there is an enormous amount of totally preventable harm going on.

And just as back then, as with now, company leaders are choosing not to take action.

Third, like I mentioned earlier, the auto industry put a lot of work into marketing campaigns to shift the responsibility of safety onto the user.

And I can't tell you how often this exact thing comes up in my own work, which is focused on designing for safety and against interpersonal harm, especially domestic violence.

People will say, well, it's the user's responsibility to understand how the product works and how someone might use it against them.

If you're going to use an app or a piece of tech, you should know what's going on.

If you don't want to use it, you shouldn't as if that's always a realistic option.

And if someone wants to use it against you, it's your responsibility to understand how that might happen and how to regain control.

It is a lot to put on people, especially those who may not have a high level of tech literacy.

This is a screenshot of a list of ways that people surviving domestic violence can stay safe online.

And it includes things like how to delete your browser history.

And checklists like this are all over the place.

There's a lot out there to help domestic violence survivors stay safe when it comes to their tech.

And I'm not saying that this is a bad thing, resources like this are absolutely essential for people in domestic violence contexts.

Especially when they're making a plan to leave and need to understand how their abusers might be digitally surveilling them.

And after they leave, when it's paramount that their abuser isn't able to track them down.

But my question is, why is this the only solution that we have?

Why do we put this responsibility on the victims to do this work?

Shouldn't we be tackling the problem at the source instead?

And that's what designing for safety is all about fixing the digital side of these problems at the digital source.

But going back to this idea of safety being the user's responsibility, I want to point out that this is a very specific tactic that is being used.

This is something that company leaders within tech are doing to intentionally shift blame and responsibility away from themselves, and onto the end user.

This is a tactic that powerful industries have always used in an attempt to not take responsibility for the harm that they're causing and to avoid regulation that will hurt their bottom line.

For both the pre 1968 auto industry, and today's tech industry have little to no government oversight and are failing miserably at self-regulation.

Tech basically gets to regulate itself now in most ways, and we all know how that is going.

Lastly, there's organized activism and growing discontent from the general public.

Public opinion is quickly shifting away from Big Tech.

People are becoming very negative towards it, which is a good thing.

And activists are working really hard to hold company leaders accountable and to educate other people about the awful things that are going on.

This combination led politicians to eventually take notice of the auto industry in 1960 and to regulate it.

And there are encouraging signs that the government is beginning to take action on certain aspects of the tech industry today, both in the U S and in other countries.

It's because of all this that I say that tech is in a pre seatbelt phase, the seatbelts are there and a lot of us as individuals and as teams are working really, really hard to make sure that our products are ethical.

Which I think means safe just and compassionate, and which I'm going to talk more about in a minute, but the reality is that a lot of products out there are still incredibly harmful.

We don't yet have laws mandating that we make the seatbelts of tech, a regular part of the process and the product, and those who lead the industry's companies are continuing to choose to prioritize profits over the tech equivalent of seatbelts that will keep the user safe.

So with all this in mind, let's take one more, look at the timeline of the paradigm shift of seatbelts.

This time with the additional framing of what's going on in the general public, which is what you see at the very bottom.

I'm going to give you a second to just look at this slide before I talk about it.

Okay, so I've broken this into three sections.

The first one on the left is when there is a lot of harm, there's some activism, but the greater public is overall pretty indifferent.

Second, the phase in the middle when activism increases and public outrage happens and public opinion begins to shift, which causes politicians to take notice and to draft new laws.

And then the final stage on the right is when the combination of activism, laws, and cultures surrounding the topic coalesce into actual behavior change.

The key insight from this, is that paradigm shifts are totally possible and they do happen, but they require a sustained effort over a long period of time.

The other insight is that it's very important to focus on specific goals.

So Ralph Nader was not the only person who was working hard as an activist around auto safety back in the 1960s, there were a lot of different people doing important work on this, but his book is a really useful example of the very specific demands that activists had for auto safety.

It wasn't just saying cars need to be safer, but there were a whole bunch of specific issues as well as specific solutions.

So going back to this question of what do we mean when we say "ethical tech" is the next thing that I want to talk about now that we understand paradigm shifts a little bit, let's spend some time understanding what we're even talking about when we say "ethical tech".

Usually we mean something to do with tech products, but it can also have to do with the tech industry itself, which is why I think that there are these sort of two main areas of focus.

Within each of these areas of focus, there are three different issues, safety, justice, and compassion.

I think that usually when we talk about "ethical tech", we're talking about one of these three things.

And because like I said, it's very important that we are specific with our goals.

Instead of just saying that, you know, tech needs to be more ethical.

I want to spend a few minutes breaking these down and talking about what actually constitutes each of these six areas.

I'm going to go through every single ethical tech issue that I've been able to identify.

And if you have ones that I don't mention, definitely contact me to let me know, because I'm sure that there's things that I've not covered in these lists.

So the first is the safety of tech products.

This includes things like using tech for stalking, technology facilitated domestic violence, which is where I spend my focus on.

Image abuse, which is sometimes called revenge porn, although that's not quite the best term because revenge isn't always part of it, and porn implies some level of consent.

Invasive surveillance, which usually involves surveilling domestic partners, children, elders, and workers.

Cyber-bullying through text and social media and other digital platforms, as well as anonymous harassment.

Like just what we see on Twitter and other social media, as well as threatening and doxing people's identities and personal information.

Next is justice.

Issues of justice within tech products include text that harms the planet, like Bitcoin mining to name one, data harms that include things like what sort of data gets collected and about who.

So for example, in Chicago, where I live, there's this really harmful thing called a Gang Database and there's zero transparency about it.

It includes a lot of people who are actually in no way affiliated with gangs, but they have no recourse to get themselves off of this list.

Then there are racist, sexist, and otherwise oppressive algorithms such as predictive policing, that weights a black man is more likely to commit a crime than a white man with the same history.

Exploitative design practices, such as bringing end-users in to create solutions to problems, and then packaging up those solutions to sell them back to them without that group or community receiving any power or any funds that came from the project, they're simply exploited for their knowledge.

And this is especially harmful when it's some type of vulnerable community.

There are "social good" projects that do more harm than good, which we see a lot in terms of designers or different groups with good intentions going into a poor community or a poor country, and attempting to understand a problem and design a solution for it.

And then leaving before the project outcomes are fully understood.

And a lot of times this isn't actually helpful and can be harmful.

And then finally there's harmful disruption, such as Airbnb, which has contributed to many cities becoming unlivably expensive for the people who actually live there.

And then lastly, in this area, there's compassion and tech products.

So the first is cruelty in advertising and promotion, such as showing a woman who has just had a miscarriage ads for diapers.

Hurtful copy, an example of this is Twitter's original messaging, when a user was over the character limit, it said something like try to think of something more clever and make it shorter.

And this might be funny if you were in the right mood, but if not, it would just be hurtful.

Failing to design for stress cases.

So for example, Eric Meyer and Sarah Watcher-Boettcher's book Designed for Real Life, talks about this and defines a stress case.

A good example that they give is Home Depot.

They might be thinking about users who are there because they're excited to be doing a home renovation, but actually some users are going through things like my refrigerator is broken, I'm about to lose a ton of food and I need to be able to find an affordable refridgerator ASAP.

Then there's retraumatizing users by doing things like showing unwanted content, such as related articles at the bottom of an article, you're reading, showing something really graphic, something that might, re-trigger a past trauma.

Next is disallowing control over what is seen.

So an example of this also comes from Design for Real Life, where Eric Meyer talks about how he tragically lost his young daughter.

And then Facebook continued to show reminders that it was her birthday long after she had died, and there was no way that he was able to stop it.

And then lastly, they're secretly experimenting with users' emotions, which is another issue that comes from Facebook.

Some people might remember in 2014, they came under fire for this because they did experiments where they, without letting the user know that this was happening, they would take all of the happy things out of that person's feed and then study what they posted to see if it got sadder, which it definitely did.

So then we get into the Tech Industry.

The first issue here is tech safety.

This includes things like workplace harassment, assault and abuse.

Next is HR teams who protect the company over the people, especially victims of the things in that first issue.

And then there's unsafe working conditions such as what we see at Amazon, in their warehouses where there's been regular documentation of all sorts of really horrible safety issues from things like overheated spaces that don't have air conditioning, to the story of the woman who was denied lighter duties while pregnant, and still had to carry heavy things and had a really tragic late term miscarriage.

Then there are issues of justice in the tech industry.

These include issues with inequitable hiring retention and promotion in which certain powerful groups get an easier time being hired, retained, and promoted.

Toxic and exploitative work cultures.

Unjust worker compensation, which again, we can look at Amazon for an example of where we see that some employees get a much higher share in the enormous amount of profits than others, poor or no healthcare failing employees with accessibility needs, which we're really seeing right now as a lot of companies, at least in the U S, are forcing their employees back to work, even though COVID is still raging, after they've shown for awhile now that they totally can accommodate people's need to work form home.

And then there's education that is reproducing existing oppressions in the industry.

So for example, things like science departments in universities, where male professors are allowed to continually harass female students without repercussion, which is pushing women out of the STEM industries before they can even enter them.

And then there's the issue of compassion within the tech industry.

There are probably more things that could be on this list, but the issues that I've identified include a lack of agency and worker burnout, which we're seeing in really huge numbers right now.

And also just simply failing to see human beings before seeing employees.

So here's a list of all of those topics that I just went through.

I'm betting that a lot of people at the conference are already very interested in one of these, are learning a lot about them or are possibly even already contributing to meaningful work.

So just take a few seconds to think about the topic that you're interested in or that you're already working on and think about where does it fall into the sort of general timeline of a paradigm shift?

Is it still in the research phase where we're just learning about it and identifying that it's a real problem.

Is it more in the education phase where we're trying to get the word out and let people know that this is happening or are there laws starting to be passed, but now we need more laws that are going to clarify it, or our behavior is starting to actually change.

So I think at this point it might help to look at a specific example from that list of problems and see where it's at within the paradigm of shifting tech to be ethical.

So let's look at the issue of racist algorithm.

So this traces its roots back to 1986, when a doctor at a medical school called St.

George's, which is in the UK, creating an algorithm to help with admissions.

And his goal was actually to make the admissions process fair and to weed out human bias.

So he wrote this algorithm.

A few years later, a bunch of staff members were very concerned about how little diversity there was in successful applicants, and there was an inquiry into the algorithm.

They found all sorts of issues.

The process of giving and taking away points to a candidate, weighed things like the applicant's name.

And if they had a non-European name, they were docked 15 points.

The algorithm also designated either Caucasian or non-Caucasian based on the applicant's name and their place of birth.

So the school was found guilty of discrimination, but they didn't really face any actual consequences.

And it wasn't until 2016, a whole 30 years later, that activism around the issue had a sort of break through moment that starts to reach the general public, which was ProPublica's piece demonstrating that criminal prediction algorithms were racist and that they had a bias against black people.

There had been articles and warnings about this for decades, as well as some meaningful studies in the early 2000s.

But it's around this time that I think the average sort of person who doesn't work in tech started to get exposed to the problem of bias algorithms.

It was two years later that Joy Buloamwini and Timnit Gebru published their paper, demonstrating that Amazon's facial recognition has a far higher error rate for dark skinned women than for light-skinned women.

And this is where we're at now in 2021.

In the US something called The Algorithmic Justice and Online Platform Transparency Act has been introduced into Congress.

It hasn't yet passed, it's in a committee, but it is exciting because this is a pretty legit law and activists are overall, really happy with it.

So next up in the timeline of what has to come next, or hopefully will come next is the first laws being passed, additional laws being passed that help sort of clarify those laws and bring about better change.

And then behavior is actually changing.

But once again, I want people to take note that this is about 30 years since the issue was first identified to the present day, when there's some real momentum going on.

And I also want to point out that at this point where there's some momentum starting to really happen, this is when opposition starts to really ratchet up.

So first off Timnit Gebru was actually fired from Google, as many people probably already know, for raising awareness about this issue in a way that Google didn't like.

There's also a lot of pushback from Big Tech companies.

So we've seen there is an there's an industry group, right now that includes companies Amazon, Facebook, Google, and Twitter, that is trying to make sure that this law doesn't pass.

They're saying that making their algorithms more transparent will provide a roadmap to hackers, Russian trolls and conspiracy theorists.

They say that actually what we should be doing to combat these problems that the algorithms are perpetuating is to expand our civil rights and discrimination laws in housing, employment, and credit.

Yes, we should absolutely do all those things, but this is a pretty transparent attempt to deflect attention away from the ways that their own companies are contributing to these problems.

And I think that we can definitely expect more pushback from company leaders who don't want to change their very lucrative way of working even a little bit, even if it means that their products will cause less harm.

A lot of people want to start their own thing, and I'm not saying that you shouldn't, but it's important not to center yourself as you work to help others.

You shouldn't start your own thing, just to start your own thing.

And if there's already a solid organization to get behind, you should join them.

Also always follow the lead of the people who are actually being impacted by the problem.

So if you want to work on the issue of bias algorithms, follow the lead of the black women who are already doing that work, especially because they're the ones who are the most impacted and they're the ones whose voices need to be centered.

I talk about this in my book, but there is a limit to empathy.

It's very important that we empathize, but it can't be a stand in for lived experiences, always follow the lead of the people who have the lived experience of being impacted by the problem that you're trying to help solve.

And then think about where your issue falls on the timeline of the paradigm shift and use that to help inform the actions that you should take.

Maybe your issue is still in the education phase, where the public needs to be made aware of it.

And there just needs to be more content out there.

Or maybe it's even earlier than that and there need to be more studies that are actually proving that this is a problem and exploring its actual impact.

It's important to remember that laws are never ahead of the curve.

They're usually the cap on many years of activism.

So it's important to recognize that like, yes, ideally laws would just kind of come in and take care of this problem at the beginning.

And we should be agitating for lawmakers to be more proactive, but it's important to know that until public sentiment begins to really turn against a certain issue, the likelihood of politicians acting on it is very low.

And then I have a few pieces of advice.

The first is to be hopeful, but be a realistic.

We know that change is possible, but we also know that it can take years and sometimes decades.

I don't think that a lot of these things are going to take 30 years like it did with seatbelts because we're able to get information out a lot quicker now and educate people more quickly, but it is very real that it's going to take years and that change doesn't happen overnight.

So with that in mind, find your team, find an organization or a group to work on the issue with, or find others at your workplace who want to enact some type of change at your company.

Find a slack group, whatever it is, just find your people.

Nothing great happens alone.

And without a team for solidarity and support, when the going gets tough, it's going to be much harder to stay focused and continue on the work.

And then lastly, set a sustainable pace.

Take breaks.

This work will take years and we need to all be in it for the long haul.

That means be being realistic about how much you can do.

Maybe you can rally your team at work to implement some big changes at your company.

Maybe you can volunteer a few hours a week with an organization, or maybe you truly don't have time for any of these things, but you can donate $10 a month to an organization of your choice that is doing important work.

And remember the Mark Zuckerberg and the Jeff Bezos's of the world.

They are counting on us to not do this.

They're counting on us to get overwhelmed and to give up.

They're counting on us to not have the staying power that they're highly paid attorneys and lobbyists do.

So don't let them win.

And then the last thing is to resist empty rhetoric around "ethical tech".

So if people are using this term be specific and push them to define like what they're actually talking about, support initiatives that are taking specific action on issues and have specific goals and push your company to do the same.

The issue was seeing "ethical tech" in this very general way is that there's no accountability because there's no clearly defined problem and no clearly defined goals.

So help people around you understand this, help your leadership, understand this, and if you see companies or people that are kind of doing this in a way that is blatantly just some empty marketing tactic, call them out.

So I want to close with this quote from Arthur Ashe, who was a groundbreaking tennis star and social activist.

He said, start where you are, use what you have, do what you can.

Maybe your thing right now is just changing one aspect about how your team works.

Like I said, maybe you can organize with your coworkers.

Maybe you can plug into a group.

Maybe you can donate some money, but whatever it is that you can do, it is going to help.

Remember that it's a tactic of people opposed to meaningful change to make us feel overwhelmed.

And like the problem is just too big for us to solve, but history has shown us that that is absolutely not true.

We totally can change tech for the better and contribute towards the paradigm shift to making it more ethical.

Thank you so much for listening to my talk.

Here is my contact information.

If you want to get in touch, eva@8thlight.com I'm on Twitter @epenzemoog and you can learn more about my work at inclusivesafety.com.

And of course, my book is Designed for Safety and it focuses specifically on issues of interpersonal harm and technology facilitated domestic violence.

Thank you so much.

Thanks once more to Eva and Ujjwal, and to all our speakers for the conference-Hermanth HM, Brian Kardell, Thomas Steiner, Ben Taylor, Ningxin Hu, Ada Rose Cannon, Alex Russell, Léonie Watson, Diego Gonzales, Penny McLachlan, Ujjwal Sharma, and Eva PenzyMoog.

And that wraps up this year's Code.

But before we go, I do want to thank a few folks.

A huge, thanks to our partners Platform.Sh really, if you are looking for amazing developer focused hosting, that takes care of so much more than just hosting, go and talk to them.

Thanks to Twilio, longtime supporters who take care of all your communications needs from SMS to email as well as video and more.

To REA, if you've not taken their challenge, there's still time.

And it really is a lot of fun.

And as I mentioned, they have a bunch of remote front end roles open.

So do take a look at their site.

Our great friends, Lookahead.

Whether you're hiring for technical roles or looking to develop your career, I do recommend you speak to them.

I'd also really like to thank Matheus Sequeira for turning the raw video of the presentations into something much more.

And to Genni Hennessy for her amazing content editing.

Make sure you keep an eye out on your emails too, for when the next round of trivia questions drop for this week.

And just before we go, we still have quite a bit coming for 2021 and beyond with two more front end focused conferences coming in the next few months.

Access All Areas is hosted and curated by the wonderful Sara Soueidan and focuses on accessibility for front end engineers.

You'll hear about technologies and techniques for ensuring your websites and apps are as accessible as possible.

AAA takes place October 29 and November 5.

And then to close the year, we have Safe, a new conference focused on privacy, security, and identity.

Again for front end developers.

This takes place December 3 and 10.

For attendees of Code or indeed at any of our events this year, there are half price tickets.

So please keep an eye out for your post-conference email, with details about how to take advantage of that.

And one last thank you.

Thanks to you for turning up here.

We do know that right now, setting aside the time to attend and spending even more time, staring at a screen is a really big task and we deeply appreciate you've taken the time to do that.

Take care and hope to see you again before too long.

And once again, a huge thanks to you.