BERNIE LONGBOY: Good afternoon from Cambridge, Massachusetts. I'm Bernie Longboy, CS50 staff member and your moderator for today. Welcome, Harvard and Yale students, and welcome and hello to our CS50 students and friends from around the world. Today, we have the first of our tech seminars from our friends at Microsoft on foldable dual-screen form factors. 

I'd like to welcome Craig Dunn, software engineer on the Surface Dual team, and Justin Willis, software engineer, Microsoft Edge team. Thank you, gentlemen. And just one quick housekeeping note-- I will be moderating and taking questions in the chat room. All right, thank you. 

CRAIG DUNN: Great. Thanks, Bernie. Hi, everyone. 

As you said, my name is Craig Dunn. I'm on the Surface Duo developer experience team here at Microsoft, and we like to go out and talk to developers all around the world and get them excited about foldable devices and form factors and thinking about how you can get your apps into that form factor and deployed onto all of the different types of devices that are available around the world. And I'm joined by Justin. 

JUSTIN WILLIS: Hello, I'm Justin Willis. So I'm a software engineer here at Microsoft working on PWAs, and yeah, that's about it. 

CRAIG DUNN: Great. Thanks, Justin. Well, let me share my screen and start our presentation for the day. 

So the reason why I'm here today in part is to tell you about the Microsoft Surface Duo 2. So here it is on the screen, and also, here is my foldable bendy device in real life. Surface Duo 2 is an Android device that Microsoft makes and sells, and it's one of the new category of foldable devices that lets you fit something in your pocket that also opens up to provide a tablet experience for times where you want the additional screen real estate for productivity or multitasking or social media or whatever. 

But I'm not here today to sell you a Surface Duo. I want to tell you about how you can work on your final project apps and take advantage of foldable devices, like the Surface Duo and foldable devices from other manufacturers, to create an interesting user experience for whatever your final project might be, building on the skills that you've learned throughout CS50. 

So an overall agenda-- foldable agenda, if you will-- is I want to tell a little bit of a story about responsive design because it's the principles of responsive design that we're going to grow from how you would currently support different screen sizes and different devices and bring that over to foldables, whether you're using CSS and HTML or JavaScript. I'm going to tell you about how you can do this just in the browser on your computer that you already have, whether it's Mac or Windows or Linux. 

Justin's going to tell us about how you can actually take web apps and the web skills that you've been learning and actually build an app that you can put on iOS, that you can put on Android. You can actually make an app that goes in the App Store. It can be free. You could charge $0.99 for it. But it's a way to leverage the skills that you've learned this semester and get reach not only from people on their browsers, but people on their phones as well. 

And I'll finish up with a pile of links that you can take away and work on later, guidance for how to design apps for foldable devices, docs that Microsoft provides on how to do this all with web technology, and I'll also mention just briefly the fact that, if you're not down with HTML and CSS and JavaScript-- like you're into Kotlin, or you're into one of the other languages-- we also have support for you to pick up on those languages and take advantage of foldable devices with them as well. So let me get started. 

This is the complete set of tooling, like I just mentioned, that we've got covered. So no matter what language is your favorite, we can help you get your app onto foldable devices. But highlighted there, the web chunk-- that's really what I'm going to focus on today. 

You can see the URL at the bottom of the screen, but don't feel like you need to grab that and type it in now, because there'll be heaps of opportunities and links I'll share throughout the presentation and summary at the end. So let me start on my story about responsive design. 

Many folks, when they start building an app-- it makes sense that you're building and testing and optimizing for the computer that's right in front of you, and for many of us that's a laptop much like this. And back when the web first started in the '90s, that was the common form factor, and it was only 1,024 pixels wide. And a lot of websites looked exactly the same, and people didn't really think too much about a bigger or smaller screen. 

Of course, that changed. Particularly in the early 2000s, bigger screens, multiple screens came out, as well as smaller screens, so phone devices. And initially, folks were like, oh, shoot, I need to build three versions of my website. So there's this huge one that acts like a poster, the one that works on the laptop, and then this mini version that works on a phone, and a lot of effort went into projecting and writing HTML and all of this stuff two or three different times to make this work. 

Of course, while people are doing that, the web was growing rapidly, and the number of devices was increasing. Nowadays, you can look at the web on your TV. You can look it through your game console. And while I haven't seen the web projected in a lot of cars, except for maybe the Tesla, there's a lot of apps that even appear on car dashboards. So there's a lot of different screen sizes that you want to start thinking about to design your app, but all of those screen sizes also present opportunities for cool app ideas. 

So when you're thinking about your final project, maybe you can come up with an app idea that's focused on one of those screens. Maybe something that works just for dashboards, something that works really well for mobile phones, something that works great in the TV and the entertainment system in people's houses. So all of these screens presented a great opportunity, but when you were building your website for each screen, it became a lot of work. 

So here's a video. I hope it comes out OK, but I'll do a demo in a bit that shows you how one of our sites, so the documentation site, is responsive to different sizes. So the animation is a bit janky, but as the window gets narrower and then wider again, parts of the interface disappear. They get hidden behind a button, or they just disappear completely. And they should still be accessible when the window is narrow, which is effectively what it will look like as well when it's on a mobile device. 

But as it gets bigger, you'll see that elements reappear and take up the additional space. So the content, which is the raison d'etre of this slide, is a middle column that's always there, but all the extras around the edge can start to be hidden or made smaller or disappear completely to adapt to that change. So this is, at a high level, what I mean by responsive design. The design is responding to changes in the device or in the window that it's being presented in. 

But what about this new class of devices? So here's a device that is a different shape to any of the others that we've had before because it folds in the middle. So it can be a small screen. It can be a big screen in both directions. 

But also, it has this fold in the middle that can interfere a little bit with what you can see. So how would we respond to these changes in this type of device? And in particular, how would we deal with the hinge and the fact that it's folding, and we have this new thing that hasn't existed before? 

We're going to talk about media queries because that is the way that we chose for web developers to represent this and make it available to you in your HTML and CSS, in the web apps that you're building. So I know you all have done CSS as part of the course. Cascading Style Sheets are a nice way to separate your presentation logic-- fonts and colors and all sorts of things-- from your HTML and your code. So CSS is a really nice way of building that stuff and making it easy to change and easy to test. 

Media queries are something-- and apologies for those of you that are already way ahead of me. I'm just going to quickly cover the background of media queries-- are a way that you can create or apply style sheets, so apply the colors and fonts and whatever, but only for a specific type of presentation. So the media, I think came from originally, is it screen media, or is it print-- IE, paper? Back when people printed stuff, they wanted to have it look different to what it looked like on the screen. 

So some examples are, you might have made a really pretty looking web page with colors and all sorts of stuff, but you didn't want to use up your blue ink when you printed it out. So the print media query lets you take care of that by removing that color only when you're print previewing or printing. And that concept of, we're changing what we're presenting to-- is it the screen, or is it a Print Preview-- to also be able to detect many other attributes of the display device. 

So that includes things like the width of the device, and that's one of the key parameters that we can use to create responsive views because we can have different things happen at different widths. And so the janky video you just saw was multiple different chunks of CSS being applied at each width so that you can make cool things happen. You can hide and show stuff when it's on a narrow phone or whether it's on a super large TV. 

So media queries are these optional chunks of styles that you can apply, and you can give them labels, and then they only apply in those certain circumstances. So there's two examples of the syntax here at the top. That's what you would put inside of a CSS file. In whatever CSS file you already have, you can create a media query chunk, which is just going to apply to print view, and a media chunk which is just going to apply to 600 or less views. 

And down at the bottom, I've shown kind of a throwback. You can also make a whole CSS file only apply via this media equals print. And I'm not going to really focus on that because the top way is more flexible, but I'm just throwing it in there for people to be familiar with. You can bring in a whole file or not based on that media parameter. 

So here's an example of a really simple print media query that I might have written for the HTML tag. It's just setting the background to white, so whatever styling I'd done elsewhere in my CSS, when I want to print it, just white. Don't waste my ink. 

And similarly, I've got a nav div or something, and I don't want to print that out because it just wastes space. So I'm setting the display for none. So this really simple print media query chunk of styles is going to make my output nicer for folks that want to print it. 

So here's that same website I just showed, just a regular screenshot. I'm using it in Edge on my laptop, and I've just blued out all of those elements-- the nav, the top nav, the article, and the "is this page helpful" stuff. All of those elements are inside of styles or inside of divs that we can just wipe away in the print media query. 

So on the right, you can see, when I do Print Preview, all I get is the content. So it's a neat way to provide functionality. If you know your final project is something that is a storefront, is helping people order food, and you want to do an invoice or a receipt or something, you just have that same view that you're showing them and hide the extra bits, and you've created a nice Print Preview that folks can use. 

So let's look at the next level of complexity-- media queries that are based on screen width. So Print Preview-- print media queries are an on and off kind of thing. You're either printing or you're not. 

But the media queries related to the width of the viewport are dynamic because as the screen is changing, or as the device is folding and unfolding, the width that is being used is going to change. So the browser is going to dynamically redraw and show and hide elements all based on the different styles that you put in those media queries. So a few examples I've thrown in here-- a max width of 600, you would put styles that are only for mobile. 

A min width of 768 would be styles that are going to be applied for a really wide-- laptops or desktops or whiteboards. And also, the third example is, well, if you don't really want to specify screen, that's kind of optional. You can just focus on, this is the width that this media query is going to use. So I'm just throwing out syntax there that builds on top of your existing CSS knowledge and, optionally, applies these classes only when the display meets the criteria that we have. 

So here's two views of that animation I just showed. I just made the browser really narrow, and that's effectively what a mobile user will see. Made the browser really wide, and that's effectively what you'll see on a desktop or a larger computer. And you'll see there's a lot more white space and elements on the right than on the left, and it's all controlled by media queries and managing and detecting the device size. 

But neither of those works exactly for foldable devices because we have this new thing. We have the hinge, and we don't have a way to express or to describe that. So basically, companies working on foldable devices group together and go to the W3C, which is the World Wide Web Consortium. I guarantee no one on the call has probably ever said the words "World Wide Web" together. We just don't say that anymore, but that's what it is. 

And we work through proposals of how this could work across companies that implement browsers, and this process has been going on for over a year as these foldable devices have started to be on sale. And we currently have availability of these APIs in Microsoft Edge and in Google Chrome, and there's other browsers obviously, like Firefox and Safari and whomever. These are standards that are in the open web that they will be able to adopt as well if they see fit. But you all, using Edge and Chrome, will be able to work with these standards. 

So what do these new standards look like? I'm going to quickly show some of the original proposal because, spoiler alert, we changed the proposal halfway through, but it's cool to see where it came from. We created this new media query that would only apply on foldable devices when there was a fault. 

So when your website is on this phone, on both screens, you can make these styles apply. So you could change the font color, or you could change the background color. But more importantly, you can change the layout to move stuff to either side of the hinge or do some other neat transformations for when you're on a foldable device. And you'll know if it's horizontal or vertical. So really simple addition to the API that lets people take advantage of foldable devices. 

We also added environment variables, and this is part of CSS that lets you get specific values for the device. So common ones would be just the width and height of the screen, things that you want to get. But we provided the way to find out the coordinates of the hinge so that you can do specific layouts that care about where the hinge is and where it sits in relation to your content. So we created these fold left, top, width, height, and you can combine those with the media queries to create interesting layouts. 

And we didn't forget JavaScript. We added just one new method, which will return when you're in JavaScript, the shape of the screen. So if there's two rectangles with a hinge in the middle, it'll give you those two rectangles, give you the coordinates. So you can easily extend any JavaScript layout you're doing by using this function. 

So here's a quick example. You can see the colorful boxes in the left. That's a screenshot of a dual screen web browser, and you can see the yellow box sits across the screen and goes up against the edge and against the hinge. 

And you can see the CSS that I've snipped out, the width and the left properties both use those environment values and the calc method to say, the width is going to be 1/100 of the view, which is that 100 VW, minus the fold and the position of the fold. And you get a nice position. So each of these boxes is positioned using those two things we just talked about. 

So great, you think we're probably done. What about three folds or three screens? So the Surface Duo and the other devices that are on the market at the moment generally look like this. They generally have one fold. 

But as we work through this with W3C and the standards bodies, people started to say, well, what about when there's more fold what about three? What about four? What you've written, the standard that we originally proposed, is very limited to a single fold being described. 

So we went back to the drawing board and created this new standard. It's also a media query, but it is extensible. So you specify the number of views that you expect, and it can be two. It can be three. 

It can be as many as complex devices can be made. So now, we can describe the case of a triple screen device or a quadruple screen device. But for now, we're really just focused on Surface Duo and the other foldables that are going to use number two. 

So we updated the media query. We updated the environment variables. So the environment variables, now, rather than being a single value, are also index with an x and y-coordinate so that you can tell it which screen you're looking at. And I've just listed out the ones that we care about here, 00-10, 00-01, and you can now query for any of the values on the screen, like the points and the coordinates that you might need to do a nice layout using these values. And even though we don't care about it right now, that can be extended for many, many screens-- devices in the future. 

And we didn't change the JavaScript much because it already returned a collection of rectangles. But we did change the name of it in response to developer feedback as well. So we quickly just looked at our first guess of what a good API would look like, and then just now, the results of a year of being in beta and receiving customer feedback and developer feedback and settling on these APIs, which are ultimately going to be stable and available in Edge and Chrome and whatever other browsers choose to support it. 

BERNIE LONGBOY: Craig, can I go ahead and read a couple of questions? 

CRAIG DUNN: Yeah, please. 

BERNIE LONGBOY: So the first one is, if I have an old phone, like an iPhone 4 and the like, could the programmer optimize it? 

CRAIG DUNN: Yeah, for sure. So one of the beauties of the media queries and the way they work is you can specify the width values that you care about to a very fine degree. So the original iPhone 4-- I can't remember off the top of my head how many pixels wide that screen is. But you could absolutely create a view, a set of styles, that would apply for that old and narrower phone, which is maybe-- oh, gosh, I can't even remember. 

But it's relatively narrow compared to modern phones like the Surface Duo, but also the big Samsung flagship models and even the iPhone 13 Pro. Those are big phones now. So you can absolutely use media queries to target the smaller one and make a really nice layout that works for those phones and then allow the works for the slightly bigger phones, and then obviously, the layout that works for desktop and so on. But you can choose-- they're very flexible in terms of how many media queries you write and how you adapt your layout according to the device. 

BERNIE LONGBOY: And that question was from-- and I'm sorry. I'm going to do my best to pronounce names-- [INAUDIBLE]. This next question is from [INAUDIBLE]. Again, please, I apologize already for my mispronunciation. Does a programming for folding devices work for the normal devices? Thank you. 

CRAIG DUNN: Yeah, so that really comes back to the way that media queries work, is that they only apply when the device supports them. And when the device doesn't support them, they just get ignored. So you can add these media queries to your web page and on a desktop, on that iPhone. 

Pretty much anywhere else, they're just going to get ignored. They just get skipped over. So basically, you create a default layout, which is what most of your customers will see, and then you add the media queries that you want to address, whether it's for foldable devices, or whether it's super narrow or super wide screens. And you tweak the styles. 

You make changes to your default that adapt to that particular device or that particular change that you want to make. So yeah, you can absolutely add these media queries, and Safari, for example, I don't think it supports them right now because Apple doesn't have a foldable device. But it's not going to screw it up at all. 

There'll be other media queries that it's skipping over as well, like the print media query. The iPhone doesn't care about that either unless you're doing a PDF generation. So it falls back to that underlying way that CSS works, but it's very low risk. You can add this stuff in. 

BERNIE LONGBOY: And this is just a comment from Ahmed Hafez. It's possible, but no one would care for old stuff, so just companies or programmers stop supporting that version of phones or software and concentrate more on the new versions. 

CRAIG DUNN: Yeah, people do tend to do that, but again, the benefit of this media stuff and the way it can fall back gracefully means that it probably is still going to work on that older phone. If you thought about the width layout stuff, it'll still work, and when you add this new bits, it'll work on the new phones, but it's not going to hurt your old stuff. So the W3C generally puts so much thought into the way that web standards evolve to make sure that they're generally backwards compatible. 

For us, it was a real pain because we've had a year long process of working through this standard building, but the result is something that's both future proof in terms of it works for multiple screens, but also backwards compatible in that it doesn't break anyone else when you add it. 

JUSTIN WILLIS: I would also like to add that it's-- so one of the biggest things about the web-- and I'll argue that I don't think there's another app platform out there that lets you do this. But yeah, not only can you support all different kinds of devices, including foldable devices and stuff, with just some CSS, but it also totally spans an iPhone 4, for example. You don't need any specific power of device, or it has to be a modern device. 

The coolest thing is the HTML and, just like Craig said, web standards, even the CSS and JavaScript stuff-- it's all very, very crucial to make sure that it keeps working on any device. Basically, you just need a device that has a web browser, and if you have a web browser, that web app or that PWA or even just that website will run. Which again, I don't-- with native apps, sure, they can run on older devices, but I will say that I think the web has the best-- you can really even customize your experience for older devices to make-- let's say it's an older screen, like an iPhone 4. 

You can do media queries all the way down to a tiny little-- there's a phone called the GIO phone that is basically just a flip phone, like we may have all had in middle school or high school, that has just a tiny little screen at the top. And you can even go all the way down to that size in media queries. So yeah, it's really cool that it's so extensible. 

CRAIG DUNN: So I'm just going to switch over and talk about how-- we're talking about foldable devices like this, and other ones, and how you can build and adapt your web apps for them. But maybe, you're not going to go and buy Surface Duo right away in order to do this. And the good news is that is no problem because the support is built right into Edge and Chrome. 

So when you're in Microsoft Edge or when you're in Google Chrome, this might be a trick that you know, it might not be, but there's really sophisticated developer tools. So you can hit F12, you can hit Control-Shift-I, or you can find the menu and go down to Developer Tools, and this is going to unlock a ton of stuff that's going to be super helpful for working with CSS, working with media queries, and working with foldable devices. 

So just quickly, when you're in developer tools, there is a button here that's going to be a little hard for you all to see. It's in the top, and it lets you toggle device emulation. So when you turn that on, you get this new nav along the top here. And also, when you're in the default responsive mode, see how I can just drag the viewport, and it's changing because I've done some of this media queries that I said. So I can simulate really easily what happens when a view changes. 

But that is not all because, in this list, there's actually a Surface Duo entry, and like I said, this is available in Chrome. It's available in Edge. And when you enable that choice, you get a new toggle dual screen mode, and now, we have a simulator for the Surface Duo device right in Edge. So all of the media queries and stuff that we just talked about, you can build and test on a desktop with the browser that you're already using. 

You don't need to go and buy a foldable device like the Surface Duo just to get started. They're fun to have, but you can do everything right in the browser. So you can see that I can spin it around and see the vertical view. And I can click this dual screen button, which is mimicking what would happen if it was like this, or I was folding and unfolding it. Yeah, it's looking pretty good. 

So the page that we're on is a URL that I'm going to share later. It's aka.ms/cs50demo, and it actually has a collection of web samples that we're going to look at right now. But the first one I wanted to show you is just this page. So you'll notice that, when it's not folded, the content is all one on top of the other, and when it is folded, the dual screen stuff flicks over to the right. That's cool because we can actually see how that happens using developer tools. 

So developer tools also have this Inspect Element, which you might have used before, and when I click on that and then click on this region, I can see now, over on the right of that screen, these are the CSS elements that are being applied. So in real time, I can see what the browser is processing. So it's processing the fact that we have a screen spanning media query, and it's processing that the left calc is using the environment variables we had. 

And I can turn it off and see what happens. Oh, it's screwing up my layout. Well, that's obvious. 

But I can interactively test and play with how this layout works on a dual screen device, and if I unfold it, it will change, and it'll show that foldable class is no longer being applied. That media query isn't being applied in this case. So you can really jump into and debug and understand how these styles are being applied right in the browser using the built-in developer tools, which is really flexible. 

So let me just jump in to the box's demo, which you saw a screenshot of before. And yeah, we can do the same thing using the Inspect Element. I can click on that blue box, and then over here on the right, again, it's showing us that the media query is being applied, the single fold vertical. The left position is being calculated with the environment variable, and yeah, if I turn it off, I can see that the box jumps around because when I've turned it off, the style isn't being applied. And when I turn it on, the style is being applied. 

Now, all of the styles in this example are only being applied when the page is on a dual screen, so when I toggle off, the boxes just sit. So to the question earlier about whether it would be able to work on iPhones or other devices, this is an example where the dual screen styles just get ignored when you're not on a dual screen device. 

And the minute I fold it again, the boxes will jump around to where I positioned them because it detected that it's on a dual screen device. So super easy, and this is the main demo I show because it lets people click around and understand how we can make elements attach to the hinge, go to the sides, just adapt themselves for the dual screen layout. 

I don't want to run out of time, but I do want to show that there's quite a few examples here. I suspect maybe Justin's is going to share the whiteboard one because he built it, so I'll skip over that. But there's a few different samples here that could be an inspiration, again, for final projects. 

So here's a photo viewer, and when it's on a regular device, it's just a massive grid of photos. And when you click on one, it just opens up over the top, which is a pretty standard way that an app would work on a device or on any phone. And when we move it onto dual screen, you have a list showing on one screen, and when you click, it zooms in and takes over the whole other screen. 

So that's an example of changing the user interface or changing what your app does or your web page does based on the fact that there's two screens. You can do something cool that you couldn't really do before-- fully see the list, but also see the image zoomed in next to it. 

There's also a Battleship game. Everyone sees these foldable devices, and Battleship is the first thing they think of wanting to play just because the shape looks the same. So this is a really neat-- all of these are open-source. 

And in fact, these are not all samples built by Microsoft. They're built by the community that's interested in foldable devices. So I'm not going to play against the computer there because I might lose. 

But there's another one here, which is a news reader, and it basically gives you an experience where the articles just lay out nicely on a two screen device. One of the great use cases for these foldable devices is book. I use the Kindle app all the time, but reading news and stuff on that format also works really well. 

And the last one I'll share, again, just for inspiration as much as anything else, is there is this really neat Space Invaders game that works best in this mode, where the game goes on the top and the controllers go on the bottom. So you can play it like a Nintendo DS, and this is all HTML. This is a web app that someone's put together that-- [MAKING LASER NOISES] It's a little bit slow while I'm on Zoom, so I probably will die pretty quickly in this one as well. 

But those are just some examples of how people can think about taking an existing user interface, whether it's a photo gallery or a game, and think of something neat or new or different to do with two screens because you've got two screens. And the game, in particular, having it folded over actually makes it easier to play. So those are some ideas that I wanted to share. I think maybe, Justin, it's a good time for you to take over. I've got a slide with your URLs, but maybe you just want to jump straight in. 

JUSTIN WILLIS: So yeah, I'll definitely jump straight in. So I'm just going to do a demo that explains more of what Craig was talking about there, and then also how you can easily get started building one of these web apps or PWAs. So first, I actually just wanted to show off a little bit more of the-- with the two demos that I have, some of the cool depth tools things, and also some other ways you can take advantage of the dual screen thing. 

One thing I will like to show, though, real quick, is someone was talking about older devices, like an iPhone 4. So as you can see, I'm using Edge, but just so you all know, the same thing works in Chrome and other Chromium based browsers, too. And Firefox also has some device emulation features in their DevTools too. So you don't have to use Edge to get all of this, although you will need Edge for the Surface Duo stuff. 

But yeah, so as you can see, there's my app, WebBoard, which is-- I'm showing it running at the web right now. But I'll show it here just in a second running as a Windows app on my Windows device. And then also, as you can see, so I'm not showing on my Surface Duo today because I'm actually having an issue with it right now. But I wanted to show it running in this emulator at least. 

So as you can see, this is the standard view, so it's just a standard mobile app view. All the controls are at the bottom, or at least the controls you're going to use the most, and then some of the other controls are up here at the top, such as sharing. Also cool thing, while we're in here-- so while this is a PWA, and it's just mainly HTML, CSS, and JavaScript, or it is just CSS, HTML, and JavaScript, that doesn't mean that I'm limited on the features that I can do either. 

So for example there, you see I have low latency inking turned on in this PWA. So this is a cool API that we have in Edge and coming soon to other Chromium based browsers, too. But it enables you to do some low latency inking, which is really cool. Same low latency inking stuff that native applications on Windows has, and then you could even do stuff like sharing and stuff like that, all using the native Windows UI. 

And then as you can see, just like Craig was showing, when it goes to dual screen, I can have some special UI for that, and then I can even have some special UI for when it's folded the other way. So it's really not limited at all on the age of the device or the performance of the device or something like that. You could even go all the way down to that GIO phone that I was talking about, which is a really, really small device, and you can still have some kind of experience for the user that's on that device. 

So I think that's pretty cool. It's something I like to point out about PWAs and just web apps in general. So that was one demo. I want to show also Simple Edit is the other demo. 

So before I jump into how you could build one of these, I wanted to show another idea that points out some of the cool things you can do on the web today. So Simple Edit is, as the name suggests-- and again, this is the name that I came up with. I'm not a designer or a product person of any kind. 

But I can go in here. I could choose Photos. Now, the cool thing you'll see there-- there's no extra popup that's saying, hey, here's-- can't open the files or there's no file inputs or anything. This is using an API that is in Chromium based browsers called the File System Handlers API. 

So it will enable me to work with the file system just like any other native app could on this device. And then I can also open up images. You can see I've actually edited this one before with this application. There's some drawing on it. There are some colors. 

And yeah, I can go in here and do things like Image, Filters, which is going to be a little slower when I'm sharing on Zoom. But yeah, this is all actually image filters that are happening on the GPU on this device. Again, fancy sounding stuff, but it's actually all just JavaScript, HTML, and CSS, so it's pretty cool what you could do with a web application. 

Now, the other thing that's cool is, as Craig's been saying, all of this is possible to do with a PWA, and it's also possible to ship this app to all devices. So for example, I have WebBoard running here as a Windows app on my Windows device installed from the Microsoft Store actually, although I could also install it from Edge if I wanted to. And on my Surface Duo, which again, I'm not showing right now, but I also have WebBoard in the Google Play store using a tool that I'll actually show here in a second. 

So you can install-- so basically, what I'm trying to point out there is I wrote one app with one code base, and I have it on the web, so I can get users to the web. I have it on the Microsoft Store, so I can get users to the Microsoft Store. I have it on Google Play, so I can get users to the Google Play store or my Surface Duo, for example. And all of the dual screen APIs and all that kind of stuff works with PWAs installed from the Google Play Store. 

And then recently, my team has also been working on iOS support, so the iOS support is a little bit different because there's not as many capabilities available to Safari. There's also not any of the dual screen stuff here that we talked about. But the point is there, you can actually ship your PWA to the Apple App Store, too. And the cool thing about the web is, because of the more limitations of Safari, you can use standard responsive design type things to ensure that your app works well on iOS. So I think that's pretty cool. 

Now, we've talked about a lot of cool stuff. but you're probably wondering. how do I even like started building something using this cool stuff that we showed today? That's always, with the web, in my opinion, the place that's hard to get started. So you learn your basic HTML, CSS, and JavaScript. And then a bunch of other really cool things are thrown at you, and you're like, hey, you can do this, this, this, and this. 

Here's a bunch of cool frameworks. Here's a bunch of cool CSS libraries, et cetera, and it becomes very-- gives me anxiety almost, honestly, trying to choose what all do I do here? What all do I say? What all do I choose? Am I choosing the right tools, et cetera? 

So my team PWA-Builder at Microsoft-- so this is a team that I work on. It's an open source project. We have multiple tools that we're working on. In fact, I'm going to go through a couple of those tools today real quick here in the demo, but I wanted to start off with our PWA starter. 

So normally, when you're building any web application, or even just a website, there's things you need to get started up front, just like I was saying. You need to choose-- normally, do you just want to get plain HTML, CSS, and JavaScript, or is it more of an application style experience? If you want to do that, maybe you need a single page-- or a framework that enables you to build single page apps. Sorry about the notification sound there. So yeah, maybe you need to build a single page app, and then there's a bunch of other questions that then happen, which is which framework do I use, like I was just talking about. 

So what we've done is we put together this starter, and what this does is it takes all of those decisions that you need to make up front and makes them for you. And we do this based on the best practices that we've established here working on PWAs here at Microsoft, working with the community who's building PWAs, and using that feedback to put together what we think is the best combination of tools that allows you to get started fast, easily, and actually spend your time building your application, not just setting up a bundler or learning what a bundler is or all of this not as fun stuff as just actually building an application. 

So there are some documentation, like Craig said. There's some links that we'll send you all that goes through how to get started here, but I just wanted to show how easy it is. So the first thing you'll need is a GitHub account. If you don't have a GitHub account yet, you will need to make one to use this specific workflow that I'm going to show here. 

So once you have that GitHub account-- and it only takes a minute or two to make. I also actually recommend making one. GitHub is really cool, and you can learn a lot and see what people are doing in their open source apps. 

But the cool thing is we're using a feature of GitHub called template repos. So what this does is it enables me to use this repo, so this PWA starter repo, that gives you all of that tooling that I just talked about up front, already set up, ready to go, just like if you had created an app in Visual Studio or even in Xcode on a Mac. This is going to give you all the setup that you need. 

So I just hit that green button that says New Template Repo, or something like that. I then go in here and name my app. For this one I'll name it harvard-pwa. I can give it a description if I want, and then I can also choose it to be public or private. I'm going to go with public just because this is an open source application. 

So then all I need to do is hit that button. Now, what this is going to do is it's going to generate my new code base that I need to actually start working on my application. And as you can see there, I now have my code base ready to go, ready to clone to my device, and where I could start coding. 

And all I had to do was click a couple of buttons. There's no reading that I've had to do so far, no putting together a bunch of tools, nothing like that. Just clicking buttons. 

So once you have this on your GitHub account, and you'll see this is now on my GitHub account, you would go to Code. And then you would click here and follow some instructions to clone it to your device. I'm not going to do that on the live demo because cloning repos from GitHub almost never goes well in the live demo. But how you would do that is you would just hit the Copy button there to get the URL. Then you would open up a terminal. 

So I'm using the Windows Terminal since I'm on-- oh. There we go. I'm on [INAUDIBLE] since I'm on a Windows device. But this could work on a Mac OS device, too. Any device that-- hopefully, my audio is-- I got a warning there. 

So yeah, Windows terminal is what I'm using since I'm on Windows, and you can actually see, too, that I'm actually using Linux, which is a WSL. A cool thing with Windows-- you can actually run Linux under the hood and do all of your coding there. So anyways, what you would do is type get clone and do Command-V. And as far as installing get and stuff, the links that Craig talked about will show you how to do that. So once you would run that command, that will then clone the repo to your device. 

So once I have that repo cloned to my device, I now have a working code base that I can open in my editor. I prefer Visual Studio Code. It's also cross-platform. It's actually web based. Just so you know, too, it is an Electron app, but all of the UI, all the functionality-- it's all just HTML, CSS, and JavaScript. And because of that, it runs across platform and also starts up pretty quickly and that kind of thing, too. 

Real quick, too, I would actually like to point out that you don't even need a huge computer to do any of this. I'm actually running on a Surface Pro X right now, which is not even considered a real developer device-- "real developer device." But I mean, you could even do this on an iPad or something like that. It's not anything that's compute intensive. 

So once I have it opened up in Visual Studio, all I would need to do is run-- actually, there's two ways we can do this. So one, you could do npm install and npm run dev, and that would do what I'm going to show here in a second. But I think the easier way to do, and the way that I'm more of a fan of, is just using the task runner that is built into Visual Studio Code. And this enables us to do some cool things, which you'll see here in a second. 

So I have my app open. As you can see, it's Test App. Cool name for my PWA. Right? Then I would go up here to Run and hit Start Debugging. 

Now, again, I haven't had to-- I'm not writing any code here. I haven't had to put anything together. We're still just working with the code that all I had to do was clone it from Git. 

So I hit Start Debugging, and as you can see, you could also just hit F5 there, which will do the same thing. We'll give this a second. Again, I'm running Zoom and that kind of thing, and as Craig was saying, sometimes, that can cause things to run a little bit slower. But we'll give this just a second. 

As you can see, it's doing a bunch of stuff in the background, I'll call it. It's not really super needed to understand exactly what's going on here at the moment. And as you can see-- oh, it's now asking me to sync my profile, so I guess I'm going to do that. And we'll give it just a second. Come on, Zoom. Cool, and now, we have our application running. 

So as you can see here, again, I haven't wrote any code at this point. I've only clicked a few buttons in GitHub, and then I hit like two buttons in VS Code. I have an application running on my device that I can then start developing on, and this is actually opened in its own app window, not in the browser. So this is emulating what a user is going to see if they choose to download your app from the Microsoft Store or install it from Edge. And you could use this now to develop your application, just like if you were working on a native app in Visual Studio, in Xcode, or even Android Studio. 

And the cool thing is, here, let's make some changes, and I'll show how they automatically update. So as you can see here, we have app home, and it says Welcome up here. I'm going to do-- let's see. Hello. We'll save that real quick, and again, this might take a second since we're running on Zoom. But as you can see here, all I did was change the code, and it's now auto reloading my changes. 

And here in just a second, you can see my change, and then I can use this whole development workload to then build my app. Make changes. I hit Save. It auto reloads. 

I go in. I test it. I can even move the screen around, make it smaller, et cetera, just like my users might, and this is where some of that responsive design stuff might come in. 

And then the other cool thing is you still get DevTools, so you can right click and inspect, or in Visual Studio Code, you can also hit this button. And what this is going to do is open DevTools actually in my VS Code. So now, I have a full IDE-- well, is it going to load? 

Cool. Like I said, the demo gods have not been with me today. But what this enables is a full integrated development experience for your PWA, just like you might be used to, like I said, with Visual Studio or Xcode or Android Studio, but all focused on building your PWA that you could then ship to all these different devices. 

Final piece of the demo here, real quick, without taking up too much time. Once I have my PWA ready to go, and once I have that published to the web-- which we actually have instructions on, let's see, yeah, deployment and packaging. You can see here, we have instructions on what we recommend for deployment and packaging, that kind of thing. 

We're going to use PWA Builder, which is another tool that my team works on, and I can use this once I have my app. So let's just say that I sat here and built WebBoard in front of you all in the last 10 minutes, and now, I'm going to package that for the Google Play Store and the Microsoft Store. So let's remember I can already get users through WebBoard.app, so this is a URL that you can share with anyone, which I think is another advantage of the web that you don't really get with native applications. 

And then all you need to go to the app stores with this, Google Play Store, Microsoft Store, and the Apple App Store, is put in the URL to your PWA. Hit a button. This might take just a second. 

We're going to run some tests just to make sure you have your technical requirements needed, that you would need to actually go to the store. If you have all these [INAUDIBLE] scores, you're good to go. You can hit Next. 

And at this point now, we're ready to publish our PWA to the stores. So at this point, you can see, you can go and build your Windows package, and you'll get some instructions and documentation on how to put that in the store. Google Play here for Android, and also the Apple Store for iOS. 

And once you do that, you then have that whole experience that I just talked about, where you have the one app that you just built in Visual Studio. It's in GitHub, so it's an open source project, but it can also be closed source. You can then deploy it to [INAUDIBLE] static web apps, which I didn't show here, but like I said, is mentioned in the readme with documentation. 

So now, everything you need is all in one place. You can actually deploy from Visual Studio Code, too, and then all you need to do is just open pwabuilder.com, put in URL, hit the couple of buttons that I did, and then you're ready to go to the Google Play Store, Microsoft Store, and Apple App Store. And combine that with the responsive design stuff that Craig just showed, and you have a full application experience that you can ship anywhere without having to build multiple apps or have multiple teams or anything like that. So yeah, I think that's where I'm going to stop and maybe hand it back off to Craig. And any questions, if there's questions. 

BERNIE LONGBOY: I don't know. Craig, do you have anything else you want to add before I go to questions? 

CRAIG DUNN: No, let's do the questions. I just shared my screen, so that Justin's summary of his talk and two links are showing. But let's do questions while folks-- 

BERNIE LONGBOY: So this is from [INAUDIBLE]. I think you did answer this. Is there any JavaScript file that can work on any number of phones and screens and resolution, like a universal layout? 

CRAIG DUNN: Yeah, so there's no-- the universal layout is touching on, yeah, that's the goal that you want to get to. But we did provide a JavaScript method, the viewports.segments, that Windows segments, that you can use to query and find out if you're on the two screens, and then adapt that layout versus just being on one screen. So the JavaScript functionality is there to allow you to create a layout that will adapt for is there a hinge, is it foldable, or is it not. 

BERNIE LONGBOY: This one is from Bing Liu. Is Edge going to adopt AVIF in the near future? 

CRAIG DUNN: Justin, do you know? 

JUSTIN WILLIS: Yeah. So no, I don't have any solid answer there. I will say, though, that yeah, as far as image formats go, I know we don't support AVIF, but we also support WebP, all the other advancing standards. And yeah, I think there's definitely a lot that we would want to do in Edge to ensure that images load well and that we support modern image formats that let you-- that enable developers to have those small images that work well over a mobile network or something like that. 

BERNIE LONGBOY: Safari supports split view because of the fact that there is a split view [INAUDIBLE] to open two pages apps with split screen. Do I need to do a different algorithm for some web pages? 

JUSTIN WILLIS: So yeah-- 

CRAIG DUNN: Go ahead, Justin. 

JUSTIN WILLIS: Oh, yeah, my bad, Craig. So I was just going to say, so the split screen thing-- I don't know if you can do it on iPhone. But on iPad, I know what you're talking about, where you can have two apps open at once. So that, you don't actually have to use like the foldable stuff for it. Safari doesn't actually support those APIs. 

The only thing you would have to make sure there is, like when Craig and I were showing DevTools earlier, and how you can make the layout thinner, and then you can make it larger if you want. You would want to do that just to make sure that your application looks well in that thinner layout that you're going to get when you have two applications open at one time on an iPad. It's actually the same thing as if you like snap one app on one side on your Windows device and snap one app on the other side on your Windows device. You can actually test it that way. 

BERNIE LONGBOY: And then we just have one comment here, one-- [INAUDIBLE] UI will be significantly different from the single window UI? Yes, it works on the other browsers. [INAUDIBLE]. Does split view also consider screen rotation? I can think of cases where left/right split wouldn't map well to an up/down split. I think you did answer that, Justin, or go ahead. 

JUSTIN WILLIS: I think Craig did, too, actually. 

CRAIG DUNN: Yeah, it's definitely a thing, which is why there are media queries for both rotations because you might want to do something in one rotation, but not the other. 

BERNIE LONGBOY: What plugins do you usually use in Visual Code? Well, that's-- 

JUSTIN WILLIS: So actually, I will say, on that question, so if you use the starter that I just showed-- so if you go to aka.ms/pwastarter-- although I would recommend starting with the second link, really, since that's docs. But you can feel free to just dive into, of course. But yeah, if you go there, that starter actually has a file that has our recommended VS Code extensions. 

And when you open it up in VS Code, you'll get a little prompt in the corner that says, hey, would you like to install the recommended extensions for this repo? If you do, it will show you exactly which ones it's installing, and you can choose, hey, I don't want to do that, or hey, I'm OK with that. So I won't go through all of them here, but the starter has our recommended ones by default. 

BERNIE LONGBOY: From Bjorn-- is the PWA Builder only for shipping to stores, or can I compile standalone executables? 

JUSTIN WILLIS: That's a good question. So you can generate-- so for Android, for example. So you can generate an APK using PWA Builder, or a app bundle-- whatever the other format that they have now. I can't remember exactly what it's called. But you can generate those, and on most Android devices, like 95% of them maybe, you can sideload APKs. 

So you can, of course, do that if you want with the APK that we generate, although it is-- we meaning it to be taken to the store. On the Windows side of things, we give you an MSIX. In fact, we actually give you a sideloadable MSIX, too, by default. That way you can test it on your device just by clicking on the MSIX, and it will install on Windows. But yeah, it's meant to be for the stores, but we do allow you to test it on your own device with standalone executables. 

BERNIE LONGBOY: And I'm going to just read two last questions-- I think we're good-- and just one last comment. Thank you for this amazing webinar. It was a wonderful experience. And the two questions-- the last two questions from Audrey Simmons, is it better to have your own servers when developing web pages? 

JUSTIN WILLIS: Probably not. I mean, you can-- it's a cool engineering exercise to do, to try to set up your own web server and stuff. But in the starter-- I know I keep going back to the starter, but all the docs are in the starter. 

In the starter, we actually have documentation that recommends-- so we recommend Azure Static Web Apps just because it's easy and integrates with the Visual Studio Code and GitHub nicely. But you can also use something like Firebase or something like that, or if you want to have your own web server. 

BERNIE LONGBOY: And last one from Angela-- is PWA appropriate for sites that are heavy on API calls for external data? I was under the impression it was mostly for offline able stuff. 

CRAIG DUNN: Yup. So yeah, that's a really good question, and the answer for actually both of those is yes. So the cool thing is, a PWA-- so anything that works as a web app will work as a PWA. All the PWA thing means is that you're using some of those more modern APIs, like service workers, that then enable the second part of your question, which is the offline stuff. And just so you know, there's actually no limitation on how many API calls that you can save the response offline and things like that. Yeah, you can, for example, save whole video files offline, whole text files offline, your entire app offline, actually. That way, the web app will work offline itself. Yeah, there's no limitation really on the capabilities of what you can do or what you can offline, or anything like that. 

BERNIE LONGBOY: Well, again, thank you, Craig and Justin from Microsoft. And thank you to our audience, and this has been wonderful. I really appreciate learning more about-- I learned a lot as well, so that was great. We're getting some more thank yous, amazing presentation. Thank you, everyone. 

CRAIG DUNN: Yeah, thanks. I appreciate everyone joining, and the link on the screen will link to everything else. But you'll also be able to see the recording, obviously.