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.
Visual information has always been tremendously useful for documentation. The assembly instructions for a piece of furniture from IKEA, for example, are almost entirely graphic so as to minimize translation costs.
But graphics also offer challenges when used in online outputs. Should we show graphics in the online help or documentation? Should we show them automatically or link to the graphics and leave it to the viewers to click on the links? What graphic file format is best? How big should the graphics be? And so on.
In recent years, single sourcing and the rise of new and extreme formats and devices, such as smartphones, have made these challenges even more serious. It was easy to add graphics to online outputs that display on large-screen devices like desktops or laptops, but what if you have to output to mobile devices with tiny screens? Or worse, what if you have to output to big screens and tiny screens at the same time? There's a technical solution to this problem that applies not only to graphics but also to almost any type of content, and that has the benefit of “future-proofing” our content as we move into new outputs.
The Technical Issue and the Solution
The issue is the size of a graphic in relation to the available space. This is rarely a problem on desktops and laptops, where screens are large enough to display all but the largest graphics without scrolling. On a small-screen device like a smartphone, for example, the same graphic may require horizontal scrolling. Consider the example in Figure 1, a graphic displayed on a computer screen versus a mobile device screen.
Figure 1.
Note the horizontal scroll bar on the mobile version. There is nothing inherently evil about horizontal scroll, but it does reduce usability, especially when it appears simultaneously with vertical scroll.
You could fix this by shrinking the graphic to fit into the available space, reducing it from 320 pixels to 240 pixels, for example. But that now makes the graphic look oddly small on a desktop or laptop screen. And what if you have to display the same graphic on other mobile devices with different screen sizes?
You could create a version of the graphic for each device and use conditionality to display the appropriate version on each device, but that quickly gets unsupportable as the number of devices goes up. A better approach is to switch from “absolute” size units, like pixels, to “relative” units, like % or em.
Figure 2.
Relative units tell the browser to display a graphic at a size relative to some other property that the browser knows about, like screen width. For example, setting the width to 90% rather than 320 pixels tells the browser to automatically display the graphic at 90% of the available screen width and lets the browser figure out what that is on each device. The browser is doing the sizing for you. For example, Figure 2 shows an image at a fixed width and using % (50% in this case). Note how the latter resizes (automatically).
Relative units aren't perfect. Browser support varies, especially in older versions of some browsers, so you need to know your users' configurations. (See www.w3.org/WAI/GL/css2em.htm for a discussion of relative size units in general, with a focus on the em unit. See www.webdevout.net/browser-support-css#css3units for a list of features supported by various browsers. The Length section of the table lists the supported size units.) I've also had trouble with graphics to which I've applied the % unit in tables in the ePub eBook format, but I'm confident that these problems will be fixed in new releases of the browsers and formats.
Consider also that while you may be able to relativize a wide graphic be fit into a narrow space, the resulting graphic may be too small to be useful. If so, you can either conditionalize and exclude the graphic or, if it's important, leave it and accept that the importance of the content sometimes justifies horizontal scrolling.
Summary
There's also a strategic reason to use relative units in graphics; it's the first step toward using relative units for anything you can—text, space before and after paragraphs, etc. The more styles whose size you make relative, the more work you offload to the browser and the more flexibly you'll be able to adapt today's content to new mobile and other new outputs that will appear tomorrow. Applying relative size units sounds like an incredibly granular code issue, but using this method actually has the strategic purpose of helping future-proof your content.
Neil Perlin (www.hyperword.com) has 32 years' experience in technical communication, with 26 in training, consulting, and development for various online formats and tools, including WinHelp, HTML Help, CE Help, JavaHelp, WebHelp, RoboHelp, ForeHelp, Flare, and many now known only in legend. Neil is a columnist and frequent speaker for STC, IEEE PCS, and other professional groups; a member of the STC's Boston Chapter; the creator and manager of the Beyond the Bleeding Edge stem at the STC Summit, and a 2010 STC Fellow.
