Neil Perlin, Developing for the Unknown at STC12

It’s of course impossible to develop techcomm content for formats that don’t exist yet, but Neil Perlin shows how you can prepare for them to future-proof your work – and job.


The problem he addresses is that content formats will change, we just don’t know yet how. The answer is generally to create solid content by setting and using open standards. By doing that (and avoiding proprietary standards, hacking code and tweaking our tools), we can ensure that our content will have a good life and be relatively easier to use in any future formats that might come down the line. And keeping with developments is important, so we decide which standards and tools can help us in the future.

Better structure

On the structural level, you can best standardize your content by using information types (also called “topic types”), such as task, concept, reference, troubleshooting, “show me”, etc. Try to keep your number of types below 10. (DITA, a structured authoring standard has only 1 general topic type and the first 3, I’ve just mentioned.)

Once you have your information types defined, you can create templates that already contain the topic structure plus some explanatory boilerplate text which you and other writers can replace with your actual content.

Multiple output formats

On the technical level, CSS is a great medium to future-proof your content: It lets you create your topics independent of layout. And it is powerful enough to support just about any HTML-based format to make your content (and you as its author) look good on the web, on tablets and on mobile.

Using CSS to future-proof your content means, among other things:

  • Keep your CSS definition simple and clear for easier use and better maintenance.
  • Define all your output formats in one CSS file by defining different media types for different devices, web and print.
  • Check that the most common browsers and devices which you write for support CSS correctly. (If not you may have to live without some CSS features for the time being.)
  • Use relative style size units instead of points (“pt”) which are not resizable.
  • Use styles for tables instead of hand-tweaking column width, etc.
  • Use character styles instead of “Bold” or “Italics” as in Word’s style toolbar.

To migrate your content from more proprietary formats may require some cleanup of embedded and inline styles. Some of this can be scripted, but you may still find yourself with a lot of semi-automatic search and replace.

Adopt, don’t adapt

On a methodological level, Neil advises to adopt a standard because it suits you and your business needs. Adapting your content to a standard because it’s common or new without a business case is not a good idea. So put your company and your job first and build up in-house knowledge about standards, formats and tools, so you can make the right choices.


It takes Neil’s long experience to successfully combine general career advice with specific tips about CSS. I really enjoyed this session. I’ve learned a few new tricks and got general confirmation that our strategy to migrate our documentation to XML in a DITA-derived structure was the sensible thing to do.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: