Once I worked at an installation where writers periodically yelled over their gray half-walls several times a day, "I DETEST FrameMaker!" or "I HATE Word!" We were constantly switching between these two apps, and frustration rose sharply when one program refused to do what the other did well. The votes split equally, but in Word, the complaint always had a single root cause: long documents. Word choked, buckled, and crashed on them.
Ten years later, Word still doesn’t play nicely with the bulk of a big doc.
Mind you, I’ve never seen a text-only file that was a problem. You can safely capture the wit and wisdom of your autobiography in Courier font with chapter titles and a scene or two that makes you blush to recall, and Word will handle the text with nary a whimper. I’m currently editing 107,000 words of text in a single Word file, and it functions as lightly as if it contained 107 words. Text is not the culprit.
The kind of documents that bring on system freeze and shredded nerves are likely to be graphic-laden catalogs, in-house project specifications, reference manuals, legal findings, or governmental studies. We’re talking manuscripts not just with words, but with photos, logos, captions, tables, graphs, cartoons, marginalia, fancy formatting, flowcharts, hyperlinks, embedded drawings, footnotes, and field codes with a table of contents at the front and an index at the back and possibly a dozen tabular appendixes just to ensure that nothing was missed. If you do much of this sort of thing, you know already that Word hates it—so let’s move on to the remedies.
Draft a Set of Specifications
I know this isn’t really a Word issue, but give me a minute here, okay? I’ve seen more big documentation projects bog down or fail to deliver on time for lack of a functional plan than for any other reason. I just wish I had $100,000 for every time I’ve gone into a writing project that was on the skids and never going to deliver on time and asked, "Where is the document plan?" only to be met with blank stares. Such stares mean that there is no plan, no one knows where it’s filed, or "scope creep" and direction changes have rendered it useless.
So, there being as many ways to cook up a spec as there are monkeys out there typing Hamlet, I’ll just list the minimum ingredients:
- Document description
- Purpose (problems this document will solve)
- Intended audience
- List of client requests
- Template (sample, description, or ID)
- Content outline
- Timetable with milestones, review cycles, handoffs
- Major roles (and players, if known)
This list of info gives an informal contract, allowing stakeholders to see if anything they care about has been missed and generally giving the impression that the writer is on top of the situation—and a very hard worker indeed. If a deadline can’t be met, I suggest something that can be done in the allotted time. It lends high visibility to the timetable, giving something to reference each time you send a portion of the doc for review.
Furthermore, every time some wise guy changes the character, direction, or scope of the project, you can rework the specs and email the changes to anyone who might remotely care, so they know the impact on delivery dates.
In short, specifications save the writer a ton of grief.
Now, on to Word-specific matters.