Getting started with Mobile Web Development: build responsive, awesome web apps


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.

4 Comments

Add a Comment

Your email address will not be published. Required fields are marked *