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.