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.