By Joe Welinske
News flash! We have a population of computing device types that is rapidly growing, and it is not the familiar desktop. For most of the past two decades, personal computing consisted of a few variants of a box, a screen, a mouse, and a keyboard. We now have many hundreds of small-yet-powerful device types that people are using on the go to do work and consume information. The mobile app ecosystems have changed people’s perceptions of what to expect from their software and the content that is presented to them.
A big question for technical communicators is how we can continue to contribute our skills in a rapidly changing world. This article is based on practical work with the presentation of information on a variety of devices. It describes a strategy for how to author and deliver information for multiple device types.
A strategy for supporting mobile apps starts with defining what that term really means. Generally, mobile apps are a new generation of software platforms designed for the iPhone, Android, and Windows Phone. But the mobile app category also includes Web-based apps that are based on open standards. The Apple ecosystem with the iPhone and iPad is fairly easy to support with just a half-dozen devices to deal with. On the other hand, we have Android where there are thousands of different device types. Windows Phone has fewer users, but it presents a radically different look and feel to the other two platforms. We also have emerging platforms for automotive and home entertainment systems that are going to be widely used in the coming years.
The question for information developers is how to deliver information to these platforms and their associated devices in a way that is both efficient and graceful. With respect to grace, you don’t want your user to have to pinch and zoom on their device screen to be able to effectively read your information. Ideally, you want that information to adjust automatically, in a smart way, for each particular device. The efficiency part of the puzzle relates to the need for some form of automation to display your content gracefully on this emerging avalanche of devices. It is impossible to customize content manually for all the possible variants.
Relatively small screens are a big part of the challenge we face. But it’s more complicated than that. Retina displays on certain devices let the user see more information without increasing screen size. User interface elements scale differently on different devices. The various platforms have proprietary coding issues that crop up. And mobile devices and software tend to follow a quickly iterating development timeline. All of this adds up to a lot of stressful issues that technical communicators haven’t previously had to deal with.
One solution is a with a single-sourcing scheme that employs adaptive content and responsive design. Responsive design makes it possible to automatically adjust the way our information flows within the screen real estate of a particular device. Adaptive content displays information when and where it is relevant. In Figure 1 shown below, you have a single source page of information coded in HTML/CSS that is displayed differently on a desktop monitor, an iPad-style 10″ tablet, a Nexus-style 7″ tablet, and a smartphone.
Media queries determine which CSS style sheet (or style sheets) will be used, depending on the characteristics of the digital device. For example, you can write a media query that applies your smartphone.css style sheet if the maximum width of the device is 480 pixels and below. At 481 pixels, your tablet.css style sheet takes over.
The change in the content from device to device is not purely for looks. It also represents an understanding that using a site on a mobile, small-screen device means the user is likely interested in less, but more focused, information. Using a bus schedule app while sitting at home at your desk is a different experience from walking down the street trying to catch the bus. We can use our skills as information experts to adapt our content to what is appropriate in a particular context.
On the technology side, Web standards make it possible to automatically adjust the presentation of content based on the attributes of the various devices. HTML5, CSS, and Media Query can be used in concert to get the desired results. Using HTML and CSS, our content pages can become object-oriented data repositories. CSS makes it possible to turn any text or image into an object that can be hidden or revealed. Information that is appropriate for display on a 10″ tablet may not be useful on a smartphone-sized device. The way you tag content will be based on making intelligent decisions about when and how to reveal your content. Applying different style sheets to a page of HTML can completely change not only the presentation of the content but what content is presented.
In Figure 2, the universe of devices to be supported has been reduced to four broad categories (or buckets). Starting from the top left and rotating clockwise, there is the smartphone, the 7″ tablet, the 10″ tablet, and the desktop/laptop. Each category represents different attributes. Screen size is the most obvious attribute, but it can also include resolution, platform, and others. A style guide is then constructed for each category. The style guides describe the information types that you want to display and the associated style codes to make that happen. For each category, you create a single CSS style sheet.
One additional piece of technology is the Media Query. This W3C standard is used widely in mobile app development. Every device that requests a page of information from a server is also announcing its attributes, like screen resolution, browser-type, etc. Media Query can interpret this information and use it to assign the appropriate style sheet to a page of requested content. The Media Query becomes the dispatcher, making sure that the presentation and date match the attributes of one of our device categories.
If you have thoughtfully developed your categories, you will find that it can scale well for future devices. As new devices appear with similar attributes, like screen dimensions, those devices will automatically fall into one of these categories. The existing style sheets and media queries continue to work automatically with the new device types. For example, when the iPad mini appeared on the market, it fit right into the 7″ tablet category. Of course, there will be some outliers. The iPhone 3G doesn’t comfortably fit in the smartphone category anymore because of its limited screen resolution.
As new devices appear, it may be necessary to create new categories. For example, the Samsung Note 2 is much bigger than most phones but smaller than tablets. In the future, we may need to add categories for automotive and home entertainment systems.
The use of conditional text is more valuable than ever. Conditional text has been around for many years for making adjustments to documentation for different contexts. Now it has a huge place at the table in terms of being able to provide single source content for different device types—recognizing that you may want to write information differently for different devices. For example, you might have a full paragraph of text to explain something in a desktop browser, but for the small screen you may want to use a single sentence. In your single-source page, you would have both versions of the text. Each would be tagged with the appropriate style code so they appear in the right version of the content.
Anytime we enter into a relatively involved scheme like what I’ve just described, it helps to have tools to smooth the way and provide a consistent and reliable output. Prototyping tools are going to be just as important as authoring tools, and you may not find one tool that can do a great job at both. Much of the key work in developing the responsive design and adaptive content comes up front with the development of your style guide and style sheets. You need to experiment with a variety of styles to decide what looks good and works effectively for which categories of output.
Within each category you are going to have adjustments to text size, spacing, and page layout, and you are going to make decisions on what information types should appear or be hidden from view. For this kind of work, you may want to rely on a Web design tool which has been optimized for working with CSS. It should support the use of Media Query and allow you to easily view your output as it is intended to appear for a particular category of devices. Our traditional Help authoring tools do not necessarily excel in this kind of service (although that’s likely to change as those tools add support for this type of work). Once the prototyping phase is over, it is pretty simple to import your media queries and style sheets into other authoring tools and/or content management systems that support context-sensitive links, navigation, and search.
Speaking of navigation, you should seriously consider completely eliminating a hierarchical table of contents from any small-screen, mobile content. Usability tests repeatedly point out the limitations of this kind of approach. When people are confronted by a TOC on the small screen, they don’t like it, they don’t want to use it, and they usually fail to find what they are looking for. Many of our favorite Help authoring tools have features for transforming TOCs meant for desktop viewing into something that can run on a small-screen device. Unfortunately, just making it possible doesn’t mean it provides an acceptable, useful solution. Avoid them. They simply don’t work. Most successful apps take the time to redefine navigation for the small screen, often using a reduced and reorganized topic list.
Another content element to start thinking about is the use of different verbs for different device types. It can be helpful to build a language interaction table, as shown in Figure 3, where you define what verbs should be used for different device types like the mouse, touch, hand gestures, voice, etc. It is time to make some important decisions. Are you going to customize your content for different device types? Or will you try and use a generic approach? There are pros and cons to both sides. Many content authoring tools have the capability to use replaceable variables for verb choices. The language can then be changed automatically for different device types. The most important thing is to begin having this discussion with your team members and peers.
Finally, if you are creating information in support of a native app for the iPhone or Android or Windows Phone, you definitely want to display it within the app itself. You don’t want your information to be displayed in the mobile browser. This takes people out of their engagement with the app and makes it difficult for them to easily get back to the app they were in. If you are using HTML/CSS for your content you should display it in what is called a “Web view” in the native app. This is easily accomplished by the app developer and lets you maintain control of the development of your content.
Hopefully, this article has given you some ideas for how to gracefully and efficiently craft your content for the ever-growing population of devices. A carefully planned approach to responsive design and adaptive content scales well while ensuring a quality user experience.
Joe Welinske is a consultant and contractor specializing in software user assistance and content strategy. He recently wrote the book Developing User Assistance for Mobile Apps. Joe produces the WritersUA (WritersUA.com) and ConveyUX conferences. His website is Welinske.com.
