If your Company has been producing manuals for a long time, they may have established ideas about production, such as what printing outfit to work with, how long a manual should be, how it should be structured, and so on. If you're new at your Company, check with your supervisor to find out what the expectations are, if any, regarding the printing of your manual. Contact the printer early on in the project. Printers will often have guidelines about what kinds of computer files they will accept for manuscripts, what formats for images and drawings are acceptable, what fonts are acceptable, and other constraints.

The printing process also dictates the number of pages in a book, which is generally a multiple of eight. If you write 25 pages of copy and images, you may find yourself with a book with seven empty pages in it. This can make the manual look strange to the reader. You'll need to coordinate the amount of content with the number of pages available. Conversely, you'll need to make some decisions if you have 36 pages of content for your 32 page book. To some extent, situations like these can be taken care of by layout changes, such as a slight alteration in the typeface size. In other cases, you'll need to edit your information to fit the manual. Unlike virtual or online manuals, it costs more money to print, house, ship, and distribute a longer owner's manual. Your employer won't want to double the manual's size just because you feel it needs to be longer.

Originally developed by and property of Adobe Systems, the pdf format has recently become an international standard, meaning that other companies can now distribute software that can create, edit, and encode PDF files. Adobe Acrobat remains the primary software to use in PDF creation, but a search for PDF development tools on the Web will turn up a number of options, including free websites like qipit.com that will take your uploaded jpeg images and convert them to PDF format and Google's new online office suite GoogleDocs which can convert Microsoft Word document files into PDF at the click of a button.

PDF files can be created from scanned hard copies, converted from other file formats like Microsoft Word, or created using Adobe Acrobat or other PDF editing software. When a company has a pre-existing hard copy manual or other document it wishes to display and distribute online, the simplest way to publish it is to make it available as a downloaded PDF. Older owner manuals are often archived and made available as PDFs for owners who have lost their manuals or bought their products used and never received a manual.

Later generations of PDF files have become highly interactive, much like web pages. They can now accommodate hyperlinks, JavaScript, and other online functionalities. A full featured software package designed especially for technical writers called the Adobe Technical Communication Suite is now available which combines these features plus other online help-producing features.

Designing and implementing Web-based help will often be a team effort involving a writer and an in-house Web designer or outside Web design firm. In many cases, the technical support portion of a company's website will need to merge stylistically and functionally with other portions of the site. In many cases, the technical writer will be responsible for writing copy for the website while the look and functionality may be up to someone else. In other cases, a writer may have complete responsibility for building a support website.

For the new technical writer tasked with creating online help, there are plenty of models, both good and bad, to view online and learn from. Go to any company's website, and chances are that you will find technical support for their products. Try accessing help for a product you own. Is the Company's help effective or confusing? Can you get your question answered or do you have to resort to e-mailing a representative? If you do, the Company's technical writing staff may have failed. Their goal is to reduce customer confusion and calls to real time help lines.

What does Wikipedia have to do with technical writing? Companies are starting to use wikis internally as a way of pooling information among team members and employees. Wikis present a great opportunity for teams to collaborate on information virtually, freeing information from the confines of a particular office or from a piece of proprietary software.

Some more daring companies are starting to publish technical support wikis which allow users to, in essence, do the technical writing for the company. In the same way he might write or contribute to a Wikipedia entry, a user can log in and report on the solution he has found for a usability issue with a given piece of software. In the world of Web 2.0, companies are experimenting with letting users solve their own problems, then help others to do the same.

Often, an illustration will answer a customer's question better than a hundred pages of copy. As a technical writer, you will be working with visual images on a regular basis. Your manuals and online help will doubtless be full of drawings, diagrams, photos, and other visual elements. In general, you won't be expected to produce these images yourself, the Company will have an art department or an outsourced commercial art supplier, but you will often be making decisions about what kind of graphics support would best get your message across. As you study technical writing through the examples you find or your Company's prior offerings, note the ways visual supports are used. What styles of graphics appeal to you? Which ones offer the most information?

In addition to static images on a page, technical writers are increasingly making use of audio and audiovisual illustrations and supplemental materials of all kinds. Writers of training materials have found that video presentations and demonstrations can help users learn the features of their products far more quickly and easily than from a manual. Video can mean camera work with live actors, or it can involve computer animation, PowerPoint-style slide presentations, or screencasts, in which the viewer sees a movie of the use of a piece of software in action right on his screen. (Check out this Ruby on Rails tutorial for an example of screencasting.).

Podcasting is another choice of a deliverable that has a potential for the technical writer. A podcast is essentially an audio or video blog post. Podcasts can be distributed through RSS feeds just like blogs can. While audio may not be a great mode of communication for hands-on training, it can be a way of talking to users about features of their products that they might not be using, of directing users to sources of support, and other informational content. Videocasts, on the other hand, can be a great aid in delivering technical and training information.

Wait, you might be thinking, I'm a writer. What's all this about video? True, you might not have the skills to shoot and produce a video yourself. But most videos start with a storyboard (a layout of the action sequence to be filmed or a plan for the editing process) and a script. And guess who writes the script for these videos? Technical writers, of course! While you may not be producing your own videos, as the technical writer (or in this case, the technical communicator) for your Company, you may well be in charge of a project that involves the production of video content. Even if you don't do it yourself, it pays to be aware of the advantages video can offer the technical writer in fulfilling their goal of ensuring usability for their company's products.