Читать книгу Building Responsive Data Visualization for the Web - Bill Hinderman - Страница 7

Before breaking out all of our tools, it’s important to set some guiding principles about how to build responsively responsibly. In this chapter, you will examine the foundations of responsive web design, including the guiding principles of your design process – being universal, flexible, economical, and specific. Also covered are seven focal points to build upon as our material becomes more technical.

FYI: This is the content you should casually drop into conversation with someone who can give you a raise.

The Gist

In May of 2010, Ethan Marcotte, a web designer and developer, coined the phrase “Responsive web design.” He did so in the still-accurate and still-important article here: alistapart.com/article/responsive-web-design. Think about that timing for a moment. In the previous chapter, you learned that the iPhone launch drastically shifted the personal computing market in 2007, three years before. And the mobile tipping point, that is, the point at which mobile devices began to outsell traditional computers, happened in 2011, one year later.

What device were you using at this point, and how regularly did you access the web on it? Largely, the mobile web was still a second-class citizen at this point, but that was a paradigm that was rapidly shifting. The timing of Marcotte’s article shows that the importance of a multidevice Internet had already begun to take hold, and users were no longer willing to settle for subpar web experiences on their mobile devices.

The concept, or goal, of responsive web design is simple: to design a website in such a way that it provides the optimal experience regardless of a user’s device. A website designed responsively adapts to the device’s viewport so that it appears to be designed for that device. This is achieved with a reliance on proportion-based grid systems, CSS @media queries, and flexible media sizes.

Responsive web design is the practice of building a website that is suitable on every device, and every viewport, no matter the size. It is focused on creating intuitive, natural experiences for everyone so that both mobile and desktop (and any other) users feel like a website was tailored for their device.

There are, in essence, two ways to approach building using responsive web design:

● Build for the limited user.

● Build for every user.

Building for the limited user means focusing mainly on building your core experience and enhancing. Building for every user means leveling the playing field for any class of device, and trying to optimize for as many viewports as possible. These two mindsets are not at all mutually exclusive. In fact, the first is encapsulated within the second.

That being said, when working on a project, you should consider your audience and your budget. As romantic as it sounds to create a perfect experience for every user, you will find yourself at one of two points:

● Optimizing for just one person.

● Broke.

The important thing is to know the intended users of your product, and optimize, as much as possible, for their use cases.

Building for the Limited User

The first way to approach responsive web design is to build for the more limited user – that is, the user without a large screen, an ergonomic keyboard, strong WiFi, and a desk in a quiet room to contain all these things.

You’re now building for people such as those on their morning commute, using a phone that’s run out of 4G bandwidth of the month, and whose train is about to enter a tunnel.

While it isn’t necessarily accurate that limited users must be on a phone, it’s a typical example that serves to illustrate how building for a small device with a potentially poor Internet connection is a good place to start. Think of this method as building mobile-first.

Until recently, web designers have approached a project by building out a richly featured desktop site, while leaving the mobile users as a secondary (or skipped) goal. Even as responsive web design has grown in use, often the plan is to begin with a “full” site, and work down by hiding features.

Flip that.

In the previous chapter, you have already seen that the future of the web is mobile, so your design needs to start where your users are. This means beginning with a focus on lightweight, performance-conscious websites built for the mobile user.

Building for Every User

It’s important to keep in mind, however, that your users are not just on their phones. Once you are accustomed to thinking about your design from the standpoint of someone looking at a small screen in a tunnel, you then have to remember that people will be consuming your content in more locations than desks and tunnels, and on more devices than smartphones. The fact is, we have absolutely no control over where our websites will be consumed.

That’s the point of the Internet: It’s universal.

This doesn’t mean the scattershot throwing of features that work best on a mobile device alongside those that require five screens in a control room at NORAD. What it means is following the same performance-conscious design that you would when building for the mobile user, then taking the time to enhance your website for different classes of device.

Some of the things you may want to consider include the following:

@font-face

background-size

border-image

border-radius

box-shadow

Flexible Box Model

hsla()

Multiple backgrounds

opacity

rgba()

text-shadow

CSS Animations

CSS Columns

Generated Content

CSS Gradients

CSS Reflections

CSS 2D Transforms

CSS 3D Transforms

CSS Transitions

Feature

applicationCache

Canvas

Canvas Text

Drag and Drop

hashchange Event

History Management

HTML5 Audio

HTML5 Video

IndexedDB

Input Attributes

Input Types

localStorage

Cross-window Messaging

sessionStorage

Web Sockets

Web SQL Database

Web Workers

Feature

Geolocation API

Inline SVG

SMIL

SVG

SVG Clip paths

Touch Events

WebGL

That list contains everything that can be tested for by Modernizr, a tool for feature detection. If it seems daunting, that’s because it is. This is typically far too much to consider in any one design (and any one reasonable budget). The important thing to remember is that none of these opportunities for enhancement are contingent upon another; and if you begin in the most accessible state, by building for the limited user, you have already jumped the first hurdle of enabling users to reach your content.

Adaptive vs. Responsive

The term responsive is still in its youth. Adaptive web design (at least as a phrase) can be seen as its older brother. Responsive and adaptive web design are very closely related, and are often used interchangeably.

The design techniques we use are encapsulated within responsive web design, which is a subset of adaptive web design, in order to create designs that dynamically adapt to different viewports and device features. Adaptive design can encompass numerous definitions, and it’s important to nail these down so that we can differentiate our more limited definition of responsive design.

The Broad Adaptive

“Adaptive Web design,” as I use it, is about creating interfaces that adapt to the user’s capabilities (in terms of both form and function).

Aaron Gustafson, Adaptive Web Design

The term adaptive web design is used in many ways that stretch and broaden its definition. Most accurately, it can be thought of as a big bucket into which we place all of our ways to adapt a website to the user.

Progressive Enhancement

In Chapter one, you were introduced to the concept of progressive enhancement. With its close ties to mobile-first web design, it’s easy to see why adaptive web design has been used interchangeably with that term. The basic structure of progressive enhancement is a website with content as its core, with everything else built upon that, progressively rising to meet a user’s needs.

At the base level, this is absolutely accurate. You are using a whole slew of client-side and server-side tools to build the best experience across any different environment. This means that interfaces adapt to the capabilities of the device and its browser.

Responsive Web Design

Unfortunately, the terms adaptive web design and responsive web design are typically used interchangeably. This is wrong and bad, and anyone I catch doing it will be removed from my Christmas card list.

As Ethan Marcotte defined it in his seminal 2010 article (http://alistapart.com/article/responsive-web-design), responsive web design consists of three things: grids, @media queries, and flexible media. That’s it.

Creating responsive layouts that work on any device is a crucial part of adaptive design, but it is just one part of a bigger mindset. If adaptive web design is the county fair, responsive web design is the pie eating contest – loud and important, and you’ll get your picture with the governor if you do it well enough, but it’s not the only part.

RESS

RESS stands for responsive design with server-side components. The bulk of what we’re doing responsively will be handled on the client. However, as much as possible, moving solutions to the server can not only make our pages more lightweight, it makes them more automatable. RESS techniques involve offloading some of the responsive work to the backend.

The RESS experience is created through normal responsive strategies, relying on progressive enhancement. The difference is that while under the same URL, the interface is changed in certain ways based on device classes.

At a high level, RESS works by recognizing the device’s user agent string (what kind of device it is) and sending that information back to the server when first making contact with the website. The server has a large library of different user agents. Connected to the data of these user agents are lists of properties that are then referenced to determine what type of payload should be given to the client.

We move this logic to the server in order to avoid sending unnecessary (or unused) content to a device. Using a tool like Google’s PageSpeed installed on the server, you can set variables from the device’s properties, and reuse them to send only the content you need.

As a basic example below, the PHP code pulls in a device library to find the width of a user’s device.

Using Google’s PageSpeed, you can dynamically replace the image’s source with a resized version, as referenced in the code below.

You’ll notice in Figures 2-1 and 2-2 that the image is exactly the same, but Figure 2-1 is much larger in both actual size and file size. If you were actually trying to show a giant image next to a small one, this would be what you want. However, when working on a responsive design, your media will most often be some fluid size that takes up a percentage of the device’s screen. As such, the two images would be displayed at the same size while being downloaded at the two very different resolutions.

Figure 2-1: Without RESS to handle image size, this image is massive.

Figure 2-2: With RESS, you can cut the image’s payload by sending a smaller size from the server.

This same technique can be used to send different CSS, JavaScript, or even direct users to entirely different versions of the page.

RESS is a powerful technique to eliminate bloat, but there is really no reason for it to be confused with adaptive web design. It’s simply another tool in your arsenal.

Limiting Your Adaptive Design Definition

Just as “adaptive web design” can be misused in the broadest sense, it can also be misused as very specific concepts. Again, all of these concepts are part of a greater web optimization scheme which we call adaptive web design.

Think of the limited adaptive design definition as a clunky way of trying to optimize for specific devices. Your goal should be to make something work for not just the screens you recognize and regularly use, but for those that you have never seen, and even those that haven’t yet been invented. Therefore, I’m presenting the following two ideas: device detection and adaptive layouts, only because they will come up in Chapters 3, 4, and 5. This is not an endorsement of either technique.

Device Detection

Device detection, typically transmitted through the device’s user agent string, is exactly what it sounds like: the process of determining an individual type of device and what features it has. While it sounds tempting to start designing by building for an individual device, you then have to build separately for every other device as well.

This concept is usefully abstracted with tools like Modernizr, or methods of RESS, by grouping devices into classes that fit into either a yes or a no category for individual features.