"White Papers" Need to be Mobile, Too

By Dennis D. McDonald

Are your white papers easily accessible on mobile devices? Viewed by some as “old school” marketing devices, others still use and expect them. Just last week, for example, I was asked for a set of my own white papers by a business prospect. That experience led me to write this article.

A longstanding tradition in the consulting, think-tank, and tech worlds, “white papers” are normally longer than typical ads or blog posts. They usually (but not always) try to present information in an objective, factual, or semi-factual manner, even when their primary purpose is as advertising. They often incorporate sophisticated graphical or photographic elements that may or may not translate well to a smaller screen.

The typical white paper’s content can come from a variety of sources, including original research, analysis of existing information, or as part of a communication or marketing plan associated with a product or service. White papers often come in series and may describe a set of related topics, issues, products, or services.

Often when the white paper is listed online the user must first fill out a form providing basic individual and organizational information before the white paper can be downloaded to the user’s device.

I’ve written my share of white papers, both on my own and under contract to clients. While I would never argue with the preeminent roles that the web and personal salesmanship play in commerce, I also believe the white paper has a role to play both for authors and for users:

• For the author or sponsor the development of a white paper forces the thinking through of both content and presentation for a key topic. People can spend significant amounts of time on writing and editing white papers especially when they are being developed for promotional or commercial purposes. The papers need to look good, and they need to give the reader a positive impression of the author and the sponsor. In other words, white papers usually — and hopefully — aren’t just throwaway items.

• For the user, the white paper can be an appropriately digestible and understandable container of information on a topic of interest. Its standalone nature as a named document helps identify and concretize the concepts it presents. This helps to focus the user’s attention on an important topic in a way that is qualitatively different from a meandering surfing of the web. Also, requiring the filling out of a form to access the white paper, while annoying, can reinforce that the white paper is somehow “special,” even in those situations where its content is primarily promotional.

Finally, white papers are usually designed and formatted to be printed on paper; doing so gives the user another opportunity to pay attention to and connect with the contents of the paper.

Assuming the white paper has not outlived its usefulness — which I believe — its format and to some extent its content needs to be adapted for use on mobile devices such as smartphones and tablet computers.

I discovered this recently while reviewing my own web site’s list of downloadable documents, most of which are made available for free as .pdf documents. When I started reviewing these documents on my own smartphone and on my black and white Kindle, I discovered some readability issues:

• Displaying .pdf versions of my longer blog posts on an iPhone presents some legibility issues, even when viewed horizontally. Genrally, the ten-point font size I have been using when generating the .pdf version via Google Docs is too small. I need to enlarge the text, just as I have enlarged the text of my other web site elements.

• When I send a .pdf to my Kindle, the .pdf text is just legible. When two-column .pdf documents are sent to the Kindle, especially when graphics are incorporated, the document may not be legible even when viewed horizontally.

• When I send an HTML document to my Kindle the straight text displays nicely, but more complex elements such as lists or tables may not be displayed accurately.

• Embedded links included in the .pdf are not always usable via the black and white Kindle’s modest web browser.

So, if you are going to publish “white papers” and you want the user experience to be positive, you need to give some thought to what users will see when they download the document to read it, especially if they intend to read the document on a mobile device of some sort.

As I increase my use of my Chrome browser’s Send to Kindle for Google Chrome extension, I expect I’ll be testing out the ability to read a web based document on my Kindle reader, either on the actual Kindle or on the iPhone’s Kindle app. I’ll be paying close attention to the experience.

Most of the documents I currently make available as .pdf documents for downloading are my longer or more “analytical” blog posts, e.g., like this. They rarely incorporate complex graphical or tabular elements, but if they did, I might need to redesign the documents to accommodate smaller screens and touch interactivity.

The following are some suggested “guidelines” for the publisher of white papers; I welcome comments and suggestions:

Proposed Guidelines for Making “”White Papers” Accessible on Mobile Devices

1. If you require a form to be filled out in order for the user to “qualify” to download your white paper, make sure the form is accessible via mobile devices. This may require presentation of a special mobile targeted form if your system does not automatically adjust elements to the target device.
2. If you incorporate web links in the white paper under the assumption it will be viewed online consider making the targets of those web links mobile-accessible as well. If you expect to have the white paper printed, make sure the linked URLs are spelled out and visible. (I’m guilty of not doing the latter.)
3. Avoid tables and complex graphical elements if you intend the document to be read on a smartphone.
4. If you think users will “send’ a white paper to another device for reading (e.g., a Kindle, a Nook, a small tablet computer) make sure it displays well after being sent.
5. Does your white paper contain a lot of fine print? If you want the fine print read, consider adjusting the text size upwards.
6. Portable devices often allow for easy switching back and forth between a vertical and a horizontal screen orientation. Documents such as .pdfs that are fixed width do not automatically adjust given the fixed line length. Consider increasing the font size to accommodate reading in either orientation.
7. Consider converting two column to one column documents. (To see what a difference single column displays makes on a smartphone screen check out the various news readers and aggregator apps that format news items into highly legible single columns of text).
8. If you do use .pdfs for distributing white papers make sure the .pdf conversion process keeps web links alive after the conversion.
9. If you publish a series of white papers make sure they are formatted similarly both for printing and for web and mobile display. (I’m still working on this one myself.)
10. Assuming you want people to contact you after reading the white paper, don’t forget to incorporate contact information in the white paper.

Don’t laugh about #10. My wife and I sent out our wedding invitations without including the date of our wedding. Ever since then I’ve been very careful to review the contents of standalone documents, regardless of where — or how — they will be read!

Copyright (c) 2012 by Dennis D. McDonald