MALE SPEAKER: Welcome
to Getting Started
with Mobile Web Development.
A short crash
course where you'll
get to set up and
build responsive,
multi-device web apps and sites
using Chrome developer tools.
Once you've chosen
your framework
and have agreed with
your team about what
it is you want to do with
your awesome, responsive site,
you're ready to dive in.
MALE SPEAKER: And one
of the first challenges
with developing for the mobile
web is the display screen.
The typically small
display screen,
compared to a desktop
or a laptop device,
really forces you to focus on
what's critical for your users.
In today's landscape you should
really think of your designs
in terms of three main
scenarios, phone, tablet,
and desktop.
These may share some design
characteristics of course,
and they'll
certainly share data,
but you should consider
the optimal experience
for each of these
scenarios separately
as you build your design.
MALE SPEAKER: As you can
see, Chrome Dev Tools
provides a series of tabs that
allow you to debug and inspect
your web apps.
For example, you can select
any element on the page
by right clicking the element
and selecting Inspect Element.
Or, as I'll do here, you can
click on the magnifying glass
and hover over an area that
you would like to inspect.
MALE SPEAKER: The
set up is simple.
All you need as an Android
device, a USB cable,
and your development machine.
Let's take a look.
Before you get started, you
need to turn on the Developer
Mode in your Android device.
This may be different
on any given device.
And you can check your device's
manual for how to do this.
In many cases though, you need
to go to your devices Settings,
click on About
Device, and then click
on Build Number seven times.
Seriously.
Next you'll want to
turn on USB debugging.
Again, this varies slightly
on your given device,
but is usually located
in the Developer Options.
We also need to make sure we
have the right tools installed.
On my laptop I
have Chrome Canary.
And on my mobile device I
have Chrome Beta installed.
Now that we have everything
set up the way we need,
open Chrome on your
development machine,
and go to Chrome Inspect.
Make sure the site
you want to debug
is open on your mobile
device, and then
connect your laptop to
your mobile device via USB.
Then confirm that you want
to allow USB debugging.
Back on our
development machine we
can see a list of the attached
devices, and the Chrome
tabs that are open
on the device.
You can even open other tabs.
You can also focus
on specific tabs.
You can reload them, and
you can even close a tab.
MALE SPEAKER: When
mobile browsers first
came along the
content on the web
wasn't designed for narrow,
small screen devices.
It was designed for
windows that were around
1,000 pixels wide, and
wider than they were tall,
with easy scrolling.
To shoehorn this content
into a tiny, mobile screen,
since rendering a
web page designed
for 1,000 pixels across
on a 320 pixel wide screen
would mean you'd
be scrolling a lot,
mobile browsers basically
lied about the window width.
They made the window act as
if it were 980 pixels wide,
even though the original iPhone
was only 320 pixels across.
This enabled sites that
were designed for a 1024
by 768 screen, that is, that
were around 980 pixels wide,
to fit on the mobile screen.
Although you needed
to do a lot of zooming
to read the text sometimes.
Unfortunately if
your site did not
happen to match that
980 pixel width,
you were either going
to overflow or underflow
the screen.
Either wasting space, or
forcing the user to zoom.
In order to control this, Apple
provided a viewport meta tag
to be added to your HTML to
control the default for how big
should my screen
act on this page.
The default is 980.
So if you put 980 here,
it would have no effect.
The mobile browser
already defaults to 980.
But setting a viewport
tells the browser
how wide the content is
intended to be, and then
the browser scales to make
that size fit on the device's
screen.
There are two ways
to use this tag.
Although typically viewport
is only being set on load,
you can actually play around
with the viewport settings
in the development tools
to tweak it, and get it
just right.
If I go into the page
and set the viewport meta
element contents from
the Mobile Dev Tools,
it will change the page as
if it had been refreshed.
However, and this is where
it gets a bit confusing,
the zoom level is
maintained by the browser
across page refreshes.
So when you change viewport
settings in the source code,
and you're reloading, be sure
to actually close the tab first.
Don't just hit reload,
or it won't necessarily
show the effects on the screen.
So let's try this
out on this page.
Let's add a device width
element to our lorem ipsum page,
and refresh it on
the mobile browser.
This is what a page
looked like before.
Now, with the meta tag in
place, let's try reloading it.
And you can see the page
now chooses a better size
because it's reflowing at the
native size of the screen.
MALE SPEAKER: So really, fixed
viewport widths are historical.
Resizing by default
was an attempt
to shoehorn the desktop
web into a mobile device.
Fixed viewport sizes
were a quick way
to provide some minimal
controls on that resizing.
With Device Width gets us
back to the same scalable
sized canvas that
the desktop web has.
So the right way to do
fluid, flexible design
in the modern mobile web
starts with this tag.
This marker lets
the browser know
you're one of the cool kids,
and you know what you're doing.
There is one more
thing on viewports.
You're naturally going
to want to lay out
elements on the page relative
to the size of the viewport.
Particularly, when you're
sizing columns on the page,
for example.
So we have a new unit type
in CSS called viewport units.
You can use these units to
size things in percentage
of width of viewport
or percentage of height
of viewport without having
to push percentage sizing
everywhere, which makes
things a little easier.
The really exciting
thing is these unit
types even work in
desktop browsers,
as well as in mobile browsers.
MALE SPEAKER: So
now that you know
how to set the
viewport meta, let's
poke around in the
developer tools
to see what we need to
do to fix this page.
Now the biggest problem
here is that the page
has a fixed column width.
If I resize the window, you'll
notice the column of text
doesn't actually change
size, just margin position.
As we mouse around the
elements inside the DevTools,
we can pretty quickly find
the first offending element.
This page element here
actually has a width set on it.
Let's disable that
and see what happens.
Well, it certainly
changed things,
but I don't think it actually
improved things very much.
Let's keep digging
inside the content
and see what we can find.
This wrapper element has a width
of 100% already, which is good.
It means that it's not
preventing us from resizing.
But this content element does
have a width set in pixels.
Let's disable that.
Now as we resize the
page our content is fine,
but the sidebar is
appearing and disappearing.
Sure enough, it has a width set.
If we set its width
as a percentage also,
now we're resizing
a little bit better.
So now let's go
back up to the page,
and let's try giving it a width.
But let's give it a width
in viewport units instead.
Now our only remaining
problem seems
to be that the header
is actually not
resizing as we want it to.
Let's go take a look at
the header image again.
The image has a max width
set, but not just a width.
So let's set its width.
And now everything seems
to be resizing well.
Now, this isn't perfect.
But all that I really
wanted to get at
was that as you try
to transition pages
from fixed layout
to fluid layout,
the core things to look
for are fixed pixel sizes
and lack of percentage resize.
Be sure to create fluid layouts.
Be sure to reflow to use
all the space on the screen,
and take advantage
of every bit you can.
And be sure you adapt to
different screens as well.
One tool that makes reflow
a lot easier, particularly
across very different
screen sizes,
is the new Flexbox
layout in CSS.
This new tool lets
you stack elements
in flexible rows or columns.
MALE SPEAKER: Responsive
design isn't just
about flexible
fluid designs, it's
also about adapting to different
scenarios and environments.
And our primary tool for
doing that is Media Queries.
Media queries have their
roots in the media type
for style sheets.
Used to declare a
style sheet that's
only applied to certain media
types, like when printing,
and in the At Media
Section in CSS,
where you can declare a
subsection of the style sheet
to only be used for
print or other media.
For example, it's helpful to
display the URL of hyperlinks
when printing, since you can't
click on the links on paper.
So that's what this rule does.
But CSS3 Media Queries
added media query terms.
This lets us make conditional
rules in our style sheets
based on environmental factors
like the width of the window,
or the orientation
of the device.
This opens up a huge
opportunity for us
to make truly adaptive layouts.
There are a number of
different properties
available inside these
media query expressions
like the width and height of
the current window, the width
and height of the device, the
device orientation, the device
aspect ratio and
window aspect ratio,
whether the device
is grid-based,
how many bits per
color the device uses,
or whether it's an
indexed color device,
or whether it's monochrome,
the overall resolution
of the device, and whether it's
progressive or interlaced scan.
MALE SPEAKER: This
was a crash course
in mobile web development
and using Chrome Developer
Tools to build responsive,
multi-device web apps
and sites.
For more best practices
and how to's, check out
the full mobile web
development course, on Udacity.
You could also find
more information
on the web fundamental site.
All the best, and happy coding.
