[MUSIC PLAYING]
SPEAKER: First, a quick recap.
Why do we need to do this?
Why do we need
responsive design?
The problem is that on the
web, one size does not fit all.
We have different devices,
different needs, even different
data requirements.
And this is at the core
of the PWA attitude
to building for the web.
We need layouts and content
that work across devices.
If your site doesn't adapt
to the user's device,
you break the illusion
and lose trust.
These quotes are from Brad
Frost and Liza Danger Gardner.
You should check
out their blog posts
about responsive design, which
are linked to from the course
materials.
As Liza says, manage
risk, focus on content.
You know, you can make
virtually any site usable simply
by sizing elements
and content correctly.
The golden rule for great
progressive web app content
is not to let content
inadvertently overflow
horizontally,
especially on mobile.
That sounds basic,
but lots of sites
break this rule by
making images, inputs,
and other large elements on
the page with fixed sizes.
Using relative measurement
units, EM, REM, or percentages,
will reduce the
severity of this issue.
Adding a meta viewport tag will
also solve a lot of problems.
This tells the browser the
size of the virtual viewport
on which it renders a web page.
Without setting the
viewport meta tag correctly,
most browsers scale down a
page to fit a virtual 980 pixel
wide viewport.
I've seen some great examples
of this in action on W3Schools.
We'll give you the URLs for
that in the course materials
with this video.
The initial scale value sets
the zoom default for this page.
Don't set a maximum value.
That will make it impossible
for users to zoom,
and that's a big problem
for accessibility.
One other thing you
should be aware of,
the viewport meta tag
will mess up the layout
for fixed-width sites.
The meta viewport
tag is designed
to work with responsive layouts.
If you use it in a
fixed-sized layout,
it will break things
until you convert the site
to a responsive layout.
Try document.documen
tElement.clientWidth
to see how the viewport meta tag
affects the virtual viewport.
Here's another simple technique.
This solves many
layout problems.
You're setting the preferred
size and the maximum size,
and it works for
video and audio too.
So yeah, you might think
that relative sizing
would fix everything.
In fact, for a while back
in the day, some of us
thought that relative sizing
could solve everything
with layout.
We had liquid layout.
Maybe even text could
be relatively sized.
But relative sizing
isn't enough.
Simplistic relative sizing
like this, the diagram,
means that you have
content areas that
are too big on desktop
and too small on mobile.
This is why media
queries were invented.
It's a simple concept.
Use different CSS for different
sized viewports based on width.
That doesn't just mean
making the same layout fit
every device.
On a phone, you might want
a single column layout,
a two column layout on a tablet,
maybe three column for desktop,
and so on.
You can use media queries
to select different layouts
depending on the viewport size.
Here's a single column layout
on mobile, two column on tablet,
and three column for desktop.
So, you think about
devices, and you might think
you could get away with this.
Ask yourself, what could go
wrong with this approach?
What about new devices?
New viewport sizes?
What about changing
window sizes on desktop?
We'll come back to this later.
Now, is that all there is?
Of course not.
There is a better way.
Go back to our
original exercise.
Remember, content is king.
Devices keep changing
and device viewports are
getting bigger and smaller--
not to mention pixel density,
pixel shape, display, quality,
and so on.
Don't force your
designers and developers
to make a change every
time a new device appears.
Start the design process with
the smallest form factor,
then add the major breakpoints
for the form factors
that you work with--
phones, tablets, laptops,
and wide screen devices.
You can then create
minor breakpoints
to handle specific
changes to elements
that don't affect all elements.
The final detail
to keep in mind is
to optimize the
content for reading.
Ideally, keep the width of your
content to 70 to 80 characters.
Wider than that value
makes content hard to read.
Now, that doesn't mean you
stop thinking about devices
and device classes.
You might want one
column for phones,
two columns for tablets,
three columns for desktop
like with saying or whatever.
You can find out more
about these recommendations
on Web Fundamentals.
Now, remember the earlier
media queries example.
In the mobile-first
world of PWAs,
we need to turn that around.
Make small viewports the
default. Look at the example
here.
By the way, there
is no fixed rule
about whether or not to include
media queries inline or use
a separate file.
Also, you might want to consider
using EMs or REMs for units
here, but I won't
go into that now.
You'll also do responsive layout
in JavaScript, if you'd like.
This is a simple way to
do conditional content.
MatchMedia is well-supported,
and there are polyfills.
Calc is really useful
in responsive design
where you want to use a
combination of fixed-widths
and percentages.
In this example, we have
two thumbnail images
side by side, 50% the width
of the parent element,
with a 10 pixel margin
between them no matter
what size the viewport.
Responsive design is about more
than just changing layouts.
As well as changing
layouts, you might actually
also want to manipulate content
depending on the viewport size
and device type.
For example, on a
phone, you might
want to make sure page
content is visible when
the user goes to your homepage.
So you might opt for a
hamburger menu for navigation
and put banner ads
lower on the page.
Also, if need be, you can
just get rid of stuff.
On desktop, your users will
want full functionality
but not on mobile, right?
Wrong.
Don't guess your user's
needs based on viewport size.
Plan content and
functionality carefully,
and don't assume users want less
content or less functionality
on phones than
desktop, for example.
Again, this is a crucial
part of the PWA attitude.
Understand your users,
don't second guess them.
Data-driven design.
Design content layouts
and transaction
processes so users
can get to what they
want as quickly as possible.
Our data shows that every
step to get to content
loses 20% of users.
Rather than removing content,
a more sensible option
can be to choose
different content.
Now, for images, this is
called art direction--
choosing different images
or different image crops,
and I'll show an
example of this later.
You might even want to
provide different text
for different viewports
such as short headlines,
but yeah, be careful
again not to assume
that mobile users
want less content.
For video, the general rule
is to use a smaller resolution
for smaller viewports.
This can result in
massive reductions
in byte size, playback
performance, improvements,
and also reduced streaming cost.
The best way to do this is
with adaptive streaming, DASH,
or HLS-- not just media queries.
And yeah, you can find
out more about that-- more
about adaptive streaming--
in the course materials.
But just to reiterate,
the key point
here is that when you're
delivering video to mobile,
don't use resolutions
larger than you need.
And talking about
video content, don't
forget to caption videos
using the track element.
It's really easy.
Let's take a look at the
relatively new technique
for creating responsive layouts.
CSS Flexbox provides flexible
sizing and alignment,
element reordering, and better
performance than floats.
CSS Flexbox is well-supported,
and we strongly recommend it.
Easy centering is the
holy grail of CSS.
Take a look at the code here.
It's incredibly simple.
I still find it
slightly thrilling.
By the way, the materials
that accompany this video
have links to lots of Flexbox
examples, including this one.
Let's look at the CSS
for the examples here.
This uses CSS Flexbox for
three different layouts
depending on the viewport width.
Let's start with the defaults
for smaller viewports.
Remember, mobile first.
The container is
declared to use CSS flex.
The flex flow property
means child elements
can wrap rather than being
squashed onto the same line.
You can also use inline flex.
That's shorthand for
flex-direction and flex-wrap
properties.
The default is row no wrap.
100% width for each
div in the container.
Add a different layout for
a slightly larger viewport,
and different again once
the width hits 800 pixels.
The container is
now a fixed-width,
and centered horizontally
using margins.
Let's take a look
at the example here.
Once again, this
uses CSS Flexbox
for three different
layouts depending
on the viewport width.
And again, let's start with the
defaults for smaller viewports.
For viewports over 600 pixels
in width, the order is changed.
On the smaller
viewports, we wanted
to give child1 full width, but
for a slightly larger viewport,
we can put it next to child2.
I could go on.
Anyway, two other
properties I'd like
to draw your attention
to, justify-content,
how items are packed,
and align-items,
how items are aligned.
CSS grid-is in some ways related
to the grid system concept
familiar to graphic designers.
A page is thought of in terms
of lines, tracks, between lines,
cells, and areas.
CSS Grid is coming,
and it's already
behind a flag in
Chrome and Firefox.
You'll find more information in
the resources for this video.
The lab exercises that
accompany this video
will help you get started with
media queries, breakpoints,
grids, and width flexbox.
[MUSIC PLAYING]
