IntroductionWelcome| 00:00 | (music playing)
| | 00:04 | Hi! I'm James Williamson, senior author
here at lynda.com, and I want to welcome you to
| | 00:09 | Responsive Design Fundamentals.
| | 00:11 | Over the last few years, we've seen a
fundamental shift in how people consume online content.
| | 00:16 | The rise of smartphones, tablets, and other
connected devices means that designing your
| | 00:21 | sites for a fixed screen size
is no longer a best practice.
| | 00:25 | With that in mind, I've designed this course to
introduce you to the basic concepts, terminology,
| | 00:30 | and strategies for creating responsive designs.
| | 00:33 | We'll start by exploring some of the basics
of responsive design: what it is, why it's
| | 00:37 | important, and how a
typical responsive site behaves.
| | 00:40 | Next, we'll tackle some of the common
concepts and techniques of responsive design, such as
| | 00:46 | the mobile viewport, working with media queries
and fluid grids, and how to improve site performance
| | 00:52 | for responsive sites.
| | 00:54 | After that, we'll discuss different strategies
that can help guide your approach to responsive
| | 00:58 | design and give you a better idea of the issues that
you'll face as you adopt a responsive design workflow.
| | 01:03 | So with that in mind, let's dig a
little deeper into responsive design.
| | 01:07 |
| | Collapse this transcript |
| Who is this title for?| 00:00 | responsive design is a growing movement in
the web design community, but it's still at
| | 00:04 | the early stages of its development,
| | 00:06 | and many of the concepts and
techniques behind it are still evolving.
| | 00:10 | I've created this course as a way of
introducing what responsive design is and what you should
| | 00:15 | focus on if you choose to
begin building responsive sites.
| | 00:19 | Since the format of this course is a little
different than some of my other courses, I
| | 00:23 | thought I'd take a few minutes to describe
what this course is and whom it's designed for.
| | 00:29 | As part of the Fundamentals series, it's designed
to give you a high-level overview of responsive
| | 00:34 | design and the techniques, concepts,
and strategies behind implementing it.
| | 00:39 | You'll note that this
course has no hands-on exercises.
| | 00:43 | It's simply designed to introduce you to
responsive design and help you understand what's involved
| | 00:48 | in creating responsive sites.
| | 00:50 | As such, this course assumes a basic level
of knowledge with the concepts surrounding
| | 00:55 | HTML, CSS, and JavaScript.
| | 00:58 | Beginning web designers can certainly expect
to come away from this course with a better
| | 01:02 | understanding of what responsive design is,
but much of the course is designed to give
| | 01:07 | experienced web designers a clearer
picture of how responsive design works.
| | 01:12 | So if you're brand new to web design, don't
be surprised to hear me reference a few terms
| | 01:16 | and concepts that you're unfamiliar with.
| | 01:18 | For those of you who are experienced designers,
this course is a great place to start if you're
| | 01:23 | curious about responsive design
and want to learn more about it.
| | 01:26 | Although the course isn't hands-on, there
are enough syntax examples, concepts, and
| | 01:31 | helpful resources to get you started building
responsive designs as soon as you finish the course.
| | 01:37 | I hope this gives you a clearer picture of
what to expect from this course, and with that,
| | 01:41 | let's go and learn more about responsive design.
| | 01:43 |
| | Collapse this transcript |
|
|
1. Introducing Responsive DesignWhat is responsive design?| 00:00 | One of the biggest challenges faced by web
designers is the lack of control that they
| | 00:04 | have over their medium.
| | 00:06 | Take print design for example.
| | 00:08 | If I'm designing this magazine layout,
I'll need to deal with variables such as paper
| | 00:13 | stock, what type of press it's
printed on, and which inks I'll use.
| | 00:17 | While these choices may influence my design
decisions, I'm still designing for fixed dimensions.
| | 00:23 | I'm largely in control of the entire process,
and the people that consume this content will
| | 00:28 | experience it in exactly the same way.
| | 00:31 | Now, contrast that with web design.
| | 00:34 | When I create content for the web, I have
to deal with an almost overwhelming set of
| | 00:39 | variables in how that content will be consumed.
| | 00:42 | For example, I have to consider the wide variety of
browsers and operating systems that people might be using,
| | 00:48 | whether my content is accessible to screen
readers or other accessibility-enabled devices,
| | 00:53 | how my content will look if and when it's
printed, or whether they're attempting to access
| | 00:57 | my content on any one of the growing
number of diverse web-capable devices that don't
| | 01:03 | really resemble the traditional
screen and browser configuration.
| | 01:07 | Of course, the change that's been
getting the most attention recently is mobile.
| | 01:12 | The recent explosion of clients accessing
the web on mobile devices has made designing
| | 01:16 | for the mobile screen a requirement,
not an additional consideration.
| | 01:21 | But mobile is only part of the story.
| | 01:23 | As you can see by the small sampling
screens that I have here, screen sizes are not only
| | 01:27 | getting smaller, they're getting bigger as well.
| | 01:31 | That means that as a designer, trying to
design separately for each context that your content
| | 01:35 | might be encountered in is almost impossible.
| | 01:38 | That's where responsive design comes in.
| | 01:41 | Responsive design is a design strategy that
is centered on designing your content so that
| | 01:46 | it responds to the
environment it's encountered in.
| | 01:49 | The term was first coined by Ethan Marcotte
who identifies three fundamental techniques
| | 01:54 | for responsive design: fluid grids for flexible
layouts, media queries to help you adapt content
| | 02:01 | to specific screen sizes, and flexible images and
media that respond to changes in screen sizes as well.
| | 02:09 | For the most part, Ethan's sticking to his guns on
those three techniques defining what responsive
| | 02:13 | design is, but like most new terms,
its meaning is still evolving.
| | 02:18 | Many people are using it to refer to any
techniques or strategies that allow designs to respond
| | 02:24 | to different environments.
| | 02:25 | I feel it's a very broad term and one that
can encompass almost anything that frees your
| | 02:30 | content from the
restrictions of a single context.
| | 02:34 | To me, learning and understanding responsive
design is less about learning specific techniques
| | 02:39 | and more about changing the way that
you think about designing for the web.
| | 02:43 | It means totally rethinking content strategies,
taking more time to consider how people might
| | 02:48 | use and access content based on specific context,
and how to take advantage of the diverse capabilities
| | 02:54 | of the different devices that
your audience is likely to use.
| | 02:58 | To that end, I think you'll find that
embracing responsive design will dramatically change
| | 03:02 | the way you plan and execute your sites.
| | 03:05 |
| | Collapse this transcript |
| Exploring the need for responsive design| 00:00 | Over the years, we've seen a lot
of web design trends come and go.
| | 00:04 | In fact, I'd say the one constant
in the field of web design is change.
| | 00:09 | With so many new developments and techniques
cropping up, it's sometimes hard to keep track
| | 00:12 | of what's important and what's not
when you're deciding what to learn next,
| | 00:17 | so it's only natural to wonder just how
important responsive design is and whether or not you
| | 00:21 | need to dedicate the time and
energy required to learning it.
| | 00:24 | Well, the easiest way for me to illustrate
this is to simply show you why it's so important.
| | 00:30 | Every single one of the screens that you see here
is able to connect to and display your websites.
| | 00:35 | And this isn't even half of the
screen sizes and resolutions available.
| | 00:41 | In the past, we've had a pretty good handle on what
the target screen resolution for our design should be.
| | 00:46 | When I first started designing web pages,
640 X 480 was the standard screen size.
| | 00:52 | From there it went up to
800 X 600, 1,024 X 768, and so on.
| | 00:58 | To keep pace with the screen sizes,
we simply made our designs wider and wider and wider.
| | 01:05 | It also became standard practice to create
designs using fixed widths, meaning that the
| | 01:09 | website was locked into a specific width
regardless of the monitor it's viewed on.
| | 01:14 | In fact, that's still the standard layout
techniques for the majority of sites online.
| | 01:19 | However, over the last five years we've seen
some dramatic changes in how sites are viewed
| | 01:25 | that are forcing us to
reexamine how we design our sites.
| | 01:29 | Some of those changes were relatively minor,
like the aspect ratio of monitors changing
| | 01:34 | from 4 X 3 to 16 X 9.
| | 01:37 | Other changes, like the rise of mobile computing,
will fundamentally change how we design sites.
| | 01:44 | Take these screens for example.
| | 01:46 | Each one of them has a
different screen size and resolution.
| | 01:49 | So which one do you target?
| | 01:51 | In the past, it might have been pretty easy
to say with confidence that the overwhelming
| | 01:56 | majority of your viewers
would use a specific screen size.
| | 01:59 | That's not the case anymore.
| | 02:01 | The time and energy required to target
each one of these different screens isn't even
| | 02:05 | worth thinking about.
| | 02:07 | That's what makes
responsive design so important.
| | 02:10 | Through using the evolving techniques of
responsive design, we can create a design that responds
| | 02:15 | to each of these environments and offers
users an experience that conforms to the context
| | 02:20 | in which it's viewed.
| | 02:21 | There's a bigger picture here
you need to consider as well.
| | 02:24 | The techniques used in creating responsive
designs are continuing to evolve to meet an
| | 02:29 | even bigger change to web design
that's right around the corner.
| | 02:33 | We've reached the point where adding wireless
connectivity to devices is now cheaper than leaving it out.
| | 02:40 | That means that we're about to experience an
explosion of devices that can connect to your content.
| | 02:44 | Already, we're seeing cars, watches, shoes,
and other devices with Internet capabilities.
| | 02:51 | So while these devices might represent the
current ecosystem we need to design for, they're
| | 02:55 | really just the tip of the iceberg.
| | 02:58 | To me, that simply underscores
how important responsive design is.
| | 03:03 | Unless we focus on ways to make our
content and designs more adaptive across multiple
| | 03:08 | environments, we're going to be restricted
to making sites that work part of the time
| | 03:12 | for only part of our audience.
| | 03:14 | So while responsive design might be seen as
a new way to approach designing sites right
| | 03:19 | now, I believe in a few years it
will simply be "the way" we design.
| | 03:23 |
| | Collapse this transcript |
| What makes sites responsive?| 00:00 | As with all web design, a
responsive design starts with HTML.
| | 00:04 | Clean, well-structured HTML helps create content that
is meaningful and easier to manipulate based on context.
| | 00:12 | Likewise, the care the designer gives when
planning the site's semantics in uses of ID
| | 00:18 | and class attributes can go a long way
towards making the site more responsive.
| | 00:23 | Clear roles for elements and consistent
structure make it easier to control how content responds
| | 00:29 | or displays within a specific design.
| | 00:32 | HTML5 also includes a few features that helps
sites be more functional across multiple devices.
| | 00:38 | The new form elements, for example, allow
designers to create forms that take advantage
| | 00:43 | of mobile device interfaces and facilitate
making phone calls and sending texts without
| | 00:48 | requiring extra markup or scripting.
| | 00:51 | As you would imagine, CSS plays a
major role in creating responsive design.
| | 00:56 | CSS media queries allow us to apply different
sets of styles based on factors such as screen
| | 01:02 | size, orientation, or resolution.
| | 01:05 | This allows us to change layout and typography
to a design that's more suited to the context
| | 01:11 | in which it's viewed.
| | 01:13 | Responsive layouts are typically fluid in
nature so that they can flex to fit the screen
| | 01:17 | on which they're viewed.
| | 01:19 | Newer CSS features, such as transitions and
transforms, allow designers to change how content
| | 01:25 | displays and interacts with the user
without requiring additional scripting.
| | 01:30 | CSS-based graphics can also help reduce
the amount of resources requested by the page
| | 01:35 | by replacing icons or other images.
| | 01:38 | JavaScript is also used in varying
degrees by different responsive designs.
| | 01:43 | It's primarily used to control resource
loading, supply the correct images and media based
| | 01:48 | on the needs of different devices, and to add
device-specific functionality like geolocation
| | 01:53 | and touch events to sites.
| | 01:56 | Essentially, these three technologies--HTML,
CSS, and JavaScript--form the backbone of
| | 02:03 | most responsive designs.
| | 02:05 | Later in this title, we'll explore some of
those techniques in a little bit more detail.
| | 02:09 | For the moment, just remember that it's the
concept and goals of responsive design that's
| | 02:14 | important to understand.
| | 02:15 | In many cases, there are multiple techniques
to help content become responsive, and in all
| | 02:21 | cases, the techniques and strategies behind
responsive design are continuing to evolve.
| | 02:27 | That means that as a designer, you should
explore multiple techniques, experiment with
| | 02:31 | your own, and think about how responsive
design fits in your overall site strategy.
| | 02:36 |
| | Collapse this transcript |
| Exploring a responsive site| 00:00 | Before we move on to talking about
specific techniques and strategies, I want to take
| | 00:04 | a moment to explore a responsive site in action so
that you can see how these concepts are executed.
| | 00:11 | To do that, I'm going to show you the demo
created by the very talented Brad Frost for
| | 00:16 | his HTML5 Rocks tutorial.
| | 00:19 | You can check out this demo and the
corresponding tutorial at html5rocks.com.
| | 00:24 | Now, first, I want to show
you the page on a laptop.
| | 00:28 | Here we can see the desktop version of the
page, which represents a product detail page
| | 00:33 | from a fictitious apparel company.
| | 00:35 | One of the first things that people
usually do when they show off a responsive design
| | 00:39 | is to resize the screen.
| | 00:42 | As you can see, the layout reflows
to reflect the size of the viewport.
| | 00:46 | While visually impressive, it really doesn't
represent how your audience will experience your site,
| | 00:52 | so I want to explore the same page with
several different devices and find out exactly what
| | 00:57 | makes this site responsive, and how the site's
responsiveness impacts how people experience
| | 01:04 | and use the site across different devices.
| | 01:07 | Before we get in to other devices, let's
stay here for a moment and take a look at what
| | 01:11 | we see on a desktop.
| | 01:13 | The layout is centered on the page, and it's
designed so that it fits within a wide range
| | 01:18 | of desktop resolutions.
| | 01:20 | There is a small menu at the top of
the page along with a search field.
| | 01:26 | Below that, you'll find the product detail,
and in this case that's three photos that
| | 01:30 | you can click to get
different views of the shirt.
| | 01:34 | To the right of that we have some additional
information about the shirt and the ability
| | 01:38 | to add it to our cart.
| | 01:40 | Below that, you'll see a list of
similar shirts and customer reviews.
| | 01:44 | At the very bottom of the page, you'll find a
mirror of the top navigation, links to company
| | 01:50 | information, and the
customer service phone number.
| | 01:54 | So, now let's examine the same page on a tablet.
| | 01:58 | For the most part, the layout is exactly the
same except that the thumbnails are now below
| | 02:03 | the main product image rather than to the side.
| | 02:06 | However, if I change the orientation,
notice that the layout changes as well to respond
| | 02:12 | to the additional width.
| | 02:14 | Now, some of the changes are not that obvious.
| | 02:18 | Note that the site now realizes it's being
viewed on a touch device and allows me to
| | 02:22 | swipe through the gallery images.
| | 02:25 | When we move to a smartphone, you can
see the layout changes dramatically.
| | 02:31 | Everything condenses down to a single
column and scales so that it fits well within the
| | 02:36 | smaller space of a mobile viewport.
| | 02:39 | Right away we can see some changes to the
site that are more specific to the mobile space.
| | 02:44 | First, the top menu is hidden away to save space,
but it is available with just a single touch.
| | 02:50 | Also, note the prominence of the search field.
| | 02:54 | Within the mobile context, giving users a
quick way of searching for content is often
| | 02:58 | faster and more effective than
supporting larger navigational menus.
| | 03:03 | The photo gallery is still touch-sensitive
and you'll notice it responds to finger swipes.
| | 03:07 | Now, if you look closely, you'll see that
there are features built into the site that
| | 03:12 | are designed to take
advantage of mobile devices.
| | 03:16 | For example, the form for the shirt
ordering uses a new HTML5 form element type that is
| | 03:21 | supported by most mobile devices.
| | 03:24 | As you can see, when we click into the
Quantity field, we are given the numeric keyboard as
| | 03:29 | a response to the input type.
| | 03:31 | Now, just below that, you'll find
a link for finding a nearby store.
| | 03:36 | Now, clicking on that is going to take advantage
of the phone's location-detection capabilities.
| | 03:42 | While that feature certainly can work on a
desktop computer, users are more likely to
| | 03:46 | take advantage of that on mobile devices.
| | 03:50 | Scrolling down we can see that the Similar
T-shirts and Reviews are presented in accordion
| | 03:55 | sections, which is a nice way of
saving space for mobile screens.
| | 03:59 | Finally, notice that the phone number is
actually using the telephone URL format, which allows
| | 04:05 | mobile devices to either make calls
or add the number to their contact list.
| | 04:10 | Now, that's just a brief overview of some
of the responsive features of this page.
| | 04:15 | For a more detailed look at what's going on
here, and the techniques behind it, check out
| | 04:19 | Brad's tutorial on HTML5 Rocks, and be sure
to check out his blog, at bradfrostweb.com.
| | 04:27 | There's a lot going on behind the scenes
here that you need to explore, but rather than
| | 04:31 | focus on exactly how Brad built this page
to be responsive, I'd rather that right now
| | 04:36 | you focus on the why.
| | 04:38 | It's important to note that each time we examine
the page we were looking at exactly the same content.
| | 04:44 | It simply responded to the context in
which it's being viewed to create a better user
| | 04:49 | experience that's tailored to that environment.
| | 04:51 | Often, we get so caught in the technical
aspects of how to build something that we lose sight
| | 04:57 | of the reasons that we're actually doing it.
| | 05:00 | As you approach responsive design, make sure
that crafting better user experiences is the
| | 05:05 | driving factor behind each of
the decisions that you make.
| | 05:08 |
| | Collapse this transcript |
|
|
2. Common ConceptsExamining the mobile viewport| 00:00 | In this chapter, I'm going to focus on some of the
common concepts and techniques of responsive design.
| | 00:06 | Many of this will focus on how we target and
design for mobile devices, and will deal specifically
| | 00:12 | with making sure that you can control how
your content displays on mobile screens.
| | 00:17 | Perhaps the most confusing aspect of mobile
displays is the concept of the mobile viewport.
| | 00:23 | Take this iPhone, for example--and I'm going a
little old school here and using the iPhone 3GS.
| | 00:30 | The screen resolution for
this phone is 320 X 480 pixels,
| | 00:35 | meaning that the screen is 320
pixels wide when in portrait mode.
| | 00:39 | However, notice that when I browse to a site
that hasn't been optimized for mobile screens,
| | 00:44 | like apple.com for example, the entire site
is scaled to fit itself into the 320 pixels'
| | 00:51 | worth of space, even though it was design
for a much wider screen resolution--in
| | 00:56 | this case 980 pixels.
| | 01:00 | To read a site like this, the user needs to
zoom up and then pan to the areas of the page
| | 01:06 | that they want to read.
| | 01:08 | So what's going on here, and why is this
the default approach for most mobile devices?
| | 01:14 | To understand that, we first have to understand
what the mobile viewport is and how it relates
| | 01:18 | to the mobile screen.
| | 01:21 | When we're browsing on a desktop device,
the concept of the viewport becomes a little more
| | 01:25 | obvious, as any open browser
window is defined as the viewport.
| | 01:30 | Because the viewport is independent of the
screen, we can resize it to whatever size we want.
| | 01:37 | On mobile devices, the viewport
functions in much the same way.
| | 01:41 | It gives you a defined area to display web
pages that is independent of the device's screen.
| | 01:47 | It's simply not as obvious as the desktop
viewport, and users don't actually resize the
| | 01:53 | viewport as much as they scale it up or
down when they zoom in and out of web pages.
| | 01:58 | Since viewports have a minimum scaling factor,
users rarely ever see their edges as they
| | 02:03 | do when they resize floating browser windows.
| | 02:07 | Because of the small size of mobile screens,
mobile viewports are designed to be larger
| | 02:12 | than the screen's resolution.
| | 02:14 | Mobile Safari has a viewport of 980
pixels, while Opera's is around 850.
| | 02:21 | When you compare that to an iPhone with a
screen width of 320 pixels, you can see that
| | 02:27 | the viewport is much larger
than the actual screen itself.
| | 02:31 | In large part, this is due to mobile
viewports having to display content that's designed
| | 02:36 | for much wider screens.
| | 02:39 | Typically, mobile browsers will display a
web page within the viewport and then shrink
| | 02:44 | that viewport down until the content
fits within the width of the screen itself.
| | 02:49 | While this usually results in tiny pages,
it does allow the user to see the page in
| | 02:54 | its entirety and decide which areas of
the page they'd like to zoom up to, and read.
| | 02:59 | If mobile browsers didn't behave this way, you'd
only be able to see a small portion of most web pages.
| | 03:05 | This would be much more confusing as you'd
have to pan around the page to explore its
| | 03:09 | content without really
knowing where anything was.
| | 03:13 | This has been described as keyhole
browsing, as it's similar to viewing an entire room
| | 03:17 | through a small keyhole.
| | 03:18 | So, while the default viewport scaling is
helpful for users browsing sites designed
| | 03:23 | for larger screens, it can make it extremely
frustrating when browsing pages that are designed
| | 03:28 | specifically for mobile screen sizes.
| | 03:32 | Let's say that you've created a responsive design
that has a mobile phone layout designed for 320 pixels.
| | 03:38 | On an iPhone, the default mobile viewport
is 980 pixels, so your 320-pixel layout is
| | 03:44 | only going to occupy about a third of that.
| | 03:47 | The viewport will then be scaled down to fit
the 320-pixel screen, making your layout really
| | 03:53 | tiny and defeating your
carefully crafted 320-pixel layout.
| | 03:59 | So, in order to build responsive sites that
fit neatly within mobile screen sizes, you'll
| | 04:04 | need to know how to control both the
viewport size and its initial scale factor.
| | 04:10 | We'll learn how to do that in our next movie.
| | 04:12 |
| | Collapse this transcript |
| Controlling viewports| 00:00 | Now that we've defined exactly what the mobile
viewport is, we need to discuss how to control them.
| | 00:07 | Currently, there are two mechanisms for
overriding the user agent's default viewport.
| | 00:12 | You can either use the viewport
meta tag or the @viewport CSS rule.
| | 00:17 | Since they both use similar syntax,
I'm going to show you code examples for each, and then
| | 00:22 | describe their effects on the viewport.
| | 00:25 | The meta viewport tag appears in the head
of your HTML, and has two basic parts: name,
| | 00:31 | which is viewport, and content, which will
contain the properties and values you wish
| | 00:36 | to set for the viewport itself.
| | 00:38 | The @viewport rule can appear anywhere in
your CSS that you want, but since it can affect
| | 00:44 | media queries, it's recommended that you place
it prior to any media queries in your styles.
| | 00:50 | Most designers place it near the top of their
styles as one of, if not the very first, rule.
| | 00:55 | The syntax is similar to the meta viewport tag.
| | 00:58 | You simply declare an @viewport rule and then
populate it with the properties that you wish to control.
| | 01:05 | Now that we have the basics of the syntax
down, let's examine the individual properties
| | 01:09 | that you can control.
| | 01:11 | As we set viewport properties,
we'll examine the site optimized for mobile screen sizes
| | 01:15 | to see how the mobile browser reacts
to changes to its default viewport.
| | 01:20 | First, I want to explore controlling
viewport width, which is arguably the most important
| | 01:25 | viewport property to responsive design.
| | 01:28 | As you can see, our layout is scaled down
dramatically, due to the default viewport settings.
| | 01:34 | And if we change our viewport syntax to set
the desired width to 320 pixels, you can see
| | 01:41 | the site now displays at the desired width.
| | 01:45 | Note that in the viewport meta tag syntax,
you don't append PX to the pixel value, while
| | 01:51 | in the @viewport CSS syntax you do.
| | 01:55 | While a specific pixel value for width might
be fine for some projects, remember that not
| | 02:00 | all mobile screens are 320 pixels wide.
| | 02:04 | If your website is using a fluid layout,
you're going to want the layout to be based on the
| | 02:08 | available screen width of the device and not
limit the viewport to just one single size.
| | 02:14 | To do that, we can use the
property value device width.
| | 02:19 | This value instructs the browser to set the
viewport to the exact size as the available screen pixels.
| | 02:26 | Setting this will remove any initial viewport
scaling and allows you to create fluid layouts
| | 02:31 | that adapt to multiple devices.
| | 02:33 | Unless there's a reason to use a specific
value for your viewports, this is the value
| | 02:38 | I recommend you use for your responsive designs.
| | 02:42 | Just as you can set width, you can also set
the height of the viewport, to either a specific
| | 02:46 | value or by using the value device height.
| | 02:50 | You probably won't need a control viewport
height all that often, but you should know
| | 02:54 | that the capability exists if you need it.
| | 02:57 | You can also set the initial scale
value for the property's content as well.
| | 03:02 | It's easy to get this property confused with
viewport width, so let's talk about exactly what it does.
| | 03:08 | Initial scale controls the zoom factor of
your content for the initial view of the page.
| | 03:15 | Once the page has been viewed, the user is then
free to scale the page at any factor they want.
| | 03:20 | Now, it's important to note that this
is independent of the viewport width.
| | 03:25 | So if the initial scale is set to 2,
for example, notice that our content is now scaled
| | 03:31 | up to 200%, even though the width
of the viewport remains unchanged.
| | 03:38 | Setting the initial scale to 1 ensures
that the content appears at 100%, regardless of
| | 03:43 | the viewport width.
| | 03:45 | It's quite common to see people set width
to device width and then also set initial
| | 03:50 | scale to 1, but in reality
that's not really necessary.
| | 03:54 | If you set the viewport width to the device width,
the browser automatically sets initial scale to 100%.
| | 03:59 | In fact, on iOS devices, there's a bug
with initial scale that affects pages when the
| | 04:05 | orientation changes,
| | 04:07 | so many people advise leaving initial scale
off entirely unless you need to set the value
| | 04:12 | to something other than 100%.
| | 04:14 | In terms of syntax, notice that you use an
integer to set the scaling factor and that
| | 04:19 | meta viewport tags use the initial
scale property, while @viewport uses zoom.
| | 04:25 | The @viewport syntax currently also allows
a percentage value as well, but since that
| | 04:30 | may change in the future,
you're safer just using a number.
| | 04:34 | You can also control the range of
scaling allowed by your site as well.
| | 04:38 | Let's say you want to allow people to zoom
in and out on your page content, but you do
| | 04:42 | want to control just how
much zooming they can do.
| | 04:46 | By using the minimum and maximum
scale properties, you can do just that.
| | 04:49 | Now, in this example I've set it up so that the
minimum scaling is 1 and the maximum scaling is 2.
| | 04:57 | Notice that the user can scale up to
200% but can't scale down pass 100%.
| | 05:04 | In terms of syntax, there is a little bit
of difference between the meta viewport tag
| | 05:08 | and the @viewport syntax.
| | 05:10 | In the meta viewport tag, you'll use the
minimum and maximum scale properties and a positive
| | 05:15 | numeric value, which
indicates the scaling factor.
| | 05:19 | In the @viewport syntax, you'll use the minimum
and maximum zoom properties, and can use either
| | 05:24 | a positive number or a percentage value.
| | 05:27 | If you wish, you can turn scaling off
entirely by using the user-scalable property.
| | 05:32 | This allows you to either enable or
disable user's ability to zoom in and out on your
| | 05:37 | page content, and is more commonly used
actually for applications than websites.
| | 05:42 | For the meta tag syntax, you'll use user-
scalable and values of either yes or no, and for
| | 05:48 | @viewport, you'll use the user-zoom property
which will accept either the zoom or fixed values.
| | 05:56 | Keep in mind that users are accustomed to
having the ability to zoom in and out of web content.
| | 06:01 | If you disable this for your site, you should
have a clear and compelling reason to do so.
| | 06:06 | These are just a few of the properties you can
control when overriding a browser's default viewport.
| | 06:11 | For a complete list of properties and for
more information on the syntax, visit the
| | 06:16 | Safari HTML Reference page for the viewport
meta tag syntax or the CSS device adaptation
| | 06:23 | specification for more
information on the @viewport rule.
| | 06:26 | Now, it's important to note that support
for the meta viewport tag is almost universal,
| | 06:32 | while the @viewport syntax is still
relatively new and largely unsupported for now.
| | 06:37 | Existing support for the @viewport rule is
also largely restricted to using vendor prefixes,
| | 06:42 | so you'll need to be mindful of
that if you choose to use that syntax.
| | 06:46 | Adoption of @viewport is happening fairly
rapidly, and the specification is maturing,
| | 06:51 | so I expect we'll see full
support for it in the very near future.
| | 06:55 | Once this happens, we'll be able to choose
exactly how we want to control user agent's
| | 06:59 | viewports when creating responsive designs.
| | 07:02 |
| | Collapse this transcript |
| Understanding screen densities| 00:00 | In addition to the increased diversity of
screen sizes, you'll also need to deal with
| | 00:04 | the growing issue of screen densities.
| | 00:08 | Screen density is the number of
pixels within a physical area of a screen,
| | 00:12 | and newer screens are featuring higher
and higher screen densities every year.
| | 00:18 | Take these two iPhones for example.
| | 00:20 | This one is the older 3G model,
while this is the newer 4S.
| | 00:25 | The 3G has a screen resolution of
320 pixels x 480 pixels, while the 4S has a resolution
| | 00:34 | of 640 pixels x 960 pixels.
| | 00:38 | Now, they both have the
same size screen, at 3.5 inches,
| | 00:42 | so in order to have a higher resolution,
the 4S has to have a greater number of pixels.
| | 00:49 | Now, that sounds pretty straightforward,
but it actually causes a number of issues
| | 00:54 | that you have to understand when
designing for higher-density screens.
| | 00:59 | The first issue is properly defining what
exactly a pixel is when you're dealing with
| | 01:04 | higher-density screens.
| | 01:05 | Now, if you've been designing for any time at
all, you probably think you've got a pretty
| | 01:09 | good handle of what exactly a pixel is, but
for screen density, we actually need to focus
| | 01:15 | on two types of pixels:
hardware pixels and reference pixels.
| | 01:21 | Hardware pixels are pretty straightforward.
| | 01:24 | Let's zoom in on an older lower-density screen.
| | 01:27 | Here you can see the
individual pixels themselves.
| | 01:31 | These are hardware pixels, and they represent
the smallest points the screen can display.
| | 01:36 | If we look at the same cross-section of a
higher-density screen, you can see that in
| | 01:41 | this example the number of hardware pixels
are doubled, allowing the screen to display
| | 01:46 | finer detail within the same dimensions.
| | 01:49 | However, this increase
causes unintended side effects.
| | 01:53 | Let's say you had a line of text that was
30 pixels high on a lower-density screen.
| | 01:59 | The same text mapped to the higher-
density screen would now appear twice as small.
| | 02:05 | That means without accounting for this difference,
graphics and websites would appear dramatically
| | 02:10 | smaller on newer higher-density displays.
| | 02:14 | That's where reference pixels come in.
| | 02:16 | A reference pixel, sometimes referred to
as a CSS pixel, is a unit of measurement that
| | 02:22 | establishes an optical standard for the length of a
pixel and is totally independent of hardware pixels.
| | 02:29 | In the W3 standard for CSS, this unit is
described as roughly 196th of an inch, depending on the
| | 02:36 | ideal distance from the viewer.
| | 02:39 | Although the definition may vary from
platform to platform, the concept is the same.
| | 02:43 | The reference pixel gives you a way to
consistently set the size of elements that is independent
| | 02:49 | from the actual screen density.
| | 02:52 | Okay, so let's go back to our pixel example.
| | 02:54 | If you've specified that an element be 50
pixels wide, it might map to the first screen
| | 03:00 | at exactly 50 pixels if the hardware
and reference pixels were the same.
| | 03:06 | On a higher-density screen, however,
the device would actually display the same element over
| | 03:11 | 100 hardware pixels to ensure
that it remains the same visual size.
| | 03:17 | It does this by applying a
scaling factor to the page elements.
| | 03:21 | This scaling factor is often referred to as
device-pixel-ratio--that is, the ratio between
| | 03:28 | reference pixels and hardware pixels.
| | 03:31 | Knowing the proper ratio is crucial for targeting and
properly preparing graphics for higher-density screens.
| | 03:38 | To see how this is taking shape across
manufacturers, let's take a moment to look at the Mobile
| | 03:43 | Matrices page created by the nice
people over at the mobile-boilerplate.
| | 03:48 | Here we can see the listing of several mobile devices and
their screen size, resolution, and screen density.
| | 03:55 | If we compare the older iPhone and iPads to
the newer ones, we can see that the screen
| | 03:59 | densities are exactly double, which means the
device-pixel-ratio for the new Retina displays is 2.
| | 04:05 | When we take a look at Android devices,
however, the ratios get a bit more complicated.
| | 04:11 | There are so many manufacturers working
with different screen densities that you can't
| | 04:16 | assume a specific device-pixel-ratio
for targeting higher-density screens.
| | 04:21 | In fact, Android uses four basic device-pixel
ratios. These are low density, or .75 for screens
| | 04:30 | lower than 120 pixels; medium density, which
is considered the baseline at 1 for screens
| | 04:36 | up to 160 pixels; high density at 1.5, for
screens up to 240 pixels; and then extra high
| | 04:42 | density at 2, for screens up to 320 pixels.
| | 04:48 | Higher screen densities aren't
just limited to mobile devices either.
| | 04:51 | Apple recently introduced a new MacBook Pro
that has a screen density of 220 pixels, which
| | 04:58 | is twice its other models, giving it
a pixel-density-ratio of 2 as well.
| | 05:03 | Okay, so now we know what screen density is
and how hardware pixels relate it to reference
| | 05:08 | pixels, but what does it
mean to you in the real world?
| | 05:12 | Well, in many cases, you
won't need to do anything at all.
| | 05:16 | For text in CSS-generated graphics,
the device will handle the scaling itself and use the
| | 05:21 | extra hardware pixels to make
everything look clearer and sharper.
| | 05:24 | For images, however, it can be a bit of an issue.
| | 05:28 | Take a look at these two screens.
| | 05:30 | On the left, you'll see an older iPad and on
the right, a newer model with a Retina display.
| | 05:37 | Although the top image doesn't look too bad
on either of them, the Retina display does
| | 05:41 | look a little blurry.
| | 05:43 | Notice that when I scale up on the Retina display,
you can clearly see the degradation of image quality.
| | 05:49 | The scaling factors involved in higher-density
screens can often actually harm image quality
| | 05:54 | as they are scaling images up by default.
| | 05:57 | If I compare it to the bottom image, which
is a higher-resolution version of the first
| | 06:02 | graphic, you can see that there's a
clear difference in image quality.
| | 06:06 | When building responsive sites,
you'll need to decide whether or not you also want to
| | 06:10 | supply larger images for higher-density screens.
| | 06:13 | The methods behind doing this, and the
factors that you need to consider when making those
| | 06:17 | decisions, are considerable,
so we'll tackle them next.
| | 06:20 |
| | Collapse this transcript |
| Designing for multiple screen densities| 00:00 | Now that we've discussed what screen densities
are and the issues surrounding higher-resolutions
| | 00:05 | screens, let's talk about ways we can
optimize graphics for higher-density displays.
| | 00:11 | One of the first things you can do is to simply
consider minimizing the amount of bitmapped graphics you use.
| | 00:17 | If you use vector image formats like SVG,
or use CSS in place of simple graphics, many
| | 00:23 | of the issues with scaling factors will go away.
| | 00:27 | Vector graphics are resolution-independent
and scale without any loss of image quality.
| | 00:32 | Likewise, CSS-based graphics for simple icons
and buttons will scale to any size and maintain
| | 00:38 | the same sharpness and clarity.
| | 00:40 | Even on lower-density mobile
screens, scaling is a way of life.
| | 00:44 | It's very common for users to zoom in on
page regions, so it's a good idea to try to make
| | 00:48 | your content as scalable as you can.
| | 00:51 | Of course, these approaches
are not without their drawbacks.
| | 00:54 | SVG images can be considerably larger than
their bitmap counterparts, and vector graphics
| | 00:59 | are redrawn with each pan and zoom.
| | 01:02 | Both of those issues can
impact performance considerably.
| | 01:06 | Likewise, drawing with CSS can be effective,
but you need to be aware of its limitations.
| | 01:12 | Complex artwork is often out of the range
of its capabilities, and often non-semantic
| | 01:16 | markup is required to achieve the desired
results. Support for CSS properties like CSS
| | 01:22 | transform aren't uniform yet either,
| | 01:24 | so make sure that any graphics created with
CSS uses properties that are well supported.
| | 01:30 | You can also use icon fonts.
| | 01:33 | Icon fonts are fonts
populated with, you guessed it, icons.
| | 01:37 | This for example, is Modern Pictograms,
which is available here at fontsquirrel.com.
| | 01:42 | The great thing about these icons is that they
are easy to size and they scale automatically
| | 01:47 | with your site's text.
| | 01:49 | Unless you use generated content, however,
you have to include unnecessary characters
| | 01:54 | in your markup, which could be
confusing from an accessibility standpoint.
| | 01:59 | Regardless, there will be times when
raster graphics are the appropriate choice.
| | 02:04 | For raster graphics, you have a few
options when targeting high-density screens.
| | 02:08 | The basic idea is this: if you need an
image to be 100 pixels x 100 pixels, you simply
| | 02:14 | create the image at the scaling factor
that's appropriate for the targeted screen.
| | 02:19 | For example, an iOS device with a Retina
display has a scaling factor of 2, so you'd create
| | 02:25 | the image at 200 pixels x 200 pixels.
| | 02:28 | It's important to note
here that DPI does not matter;
| | 02:31 | it's only about the physical amount of pixels.
| | 02:34 | Now when targeting the high-density screen,
you use the high-res image and then resize
| | 02:39 | it to the desired 100 pixels x 100 pixels size.
| | 02:43 | Because of the default scaling factor,
the additional pixels will map to hardware
| | 02:47 | pixels, which will give you a much
sharper and more detailed image.
| | 02:50 | While this technique is relatively simple,
actually targeting high-density displays can be a bit trickier.
| | 02:57 | One solution is to simply not target them
at all and use high-res graphics wherever
| | 03:02 | you feel they're appropriate.
| | 03:03 | Lower-density screens will still display
them just fine, and in fact, you'll probably see
| | 03:08 | improved image quality due to the scaling
factors involved with lower-density screens as well.
| | 03:13 | The downside to this approach is that these
higher-resolution graphics are larger in size,
| | 03:19 | meaning that you are asking for some of your
users to download larger images than they really need.
| | 03:24 | You also have the issue of
the scaling factors themselves.
| | 03:27 | Not every high-density screen
uses the same device-pixel ratio,
| | 03:30 | so you'd have to account for the largest size
needed, which again leads to unnecessary file
| | 03:35 | sizes in most instances.
| | 03:38 | If you want to target the devices
themselves, you have two main options at present.
| | 03:42 | First, if you are targeting CSS background
images, you can use media queries to target
| | 03:48 | specific device-pixel-ratios.
| | 03:50 | Then you simply change out the image for the
high-res version and use the background size
| | 03:55 | property to properly size the image.
| | 03:58 | The issue here is that support for device-pixel-
ratio isn't even across platforms, and it currently
| | 04:03 | requires vendor prefixes.
| | 04:05 | You're also limited to background images,
meaning that context-based images using the
| | 04:10 | image tag can't be swapped using this technique.
| | 04:13 | To do that, you'll need JavaScript.
| | 04:16 | Using JavaScript, you can query a user
agent's device-pixel-ratio and then pass a request
| | 04:21 | to use the higher-res
images over the lower-res images.
| | 04:24 | You have to be careful here, in that you don't
want user agents to download unneeded assets,
| | 04:29 | so writing the script so that it controls
resource loading properly is very important.
| | 04:35 | In the end, you'll need to consider carefully
whether using high-res images is appropriate
| | 04:39 | at all. And perhaps one of the
biggest pieces of irony in web history,
| | 04:44 | mobile devices, which have the most unreliable
network connections and data plans that often
| | 04:49 | charge by the amount of data being used,
now feature the highest-resolution screens requiring
| | 04:54 | the biggest images to take advantage of them.
| | 04:57 | You need to think carefully about who your
users are, the context in which the images
| | 05:02 | are being used, and whether or not it's
appropriate to serve high-resolution images for the site.
| | 05:07 | Of course, screens continue to evolve,
and high-density screens are finding their way
| | 05:12 | to more than just phones and tablets.
| | 05:14 | It won't be long before these screens are
the dominant displays across all devices.
| | 05:19 | Because of this, having the ability to properly
target screen density and then serve the proper
| | 05:24 | assets is crucially important to web authors.
| | 05:27 | There are currently a number of browser developers
and standards writers working on this issue right now,
| | 05:32 | so pay careful attention to how HTML and
CSS change to provide this functionality.
| | 05:38 | One day soon, we'll have syntax in place that
allows us to specify which assets to use for
| | 05:43 | which device and how bandwidth
might play a role in that selection.
| | 05:48 | Currently, however, we'll need to make do
the best we can using the techniques that are
| | 05:52 | available to us now.
| | 05:54 | That means that as a designer, you'll have
to carefully consider all of your options
| | 05:58 | when designing for multiple screen densities.
| | 06:00 |
| | Collapse this transcript |
| Understanding media queries| 00:00 | Media queries are an important part of
responsive design, as they allow you to write styles that
| | 00:05 | respond to changes in things
like screen size or orientation.
| | 00:10 | They're not really a new feature of CSS, but
rather, an extension of the existing media declarations.
| | 00:17 | Through media declarations, CSS has allowed
us to filter style application by media type
| | 00:21 | for quite some time now.
| | 00:23 | In the past, we have been able to define
which styles apply to screen devices, projectors,
| | 00:27 | printers, and handheld devices
through some pretty basic syntax.
| | 00:32 | While these capabilities were extremely handy
in making sure that you could write separate
| | 00:35 | style sheets for screen and print, they never
really realized their ultimate goal of defining
| | 00:41 | multiple device types.
| | 00:43 | Mobile manufacturers for the most part,
shunned the handheld media type due to its limited
| | 00:48 | use and their desire to give
users the full web experience.
| | 00:53 | That left a huge gap, in terms of a
designer's ability to write styles that changed based
| | 00:58 | on the type of device being used.
| | 01:01 | To fill that gap, media queries were created to
allow designers to extend the media declarations
| | 01:06 | to include various media
properties when filtering style application.
| | 01:11 | This is actually incredibly more useful,
as it allows designers to control styling based
| | 01:16 | on factors such as screen size,
orientation, or color, which is far more flexible than
| | 01:21 | simply defining a device type.
| | 01:24 | Let's take a quick look at
the syntax and how it works.
| | 01:27 | Media queries contain a media
type and one or more expressions.
| | 01:32 | These expressions contain media features,
which are then evaluated and used to determine whether
| | 01:38 | styles are applied or not.
| | 01:41 | Keywords such as "and," "not," or "only," help
you refine exactly when styles are applied.
| | 01:49 | Not negates the expressions that follow it
and applies the styles only if the conditions
| | 01:54 | that follow it are not met.
| | 01:57 | Only can be used to detect for media query
support, as older user agents that don't support
| | 02:03 | them will ignore any media
declarations that begin with only.
| | 02:07 | The and keyword allows you to join expressions
together, further filtering when styles will be applied.
| | 02:13 | You can also comma-separate a list of media
queries, which is very much treated like the
| | 02:18 | or logical operator.
| | 02:20 | In this case, if one of the expressions
returns true, the entire list is applied.
| | 02:26 | We also have a very diverse
group of media features to test for.
| | 02:30 | We have width, height, device-width, device-height,
orientation, aspect-ratio, device-aspect ratio,
| | 02:39 | color, color index, monochrome,
resolution, scan, and grid.
| | 02:46 | As you can see, some of the features
also accept a minimum or a maximum prefix.
| | 02:52 | This allows much more flexibility, as you can
check for a minimum height or a maximum width
| | 02:57 | instead of a fixed value.
| | 02:59 | Media queries can also be
used in several different places.
| | 03:02 | Depending upon how you access your styles
within your sites, it's helpful to know some
| | 03:06 | of the variations on media query syntax.
| | 03:09 | If you're using a link tag to access external
styles, this syntax that I've been using here is fine.
| | 03:16 | If you're creating modular style sheets
and using @import to bring in external styles
| | 03:20 | within style sheets, you'll want to modify
@import to include a media query as you see here.
| | 03:26 | You can also apply media queries
within the style sheets themselves.
| | 03:30 | By using an @media block to surround styles, you can
filter how styles within style sheets apply as well.
| | 03:37 | I also want to mention that if you
don't declare a media type, all is assumed.
| | 03:42 | So if you're filtering results to apply to
all media types, you can simply exclude the
| | 03:46 | media type and the remainder of
the syntax will still work just fine.
| | 03:51 | To learn more about media query syntax, be sure to
check out the media queries specification on the W3C site.
| | 03:58 | As you see here, you can go
to w3.org/TR/css3-mediaqueries.
| | 04:07 | So, when can you actually
start using media queries?
| | 04:09 | Well, right away, especially if
you are working on mobile devices.
| | 04:13 | Most modern browsers and mobile platforms
support media queries, and using scripts such
| | 04:19 | as Scott Jehl's Respond.js can help add support
for older versions of Internet Explorer. Okay.
| | 04:27 | So now that you know a little bit about
media queries and what they can do for you, it's
| | 04:31 | important to see how they work
when building responsive designs.
| | 04:34 | We will tackle that in our next movie.
| | 04:36 |
| | Collapse this transcript |
| Creating breakpoints with media queries| 00:00 | Now that we know a little bit more about
media queries, we need to take a closer look at
| | 00:05 | how they're implemented in a
responsive design workflow.
| | 00:08 | We'll start by exploring
the concept of a breakpoint.
| | 00:12 | A breakpoint indicates the moment your
layout switches from one layout to another, and is
| | 00:17 | usually triggered by the width
of a screen. Take this example.
| | 00:21 | When I resize the screen, you can see the
containing block changes both size and color
| | 00:27 | when the viewport reaches a certain size.
| | 00:29 | The screen sizes are based on the typical screen
sizes for smartphones, tablets, and desktop devices.
| | 00:37 | While many layouts will have more than these
three basic breakpoints, almost all responsive
| | 00:41 | designs will feature some
combination of those three screen size ranges.
| | 00:47 | This means that one of the first things
that you need to do when planning a responsive
| | 00:50 | design is define the
breakpoints for your layout.
| | 00:54 | Here you see a list of three
of the most common breakpoints.
| | 00:58 | Mobile styles will target any screen
smaller than 480 pixels wide, while tablet styles
| | 01:04 | will usually target screens
between 481 and 768 pixels.
| | 01:09 | Desktop styles, on the other hand, will
target any screen wider than 768 pixels.
| | 01:15 | Obviously, all tablets and smartphones
aren't the same size, so you'll need to determine
| | 01:20 | which range of screen
widths you will want to support.
| | 01:23 | Those measurements are widely
used and are a great way to start.
| | 01:27 | Once you have your breakpoints, you'll need
to then define your media queries to filter
| | 01:31 | style application based on your target sizes.
| | 01:35 | Here you see three media queries
that target our sample breakpoints.
| | 01:39 | Although there are variations on the syntax
you can use, I want to walk through the syntax
| | 01:43 | that's being used here to
explain how breakpoints are being set.
| | 01:47 | Note that each of the media queries uses the
only keyword, which hide the styles from older
| | 01:53 | non-conforming user agents.
| | 01:55 | Because of this, you will want to have
a set of default styles to fall back on.
| | 02:00 | The screen media types ensure that the
styles apply to screen-based devices.
| | 02:05 | The mobile media query uses the maximum-width
media property to restrict styles to screens
| | 02:10 | under 481 pixels, which should target
the majority of smartphone devices.
| | 02:16 | The tablet media query uses slightly longer
syntax, by combining both a minimum and a maximum-width
| | 02:22 | media property to define a
specific range of screen sizes.
| | 02:27 | Essentially, this targets any
screens between 481 to 768 pixels.
| | 02:33 | Note that the minimum-width value
is one pixel over the smartphone query.
| | 02:37 | You want to make sure there is no overlap as
you plan your breakpoints which could cause
| | 02:42 | some cascading issues within your styles.
| | 02:44 | Finally, the desktop media query simply
targets any screen size over 768 pixels.
| | 02:51 | Notice that all three of these media queries
are using the width property with a minimum
| | 02:56 | or a maximum prefix.
| | 02:58 | Although device-width is also an
option, width is slightly more flexible.
| | 03:03 | Device-width is equal to the available
pixels on the device itself, whereas width simply
| | 03:09 | refers to the width of the viewport.
| | 03:11 | This means that any resizing that's done to
the viewport will actually trigger media queries
| | 03:16 | if you're using width.
| | 03:17 | Plus, there are inconsistencies in how devices
report device-width, which makes width a slightly
| | 03:23 | more stable choice.
| | 03:25 | You have probably noticed that in each of
these media queries, I've got a very simple
| | 03:29 | CSS rule that changes the background color
and some other properties for this paragraph.
| | 03:34 | Now, to see these in action, all I
need to do is resize my browser window.
| | 03:39 | Each time the width of the screen hits a
breakpoint, the background color of the text changes.
| | 03:45 | If we view this page on a tablet and a
smartphone, you can see the appropriate media query is
| | 03:50 | triggered and the
expected properties are applied.
| | 03:52 | Of course, to create a responsive design,
the CSS required for each media query will
| | 03:57 | be a little bit more complex and usually
feature layout styles based on a fluid grid that is
| | 04:02 | specific for each breakpoint.
| | 04:04 | I should also point out that there is a
growing movement among responsive designers to set
| | 04:09 | breakpoints using ems instead of pixels.
| | 04:12 | By using ems, the width of the screen is
set relative to the device's font size.
| | 04:16 | Here for example, we could change this media
query from pixels to ems by dividing the width
| | 04:21 | of 480 pixels by 16 pixels and
setting that to the resulting 30 ems.
| | 04:28 | Since the average device font size is 16 pixels,
this is usually a good place to start from.
| | 04:33 | While this requires us to do a little math
on the front end, we now have a responsive
| | 04:37 | design that responds not only to the
screen's width but also user's zooming as well.
| | 04:42 | While creating breakpoints with media
queries is an important part of responsive design,
| | 04:46 | it's only the first step to
creating responsive layouts.
| | 04:49 | To create a layout that's truly responsive,
you'll need to combine these breakpoints with
| | 04:54 | fluid grids, which we'll discuss next.
| | 04:56 |
| | Collapse this transcript |
| Using fluid grids| 00:00 | One of the most famous observations about
responsive design is that it's becoming more
| | 00:05 | and more important to think
of your content like water.
| | 00:09 | It needs to have the ability to flow
into whatever container it's viewed on.
| | 00:14 | If you limit yourself to creating fixed
layouts for each of your breakpoints, you're ignoring
| | 00:19 | the wide variety of
screen sizes within each range.
| | 00:22 | One of the best ways to make sure your content
works, regardless of the screens being viewed
| | 00:27 | on, is to use a fluid layout so that your
content can flex and resize within each of
| | 00:33 | your set breakpoints.
| | 00:35 | As you can imagine, creating separate fluid
layouts for each breakpoint creates considerably
| | 00:40 | more work than crafting a single
fluid layout or separate fixed layouts.
| | 00:46 | For this reason, many designers have adopted
the use of fluid grids to make crafting multiple
| | 00:50 | layouts faster and more precise.
| | 00:53 | Grid systems are a fantastic way of
creating structured, properly proportioned layouts
| | 00:58 | and have been used by designers for
decades across multiple disciplines.
| | 01:03 | For a web design, grids are typically defined
as a number of columns and gutters that are
| | 01:08 | then used by the designer to establish
the widths of page elements and regions.
| | 01:13 | The exact number of columns and their base
width is typically up to the designer, and
| | 01:17 | is usually related to a default font size,
ideal ratio, or an ideal screen width.
| | 01:23 | Many designers will use a 16-pixel-based grid as
that's the default font size for most browsers,
| | 01:29 | or will use a base value that
divides into their ideal layout width.
| | 01:35 | Although the most popular currently is 960
pixels, many designers are moving to grids
| | 01:40 | based off of larger ideal screen
sizes, such as a thousand pixels.
| | 01:44 | Once the grid is established,
page elements are mapped to grid coordinates and values
| | 01:50 | are assigned based on
where they fit within the grid.
| | 01:54 | To make the grid fluid, you would simply
use either relative units of measurement, like
| | 01:58 | ems, or percentage values for the
width of the columns and gutters.
| | 02:03 | Grid frameworks can be built to use a
single grid with enough columns to handle various
| | 02:07 | screen widths or they could
feature multiple sets of fluid grids,
| | 02:11 | each one optimized around a specific breakpoint.
| | 02:14 | Typically, in a multiple set framework,
the number of columns increases as screen sizes
| | 02:20 | get wider and the width of the gutters change to
maintain spatial relationships at each breakpoint.
| | 02:26 | Regardless of the approach taken in
constructing the grid system, it's usually built with an
| | 02:30 | array of classes that define the number of
columns that an element should span, any floating
| | 02:35 | or positioning requirements, and
the desired padding in margin values.
| | 02:40 | Additional classes are used to clear floats,
define containing elements, and handle any
| | 02:45 | additional layout requirements.
| | 02:47 | Once the framework is built, creating
the actual layout becomes fairly simple: based on the
| | 02:52 | desired layout, you simply add the
appropriate classes to the appropriate page element.
| | 02:57 | As you could imagine, building this type
of grid framework requires a lot of work.
| | 03:01 | I'm sure by now you've probably
wondered if all that work is really necessary.
| | 03:05 | Well, remember that each project is
different, and you can certainly do this by degrees.
| | 03:10 | If you're design is relatively simple and
unlikely to change frequently, it might be
| | 03:14 | more efficient to simply create layouts for each
breakpoint that's tailored for specific screen ranges.
| | 03:20 | If your layouts are more complex or have a
wide range of variations in terms of page
| | 03:24 | types, it's probably worth it to take the time to
craft a framework around your site's specific needs.
| | 03:30 | Once the framework is built, it dramatically
speeds up development time and makes it extremely
| | 03:35 | easy to test and prototype layout variations.
| | 03:39 | Perhaps the best thing about building this type of
framework is that you can use it again and again.
| | 03:43 | Once built, creating flexible page layouts across
multiple screen sizes becomes much, much simpler.
| | 03:50 | If you simply don't have the time to
construct your own fluid grid system or feel that
| | 03:54 | your technical skills aren't quite at that
level yet, I'm happy to tell you that there
| | 03:57 | are a multitude of existing frameworks that you
can download and use within your own projects.
| | 04:02 | These frameworks range from the very simple
layout-only styles to entire boilerplates
| | 04:07 | that come with a mixture of HTML, CSS, and JavaScript
that provide a full framework for site development.
| | 04:14 | Which framework is right for you is largely
a personal decision and likely to be impacted
| | 04:18 | heavily by the goals of individual projects.
| | 04:20 | The good news is you have a
lot of options to choose from.
| | 04:23 | Of course, there are some
downsides to using fluid grids.
| | 04:27 | The styles are heavily class-based and usually use
non-semantic class names that can clutter up your HTML.
| | 04:34 | Some require specific containing and clearing
elements that may force you to include additional
| | 04:38 | markup to your HTML as well.
| | 04:41 | Most of these frameworks
are fairly large in size, too.
| | 04:44 | Since it's doubtful that you'll ever use every
layout option a grid framework might contain,
| | 04:48 | you could be including a significant amount of
code in your projects that you don't really need.
| | 04:54 | Whether you use an existing framework or
build your own, it's certainly worth your time to
| | 04:57 | download and explore a few of them, just to
see how different developers have approached
| | 05:01 | building fluid grids.
| | 05:04 | If you're new to CSS and need more
information on the basics of building fluid layouts, be
| | 05:08 | sure to check out my CSS: Page Layouts
title in the lynda.com online training library.
| | 05:14 |
| | Collapse this transcript |
| Making images responsive| 00:00 | Using fluid layouts ensures that as screen
sizes or orientations change, content will
| | 00:06 | reflow, or reconfigure along with it.
| | 00:09 | That works seamlessly for contents such as
text which naturally reflows along with its
| | 00:14 | containing element,
| | 00:15 | but what about content that is by default
defined at a fixed size, such as images or other media?
| | 00:22 | An image designed for a large desktop
monitor is unlikely to fit into a layout designed
| | 00:27 | for a 320-pixel-wide smartphone.
| | 00:30 | Likewise, images designed to accompany
content on a mobile screen would probably look like
| | 00:35 | thumbnails when viewed within desktop layouts.
| | 00:39 | This means that in the best of circumstances,
these images will look out of context and
| | 00:43 | in many cases, will break your
carefully crafted responsive layouts.
| | 00:48 | This problem underscores how important it is to
find ways to make images and other media responsive.
| | 00:54 | At first glance, you'd probably be tempted
to say the solution is pretty simple: just
| | 00:59 | replace the fixed dimensions with relative
measurements or percentages and then boom,
| | 01:04 | flexible responsive images.
| | 01:06 | Well, unfortunately, it's just not that simple.
| | 01:09 | Matt Wilcox recently called the issue
surprisingly complex, and I'm inclined to agree with him.
| | 01:16 | Currently, if you want to make images
responsive, you do have a couple of options.
| | 01:20 | First, you could simply do what we
discussed earlier: replace the fixed dimensions with
| | 01:25 | percentages or relative units.
| | 01:27 | You can even add a maximum-width property to
avoid scaling the image past its original size.
| | 01:33 | To make the math of calculating image
proportions a bit easier, you could also place the image
| | 01:38 | in a flexible container and simply use a
max-width equals 100% property to constrain the image
| | 01:45 | to the size of its container.
| | 01:48 | Since this works with any element, you could
use this with other fixed media assets such
| | 01:52 | as Flash or video as well.
| | 01:54 | Well, that sounds easy enough and it seems to work,
so what are some of the issues with this technique?
| | 02:00 | Well, Internet Explorer
doesn't support maximum-width,
| | 02:03 | meaning you'll have to use a
workaround to achieve the same effect.
| | 02:06 | Also, you have to be careful when
mixing width and maximum-width properties.
| | 02:11 | The width property explicitly sets the
width of the element, while maximum-width tells
| | 02:16 | the element not to exceed a specific width.
| | 02:19 | Those are not the same thing.
| | 02:22 | Perhaps the biggest issue with
this technique is one of size.
| | 02:26 | Since you never want to scale images up and
damage the image quality, you'll need to supply
| | 02:30 | the largest image size that
your layouts might require.
| | 02:34 | This means that you'll be asking mobile
devices to download larger images than they need and
| | 02:38 | then scale the images within the browser.
| | 02:41 | Both of these actions will harm performance
on mobile devices and are less than ideal.
| | 02:45 | If the image is purely decorative and not
really necessary to the structure of the page,
| | 02:50 | you could serve the image as a background image.
| | 02:53 | By doing that, you could place requests for
separate background images in each media query,
| | 02:59 | ensuring that you're requesting only the
image that you need for the proper device.
| | 03:04 | This allows you to not only control the
image's size, but also the image's context.
| | 03:09 | If you're scaling an image down with a lot
of detail, for example, that detail will often
| | 03:13 | get lost as the image gets smaller.
| | 03:16 | By serving a separate image for smaller layouts,
you can crop the image or modify it to convey
| | 03:22 | the right visuals for the appropriate space.
| | 03:24 | In many cases, this solution works great,
but it's not without its problems either.
| | 03:30 | It's limited in that it can only work for
images that don't need to be in the actual HTML.
| | 03:36 | For images where accessibility is required
or that fit within the context of the HTML,
| | 03:41 | this technique won't work.
| | 03:43 | It's also worth noting that in earlier
versions of Android, all of the CSS background images
| | 03:48 | would be downloaded, not just the ones
needed for the appropriate media query.
| | 03:52 | Now, this has since been fixed in Android,
but it will create large resource downloads
| | 03:57 | for users on older Android devices.
| | 04:00 | If you're looking for some more robust options,
there are a few solutions that have been created
| | 04:04 | to utilize JavaScript or server-side
scripting to examine the page, determine the context,
| | 04:10 | and then serve the appropriate image.
| | 04:13 | The Filament Group has a fantastic client-
side solution that they dubbed Responsive-Images,
| | 04:18 | and you can check that out
at their GitHub repository.
| | 04:21 | Essentially, you just modify your .htaccess
file, link to their responsive images JavaScript
| | 04:27 | file, and add a query string on any image that
requires a larger desktop version of that image.
| | 04:33 | The script will then parse the page and
replace the smaller images with the larger ones when
| | 04:38 | they're appropriate.
| | 04:40 | There are many solutions like this one that
have been developed over the last couple of
| | 04:43 | years, and most of them
share this basic approach:
| | 04:46 | have script determine the context, then
parse the page and serve the appropriate image.
| | 04:52 | As with our other techniques,
these solutions have their share of problems as well.
| | 04:56 | First, they're a little bit more
complex than a pure HTML or CSS solution.
| | 05:02 | The JavaScript parsing can slow load times,
and often replacement images are requested
| | 05:07 | after the original image is already downloaded.
| | 05:10 | That brings us to perhaps the biggest
downfall of these types of techniques, and that's the
| | 05:14 | evolution of browser prefetching.
| | 05:17 | In an attempt to speed up page loads,
browsers have begun to employ look-ahead prefetchers
| | 05:22 | to request and download page assets
before the HTML has finished loading.
| | 05:29 | This means that any technique that
attempts to parse the page and replace assets will
| | 05:34 | be replacing assets that, to some
degree, have already been downloaded.
| | 05:38 | Essentially, all this means that while we
do have some choices currently in making our
| | 05:42 | images work within responsive designs,
the current solutions are far from perfect.
| | 05:48 | In our next movie, I want to delve further
into the problems behind responsive images
| | 05:52 | and a few of the solutions that are on the
horizon that you'll need to keep an eye on.
| | 05:56 |
| | Collapse this transcript |
| Examining the future of responsive images| 00:00 | In the previous movie, we talked about some
of the current responsive image techniques
| | 00:05 | and why they are not entirely ideal solutions.
| | 00:07 | To gain a better understanding of why these
techniques fall short, it's helpful to list
| | 00:11 | out all of the things we need to be
able to do in regard to responsive images.
| | 00:17 | To truly have responsive images, we need
to have the ability to choose which image is
| | 00:21 | served to which device.
| | 00:23 | It's not enough to simply have an image
that scales down for smaller screens; rather, we
| | 00:28 | need to have the ability to make sure the
right image is served to the right context.
| | 00:33 | Currently, that's largely determined by three
factors: screen size, screen density, and bandwidth.
| | 00:40 | A screen that is 320 pixels wide is obviously
going to need a different set of images than
| | 00:45 | one that is, say, 1440 pixels wide.
| | 00:49 | Likewise, higher-density screens can
display much higher resolution images so it would
| | 00:54 | be nice to be able to serve high-res graphics
to displays they can take advantage of them.
| | 00:59 | In regards to latency and bandwidth,
obviously a larger image would be more of a burden over
| | 01:05 | slower connections, so it would also be nice
if we could substitute smaller low-res graphics
| | 01:11 | for those instances.
| | 01:12 | Unfortunately, when you look at these three
criteria side by side, it's obvious that in
| | 01:18 | many cases you're going
to have competing factors.
| | 01:21 | For example, in many cases mobile devices
are going to have lower bandwidth connections
| | 01:25 | or a higher degree of latency;
| | 01:27 | however, those devices are currently more
likely to have high-density screens than desktops.
| | 01:33 | To make matters worse, we need to
establish these factors and choose the proper image
| | 01:38 | before the request for page assets are made.
| | 01:41 | Since browsers are constantly looking for
ways to speed up page loading, techniques like
| | 01:45 | pre-fetching, which begins to download
resources before the HTML is fully loaded, are going
| | 01:51 | to make enabling
responsive images that much harder.
| | 01:55 | In fact, there are so many variables that go
in to establishing the proper image context
| | 02:01 | that the best solution is likely to be one
in which we give the user agent a number of
| | 02:06 | images to choose from and let it select
the proper one based on its current profile.
| | 02:12 | Thankfully, the browser development community
and the groups responsible for writing the
| | 02:16 | HTML and CSS specifications are aware of the
problem and how hard at work to solve it.
| | 02:22 | I want to discuss a few of the solutions that
have been proposed that you need to keep an eye on.
| | 02:27 | As solutions begin to be implemented,
you should be prepared to start experimenting
| | 02:31 | with them in your own workflow.
| | 02:33 | Recently, the WHTWQ, the organization behind
the HTML5 specification, proposed a modification
| | 02:39 | to the existing image element.
| | 02:41 | They proposed adding a
new attribute called srcset.
| | 02:45 | The proposed syntax would allow authors to
provide a comma-separated list of images and
| | 02:50 | related property such as viewport width,
height, and pixel density, that the user agent could
| | 02:56 | then use to determine which image to use.
| | 02:59 | The nice thing about this syntax is that
it's fairly straightforward and uncluttered,
| | 03:03 | it doesn't require any new HTML
elements, and it's backward-compatible.
| | 03:08 | User agents that don't understand srcset will
simply use the default source attributes image.
| | 03:14 | A competing proposal by the w3c's Responsive
Images community group is the picture element.
| | 03:21 | Picture would be a new HTML element
modeled after the HTML5 video element.
| | 03:26 | As you can see from the syntax, the picture
element acts as a parent for a range of source
| | 03:31 | elements and an image element.
| | 03:34 | Each source option can contain alternate images,
image properties, and optional media queries
| | 03:40 | for further filtering refinement.
| | 03:42 | You may have picked up on the fact that this
example has srcset as one of its source attributes.
| | 03:47 | Now, this is a result of an attempted
compromise between the WHTWG's srcset proposal and
| | 03:53 | the working groups picture proposal.
The user agent would choose from either the source
| | 03:57 | image that matches the current
conditions or use the default image tag.
| | 04:01 | Now, both picture and scrset have their
share of problems and currently, there is a very
| | 04:07 | vigorous debate going on among implementers as to
what the best approach of these two choices would be.
| | 04:13 | Since the syntax of both options continues
to change rapidly, my guess is that we'll
| | 04:18 | see a hybrid version of both, or maybe even
totally different solution that approaches
| | 04:23 | the problem from a different angle.
| | 04:25 | Other proposed solutions have included enhanced
meta tags or modifying http headers to contain
| | 04:31 | bandwidth and viewport dimensions.
| | 04:34 | To me, the issues surrounding responsive
images illustrate the fact that responsive design
| | 04:39 | is a totally new approach to designing websites.
| | 04:42 | And many aspects of it are still evolving.
| | 04:45 | As such, as a designer, you're going to need
to pay careful attention that how techniques
| | 04:49 | change and how implementations are carried
out so that you're prepared to adopt them
| | 04:54 | as they mature.
| | 04:55 |
| | Collapse this transcript |
| Building responsive forms| 00:00 | Responsive design isn't just about
modifying layouts to fit screen sizes.
| | 00:05 | To build truly responsive sites, you need
to think about the context in which the site
| | 00:09 | is being used and then try to tailor the
user experience to best suit that environment.
| | 00:15 | That's especially true for
site features such as forms.
| | 00:19 | Making sure your forms are clear and easy to fill
out is an important part of any good user experience.
| | 00:26 | Since form factors change from one device
to another, it can be challenging to build
| | 00:30 | forms that are equally effective across devices.
| | 00:34 | With that in mind, I want to go over a few
practices and techniques that you can use
| | 00:38 | to help make your forms more responsive.
| | 00:42 | As you might expect, you need to start the
process of building responsive forms during
| | 00:47 | the initial planning stages.
| | 00:49 | My recommendation is that you start by
considering the mobile context first.
| | 00:56 | Good mobile forms have reduced
clutter and focused form elements.
| | 01:00 | By thinking about how to build more streamlined
form that still captures what you need, you'll
| | 01:05 | eliminate extraneous form controls and
build a better overall user experience.
| | 01:11 | In fact, most of the recommendations that
I'm going to give here are centered on forms
| | 01:16 | and mobile devices.
| | 01:17 | That's because within the mobile context there
are usability considerations that users don't
| | 01:22 | really run into on desktop devices.
| | 01:25 | By keeping those considerations at the
forefront as you plan, you'll create better overall
| | 01:31 | forms and make it easier to
adapt your forms to mobile devices.
| | 01:36 | It probably goes without saying, but make
sure that you're structuring your forms so that
| | 01:40 | you can build responsive form layouts.
| | 01:43 | And for some reason, form layout is the one
aspect of page layout where tables just refuse
| | 01:48 | to die. Eliminate extraneous markup on your
forms and use structural elements like lists
| | 01:55 | and field sets to
properly mark up form structure.
| | 01:59 | This will make your forms cleaner in terms of
markup and easier to style with responsive layouts.
| | 02:05 | In terms of layout, think about how form designs
should change from one screen width to another.
| | 02:11 | It's perfectly acceptable to have labels
beside form elements for wider screens, but as the
| | 02:16 | screen sizes become smaller, you need to start
putting the labels on top of the input elements
| | 02:21 | to save screen real estate and
make your forms easier to read.
| | 02:26 | Make sure the color choices that you make
and how you organize form sections help guide
| | 02:30 | mobile users through your forms as well.
| | 02:33 | Keep in mind that on mobile screens, only a small
portion of your form will be visible at any given time.
| | 02:40 | By keeping this height constraint in mind,
you can group form elements in ways that guide
| | 02:44 | the user throughout the process.
| | 02:47 | This is especially important for longer forms.
| | 02:50 | Also, remember that smaller screen sizes are
primarily touch-enabled, so when laying out
| | 02:55 | form designs for smaller screens, make sure
that the form elements have enough distance
| | 03:00 | from each other to discourage the user from
accidentally focusing on the wrong element.
| | 03:06 | To that end, it's helpful to wrap input
elements with label tags rather than associating labels
| | 03:12 | with the for attribute.
| | 03:14 | By wrapping inputs with label tags, both the
input element and the label text become responsive
| | 03:20 | to clicking or touch, giving mobile users a
larger target region when activating form elements.
| | 03:27 | Speaking of form elements, make sure that
you're using the newer HTML5 form elements
| | 03:32 | and attributes when appropriate.
| | 03:35 | New input types, such as email, URL, and search,
not only add more semantic information about
| | 03:41 | the form element, but robust mobile support
for these elements aids user experience by
| | 03:46 | changing input controls
to reflect the input type.
| | 03:51 | Compare the keyboards displayed when
these two form elements are selected.
| | 03:57 | The first uses the email
type, while the second uses URL.
| | 04:03 | Each supplies the users with common email
and web address elements without making users
| | 04:09 | search for special characters.
| | 04:11 | Little things like this can go a long way
towards building better user experiences.
| | 04:16 | While it's a common practice on desktop
layouts to have descriptive text that guides users
| | 04:20 | in filling out the form, at smaller sizes, this
text becomes an impediment to accessing form elements.
| | 04:27 | Think about ways you can break this
information up or even remove it all together.
| | 04:32 | One way to reduce the amount of extraneous text
is to use placeholder data in your form elements.
| | 04:37 | This can be a great way to pass on useful
information and explain formatting guides
| | 04:41 | for information such as
addresses and phone numbers.
| | 04:45 | The HTML5 placeholder attribute is widely
supported among mobile browsers, so adding
| | 04:49 | it to your markup is another way to
create consistent form experiences.
| | 04:54 | Form validation is something you
want to plan very carefully as well.
| | 04:57 | For mobile users, client-side validation is
better, as it helps reduce the number of calls
| | 05:02 | made to the server and improves performance.
| | 05:05 | For simple validation, most mobile
browsers do support the HTML5 required attribute.
| | 05:11 | However, you're probably going to want to
give users more robust feedback than what's
| | 05:15 | provided by the user agent.
| | 05:17 | To that end, make sure that the form
validation feedback is succinct and displays in a way that
| | 05:23 | doesn't interrupt the flow of
the form or confuse the user.
| | 05:27 | Placing feedback directly underneath form
elements is a good choice for smaller screens.
| | 05:32 | You also want to make sure that
you're using the proper form element.
| | 05:35 | I know it sounds silly to say something like that, but you
have to think about what's appropriate given the context.
| | 05:42 | For mobile users, it's best to use form
elements that makes submitting data easier, automates
| | 05:47 | input when possible, and even combines form
elements to require less input from the user.
| | 05:53 | For example, rather than giving the user
three inputs to submit physical addresses, why not
| | 05:58 | combine them into a single input and then
use placeholder text to show how the address
| | 06:03 | should be formatted?
| | 06:04 | Instead of using a radio button grouping
of multiple choices, why not replace it with
| | 06:08 | a single dropdown menu?
| | 06:10 | Taking time to carefully plan how forms
will display on both desktop and mobile devices
| | 06:16 | will force you to make some difficult decisions.
| | 06:19 | That leads me to my final point.
| | 06:21 | In some cases, what works for one context
isn't going to necessarily work for another.
| | 06:26 | Often, you'll be able to use a combination
of media queries and JavaScript to modify
| | 06:31 | forms across devices, but there will be times
that creating separate forms from mobile devices
| | 06:36 | is the better option.
| | 06:38 | Just be sure to carefully consider user
requirements when designing forms and make sure that you're
| | 06:42 | providing users with the best
experience possible across devices.
| | 06:46 |
| | Collapse this transcript |
| Improving site performance| 00:00 | When building responsive designs, designers
often get so caught up with the visual design
| | 00:05 | and functionality of the site that they
overlook one of the most critical aspects of building
| | 00:09 | for multiple devices, and
that is site performance.
| | 00:14 | In designing for the desktop, we become
accustomed to creating sites that are built for high-
| | 00:18 | bandwidth consistent connections.
| | 00:20 | That's not the case with mobile devices,
where you have to deal with a totally different
| | 00:24 | set of performance issues.
| | 00:25 | Network connections and bandwidth speed can vary
wildly from user to user, or even during a single session.
| | 00:32 | Network latency can slow sites as well,
regardless of connection speeds, and user behaviors like
| | 00:38 | riding a train or getting into
an elevator can affect loading.
| | 00:42 | So, obviously, if you're going to design
across multiple devices and platform, performance
| | 00:47 | becomes a bigger concern.
| | 00:49 | There are many ways to improve performance,
but perhaps the most overlooked is also the most simple.
| | 00:55 | Be sure to keep your code as
lean and clutter-free as possible.
| | 00:59 | By using standards-compliant code,
eliminating extraneous markup, and keeping your external
| | 01:04 | scripts and styles as lean and efficient as
possible, you'll reduce page sizes and lower
| | 01:10 | the amount of time it takes to parse your code.
| | 01:13 | The result can be
dramatically faster loading times.
| | 01:16 | You also want to keep the HTTP
requests made by your site to a minimum.
| | 01:21 | Each time your site requests an image,
external CSS file, script, or any resource from the
| | 01:28 | server, it's an interaction
between the device and the server.
| | 01:32 | Over mobile connections, sites with a high
amount of server requests can be slowed down
| | 01:37 | significantly by network
latency and bandwidth speeds.
| | 01:41 | So how do you limit this requests?
| | 01:43 | Well, first make sure that you combine external style
sheets and scripts, when possible, into single documents.
| | 01:49 | If you are linking to four different style
sheets for desktop, tablet, smartphone, and
| | 01:54 | print styles, you're making four
separate HTTP requests for those resources.
| | 02:00 | Simply combine them into a single
style sheet using @media request.
| | 02:04 | Yes, the style sheet will be larger in size,
but you're always better off by downloading
| | 02:08 | a larger resource with fewer HTTP request.
| | 02:12 | Likewise, if you're linking to multiple external
scripts, try combining them into a single file.
| | 02:19 | And development-wise, this can be tricky,
but there are tools out there, like the Filament
| | 02:23 | Group's QuickConcat and Enhance.js, which can
combine files at runtime into single request.
| | 02:31 | You can also reduce requests by
modifying how you author your CSS.
| | 02:35 | If an image isn't needed within the context
of the content, meaning it's purely decorative,
| | 02:41 | change it to a background image and only
request it in the appropriate media query.
| | 02:46 | Not only will this prevent your full-screen
banner from downloading to mobile devices,
| | 02:50 | but it will eliminate the server request for it.
| | 02:53 | And often you can use styles to
eliminate certain requests altogether.
| | 02:58 | For example, by using gradients, rounded
corners, transforms, and other CSS3 techniques, you
| | 03:03 | can draw simple buttons and icons through CSS and
eliminate the need for images in those instances.
| | 03:10 | You can also combine images and icons into
sprites so that you're using the same image
| | 03:15 | for multiple icons and user interface elements.
| | 03:19 | This alone can save dozens of HTTP requests.
| | 03:23 | Using data URIs can lower the
amount of server requests as well.
| | 03:26 | A data URI allows you to embed images directly
into your CSS without having to request the
| | 03:32 | image from the server.
| | 03:34 | Now it adds a bit to your CSS code so
it's really only appropriate for smaller icons
| | 03:39 | and images, but it can be yet
another way to improve performance.
| | 03:44 | You should also evaluate any external resource
to make sure that you're actually using them.
| | 03:49 | For example, do users really need to download
the entire jQuery library to control something
| | 03:54 | you could write in just a
few lines of custom JavaScript?
| | 03:58 | You should always minify and compress external
resources, but it's also a good idea to evaluate
| | 04:03 | whether or not you really can eliminate
some of that redundant or unnecessary code.
| | 04:09 | It's also pretty common to use a JavaScript
library in one context but not the other.
| | 04:14 | For example, I might use the lettering.js
library to fine-tune my typography on a desktop
| | 04:20 | site, but not use it at all for my mobile app.
| | 04:23 | Well, if that's the case,
why make mobile users download it?
| | 04:26 | What all these really boils down to is that
you need to spend a fair amount of time as
| | 04:30 | you plan your site making sure that it's
structured in a way that maximizes performance.
| | 04:36 | Any responsive site that's designed to look
good on mobile devices should also be designed
| | 04:40 | to perform well on them.
| | 04:43 | To learn more about the CSS techniques that I
discussed in this movie, be sure to check out
| | 04:47 | the many wonderful CSS titles in the
lynda.com online training library, including my CSS
| | 04:54 | page layout course, which discusses simple
CSS drawing and CSS sprites in more detail.
| | 04:59 |
| | Collapse this transcript |
|
|
3. Responsive Design StrategiesDesigning for the appropriate context| 00:00 | I want to discuss some of the strategies that you'll
need to consider when approaching responsive design.
| | 00:06 | To build a successful responsive site, you need to go
beyond simply repositioning elements within a layout.
| | 00:12 | You need to make designing for multiple
user contexts an important part of your planning
| | 00:16 | process and carefully consider how your
site should function within those contexts.
| | 00:22 | At the outset of this chapter, I need to
carefully state that responsive design is not the right
| | 00:27 | solution for every situation, and that I'm
not advocating it as the only solution for
| | 00:32 | designing across multiple devices.
| | 00:34 | There are going to be times when a separate
mobile site or application is the better choice.
| | 00:39 | As a designer or developer, it's your job
to assess the goals of the project and then
| | 00:44 | determine the appropriate approach.
| | 00:47 | By learning more about responsive design and
its relative strengths and weaknesses, you'll
| | 00:52 | be able to make better decisions
about when and where it's appropriate.
| | 00:55 | I can state with relative certainty, however, that
our days of just designing for the desktop are over.
| | 01:02 | You can no longer ignore the mobile context,
and not designing for it means that a significant
| | 01:07 | percentage of your site's visitors
will have a less-than-ideal experience.
| | 01:12 | If you've decided that your project doesn't
warrant a separate mobile site or application,
| | 01:18 | you still need to invest some time into thinking about
how your site is going to work across different devices.
| | 01:24 | Currently, many designers work like this.
| | 01:27 | They develop a site with a client, test it
across multiple browsers on a desktop, and
| | 01:32 | then, as the project nears completion, spend
some time thinking about how the content should
| | 01:38 | look on mobile devices.
| | 01:40 | Even worse, this stage is often device-specific,
as the client will ask for an iPhone or iPad
| | 01:47 | version of the site.
| | 01:49 | The end result is often a mess, driven at
this late stage by budget concerns or a site
| | 01:55 | structure that doesn't
lend itself to mobile devices.
| | 01:59 | In my opinion, this is why so many designers
tell me that they hate designing for mobile
| | 02:03 | screens, or that the process of
designing across devices is simply too hard.
| | 02:09 | I always compare this to an engineering team
designing a flashy sports car and then, late
| | 02:15 | in the game, being asked to make sure it has
four-wheel drive, can seat a family of five,
| | 02:20 | and gets good gas mileage.
| | 02:22 | At that stage of the process, it'd simply
be too hard to go back and satisfy all of these requirements.
| | 02:29 | That's why it's critical to understand
the context in which you are now designing.
| | 02:34 | You have to ensure that your design is
targeting the appropriate context in which the site
| | 02:38 | will be used, and that you understand those
contexts well enough to make decisions when
| | 02:43 | they conflict with each other.
| | 02:45 | For example, if you are designing a site for
a company that sells jellybeans, they might
| | 02:50 | express the desire to show as much
product on the browsing page as possible.
| | 02:55 | On the desktop, that's fairly simple.
That format lends itself to being able to visually
| | 03:00 | display a large number of items.
| | 03:03 | But how is that page going to
translate to a mobile device?
| | 03:06 | Well, you could create a slideshow, but for
a large number of items, users would likely
| | 03:11 | find that a tedious way to
browse for what they were looking for.
| | 03:15 | You could create a search feature that allows
users to target just the flavor they're looking
| | 03:20 | for, but how does that translate to
allowing customers to discover new flavors?
| | 03:25 | A better approach would be to consider each of
these contexts as the initial design is planned
| | 03:31 | so a solution can be found that
satisfies the user's needs regardless of the device
| | 03:35 | they're accessing the content on.
| | 03:38 | This means of course that if you haven't spent
much time focusing on designing for the mobile
| | 03:42 | context, it's time to start.
| | 03:44 | The mobile space is still relatively new and
evolving, so it's only natural that designers
| | 03:49 | haven't focused on it as much as other contexts.
| | 03:53 | The reality we find ourselves in now,
however, is one where the mobile device has become
| | 03:58 | an equal partner to desktop devices
and in many ways has surpassed them.
| | 04:04 | That's the main reason that I feel that
responsive design is more than just a trend,
| | 04:08 | it's the proper approach to ensuring that
your sites work across as many different devices
| | 04:12 | and contexts as possible.
| | 04:14 |
| | Collapse this transcript |
| Planning a responsive design| 00:00 | Planning a responsive design can be a
frustrating and time-consuming practice, especially if
| | 00:05 | you've never designed
outside of the desktop before.
| | 00:08 | Responsive design is still evolving, and there aren't
many established best practices around planning for it,
| | 00:14 | so it's likely that you'll evolve your responsive
design workflow over the course of several projects.
| | 00:20 | Now, obviously, each project does different and
there is no one-size-fits-all responsive solution.
| | 00:26 | With that in mind, I do want to go over a
few things you need to consider when planning
| | 00:30 | for responsive design and hopefully provide
some insight into how adopting a responsive
| | 00:36 | design workflow is going to disrupt
many of your established processes.
| | 00:41 | One of the first things that you'll
realize when planning a responsive design for the
| | 00:44 | first time is it's all about the content.
| | 00:48 | Content strategy has gotten a lot of attention
lately, and my guess is that responsive design
| | 00:53 | is about to take that
focus to a whole new level.
| | 00:55 | You see, at first glance, responsive design
appears to be about designing for mobile screen sizes.
| | 01:02 | However, once you begin mocking up content
over multiple screen sizes, you quickly realize
| | 01:07 | that changes in content placement can
dramatically impact a site's effectiveness.
| | 01:13 | That's why I recommend starting every
responsive design by creating a content inventory and
| | 01:18 | then giving that inventory a hierarchy.
| | 01:21 | By understanding how much content your site
will have and how important that content is
| | 01:26 | in relation to each other, it becomes much
easier to determine how to structure and design
| | 01:31 | that content across multiple screens.
| | 01:33 | I've also seen many projects where designers
start out with a desktop version of the site
| | 01:39 | and then begin planning how a mobile or tablet
version of the site should look and function.
| | 01:45 | In my opinion, this is the
wrong way to go about it.
| | 01:48 | In fact, I recommend either starting with
a mobile wireframe and then expanding that
| | 01:53 | to a desktop version, or working on
mobile and desktop wireframes simultaneously.
| | 01:59 | This is more effective because it forces
you to be more focused regarding content and
| | 02:05 | how that content should be presented.
| | 02:07 | By working in the mobile space first, you force
yourself to design within a narrow linear space.
| | 02:14 | These restrictions help you refine what's
really important on the site and how that
| | 02:18 | content should be presented.
| | 02:20 | It also helps you plan the initial structure
of the page, as you're more likely to understand
| | 02:25 | how that content is going to
change across screen sizes.
| | 02:28 | This approach also allows you to start
thinking about how mobile device capabilities can help
| | 02:33 | create better experiences with that content,
instead of trying to attack on those features
| | 02:38 | later in the design process.
| | 02:40 | After you develop a content strategy for
the site and initial wireframes for mobile and
| | 02:45 | desktop, it's time to start
thinking about breakpoints.
| | 02:49 | I've seen some designers obsess over
a matrix of device screen sizes and develop
| | 02:54 | a long list of breakpoints to ensure
they're supporting a host of specific devices.
| | 02:59 | Now, that approach is time consuming and costly.
| | 03:02 | It can lead to unrealistic expectations
about device support, and it ignores the fact that
| | 03:08 | the diversity of screen sizes
will only increase over time.
| | 03:12 | I feel a better approach is to simply design
towards screen sizes and be totally device-agnostic.
| | 03:19 | Start with your extremes--the small screen size
you want to support and then go up to the largest.
| | 03:24 | Now basically, that means determining where
your breakpoints for mobile and desktop are
| | 03:28 | going to be and whether or not you think it's
prudent to design beyond those current standards.
| | 03:34 | Let's say, for example, that you decide your
low-end breakpoint is going to be at 480 pixels
| | 03:39 | and that your high-end
breakpoint will be at 1,200 pixels.
| | 03:43 | Once you have that range, you could begin
thinking about where major changes to the layout
| | 03:47 | are going to occur.
| | 03:49 | The easiest way to do this is to plan out
what your content is going to look like at
| | 03:53 | both of those initial stages and then decide when
room for extra columns or content regions appear.
| | 04:00 | Now, notice that I'm not advocating established
breakpoints for tablets or portrait and landscape
| | 04:04 | versions; rather, you're letting the expanding
width to the screen dictate the flow of content.
| | 04:10 | If you take this approach, you'll find that
those breakpoints establish themselves naturally,
| | 04:15 | and you'll end up with three to four major
breakpoints that progress your design through
| | 04:19 | increasingly wider screen sizes.
| | 04:22 | For most projects, this set will be all you
need, and what's nice about this approach is
| | 04:27 | that it allows you to tweak your layout based
on what the available screen size gives you.
| | 04:32 | For example, let's say you have a list of
navigation links that fits nicely between
| | 04:36 | 480 and 1,000 pixels.
| | 04:39 | However, you notice that if you scale down
below 480, the rest of the layout continues
| | 04:43 | to work fine, but the
navigation breaks around 420 pixels.
| | 04:47 | Since there are several devices out there
within that range, perhaps you create another
| | 04:52 | smaller breakpoint at this size, which only
targets the navigation through reducing the
| | 04:57 | size or removing icons.
| | 04:59 | These smaller breakpoints, which I call tweak
points, allow you to refine your designs throughout
| | 05:04 | the scaling process.
| | 05:07 | Another thing you should be thinking about
during this process is to what level device
| | 05:11 | functionality should be considered.
| | 05:13 | Since smaller layouts lend themselves to
smartphones and tablets, it's important to start thinking
| | 05:17 | about when and if it's appropriate to include
device-specific capabilities, like geolocation,
| | 05:24 | instant messaging, and touch sensitivity.
| | 05:27 | Thinking about how the site will function
within each context is just as important, if
| | 05:31 | not more so, than how the layout will change and
should be planned in parallel to your initial mockups.
| | 05:37 | Of course, there is a much larger list of
things you should consider as you plan content
| | 05:41 | strategies and breakpoints.
| | 05:43 | Navigation can be a very difficult problem
to solve for responsive design sites so you
| | 05:48 | should begin solving how navigation is
going to work very, very early on the process.
| | 05:53 | It's also helpful to create consistent coding
standards for how content should be structured
| | 05:58 | and how that content will be
styled across media queries.
| | 06:02 | This step is more important for larger
projects or team-based environments, but establishing
| | 06:06 | standards at the beginning of a project
forces you to focus on being consistent throughout
| | 06:11 | your site, which is crucial
for executing responsive designs.
| | 06:15 | Finally, by considering all of these factors
at the very beginning of a project, you can
| | 06:20 | ask yourself a very important question:
| | 06:23 | Given the goals of the site, the content
involved, and the desire to user experience, can you
| | 06:28 | create them all within a
single document structure?
| | 06:32 | Often, that answer is no, which will force
you to either re-define your goals, modify
| | 06:37 | the site's content, or realize that an application
or separate mobile site might be a better way to go.
| | 06:44 | Just realize that planning a
responsive design is not a simple process.
| | 06:48 | Like anything else, it will get easier the
more you do it, but be prepared to hit some
| | 06:52 | unexpected roadblocks as you start out.
| | 06:54 | In fact, I'd advise you to add some time in
your planning process to work through some
| | 06:59 | of the more difficult responsive design
issues that are almost certain to appear.
| | 07:03 |
| | Collapse this transcript |
| Building responsive mockups| 00:00 | Responsive design is so new that many of the tools
needed to assist designers simply don't exist yet.
| | 00:06 | That's especially true for
wireframing and prototyping tools.
| | 00:10 | The existing programs and processes are, for
the most part, still tied to fixed-width layouts,
| | 00:16 | which forces designers to find ways to
adapt existing tools to evolving workflows.
| | 00:22 | As with any emerging process, people are still
experimenting with techniques that work best for them.
| | 00:28 | I'm going to cover a few approaches,
including my own, to creating responsive mockups, and
| | 00:33 | then discuss how designers are currently using
existing tools to assist their responsive design workflow.
| | 00:39 | Often I see people start by attempting to
create pixel-perfect versions of their layouts
| | 00:45 | for different devices or screen sizes.
| | 00:48 | This could result in building anywhere between
three to six versions of each mockup, covering
| | 00:53 | smartphones, tablets, desktops, interactive TVs, and
portrait and landscape versions for each device type.
| | 00:59 | As you can imagine, creating mockups for each
of these stages and tweaks isn't very efficient.
| | 01:03 | For the most part, I've been creating
three or four versions of mockups, which feature
| | 01:08 | small, medium, and large screen sizes, usually
correlating smartphones, tablets, and desktop.
| | 01:15 | The more I work with responsive designs, however,
the more I find myself creating initial wireframes
| | 01:20 | to block content out, and then creating more refined
mockups for just the mobile and desktop screen sizes.
| | 01:27 | And from that point, I design
the rest within the browser.
| | 01:31 | Designing within the browser is harder,
and takes a little getting used to.
| | 01:34 | However, by establishing flexible layouts
at the narrow and wider ends of my design,
| | 01:39 | I can quickly resize the browser and
determine exactly the point at which a layout breaks.
| | 01:45 | This makes it easier to define breakpoints that
fit the design and then code incremental tweaks.
| | 01:51 | I'll be the first to admit that this approach isn't
going to be right for everyone or even every project.
| | 01:57 | Designing within the browser means that
you're much further along in the execution of the
| | 02:01 | site, even as you're still
technically in the planning stages.
| | 02:05 | For larger or more complex sites, this type
of approach can be unworkable unless you're
| | 02:10 | simply creating prototypes.
| | 02:12 | Regardless of the approach you take, I can't
recommend strongly enough making initial sketches
| | 02:17 | an important part of your design process.
| | 02:20 | Sketching out wireframes brings a tactile
connection to content and functionality planning
| | 02:24 | that I've never been able to
get from digital wireframing.
| | 02:28 | Plus, it's really easy to rapidly sketch
out multiple options and then just throw them
| | 02:32 | away as you refine them.
| | 02:34 | There are a number of responsive design
sketchbooks and sketch sheets that you can order or download
| | 02:39 | for free online that make the
process of sketching response much easier.
| | 02:43 | In fact, for the most part, I haven't found
a digital tool that matches these sheets in
| | 02:48 | terms of visualizing content
across multiple screen sizes.
| | 02:53 | Since most traditional tools haven't evolved
yet to simulate responsive design, many designers
| | 02:58 | are turning to some unconventional choices.
| | 03:01 | Keynote, and to a lesser degree, PowerPoint are
increasingly being used to create responsive prototypes.
| | 03:07 | The large selection of user interface
elements, the ability to import custom graphics, and
| | 03:12 | the animation capabilities give users a way
to simulate interactivity and content reflow
| | 03:18 | within responsive designs.
| | 03:20 | Other designers are abandoning traditional tools
altogether and creating responsive wireframes with HTML and CSS.
| | 03:27 | Now, their reasoning is that since you need
to simulate how content flows responsively,
| | 03:32 | no other toolset allows you to
showcase this as well as HTML and CSS itself.
| | 03:38 | It also gives the designers an initial framework from
which to build the site once the prototypes are approved.
| | 03:44 | Many existing responsive frameworks--like the
one I'm showing you here, Skeleton--are increasingly
| | 03:49 | becoming not only the foundation for responsive
sites, but also the means to prototype them as well.
| | 03:55 | This approach seems to evenly split the
design community, with many finding it an intuitive
| | 03:59 | way to work, while others just find it
tedious and unsuited for larger projects.
| | 04:04 | In terms of existing tools, I expect to see
additions to Adobe's Photoshop, Fireworks,
| | 04:09 | and Illustrator programs very soon,
to assist with responsive designs.
| | 04:13 | Currently, Fireworks and Illustrator allow
multiple pages, or storyboards, which allows
| | 04:18 | you to create multiple mockups of the same
content at different sizes, but Photoshop
| | 04:23 | is notably lacking in responsive design tools.
| | 04:26 | So obviously, we're at the stage where we
find ourselves waiting for the tools to catch
| | 04:30 | up to our desired capabilities.
| | 04:33 | This means that regardless of the approach
you adopt or the tools that you use, you
| | 04:37 | need to find the right technique to
communicate how content changes over different screen
| | 04:42 | sizes and how functionality
adapts across multiple devices.
| | 04:47 | As you search for the proper toolset and
techniques and begin to create a responsive workflow
| | 04:51 | that's right for you,
make sure that that remains your focus.
| | 04:54 |
| | Collapse this transcript |
| Developing a content strategy for responsive sites| 00:00 | Good content strategy is critical
to responsive design. How critical?
| | 00:05 | Well, I feel pretty confident in saying that
if your responsive design doesn't have a solid
| | 00:10 | content strategy, it will fail.
| | 00:12 | In fact, in almost every responsive design
that I have seen criticized, the negative
| | 00:17 | comments have dealt with problems surrounding
content, whether the person making the comments
| | 00:22 | realized that or not.
| | 00:24 | So, what is content strategy, and why
is it so important to responsive design?
| | 00:30 | Content strategy refers to the practice of
identifying, organizing, and managing a site's content.
| | 00:36 | With the rise of content management systems
over the past decade or so, the discipline
| | 00:41 | has received a lot of attention, with many
large organizations now having a dedicated
| | 00:46 | content strategist on staff.
| | 00:50 | Just one look at a responsive site will tell you
why having a clear content strategy is so important.
| | 00:55 | On larger screens, it's really easy for the
viewer to scan your content and find exactly
| | 01:00 | what they are looking for.
| | 01:02 | As screens begin to get smaller, content
needs to shift: four columns becomes three, three
| | 01:07 | becomes two, and two finally becomes one.
| | 01:12 | At a smaller screen size, users are forced to react
to the content that's initially presented to them.
| | 01:17 | And then they have to actively seek the content
they're looking for if it's not immediately visible.
| | 01:23 | Let's go back for a moment to the site that we
were talking about earlier that sells jellybeans.
| | 01:27 | On the product detail page, you might have the
first column display an image of the jellybeans
| | 01:32 | and a detailed description of the flavor.
| | 01:35 | To the right of that, maybe you have a
list of related flavors that users can browse.
| | 01:40 | In the third column, maybe you have the
purchasing information and a button to add their current
| | 01:44 | jelly beans to your current order.
| | 01:46 | Well, that looks fine in the desktop, but what
happens when we begin to shrink the screen size?
| | 01:52 | In most cases, designers simply revert to
stacking the content one on top of another
| | 01:57 | in the order that they're found.
| | 02:00 | That means that in this case, the purchasing
option would be way down the screen on phones,
| | 02:06 | and users would have to scroll through all
the related jelly beans before they could
| | 02:10 | buy the one they want.
| | 02:11 | Now, that's a problem.
| | 02:14 | But it's a content
problem, not a responsive one.
| | 02:17 | So, right away, you can see how
difficult the decisions regarding content become.
| | 02:22 | You are faced with deciding when content shifts,
which piece of content appears on top of another,
| | 02:27 | and when you should hide content, and what
type of mechanism to use if you want to enable
| | 02:32 | users to reveal it.
| | 02:34 | Above all, your goal should be to create a
responsive layout that emphasizes the most important content,
| | 02:40 | makes the relationships between content
clear, and provides ways for accessing content
| | 02:45 | in an efficient manner on smaller screens.
| | 02:48 | That's no easy task,
| | 02:49 | and why it's so important to have a
guiding strategy for your site's content.
| | 02:54 | Now obviously, this is a little easier if
you have a content strategist on your team.
| | 02:58 | But that's not always possible.
| | 03:00 | And chances are you might have to go this
alone, or work with your client to establish
| | 03:04 | rules around the site's content.
| | 03:06 | Either way, regardless of the size of your
team or whether you're working with a client
| | 03:11 | or on your own project, there are a few things
that you should nail down early on when working
| | 03:15 | on responsive designs.
| | 03:17 | First, make sure that you start with the
content before you do any other type of planning.
| | 03:23 | Inventory the content that will appear
on your pages, and begin to categorize it.
| | 03:28 | Think about exactly what
the content's purpose is.
| | 03:31 | How does the page content relate to each other?
| | 03:33 | Given the goals of the page,
which content is the most important?
| | 03:38 | Is this repeating content across the
site or is it specific to just this page?
| | 03:43 | How many different categories of content do you
have, and how are they being used throughout the site?
| | 03:49 | Content strategists will often design
diagrams of your site's content, which can help you
| | 03:53 | visualize relationships,
categorize it, and establish hierarchies.
| | 03:58 | Breaking your site's content into discrete
chunks like this can often lead to surprising
| | 04:02 | discoveries in terms of how you build
pages and group content in unexpected ways.
| | 04:08 | It will also help you generate a set of
rules that govern how content should be displayed
| | 04:12 | and shifted as screen sizes change.
| | 04:16 | You can expand on this as you
begin to wireframe your pages.
| | 04:19 | Start with the smallest screen size and
then use the page inventory to determine which
| | 04:24 | content should display first and how users are
likely to want to interact with it in related content.
| | 04:30 | If you have trouble with this, imagine that you
can only show one piece of content on the page.
| | 04:35 | What would it be?
| | 04:37 | From there, continue to add content, and visualize
how users are likely to find and interact with it.
| | 04:44 | Then begin to wireframe the
pages at wider screen sizes.
| | 04:48 | Determine how the content can expand over
large screen real estate in engaging ways.
| | 04:53 | Creating this content hierarchy and
visualizing how it needs to change over screen sizes will
| | 04:58 | make it much, much easier for you to
structure your pages and write your styles.
| | 05:03 | It also means that you'll be less likely to
find yourself in a situation where the page
| | 05:07 | structure prevents you from
reflowing content the way you need to.
| | 05:11 | Keep in mind that one-size-fits-all content
rules are very unlikely to work over a full site.
| | 05:17 | And in many cases, the decisions you'll make
regarding content are likely to be judgment calls.
| | 05:22 | That's why it's important that you involve
as many people as you can in categorizing
| | 05:26 | and ranking content as
early as you can in the process.
| | 05:30 | Without a clear understanding of the types
of content you have, how important it is to
| | 05:34 | the site's goals, and how it relates to each
other, it's impossible to create an effective
| | 05:39 | responsive design.
| | 05:40 |
| | Collapse this transcript |
| Understanding the mobile context| 00:00 | Throughout this title, I've used the term
context to refer to how users experience and
| | 00:06 | interact with your sites across various devices.
| | 00:09 | Contexts are useful because they help us
make assumptions about how someone will use our
| | 00:14 | sites, and what their focus, capabilities,
and limitations might be as they use it.
| | 00:20 | We've designed for the desktop context for so
long, we're barely conscious of the assumptions
| | 00:24 | that we make regarding things like the user
behavior, screen real estate, browser capabilities,
| | 00:29 | plug-ins, and bandwidth speed.
| | 00:32 | Because we've been designing for it for so
long, for most of us, it's almost second nature.
| | 00:37 | However, recently we've had to start
considering another context as we design, and that is
| | 00:43 | the mobile context.
| | 00:45 | Because it's relatively new and still evolving,
I want to take some time to explore the mobile
| | 00:49 | context and break down some
of the myths surrounding it.
| | 00:53 | When mobile devices first started to connect
to the Internet, it was usually through feature
| | 00:57 | phones on slower network connections.
| | 01:01 | These devices often lack real browsers and sometimes
presented content only through third-party portals.
| | 01:08 | As their capabilities increased, the experience
began to improve, but for the most part, trying
| | 01:14 | to browse the web through these
devices was a frustrating experience.
| | 01:19 | These experiences led to some underlying
assumptions about the mobile web that we're still hearing now.
| | 01:25 | How often have you heard things
like, "Mobile users are on the go.
| | 01:29 | They don't have time to look at a lot of
information, or read long passages of text.
| | 01:34 | Keep it simple and pare things down," or "Mobile
devices have limited browsers and slow connections,
| | 01:40 | so cut back on features and resources," or my
favorite: "Mobile users don't want or need your full site.
| | 01:47 | It's better to create a smaller separate
site and then redirect mobile users to it."
| | 01:53 | These examples may be a bit extreme, but all
too often the term mobile is used to justify
| | 01:59 | limiting either content, features,
or functionality for a group of users.
| | 02:04 | Frankly, we're making too many
assumptions about exactly what a mobile user is.
| | 02:11 | The truth is, a mobile user is all of us.
| | 02:15 | Of the 7 billion people in the
world, over 77% own a mobile device.
| | 02:22 | This means that mobile users come in an
amazing diversity of behaviors and needs.
| | 02:27 | Yes, people use mobile devices
spontaneously as they wait in line or shop at the mall,
| | 02:33 | but they also use them in more focused
activities like surfing online at home, booking flights,
| | 02:39 | watching movies, or reading product reviews.
| | 02:42 | In fact, about the only assumption we can
make about mobile users is that they're always
| | 02:47 | connected; whether they are riding the bus,
sitting in bed or finishing a workout, they
| | 02:52 | have the ability to access your content.
| | 02:56 | We also tend to make some broad
assumptions about mobile devices,
| | 03:00 | but when you think about
it, really, what is mobile?
| | 03:03 | It's certainly not just phones,
as I'd say my laptop is pretty mobile.
| | 03:08 | What about other devices that are increasingly
becoming connected, like cars and shoes and watches?
| | 03:14 | Are they mobile?
| | 03:16 | People also often assume that mobile
devices have bad or slow connections.
| | 03:20 | However, when I use my phone or tablet at
home, I connect through my high speed network.
| | 03:26 | Conversely, when I'm on the road, my hotel
connection often makes browsing on my laptop painful.
| | 03:32 | Of course, we do have to account for the reality
that mobile users will often have low bandwidth
| | 03:37 | or high-latency connections,
but it's not always the norm.
| | 03:41 | So, what can we say with
certainty about mobile devices?
| | 03:45 | Well, screen sizes are smaller, which forces us
to rethink how we prioritize and present content.
| | 03:52 | However, the incredible diversity in
screen sizes means that we can no longer attempt
| | 03:56 | to target one size or one device.
| | 04:00 | Mobile devices are also always connected.
| | 04:03 | This means that we should plan for mobile
users to connect at any time along diverse
| | 04:07 | network conditions.
| | 04:10 | Mobile devices also have capabilities
and feature sets that desktops don't.
| | 04:15 | Features like location detection, touch events,
accelerometers, built-in phones, and messaging
| | 04:20 | gives you an opportunity to craft
experiences in totally new ways.
| | 04:25 | If we take these capabilities into
consideration as we plan our sites, we're likely to rethink
| | 04:30 | the ways that users can connect
and interact with our content.
| | 04:35 | Above all, realize that by limiting features
or content, you are likely frustrating a large
| | 04:40 | group of users who want access to it.
| | 04:43 | It's best not to set artificial conditions
by assuming what someone might or might not
| | 04:48 | want to do on a mobile device.
| | 04:51 | Instead, start by using the actual
constraints of the device as a way of focusing content
| | 04:56 | so that you're emphasizing
what's really important to the user.
| | 05:00 | In fact, to me, the mobile context
really shouldn't focus on behavior at all.
| | 05:05 | There are simply too many mobile users to try
and categorize them into one set of behaviors.
| | 05:10 | If we really want to reach them, we are
better served by looking at the mobile context as
| | 05:15 | one that focuses on the device's
capabilities and practical limitations.
| | 05:20 | This in turn will help us focus our content,
and in the end, give it greater expression.
| | 05:25 |
| | Collapse this transcript |
| Designing for mobile capabilities| 00:00 | If your goal is to create engaging user
experiences across multiple devices, then you need to
| | 00:06 | pay close attention to
what those devices can do.
| | 00:09 | Now, in many ways, embracing responsive
design requires us to rethink how we've designed
| | 00:15 | sites in the past and reexamine how people might
want to use and interact with our sites' content.
| | 00:22 | If you own a smartphone or tablet, you probably
already have a good idea as to what they are capable of.
| | 00:28 | In fact, I'm betting that by now, you're
accustomed to using apps or sites that blend together
| | 00:33 | features like cameras, location detection,
and messaging into one seamless experience.
| | 00:39 | Well, if you are accustomed to it,
your users probably are as well.
| | 00:43 | Now, there is currently an ongoing debate about
whether apps or websites are the future of the web,
| | 00:49 | but I think that argument misses a very
important point. For the most part, users don't care.
| | 00:55 | All they really care about is that your site
delivers the experience they expect and since
| | 00:59 | they are being conditioned to expect integrated
feature-rich interactions, you need to understand
| | 01:04 | what mobile devices are capable of and how to
use those features within your responsive design.
| | 01:10 | And with that in mind, let's take a look at some
of the more prominent features of mobile devices.
| | 01:15 | The very term mobile suggest a device that's
portable and allows users to access content
| | 01:20 | anywhere they happen to be.
| | 01:22 | So, it makes sense that most mobile
devices have some form of location detection that
| | 01:28 | allows you to determine exactly where
the user is and respond accordingly.
| | 01:33 | Many hand-held mobile devices also support
motion detection in the form of accelerometers.
| | 01:38 | This allows you to respond to
motion, hand position, and screen tilt.
| | 01:42 | Often, this is accompanied by a built-in compass,
which also allows you to precisely target device direction.
| | 01:49 | Another common feature involves audio and
media, as devices have microphones, speakers,
| | 01:54 | and cameras, which allow you to record pictures,
video, and audio or access the user's media library.
| | 02:00 | It's also very common for these devices to
have touch screens, which allow your sites
| | 02:04 | to respond to touch events and gestures.
| | 02:07 | One of the most overlooked features
of mobile devices is the phone itself.
| | 02:12 | Phone capabilities, messaging, and push
notification services allow you to give users multiple
| | 02:17 | options to connect with, and
communicate through, your site.
| | 02:21 | While this isn't a complete list of all
mobile device features, it does illustrate the fact
| | 02:26 | that if we're planning for our sites to
reach across media and devices, we need to start
| | 02:30 | designing towards those mobile capabilities.
| | 02:33 | And the first step is to carefully consider
whether taking advantage of these features
| | 02:37 | is appropriate or not,
given the goals of your site.
| | 02:40 | Now, think about how users might anticipate
interacting with your content, or what their
| | 02:45 | expectations might be.
| | 02:47 | Now, remember, just because you
can doesn't mean that you should.
| | 02:50 | Next, you will have to consider how these
features will affect your page structure and
| | 02:54 | design for larger screen sizes.
| | 02:57 | How will that functionality be
replaced or represented on desktops?
| | 03:01 | Will you have to hide large portions of your
interface, or are there ways to make the same
| | 03:04 | content behave in a different way
based on where it's being viewed.
| | 03:08 | Now, these are not easy questions, but it's
necessary that you think through how these
| | 03:12 | features will scale in a responsive design.
| | 03:15 | Unlike building an application, where you can
focus on just one user experience, responsive
| | 03:20 | design forces you to consider
functionality across multiple contexts.
| | 03:24 | And often, this means trade-offs are involved,
and many decisions will be judgment calls
| | 03:29 | based on what you feel will be more effective.
| | 03:31 | Now, of course some of these features are
a little easier to implement than others.
| | 03:36 | To create a phone number that users can
touch to call, all that's really required is you
| | 03:40 | mark up the phone number in an
anchor tag using the telephone URL scheme.
| | 03:45 | You can then hide the link on desktops using CSS
since desktop browsers don't really support it.
| | 03:50 | Other features, like location detection,
involve using JavaScript APIs like geolocation to
| | 03:55 | capture and respond to data.
| | 03:57 | While these APIs make it easy for anyone
with moderate scripting skills to take advantage
| | 04:01 | of them, they require a bit more
skill and planning to implement properly.
| | 04:06 | One thing that can help is taking the
advantage of the Modernizr JavaScript library.
| | 04:10 | Modernizr helps you detect support for
things like geolocation and touch events, and then
| | 04:14 | manages resources and scripting based on support.
| | 04:17 | Since it also allows you testing in some
media queries, it's a great way to add that type
| | 04:21 | of functionality responsively.
| | 04:24 | And unfortunately, it's not always that simple.
| | 04:26 | Things can get much trickier if you're attempting to
use native device features such as cameras or audio.
| | 04:31 | Now, often these features require you to
use a third-party framework to bridge that gap
| | 04:37 | between the phone and your site.
| | 04:39 | At that point, you begin to move away from
building responsive designs to building applications,
| | 04:44 | so you should carefully consider the features
that you want to use and then research what's
| | 04:49 | required to add that functionality.
| | 04:51 | Once you understand what's involved in
implementing it, you will be better prepared to decide
| | 04:55 | if it's in fact right for your design.
| | 04:58 | Regardless of what you decide, never lose sight
of the fact that it's ultimately about the user.
| | 05:04 | Remember that they are likely to have certain
expectations about what they can do with your
| | 05:07 | content on mobile, yet they are also
likely to visit your site on desktops as well.
| | 05:13 | You want to make the transition between experiencing
the site on mobile and desktop as seamless as possible.
| | 05:18 | This doesn't mean that the site has to
function exactly the same within each context, but
| | 05:23 | that you should think about what's appropriate in each
case and then strike a balance based on what's possible.
| | 05:28 |
| | Collapse this transcript |
| Creating flexible HTML| 00:00 | Although HTML doesn't get as much attention
as CSS when responsive design is discussed,
| | 00:06 | how you structure your HTML is just as
important as how you author your styles.
| | 00:12 | Without carefully planning and structuring
your code, you'll never be able to create the
| | 00:15 | flexible layouts you'll need for
a successful responsive design.
| | 00:19 | In many ways, your HTML needs to
be just as flexible as your styles.
| | 00:24 | If you plan for your sidebar content to
reflow a certain way on smaller screens, your page
| | 00:30 | structure needs to be constructed
in a way that's going to allow it.
| | 00:33 | Obviously, this means that your planning
process has to consider both the needs of your code
| | 00:38 | structure and your styling requirements simultaneously,
which may require you to alter your existing workflow.
| | 00:45 | For environments where the page structure
is driven by a CMS or is locked in due to
| | 00:50 | other factors, you could find yourself
limited in terms of your ability to reflow content.
| | 00:55 | If that's the case, you may have to rework
your entire process or find ways to make a
| | 01:00 | responsive design work within your constraints.
| | 01:03 | While every project is different, there are
a couple of basic things that you can do to
| | 01:08 | help ensure your HTML will
work well with responsive designs.
| | 01:13 | First and foremost, you should focus on
writing clean code without extraneous markup.
| | 01:19 | That really should be the goal of all web
design, but it's especially important for
| | 01:23 | responsive designs, as cluttered code can
make writing multiple layout styles cumbersome.
| | 01:29 | I also recommend that you
adopt HTML5 if you haven't already.
| | 01:34 | Not only is the authoring process simpler,
but it will also requires less overall code,
| | 01:39 | which in turn creates more lightweight pages.
| | 01:42 | It also gives you the added
benefit of increased semantics.
| | 01:44 | In responsive design, it's very important that
content be easily identifiable and clearly segmented.
| | 01:51 | HTML5's structural elements, such as article,
aside, nav, and section, help you structure
| | 01:56 | your content in a more meaningful way.
| | 01:58 | And if you haven't yet, you also need to
start exploring microformats as a way of adding
| | 02:03 | even more meaning to your code.
| | 02:06 | Not only will they extend your content and
make it more searchable, but it will also give
| | 02:10 | you a way to group content together in a more
granular fashion and provides you with content-
| | 02:15 | specific styling hooks.
| | 02:17 | As you begin to create more meaningful code,
be sure to create standards for how specific
| | 02:22 | content types and regions are structured.
| | 02:25 | By thinking through these structures early
in the process and making sure that you write
| | 02:29 | consistent code throughout your site, you're
going to make the process of writing responsive
| | 02:33 | styles a lot easier.
| | 02:36 | It's entirely possible that adopting
responsive design will force you to rethink the way you
| | 02:41 | structure your HTML, and over time it's
really easy to get in the habit of coding the same
| | 02:47 | repeating structure over and over again.
| | 02:49 | Now, how many times have you created a basic
page structure that includes a header at the
| | 02:54 | top with navigation, a main article to hold
the main content, a sidebar for related content,
| | 03:01 | and a footer at the bottom?
| | 03:02 | This structure works fine for the
well-established pattern of a two- or three-column layout.
| | 03:08 | However, for content that needs to reflow
in a specific way, or even merge as page sizes
| | 03:13 | change, this structure
might be entirely too rigid.
| | 03:17 | Making sure that your HTML provides a
necessary page structure while giving you the freedom
| | 03:22 | to reflow content correctly is one of
the major challenges of responsive design.
| | 03:27 | One way that you can make this a little
bit easier is to start thinking of content
| | 03:31 | as discrete chunks of code.
| | 03:34 | Creating smaller sections of content can provide
you with modular content blocks that are easier
| | 03:39 | to manipulate over multiple layouts.
| | 03:42 | Now, don't take this approach too far.
| | 03:43 | The last thing you want to do is have
your layout dictate your code structure.
| | 03:48 | Occasionally, you'll have to make certain
trade-offs in order to reach the best solution,
| | 03:52 | given the goals of your layout.
| | 03:54 | Just make sure that you never
sacrifice accessibility for layout.
| | 03:57 | In some cases, you simply won't be able to
arrive at a structure that will work for all
| | 04:02 | of your responsive layouts.
| | 04:04 | At that point, you either have to reassess
your page layout goals or you can turn to
| | 04:09 | scripting for help.
| | 04:10 | Scripting can be used to replace content,
generate content, or even move content on
| | 04:15 | the fly as conditions change.
| | 04:18 | Let's say you have a long vertical menu that
would take up too much space on mobile screens.
| | 04:23 | You could simply dynamically replace it
on smaller screens with a select menu.
| | 04:28 | For instances where page structure prevents
you from reflowing content properly, you could
| | 04:33 | create empty placeholder elements for specific
content chunks and then use scripting to fill
| | 04:38 | them with the appropriate content
based on the desired layout flow.
| | 04:42 | Now, this is the approach that the Filament
Group uses for their append-around component,
| | 04:47 | which you can find at their
South Street GitHub Repository.
| | 04:50 | So yes, obviously scripting can be very
effective at solving tricky structural issues.
| | 04:55 | I would caution you, however, not to rely too
heavily on scripting for modifying page structure.
| | 05:00 | It usually requires at least some extraneous
markup and can really slow page load times,
| | 05:06 | in some cases, dramatically.
| | 05:08 | Now, there will be times what it's the right
solution, but if you can achieve the same
| | 05:12 | results without using it you're better off.
| | 05:14 | Of course, this entire discussion ignores
the bigger issue, which is that current CSS
| | 05:19 | layout techniques are not
suited for responsive design.
| | 05:23 | Float-based layouts are directly tied to source
order, making it almost impossible to dramatically
| | 05:29 | reorder elements from
one screen size to another.
| | 05:33 | Thankfully, CSS is evolving as well.
| | 05:36 | Be sure to keep your eye on the W3C's
Flexible Box Model, otherwise known as Flex Box, and
| | 05:43 | on the CSS Grid Template Layout Module.
| | 05:46 | Now, both of these layout modules
promise a degree of source order independence.
| | 05:52 | Once they're fully implemented across major
browsers and devices, it will be much easier
| | 05:56 | to create responsive design
layouts from well-structured HTML.
| | 05:59 |
| | Collapse this transcript |
| Testing responsive designs| 00:00 | Testing is a critical component of any web project,
and that's especially true for responsive design.
| | 00:06 | The trick in testing responsive sites is
in accurately testing how your site is going
| | 00:11 | to look and perform across multiple devices.
| | 00:15 | Most people test responsive design projects
by simply resizing their browser window as
| | 00:20 | they refine their layouts.
| | 00:23 | While this type of testing is helpful at
giving you immediate feedback, it doesn't accurately
| | 00:28 | show you how the site will render on mobile
browsers, and it ignores performance altogether.
| | 00:34 | Thankfully, there are a few tools out there
that can help you test your responsive designs.
| | 00:39 | The first thing that most people want to
test when designing responsive layouts is their
| | 00:43 | media queries and whether or not
they're hitting the right breakpoints.
| | 00:46 | Now, you can resize your browser window to
test this, but you're not really getting any
| | 00:50 | feedback as to the actual trigger points
themselves, and it's not exactly a speedy process.
| | 00:56 | In fact, many designers became so frustrated
with this that they created a couple of online
| | 01:01 | tools to help speed up the
process and make it a bit more precise.
| | 01:06 | Benjamin Keen has created a nice bookmarklet
that you can add to your browser's bookmark toolbar.
| | 01:11 | A single click of it will show your
current page rendered in as many sizes as you wish.
| | 01:16 | You simply create the bookmarklet by
adding the dimensions you want to test, generate
| | 01:21 | it, and then you'll be able to
test multiple breakpoints at once.
| | 01:25 | This is extremely handy for testing locally.
| | 01:31 | The Responsinator isn't a bookmark, but rather,
it's a site where you can go ahead and enter
| | 01:36 | any URL you want and see the page rendered at
preset breakpoints that match popular phones and tablets.
| | 01:46 | Now, there are a lot of online tools like The
Responsinator, and doing a quick search will
| | 01:50 | give you a ton of options.
| | 01:52 | Two of my favorites are responsive.is, which
allows you to enter a URL and simply click
| | 01:58 | the icon of the device
that you want to simulate.
| | 02:01 | What's nice about this is you see the
content actually animate as it reflows.
| | 02:06 | I also really like Screen Queries.
| | 02:10 | The thing that I love about this one is
that not only you can enter in the URL or test
| | 02:13 | a page locally, you get a nice grid,
which shows you where your breakpoints are,
| | 02:18 | you can focus on the actual rendering, and
scroll down through your designs, and it has
| | 02:24 | a ton of preset screen sizes and devices that
allow you to quickly test across multiple devices.
| | 02:33 | While examining your breakpoints is an important
part of testing responsive design, it shouldn't
| | 02:37 | be your only concern.
| | 02:39 | If people are going to be viewing your site
on mobile devices, you want to make sure they're
| | 02:43 | performing properly.
| | 02:45 | One of the best online mobile
tests that I found is Mobitest.
| | 02:48 | Now this is a free online testing service
that allows you to enter the URL of your site
| | 02:53 | and also choose the device
that you want to test on.
| | 02:57 | Now, once the test is complete, it's going to
load up a screenshot of your site on that device.
| | 03:03 | It's going to tell you what your average
load time is. And one of the things I really love about
| | 03:08 | this, you get this really nice waterfall chart
that shows you all of the resources that loaded
| | 03:12 | for this page and how long it
took those resources to load.
| | 03:15 | So this way you get a little bit of a clearer
picture of which resources might be slowing your site down.
| | 03:21 | It's also especially helpful for checking to
see if you're managing your resources properly
| | 03:25 | and if specific resources either did or did
not load based on how you are managing them.
| | 03:31 | You might also want to look at using mobile
emulators for testing, especially if you don't
| | 03:36 | have access to multiple devices.
| | 03:38 | Now, a mobile emulator is just that.
| | 03:40 | It's a program that does its best to simulate a
specific mobile device, browser, or operating system.
| | 03:47 | You can either use online emulators like
TestiPhone.com and Opera's Mini simulator, or you can download
| | 03:54 | and install emulators like Opera's Mobile
emulator and the emulators that come with
| | 03:59 | Apple's iOS SDK and Android's SDK.
| | 04:02 | In fact, you can pretty much find an
emulator for almost any mobile device.
| | 04:08 | For a more thorough look at emulators, I recommend
using mobiForge's excellent article on mobile emulators.
| | 04:13 | It's a great way to learn where to find them as
well as some of the pros and cons to using them.
| | 04:18 | Now, I think that emulators are a great way
to simulate specific mobile environments,
| | 04:23 | but they can be difficult to set up and they're
not always 100% accurate in showing you exactly
| | 04:29 | how your site is going to
behave on an actual device.
| | 04:33 | Although all the approaches that I've mentioned are
helpful nothing, beats testing on the actual device itself.
| | 04:39 | Now, I know that building a large device
library can be expensive, but at a minimum, you should
| | 04:44 | have a sample of iOS and
Android devices to test on.
| | 04:48 | While you're testing on the devices,
you'll need some way to debug your sites so that
| | 04:51 | you can test for performance and make sure
that everything is running the way that it should.
| | 04:56 | Opera's Remote Debugging tool is a great
way to pair Opera's Dragonfly Debugger on your
| | 05:01 | desktop with the site on a mobile device.
| | 05:06 | For WebKit remote debugging check out Weinre, or
Weinre depending upon how you like to pronounce it.
| | 05:12 | It lets you set up remote debugging with
WebKit Inspector so that you can inspect the pages
| | 05:16 | running on mobile devices.
| | 05:19 | You may have gathered from all of the
options that I've shown you that testing responsive
| | 05:23 | designs can be a bit of a pain.
| | 05:26 | Well, if you're not used to testing sites
across multiple devices, you should be prepared
| | 05:30 | to have a slower-than-
usual testing cycle at first.
| | 05:33 | You should also be prepared for having to
deal with an entirely new system of browser
| | 05:38 | bugs as you add mobile browsers to the mix.
| | 05:41 | However, once you begin to understand what
works and what doesn't, you'll adopt the testing
| | 05:46 | workflow that allows you to make sure your
sites work as well as possible across multiple
| | 05:50 | browsers and devices.
| | 05:51 |
| | Collapse this transcript |
|
|
ConclusionExploring fluid grid frameworks| 00:00 | In our final chapter, I want to leave you
with some helpful resources that can make
| | 00:04 | it easier for you to experiment
with, and adopt, responsive design.
| | 00:08 | I'll start by showing you some of
my favorite fluid grid frameworks.
| | 00:13 | Using an existing fluid grid framework can
speed up development, help keep code consistent
| | 00:18 | across projects, and give you
a solid starting code base.
| | 00:21 | You know, they're not for everyone however,
as they can add unnecessary code to your sites
| | 00:26 | and occasionally require non-semantic markup.
| | 00:28 | So, whether or not you use them for your own
responsive sites is largely a matter of personal choice.
| | 00:34 | I encourage you to examine as many of these
frameworks as possible and try them out before
| | 00:39 | committing to them for a specific site.
| | 00:41 | I'm going to start by showing you a couple
of grid-only options and then moving on to
| | 00:46 | a few full frameworks.
| | 00:50 | The Golden Grid System is a folding grid
system that features an 18-column grid, which folds
| | 00:55 | down to eight and four columns
respectively as it hits tablet and mobile breakpoints.
| | 01:00 | It also features elastic gutters, a
baseline grid with presets designed to accommodate
| | 01:05 | user scaling, and a nice add-on script
that allows you to overlay your grid over your
| | 01:10 | content as you design.
| | 01:13 | Simple Grid is a grid system with four pre-built
breakpoints for targeting multiple screen sizes.
| | 01:20 | While the grid isn't fluid out of the box,
it is very lightweight and easy to modify
| | 01:24 | with your own layout values
based on the grid structure.
| | 01:28 | Its class naming system also makes it easy to
create nested columns to build more complex layouts.
| | 01:37 | Columnal is a fluid grid based off of
an earlier non-responsive grid framework.
| | 01:42 | It features nestable columns, classes that
control vertical spacing, pre-built wireframing
| | 01:47 | templates, and a PDF of the grid system that can
help you sketch out your ideas before you code.
| | 01:55 | The Responsive Grid System is a very
flexible responsive grid that allows you to decide
| | 01:59 | how many columns you need, modify and add
as many breakpoints as you want, and section
| | 02:04 | up content in intelligent ways.
| | 02:07 | You're also encouraged to either download the entire
grid or just the pieces that you need to work with.
| | 02:15 | Gridset is a new service focused on making
it easier for designers to create fluid grids.
| | 02:21 | The site allows you to set parameters for
your grid and then generates the grid for
| | 02:25 | you based on your requirements.
| | 02:27 | You're allowed to save grids, reuse them,
or create new ones based on layout needs.
| | 02:31 | Now, as of this recording, Gridset is in beta,
but it should be available to everyone soon.
| | 02:39 | If you're looking for something a bit more
robust, you might want to consider adopting
| | 02:43 | a full-featured framework or boilerplate.
| | 02:47 | Foundation 3 is responsive framework that
includes a fluid grid, prototyping features,
| | 02:52 | and presets for typography, forms,
navigation, and other site elements that take the work
| | 02:58 | out of starting cross-browser-compliant responsive sites.
| | 03:02 | Check out the foundation
website for a full list of features.
| | 03:07 | A mobile framework that's been getting a lot
of attention lately is Twitter's Bootstrap;
| | 03:12 | it's a collection of HTML, CSS, and JavaScript
that includes a fluid grid, starter layouts,
| | 03:18 | UI components, and much, much more.
| | 03:20 | It's an incredibly comprehensive solution
to developing responsive sites, and you can
| | 03:24 | download it for free from
Twitter's GitHub repository.
| | 03:30 | The Mobile Boilerplate is a companion
framework to the HTML5 boilerplate, and even though
| | 03:36 | it doesn't contain a fluid grid,
I'm including it here because of its incredible focus on
| | 03:41 | building mobile-friendly sites.
| | 03:43 | It's designed to provide cross-browser
consistency on all major smartphones and provides fallback
| | 03:49 | support for older devices, and it gives you
features like offline caching and polyfills
| | 03:53 | from media query support.
| | 03:55 | It's actually a really great way to start
any responsive site and fluid grids can be
| | 03:59 | used in conjunction with it. I also
want to mention Skeleton, one of my
| | 04:05 | favorite responsive frameworks.
| | 04:07 | Skeleton is lightweight, includes a fluid
grid, basic typography controls, and default
| | 04:13 | styling for forms and buttons.
| | 04:16 | Unlike other frameworks, skeleton provides
you only the very basics in styling, meaning
| | 04:20 | that it's designed to give you a solid
foundation upon which to build your own unique styles.
| | 04:26 | Of course that's not all the fluid
grid systems and frameworks out there.
| | 04:29 | I encourage you to try out the ones I've shown
here and search for other frameworks that you can use.
| | 04:34 | Have fun experimenting with them, carefully
consider which features you'll need, and be
| | 04:39 | honest about comparing the benefits of using
them to the downsides that they might bring
| | 04:43 | to your projects as well.
| | 04:45 |
| | Collapse this transcript |
| Looking at responsive design tools| 00:00 | Unfortunately, many of the capabilities we
need to create truly responsive designs either
| | 00:05 | don't exist at the current time or are
unevenly supported across user agents.
| | 00:11 | Thankfully, there are lots of people in
organizations working very hard to make creating responsive
| | 00:17 | designs easier and to plug the holes in
some of those existing capability gaps.
| | 00:22 | I'd like to show you some of the tools that
can make creating responsive designs a little
| | 00:25 | easier and some that can help you ensure
that your responsive designs work across as many
| | 00:31 | devices as possible.
| | 00:33 | I really like to sketch my ideas out
first before I move on to creating code.
| | 00:38 | To me, this helps me visualize how my
content will be presented and work through a site's
| | 00:43 | responsiveness before
actually authoring any of the CSS.
| | 00:47 | That's why I absolutely love the responsive web
designs sketch sheets created by Jeremy Alford.
| | 00:52 | You can download the sheets, print them out, and
be brainstorming your responsive design in minutes.
| | 00:59 | Instead of using an existing fluid
grid, you might want to build your own.
| | 01:03 | Two tools that I really like in this
regard are Tiny Fluid Grid and Fluid Grids.
| | 01:08 | Now Tiny Fluid Grid has a very simple
interface that allows you to set some quick parameters
| | 01:15 | and then download the resulting grid.
| | 01:19 | Fluid Grids is a bit more manual, as it allows
you to enter to the total number of columns
| | 01:23 | you want and let's say the width of those
columns and then the width of the gutters.
| | 01:28 | All you have to do is click Get the grid.
| | 01:31 | It'll go ahead and generate the grid for
you and allow you to copy and download that.
| | 01:36 | You know, even if you're not keen on using
somebody else's grid, both of these tools
| | 01:40 | are great ways to examine
exactly how fluid grids are built.
| | 01:45 | Once you start building responsive sites,
you'll soon realize how many deficiencies
| | 01:49 |
there are in terms of implementations.
| | 01:52 | There is very little in the way of built-in
feature detection, resource management, and
| | 01:56 | content switching in our current browsers.
| | 01:58 | Well, thankfully, many tools are
being developed to address that.
| | 02:01 | Now, the first one I want
to show you is Categorizer.
| | 02:03 | Now, this is a device-detection script that
determines whether the user agent is a desktop
| | 02:09 | device, TV, tablet, or smartphone.
| | 02:11 | Now from there, you can load necessary resources,
redirect pages, or perform platform-specific actions.
| | 02:19 | If you've watched any of my previous tiles,
you've probably seen me talk about Modernizr.
| | 02:24 | Modernizr is the current standard in feature
detection, as it allows you to quickly determine
| | 02:28 | if a specific feature is supported and then load
resources, styles or content, based on the results.
| | 02:34 | Modernizr features asynchronous resource
loading, an ability to test against the
| | 02:39 | results of media queries, which makes it
an indispensable tool for responsive design.
| | 02:45 | Earlier, we discussed how
difficult responsive images are.
| | 02:48 | The same can be certainly said for
responsive video as well, which is why fitvids.js is
| | 02:54 | such a welcome tool.
| | 02:56 | This jQuery plug-in allows you to quickly
create fluid video embeds on your page that
| | 03:01 | are also cross-browser-compliant.
| | 03:04 | Although you'll find this actually baked in
to many of the responsive design tools that
| | 03:08 | you'll use, it's worth discussing
respond.js by the Filament Group on its own.
| | 03:14 | Because older user agents didn't support
media queries, responsive sites are often seen as
| | 03:18 | not being very backwards-compatible.
| | 03:20 | Respond.js is a very lightweight polyfill that
enables media query support on older browsers.
| | 03:29 | The Filament Group has several tools that can help
make your life easier when designing responsive sites.
| | 03:35 | Overflow helps ensure consistent support for
the CSS overflow property among mobile devices.
| | 03:41 | Since inconsistent support can create serious
user interface problems when scrolling through
| | 03:45 | content, this is a very useful tool.
| | 03:49 | And even though I've already mentioned it, I want to
recommend Filament Group's Southstreet toolset again.
| | 03:55 | Filament Group refers to Southstreet
as a progressive enhancement workflow.
| | 03:59 | Now, it's essentially a set of tools that they've
developed over the years for building responsive,
| | 04:04 | cross-device web applications and sites.
| | 04:07 | It's amazing to me that a leading developer
of responsive designs would developed these
| | 04:12 | tools around the best practices that they've
evolved and then put them out there for free.
| | 04:17 | But that's exactly what
the Filament Group has done.
| | 04:19 | If you're going to be designing responsive
sites, you need to at least examine these
| | 04:23 | tools and learn from their processes.
| | 04:26 | Finally, I want to mention response.js.
| | 04:30 | This is a jQuery library that
focuses on building responsive designs.
| | 04:34 | It has features that let you swap code blocks
for different devices and a little responsive
| | 04:38 | images and triggers for responding
the screen sizes or device features.
| | 04:43 | Be sure to check it out and see if
it has features that you can use.
| | 04:46 | Now, obviously some of the tools I've
mentioned here are more technical than others.
| | 04:51 | Don't be intimidated if you don't quite
understand what a tool does or how to implement it.
| | 04:56 | Just make sure you experiment with some of
the tools I've mentioned here, so that when
| | 04:59 | issues arise as you build responsive
sites, you'll be ready to deal with them.
| | 05:04 |
| | Collapse this transcript |
| Additional resources| 00:00 | I want to thank you for watching
Responsive Design Fundamentals.
| | 00:04 | I hope that you have a clearer overall picture
of what responsive design is and how adopting
| | 00:09 | responsive design will
affect your overall workflow.
| | 00:12 | Before I finish, I want to leave you with a
few of the responsive-design-focused blogs
| | 00:16 | and sites that I read on a regular basis.
| | 00:19 | Reading these can help you dive deeper into
responsive design and perhaps more importantly,
| | 00:24 | keep an eye on how it evolves.
| | 00:26 | First, I recommend bookmarking
the Filament Group's lab page.
| | 00:30 | You've probably heard me mention the
Filament Group a couple of times during this title.
| | 00:34 | They are a web development agency that specializes
in building experiences across devices and platforms.
| | 00:41 | Their lab page is a fantastic collection of
articles that document their processes and
| | 00:45 | observations resulting from their work.
| | 00:48 | Since they are at the forefront of
responsive design, it's well worth your time to keep
| | 00:52 | an eye on their site.
| | 00:54 | I also recommend Luke
Wroblewski's lukew.com site.
| | 00:59 | Luke is the author of Mobile First and one of
the leading proponents of mobile-friendly design.
| | 01:04 | This is perhaps the best resource online to
learn about designing for the mobile context.
| | 01:09 | It's also a good idea to keep your eye on
unstoppablerobotninja.com, if you don't already.
| | 01:17 | This is the online blog of Ethan Marcotte,
author of responsive design and in many ways
| | 01:22 | the first designer to
articulate the concepts behind it.
| | 01:26 | I'm also a big fan of Brad
Frost and his blog, BradFrostweb.com.
| | 01:31 | Brad writes articles and tutorials that focus
on responsive design, and is one of the leading
| | 01:36 | voices on designing across multiple contexts.
| | 01:39 | Of course, I also recommend checking out all
of the web and mobile design and development
| | 01:44 | courses in the lynda.com
online training library.
| | 01:48 | We're adding new responsive design titles
to the library all the time, so be sure to
| | 01:52 | check back frequently.
| | 01:53 | Well, that's all for now.
| | 01:56 | Feel free to drop me a line on my blog,
www.simpleprimate.com, or join the conversation on Twitter, where
| | 02:03 | you can reach me by tweeting
or following @jameswillweb.
| | 02:07 | Thanks again for watching everyone, and
I'll see you in my next lynda.com title.
| | 02:11 |
| | Collapse this transcript |
|
|
