The Rise of the "Un-Desktop" and Responsive Design

By Neil Perlin | Fellow

This column presents overviews of new technologies that may affect technical communicators in the near future. If you have feedback, or would like to suggest topics for subsequent columns, please contact Neil Perlin at nperlin@concentric.net.

Consultants rarely make flat statements but I’ll make an exception for responsive design. In my opinion, responsive design is the most significant development in technical communication since the move from RTF to HTML in 1997. In this column, I’ll explain what responsive design is, why it’s important, and how it works.

What Responsive Design Is

Responsive design is a design and coding approach that lets us create one online output that looks good on any device in existence today and possibly tomorrow, no matter what its screen size and resolution.

The Children’s Museum of Pittsburgh site at https://pittsburghkids.org/ uses responsive output. See the site at full-screen in Figure 1 and the same site on a tablet-sized screen in Figure 2. (To simulate this, simply shrink your browser window.) Notice that part of the menu has been subsumed into the “More” menu item (see Figure 3). Clicking “More” reveals the hidden items. Also notice the number and size of the small images along the bottom of the screen. Reducing the image further, to a smaller tablet, produces what is seen in Figure 4. We’ve gone from four small images along the bottom to two larger ones. Scrolling down a bit reveals the other two images, also larger. And Figure 5 shows the same website on a phone-sized screen, again simulated by shrinking the browser window. The menu now shows what the museum considers to be the essentials—Visit Us, Call Us, and Find Us. All the other items are now subsumed into the Menu option at the upper right. The important thing is that you’re not seeing multiple outputs, each formatted for different screen sizes. You’re seeing one output that automatically reformats itself based on the device screen size, resolution, or other properties.

How Responsive Design Works

Responsive design uses three core elements—relative formatting, fluid grids, and media queries. Here’s a brief summary of each.

Relative Formatting

We typically specify text size in points: 72 pts = 1 inch. This is a familiar size unit from hard copy, but it’s less effective online because it’s “fixed” and doesn’t scale in browsers. The alternative is “relative” units that can scale in different browsers and on different devices. Commonly used units today are % and em. (See the W3C discussion at www.w3.org/Style/Examples/007/units.en.html#font-size.)

Using relative formatting lets developers create content that can resize relative to some other unit. As a simplified example, the % is relative to the size of the default paragraph style in a browser. If normal is 100%, setting h1 to 160% makes h1 60% larger than the default paragraph style, with the effective size varying by browser. If browser A’s default paragraph style equates to 10 pt, then a 160% h1 equates to 16 pt. If browser B’s default paragraph style equates to 12 pt, then a 160% h1 equates to 19.2 pt. This lets the content adapt automatically to the device on which it’s displayed. This relativity applies to other content elements, too. For example, we can express a graphic’s size as a percentage rather than a fixed size. So setting a graphic’s width to 50% lets it change automatically depending on the screen space. The same holds true for tables and other elements.

Fluid Grids

A fluid grid is a layout that can change in response to changing screen size. For example, you might start with a grid that looks like this:

But changes to this as the screen gets narrower:

We don’t see the grids behind the museum site but we do see its effect in how the layout changes. See www.1stwebdesigner.com/tutorials/fluid-grids-in-responsive-design/ for a good overview.

Media Queries

Media queries test for certain device properties and apply different styles based on the result. A media query might look like this:

@media screen and (min-width: 320px) {

}

This tests whether the device is a screen (a programmatically testable property) and whether its width is 320px or more. If a device meets these criteria, certain CSS settings take effect. This additional query:

@media screen and (min-width: 800px) {

}

This query then tests to see if the width exceeds 800px. If so, different CSS settings take effect. Each set of settings might reformat the screen or show or hide different elements, as seen in the museum site. The 320px and 800px figures are “breakpoints” and are the property at which the new CSS settings take effect.

Why Is Responsive Design So Important?

We usually create online content for desktop or laptop PCs. Their screens and resolutions started off big and got bigger over time, so we had all the space we needed. But when mobile devices with tiny screens came on the scene, we had to adapt our large-screen layouts to those tiny screens. This wasn’t too hard when the first mobile device appeared. We just created a smaller version of the full-screen output. Then the second mobile device appeared, with a different screen size. We created another smaller version of our output. Then a third, different mobile device appeared….

The problem is that, sooner or later, we’re going to run out of the resources to support all these devices. (There are now so many mobile configurations that the term “mobile” can be more accurately described as the “un-desktop”.) How do we output our content to look good on all those devices? The answer is responsive output. The museum site is a good example of that in a standard website. (To see others, go to “50 Best Responsive Website Design Examples of 2013” at http://socialdriver.com/2013/06/10/50-best-responsive-website-design-examples-of-2013/.) But we can also implement responsive design in our online help and content using our standard HATs (help authoring tools).

How Today’s Help Authoring Tools Enable Responsive Design

Responsive design is only four years old, described by Ethan Marcotte in the 2010 article “Responsive Web Design” (see http://alistapart.com/article/responsive-web-design). (It’s worth reading just for the rare opportunity to see an idea being born.) Implementation called for heavy code skills until our HATs added support for it. MadCap Flare, Adobe RoboHelp, and ComponentOne Doc-To-Help support it and other HATs probably do or soon will.

Working through a HAT eliminates the need for code skills. For example, Figure 6 shows the implementation in MadCap Flare 10, and Figure 7 shows the responsive design breakpoint selector in Adobe RoboHelp 11.

There’s much more to the responsive design support than what these two images show, but the point is that there’s no code involved. You can start experimenting with responsive design now.

Summary

Just as the move to online content eliminated the constraints of paper, responsive design eliminates the constraints of traditional PCs. It opens new opportunities for technical communicators by expanding the universe of devices to which we can publish our outputs. This is why I consider responsive design to be one of the most significant changes in technical communication in years.

Responsive design won’t be widely adopted within technical communication overnight. It took several years before online help became a significant force and before HTML became the dominant standard it is today. Implementation in legacy projects is likely to require the cleanup of a lot of local formatting, the adoption of platform-agnostic content standards (such as switching from SWF to HTML5 for movies), and the adoption of new standards for writing content (when the same content might appear on a PC and a smartphone, do we tell users to “click the button” or “tap the button”?).

Few of my training and consulting clients need responsive design yet, but everyone I talk to is aware of the explosion of new devices and the possibility of having to support them. Responsive output will help.

Neil Perlin (nperlin@nperlin.cnc.net) is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 35 years of experience in technical writing, with 29 in training, consulting, and developing for online formats and tools including WinHelp, HTML Help, JavaHelp, CE Help, XML, RoboHelp, Flare, and others now almost unknown. Neil is MadCap-certified for Flare and Mimic, Adobe-certified for RoboHelp, and Viziapps-certified for the ViziApps mobile app development platform. He is an STC Fellow and the founder and manager of the Beyond the Bleeding Edge stem at the STC Summit.