November 2011
By Nad Rosenberg

Nad Rosenberg is president and founder of TechWRITE, Inc., a technical communciations company based in the US. Before starting TechWRITE in 1985, Nad managed documenation departments for several large corporations.

Mobilizing your content

The mobile device has affected us tremendously – certainly in our personal lives – and now it is about to affect our professional lives, if it hasn’t already done so. This year, smartphone sales will equal PC sales. The proliferation of content on these devices is so great that some people have compared the mobile phenomenon to the invention of the printing press. But what does this mean for technical communicators? Certainly there are many new opportunities for technical communicators in “mobileland”. And as always, opportunities bring along their own set of problems and solutions.

Let’s look at some statistics that illustrate the size and growth of the “mobile monster”:

  • There were 500,000 Android activations per day as of June 28 (an increase of 25% over the previous month).
  • By 2014, more than 1 billion information workers will be using smartphones.
  • According to the International Data Corporation (IDC), by 2020 there will be 35 billion connected mobile devices.
  • U.S. consumers spend as much time with mobile media as they do with print magazines and newspapers combined.

The impact on society can well be compared to the Gutenberg era. An interesting quote from Matthew Battles, a Harvard historian and librarian, reveals: “It took writers, authors, and publishers a while to figure out how to use the press, how to organize information, and tell stories in new ways. It took awhile for the format to catch up to the new tools and technology.” Obviously, some of the same things are happening today.

The mobile era brings many new opportunities to technical communicators: In this article, we’ll look at the following mobile content platforms:

  • Mobile apps and mobile web sites
  • PDFs
  • eBooks

Mobile apps and mobile web sites

Mobile apps (applications) and mobile web sites pose a unique set of challenges in regard to content and usability. But before we discuss these, here’s a little background:

Native apps

Mobile apps that run on the device’s operating system are called “native” apps. They are typically written in C, C++, Java ME, etc., and are considered “real” apps by some people. Games as well as entertainment, reference, and educational apps are some examples of native apps. Probably the most significant fact about native apps is that they do not need connectivity to work – and because of this, they run faster than non-native apps.

Since they reside on the mobile device, native apps can store and retrieve phone data. Further, they can take advantage of the mobile device’s hardware features such as the accelerometer, camera, and compass. While this is certainly a plus, the negative side is that native apps can run only on the devices for which they were designed. The net result is that, for example, you cannot use a native iPhone app on your Android.

Mobile web sites

Mobile web sites can be designed to look just like native apps (and are called web apps), or they can simply be web sites optimized for the mobile environment.

They run inside the browser on the mobile device, even though with web apps you often cannot see the browser buttons. They are typically written in HTML or JavaScript, and they generally cannot use the device’s resources (contacts, calendars, photos) or features (accelerometer, camera, compass).

But mobile web sites have one major issue – they require internet connectivity and thus tend to be slower than native apps. On the plus side, mobile web sites can be accessed on any type of smartphone or tablet and on some eReaders.

Hybrid apps

Hybrid apps are a combination of native apps and mobile web sites. Many hybrids receive data from the internet (and thus require connectivity), but they also perform functions in native mode on the mobile device.

Design factors

So now that we’ve reviewed the types of mobile apps, let’s take a look at some of the factors that we, as technical communicators, need to deal with when working with mobile apps and mobile web sites.

Size matters

First of all, in the mobile environment size really does matter. While the size of mobile devices is definitely a blessing for users, it’s a curse for designers.

As you can see, there are considerable differences in size and resolution.

Mobile Device

(number of distinct pixels in each dimension)

Screen Size
(measured diagonally in inch)

iPhone 4

960 x 640


Droid X

854 x 480


iPhone 3GS

320 x 480


BlackBerry 9800 (Torch)

480 x 360


iPad 2

1024 x 768


The bottom line here is that you cannot simply shrink what’s on an existing web site and slam it into a mobile device. You have to redesign the look and feel, the text, and the graphics.


“Touch” is next on the list of differences between the mobile and the PC/Mac platforms, and it also significantly affects design. Many mobile devices are touch-oriented – or at the very least, they’re not mouse-driven. Essentially, these devices are gesture-oriented, and there’s a vocabulary of gestures that technical communicators should be aware of, including:

  • Tap – To press or select a control or item (analogous to a single mouse click).
  • Flick – To scroll or pan quickly.
  • Double-tap – To zoom in and center an image. Double-tap to zoom out.
  • Pinch open/close – To zoom in/out.
  • Shake – To initiate or undo an action.

Touch functionality has many ramifications for technical communicators. First of all, icons need to be large enough to accommodate a finger tap. According to Apple, that means 44 points by 44 points (see the link to Apple design standards under References). Apple defines these “points” as areas drawn on a screen.

On a standard-resolution device screen (iPhone 3GS), one point equals one pixel. But other resolutions may have a different relationship. On a Retina display, i.e., the iPhone 4, one point equals two pixels. And of course the bad news here is that in some circumstances, you may need two sets of graphics, one for standard resolution and one for Retina displays.

Along these same lines, you have to make sure to leave enough space between links – otherwise a large fingertip might tap the wrong link. For this reason alone, you can see why standard web sites should not be ported directly to mobile.

Loading speed

Interestingly enough, loading speed affects design. Unless you’re developing a native app, such as a game, your mobile device will probably need to download at least some information from the internet. As most of you probably know, mobile download speed will depend on many factors, but one thing you can count on is that it probably will not be as fast as your PC or Mac. This translates into a design issue, specifically the need to reduce the amount, size, and complexity of graphics.

Then there’s the variability issue. On mobile web sites, for some users, pages will download instantaneously, while for others, it will take much longer. It often depends on the user’s WiFi access. Since you have no control over this, it’s best to make sure pages load as quickly as possible. In other words, keep the graphics at a minimum.

Additionally, you’ll want to reduce the need to move through a lot of links to get to the point, because it may take time to download each page. And don’t forget that there are some PC/Mac features, such as rollovers, that won’t work on mobiles. (If you’re not using a mouse, you can’t have a rollover.)

One more thing – make sure your layout is flexible. You never know which device someone will use to access your site or what the orientation will be (portrait or landscape).


Navigation on mobile devices needs to be significantly different from PCs or Macs. Because of the issues of physical space and graphics downloading, the typical graphical tabs at the top of the page are not suited for the mobile environment.
Most people start using their smartphones in portrait mode, where there’s just not enough real estate to build a long row of tabs. Other navigation solutions need to be found, and you can get some good ideas from looking at a variety of mobile web sites (see References for links to interesting sites).

Quick access

It’s important to remember when and where people access their smartphones. It’s usually when they’re away from home or the office and want to get some piece of information quickly. So you need to make sure important information is positioned appropriately and chunked adequately so users can get what they want as soon as possible. And keep in mind that nobody wants to read a long article on a mobile.

Additionally, no one wants to do complicated searches on their smartphones. It’s difficult to enter text on a mobile device, so you should reduce the need for text entry. If possible, provide drop-down selections instead of making users type full search criteria.

Test, test, test

Before launching your app, make sure it’s been tested on many different devices. There are mobile simulators on the internet, but nothing works as well as testing on a real device. The guiding principle when moving to mobile is KISS, the famous acronym that stands for Keep It Simple, Stupid. Basically, with mobile, the simpler, the better.


PDFs are often accessed on mobile devices. Most of the problems with PDFs are exacerbated on smartphones, in particular. Many smartphones come with PDF readers. But if they don’t, you have to install the app. On some phones, even when the reader app is installed, you may have to wait for it to load when you click on a PDF link.

The genesis of most PDFs is a Word document, which is designed for the printed page (8 ½ by 11 in the US and A4 elsewhere). This means that when you access a PDF on a smartphone, typically the type is too small.

If you or your customers are using the older PDF readers, you have to enlarge the PDF manually and then scroll horizontally to read it (which is annoying). However, if you use Adobe Reader X or some of the non-Adobe readers (e.g., GoodReader), you can enlarge the text, and it will reflow, that is, readjust its size to fit the device. Note: At present, Adobe Reader X only works on the Android and Nokia. So if you really want PDFs to be legible on your smartphone, you may need to advise your users to select the appropriate reader.

One positive note about PDFs is that they are easily legible on the iPad, primarily because the iPad’s larger size and aspect ratio are more similar to the printed page.


eBooks are electronic books that can be easily read on special devices called eReaders (like Amazon’s Kindle or the Barnes & Noble Nook), or they can be read on smartphones or tablets if there’s an eReader application installed (there are many free or nearly free eReaders available).

The number of books published on the eBook platform is growing exponentially. Here are some interesting facts:

  • In February 2011, US publishers sold more eBooks than they did books in any other format, including paperbacks and hardcovers, according to a report from the Association of American Publishers. This is the first time ever that eBook sales have surpassed those of all other formats.
  • The government of South Korea has said it will replace paper textbooks with electronic tablets in all state-run schools by 2015.
  • The share of adults in the United States who own an eBook reader doubled to 12% in May 2011 from 6% in November 2010.

This has significant ramifications for technical communicators.

Reflowable text

The big advantage of eBooks over PDFs (viewed on many PDF readers) is that the eBook text is reflowable. This means the text automatically adjusts itself for legible reading according to the size of the display. There’s no horizontal scrolling to finish a sentence. The user can adjust the size of the text to his or her liking, and the entire book readjusts to fit appropriately on the screen. So if the text is too small, you can enlarge it, and all the text in the book will adjust perfectly.
The other plus about eBooks is that there are no gaps between pages as with PDF, and readers typically swipe horizontally to move to the next page.

Other nice features

The library management tools that come with most eReaders provide many other great reading enhancements, including:

  • The ability to change font selection and size – a nice way to accommodate different reading preferences.
  • Night reading – which lets readers change the book’s background color to black and the type to white – a perfect feature for a road warrior stuck on an airplane in the middle of the night.
  • Search, annotate, and bookmark – all handy tools if you need to find and collect information for future reference.


Creating your own ePubs

One of the most interesting things about eBooks, is that you can make them yourself using the open source ePub standard – you don’t need the resources of a large publishing house to tap into this new mobile content platform. An ePub, which is based on HTML/XHTML, is really just a .zip file that contains the necessary files for display on an eReader. ePub is the most widely used eBook format and is supported by all major eReaders except Kindle (but that is about to change).

To create an ePub, all you need is some software, a formatted document, and some time (more time if the document’s formatting isn’t simple). The bottom line is that once you’re done, you can easily read the document on a smartphone, tablet, eReader, or even a PC or Mac.

You can create an ePub from many different types of documents. HTML is the easiest format to convert from, but you can also convert from PDF, FrameMaker, RTF, and TXT.

To perform the conversion, you can use Calibre, the most popular free ePub conversion software (, or a commercial software package such as Adobe’s InDesign.

The one major problem with ePubs is that complicated formatting (especially complex tables) will undoubtedly need tweaking following the conversion. So if you’re going to jump into the ePub world, you should have at least a basic knowledge of HTML. To perform post-conversion editing on your ePub, you can use Sigil ( a free editor, which provides both WISYWIG and code views of the ePub.

The future of ePubs in tc

Although ePubs are now primarily published for the commercial book market, it seems likely that this format could soon move into the world of technical communications. As with most mobile technologies, ePubs (plus other forms of eBooks) are rapidly evolving. Many of the ePub issues that require HTML tweaking are sure to be improved in future versions of the standard and the software on which it’s based. Further, as the proliferation of ePub continues, the software used for ePub creation is bound to improve in terms of options, usability and power. And once this happens, it seems likely that technical communicators will be producing documents in ePub format.

The bottom line

The mobile monster is basically good news for technical communicators. Many segments of the mobile industry can use people with our talents. And, as always, it’s a matter of involving yourself in learning new technologies and convincing your companies, customers, and colleagues that you can add tremendous value in taming the mobile monster.


Examples of mobile web sites: