When your readers want to have their own hard- or soft-copy of your document, you have already halfway won. So, you should make that as easy as possible, even invite them to take a copy! This article will show you some ways to do that.

When your readers want to print out or download your document - that's about the best that you can hope for! Obviously, they found it interesting - expecting that they would like to refer to it again, some time later.

Alas, some publishers have not yet realized what an edge that's giving to them. (A rather deterrent example might show you what I mean click here! [+] )

As an online communicator, you need more than just a good  technical understanding . Even more than some  language skills . You should also have some gut feeling of your readers - what they will be interested in, and how to present it to them.

To  invite  your readers not only for  reading  but also for  printing out  or  downloading  your articles, that's much more than providing online a  PDF-version  of a  print  document. That's neither fish nor flesh. Moreover, it's taking ages to download it - perhaps only to see that it's not what you expected!

In this article I will show you a number of things to do that, thus fostering a loyal community among your readers. Let them feel, they can have your documents at their  full  disposal,  anytime  and  anywhere !

Printing

Presenting an online document such that it is easy to take a hard-copy of it, seems to be a contradiction in terms. After all, a print-out of an online document is  offline  by its nature - is this really a part of  Online Communication ?

Yes, it is. Don't forget - the purpose of Online Communication is to get across information that is relevant also beyond the time when the readers are sitting at the computer.

Let's take it simply quantitatively: The real online-time you spend for reading online information is just a minor fraction of the time you want to be able to apply that information. (At least today that's true, though it might be changing in the near future - see Future Outlook).

Things being as they are - there is still nothing better to make an information available  anytime  and  anywhere  than that 500 years old technology of printing it to paper.

So there is a good reason why you should make sure that your online documents are easy to print to paper. Still comprising as much information as possible.

Of course there are some restrictions you just can't avoid. Yet, at least you should be aware of it. For example:

• Structured vs. sequential presentation
• Hypertext vs. text flow
• Un-hide Hidden text

Click the list item you want to know more about!

Printing - Structured vs. Sequential

One major difference of Online Communication compared to writing on paper is the limited screen size. As a consequence, you need to deeply structure your subject (see this section in my article Online Communication: Unlike Writing on Paper!

Structuring, that means breaking down your subject into parts small enough as to fit into one screen. Of course, this will be possible only for  elementary information . Broader information should be presented in form of a list, with each item being about the title of a sub-section, providing a hyperlink to the pertaining sub-section. If you think it appropriate, you should place a few sentences in front of it. (For example, see how I did it in section printing that was introducing the sub-section you are reading currently!)

Reasonably, the sub-sections will not be presented next to each other but with some empty space between them. On screen, that is. It would be rather irritating to have the sub-sections scattered all over the paper, when printing the document to paper. Therefore you should use  flexible section breaks . For example,

1. Scroll by repeatedly pressing the  PgUp  or  PgDn-key. Note the empty space between the sections.
2. Now print out this document. (You don't have to waste paper, if you have print software providing you with a print preview.) Note that there are now empty spaces between the sections now!

Printing - Hypertext vs. Text Flow

When writing on paper, one page can comprise much more information than one screen. You can simply say something like "see above" and rely on that your reader will easily figure out what you mean.

In Online Communication, you should provide a hyperlink to a bookmark, suitable for scrolling to the place you refer to. You can even link to a specific place in a  separate  document. (You want to know how? Click here [+])

Printing - Un-hide Hidden text

• When writing an online document, keep in mind that you want to rivet the attention of different groups of readers:
  • Those who just want to get a  quick overview .
  • Those who know the basics already and came back to read  details .
• Whatever the group of readers, your writing should not significantly exceed  one screen .
  If you need more room for writing on a complex matter, you will need to do more  structuring .

General Information: Information that will be interesting to all readers to some extent.

For it, you have one screen per section to unfold it.

Specific Information: Information that will be interesting only to specific groups of readers.

For it, it's no good idea to use up the scarce screen space - irritating readers who are not interested in it  . To require them to skip it, gropingly looking for the right place to resume reading.

Storing

Printing is the best that you can do to make an information available when you are away from the computer - as you are  today  for a substantial part of your time.

But let's think ahead now: In the near future, you will probably have a computer right at hand most of your time awake. Though it will hardly be anything you would perceive as a "computer". (See Future Outlook) Then storing online information could become even more important than it is today.

Storing an online document preserves much of its structuring, interactivity, etc. Yet there are also some things you should be aware of, if you want to make your documents easy to consume. (Probably this will be  reading , most of the time. But  hearing  and other senses might become relevant, as well.)

Examples of the things to remember:

• Compatibility
• Environment
• Layout
• Add Keywords + Text Metrics!

Again, click the list item you want to know more about! And don't forget: Try it Yourself: Download this Article!

Storing - Compatibility

• Online its documents are looking quite  attractive , even  informative  sometimes. So you decide, you would like to download it for including it in your archive.
• Yet, when you click menu  File , item  Save As ..., the problems are starting: You get an error message  Page will not be stored completely  (or something like that). 
• Even if it is stored, you're in for disenchantment when you try to activate your local copy: Many of those features that were looking so great (online!) are now just   dead  .
• If you are lucky, you can bring some of them back to life (offline!).
• But usually this will mean a good deal of work.
• And even if it is back to life for the moment - a few weeks later, when the Internet cache on your PC has changed, some of the externals associated with the downloaded document are no longer available.

• Externals
• Flash etc.

Click the list item you want to know more about!

Compatibility - Externals

When clicking  File  -  Save As ...  - file type:  web site, complete , only the HTML file and its  direct externals  (files accessed by  src=  or  href=  with extension  css ,  js ,  jpg ,  gif  and some other image file types) are stored.

Files accessed within  window.open  are not stored automatically.

Therefore, if you have an image that you feel it should be presented in an extra window, you better code it as e.g.

Compatibility - Flash etc.

In addition to static images (format  jpg ,  gif , etc.) recently newer, dynamic images such as Macromedia or Shockwave  Flash  ( swf ) and others have been adopted.

That's fine, only - they are mostly handled like "something completely outside" of what we are used to. With the effect that online documents with such embellishments.

In fact, they should be handled just like the well-known static images of type  jpg  or  gif . The coding could be quite the same, with the only difference that there is " swf " in place of " jpg ". Then the Flash-images would be stored automatically and could be called from the offline-copy just as it was online:

Storing - Environment

Frequently, when you download an online document and try to activate the local copy, you get an error message like this:

When you overcome your frustration and look more closely what happened, it turns out:

• Upon starting, somehow a JavaScript function e.g.  OpenWindow  was called.
• Somewhere in an external  js-file that function is defined as

  function OpenWindow(url) { window.open (url, …); }
  

• Going into runtime details, you find that variable  url  (which is the URL of the web site where you downloaded it from:  http://… ) now is the path on your hard disk where you downloaded it to ( C:/… ) And from that location, of course, the object required is not available.
• This problem would have been easy to avoid - simply by adding one code line:

  function OpenWindow(url) {
   if(url.indexOf('http:')!=-1)        // additional code line  
                 window.open (url, …); }
  

However, the publisher of the document just didn't realize that anyone of the readers might find it so interesting to take a copy of it. He/she had simply taken for granted that this document would be a part of the web site forever!

Otherwise the publisher would have provided that simple code line  if(url …)  Just a trifle, but overlooking it might pose a major obstacle towards the readers' loyalty!

Storing - Layout

One problem you find at many web sites is that they have been implemented with obviously just one browser in mind:  the own one . Everything looks perfect if you your browser has exactly

• the same screen resolution as the implementer's
• the same color depth as the implementer's
• been set to the same letter size as the implementer's.
• etc.

If not,

•  line  and  page breaks  tend to appear at places where they are completely ruining the contents that are supposed to get across
• text might be written in a  letter size  that's awfully  hard to read 
•  text and background color  have so little contrast that they seem to merge into one another

That's even the more irritating since HTML offers all kinds of flexibility. Most of these restrictions are not necessary if you

• Use <NOBR> … </NOBR> brackets where a line or page break should never occur - e.g. (click [+])

  Use <NOBR> … </NOBR> brackets

  around hyphenated-words (that is "<NOBR>hyphenated-words</NOBR>" in HTML), etc.
• Use a hard space where a line or page break would be vexing the readers - e.g. (click [+]

  Use Hard Space (&nbsp;)

  A line or page break would be confusing between  number  and  scale unit  (e.g. "50 %" should be coded as "<NOBR>50 %</NOBR>")
  )
• When defining dimensions, use percentages instead of absolute numbers - e.g. (click [+])

  Use Percentages Instead Of Absolute Numbers

  If you want a table column, a <DIV> width etc. to be just half of the screen, don't code it as  width=400 . (This would be Ok only if the monitor is set to a resultion of 800 x 600!)

  Code it as  width=50%  instead.

• Consider to space layout elements more closely - e.g. (click [+])

  Spacing Layout Elements More Closely

  By default, HTML uses the precious screen space quite lavishly.

  For example, between the previous and this paragraph there is a default spacing.

  Between the second paragraph and this one, the spacing has been reduced by 10 pixels.

  You can achieve that by coding  STYLE=margin-top:-10"  to the <P> tag:

  <P STYLE=margin-top:-10"> … </P>

  E	For example, this section "Layout" would have been scattered across several screens if I had not considered the spacing. It would have been hard for you to make any sense of it!

• Use only standard HTML colors, if possible - e.g. (click [+])

  Use Standard Colors!

  Can you read this?

  Could you read the previous paragraph? Probably not. It was colored by

  <P STYLE="color:#FFB6C1; background-color:#FFB6C0">

  But this paragraph is colored by

  <P STYLE="color:blue; background-color:lightpink">

  E	The first paragraph was colored by a color number ( # … )This can come out on screen very unfortunately, and even inconsistently on different screens. In the second example, standard HTML colors were used. You can rely on that they will look fairly the same on all screens.

Storing - Add Keywords + Text Metrics!

To you, the author, your document seems quite unique. To your readers, however, your document is just one among many (perhaps thousands) of similar documents.

So, when they are downloading and storing your document, you should make it easy to your readers to store it in an organized way, in any kind of  data base . Such that they will be able to retrieve your document easily among thousands of others. Even at a time when it is long since they stored it, when they might have forgotten already that they have it in stock.

Therefore, the author of an online document should remember to add some things to his/her brainchild that are easy to overlook when writing a paper document:

• First and foremost, come up with a collection of keywords. In which contexts would you like your document to be remembered?

  E	A good place to look for meaningful keywords are the titles of your document, words marked somehow (bold, italic, etc.), or capitalized words. In short, words that a  web spider  would use to index the page./TD>

• The other thing you should add to your document is a bit elusive. Summarizing they could be called text metrics: Data that is not meaningful in the context of your topic but are relevant to your document itself. "Hard data" helping to efficiently store your document and to follow it up if necessary. Examples:
  • author's name
  • any indication as to the author's relationship to the topic
  • how to contact the author
  • word count
  • file size
  • (and you might think of many other things to include here)

Try it Yourself: Download this Article!

1. well structured, for making it easy to read it on screen (even under different browsers)
2. many temporaries included,  on screen  popping up when clicked by the user,  in print  they are all visible permanently
3. copy-friendly:
   • many runtime features, giving a smooth, compact print document when being printed out
   • with keywords + text metrics, in order to help readers to store it in an organized way
   • adapts itself automatically to the environment it is stored to

• print it out online,
• or download it and try (even when storing at different places):
  • read it on screen offline!
  • print it out offline!
  • include it in a data base!

Highlight "Copy-friendly!"

Perhaps you don't want to look like a cheap-jack. But after all - what good is all the effort you took for making your document copy-friendly, if the readers don't know that you spent some thinking on it? So, invite them to take their own copies or to print it out!

A simple, not too blatant means to do that is a badge "Copy-friendly!" somewhere near the beginning, right on the first screen.

If you want to provide some additional information what this means, you can make that badge the anchor of a  TempInfo  giving some details. (Look at the first screen of this article, how I did it!)

Appendix 1: Implementing  Flexible Section Breaks 

• on screen generates sufficient empty space between sections for making reading easy: When reading one section, the readers should not be confused by text belonging to the next section.
• on paper these empty spaces are eliminated, for providing a smooth text flow.

• HTML of Section Break
• Actions  onbeforeprint  and  onafterprint 
• JavaScript:  OnBeforePrint  and  OnAfterPrint 

HTML of Section Break

We want a  Flexible Section Break  to be easy to handle by one code line only:

E	What  if(athome)  is good for, see section Flag athome

This can be implemented as a <DIV> with  CLASS="ScreenOnly"  that is normally visible. Only for printing its  display  is temporarily switched to  'none'  So it could be coded as follows:

In JavaScript this could be done by

Actions  onbeforeprint  and  onafterprint 

In JavaScript, an impending printing can be detected by testing for event  onbeforeprint .

When the printing is over, an event  onafterprint  is created.

These events could be intercepted by coding the BODY-tag as follows:

E	OnBeforePrint()  and  OnAfterPrint()  are two JavaScript functions to switch the DIV's  display  off and on again. See next sub-section.

A more efficient method, however, is to assign these functions to the events right within another JavaScript function (e.g.  SectionMenu  Thus it is done sort of "automatically": You don't have to remember that complicated <BODY> tag when writing your online document. This is done by:

E	Notice that both functions must be coded without  ()  here. The reason is that their  entry point addresses  are assigned to the events, not their  return values .

JavaScript:  OnBeforePrint  and  OnAfterPrint 

You will remember that in a previous section all section breaks have been declared with  CLASS="ScreenOnly" . Thus we can easily sort out all of these objects:

E	You better don't test for  obj.className=='ScreenOnly'  but for  obj.indexOf('ScreenOnly') . Then this class can be combined with any other class.

So both functions could simply be coded as follows:

<SCRIPT>
function  OnBeforePrint()
{ for(i=0;  obj = document.all(i); i++)
    if(obj.indexOf('ScreenOnly')!=-1)  obj.style.display = 'none';
}
function  OnAfterPrint()
{ for(i=0;  obj = document.all(i); i++)
    if(obj.indexOf('ScreenOnly')!=-1)  obj.style.display = '';
}
</SCRIPT>

Appendix 2: Implementing  Flexible Hidden Text 

• on screen is hidden, to appear only when the reader clicks at a special place (the "anchor").
• on paper is printed just like the normal text, only with a border around it. (To indicate that this text applies to particular readers only.)

• HTML of Flexible Hidden Text
• Actions  onbeforeprint  and  onafterprint 
• JavaScript:  OnBeforePrint  and  OnAfterPrint 

HTML of  Flexible Hidden Text 

 Flexible Hidden Text  is, in regard to printing, just the inverse to  Flexible Section Break . However, it is also to be become visible when the readers are clicking its anchor. Therefore we need a unique identifier, so we have to banish the mark ( TempInfo ) into the  CLASS  name.

Thus we arrive at the following code:

<DIV ID=… CLASS="TempInfo"  STYLE="border: … ">
		:
	temporary information
		:
</DIV>

Actions  onbeforeprint  and  onafterprint 

We can simply handle  TempInfo  by the same functions  OnBeforePrint  and  OnAfterPrint  So we need the same code as with  Flexible Section Breaks  (see this section):

JavaScript:  OnBeforePrint  and  OnAfterPrint 

So we decided to integrate the handling of  Flexible Section Breaks  and  TempInfo  in the same functions  OnBeforePrint  and  OnAfterPrint 

Thus we arrive at the following coding scheme:

<SCRIPT>
function  OnBeforePrint()
{ 	:
	:
  for(i=0;  obj = document.all(i); i++)
    if(obj.className=='TempInfo')  obj.style.display = '';
}
function  OnAfterPrint()
{ 	:
	:
  for(i=0;  obj = document.all(i); i++)
    if(obj.className=='TempInfo')  obj.style.display = 'none';
}
</SCRIPT>

Appendix 3: Making It Auto-adaptive to Any Environment

We want our online document to behave differently according to its location. But in the first place it should adapt itself to the browser. Notation:

• at home: online or on mirror site
• else: offline, anywhere else

On screen it should be:

In print it should always be (under any browser): default  SectionMenu , no section breaks, no hints/links, but:

• at home: Temporary Information faded in

• else: Temporary Information remains hidden.
  (If you have information that should be included in print, too,
  don't make it a TempInfo but move it to an appendix.)

Flag  athome 

If the right  js-file is accessible (i.e. we are  athome ), the full functionality is available. If not, we should evade calling any of the functions declared in the js-file - or we would get a runtime error:  Object expected 

This is the typical situation calling for  Exception Handling :

• First, we  try  to call the first custom-specific function. (Usually this will be  SectionMenu .)
• Depending on the outcome of this trial, we set a flag ( athome ).
• All the other calls of custom-specific functions should be preceded by a conditional clause  "if(athome)" . Thus potential runtime errors will be avoided.

In JavaScript this is done by

var athome = true;
try      { SectionMenu(…) }
catch(x) { athome = false; }

If calling a custom-specific function when the js-file with its declaration is not accessible, this would result in a runtime error. But if we are placing the test  "if(athome)"  in front of each calling, that error is intercepted: The document can be launched at any location, with a behavior as outlined in Appendix 3.

Hiding default  SectionMenu 

When the document is launched at different locations, it should behave differently (see Appendix 3). Thanks to flag  athome  it is easy to implement that.

One step we did already by testing for  if(athome)  before each call of  SectionFooter  (see previous section)

But we can use that flag also for suppressing the  default SectionMenu  whenever the  full  IE-SectionMenu is called:

<DIV id="NS">
		:
	default SectionMenu
		:
</DIV>
<SCRIPT>if(athome && document.all) NS.style.display='none';</SCRIPT>

Appendix 4: Screen-only and Print-only Information

If you want to give your document an additional glazing, you can provide a section that will be visible only on screen or only in print.

An example of screen-only is the  badge "Copy-friendly!"  at the beginning of this article, that would evidently not be in place for printing.

An example of print-only might be a  Table of Contents  that would make sense in print only. On screen there is always a  SectionMenu  with links to the respective section.

You can do that simply by including the screen-only or print-only information in a <DIV> as follows:

<DIV CLASS="ScreenOnly" … >
		:
	screen-only information
		:
</DIV>

<DIV CLASS="PrintOnly" … >
		:
	print-only information
		:
</DIV>

Future Outlook

In the foreseeable future Online Communication in general, notably the aspect of  reader friendliness , will probably come to much more significance than it seems today.

Today, computing is perceived as something still being apart from everyday life. After all, you really have to have some training to cope with a computer. To get out of it more than just the basic things, you can't get away from some programming. Mainly the elder people still have their problem with it.

In a few years from now, computers will be so ubiquitous that you will hardly know wherever in your daily life there is one. In a few years, by the advent of  e-paper  and  wearable computers , the very meaning of the word "computer" will be obsolete. Handling a computer will be "nothing special" any more. Little kids do it when playing with their toys; elder people do it when reading their newspapers or watching TV - not even being aware of it!

Online communicators will be the ones responsible for presenting contents
in a way that it is "nothing special" to get to know them.

Part of an online communicator's job will be to present contents such that it is just 1, 2 clicks (or simply finger tapping) to get out any information that is in there.  Online  as well as  offline .