How do you think in Word?

Now's your opportunity to help me, especially if you mostly create text using a markup language but occasionally use a word processor.

First a disclaimer: I think it's likely we all learn, think, and work somewhat differently. The fact that I work one way doesn't mean I think you should necessarily work that way, too. Somewhere I recall reading that many people (especially technical people) tend to pick one main tool, master it, and arrange the rest of their work around that core. Today I'm asking how you work when you have to work outside of your core toolset.

Now some background: I've used word processors for quite a few years, starting with Speedscript, AppleWorks GS, and then Word 5 (or was it 4 or 5.1?). I've used many versions of Word up through 2007 at some level of intensity. A few years ago, I worked on a successful documentation project that involved on the order of 100 Word and Excel documents, some quite lengthy (I seem to recall one in the 700 page range).

At some point, I discovered markup languages. I started with nroff and later moved to LaTeX. After that Word project, I moved to DocBook and completed a follow-on project that garnered some nice praise for having gotten around some of the challenges of the first project while producing quite readable and professional-looking documentation. I currently use asciidoc, LaTeX, DocBook, and J Publish.

In all of this, I find it helpful to have great tools. I've built my toolbox around GNU Emacs, starting around version 18.24. For LaTeX, I use AUCTeX; for DocBook, I use nXML mode and eDE on Windows or any of several toolchains on Linux. antiword is handy for converting other people's Word documents into a form I can import into one of those tools, and I make use of revision control (currently bazaar) and makefiles to help with organization and productivity while reducing the chance for unfortunate mistakes. I've used cweb when writing about simulation models.

Despite my tendency to use markup languages, I do still use a word processor from time to time. OpenOffice.org write is my current preferred choice, because I find its approach to styles is robust and easy to use, because it stores files in an open format, and because I haven't lost an OpenOffice.org document yet.

I often think by writing. I am noticing that I find it easy to think when writing with a markup language, but I'm finding it much more challenging to think effectively when faced with the simultaneous content and layout creation tasks in a word processor. While I sympathize with much of this rant, I'm looking for solutions, not conversion, today.

The first question: if you, like me, work well in markup languages, how do you think when writing in Word? Are there tricks to the setup to make it easier? For example, I think there used to be an unformatted mode in which you basically just saw text. That sounds attractive, but I thought it had been deleted from Word. I spoke with a former journalist recently, and he noted that he often composed text in email and then pasted it into Word for formatting. What other ideas can you suggest?

The second question: how do you format the final document? I know the "right" answer: create and use styles and templates, yet I find that harder to do in Word than in OpenOffice.org or even than in systems such as LaTeX. Do you have any tips, especially for those situations in which you're working with documents that were created at least partially with direct formatting?

asciidoc isn't just for small documents anymore

I've used asciidoc for quite a while as a tool to generate small reports for clients. As I've discovered how easy it is, I'm also using it to keep notes. The lightly formatted (perhaps stylized would be a better word) text is better organized visually than simple text, and, if I need to turn it into typeset text, it's pretty easy to convert it into a range of formats: HTML, XHTML, PDF, RTF (and, from there, DOC), ODT, and more. I've tested its ability to create (LaTeX) beamer presentations and might use that regularly if I didn't stretch beamer a bit more than the asciidoc beamer translator supported at the time.

Yet I had fallen for the idea that asciidoc was for small documents, at least until I read Noah Slater's posting on the asciidoc mailing list saying he was using it to write a book that will be published by a professional publisher using their DocBook backend processes.

What do you need to use asciidoc successfully? I started using it on Windows with Emacs as my editor. I now use it on GNU Linux (Ubuntu, to be specific). Both work just fine. It seems easier to set up any backend processes on Linux, but your organization can set those up once and then users don't need to do that configuration themselves.

To get from asciidoc to PDF or RTF requires you have a DocBook toolchain. That's fairly straightforward on Linux; the main challenge is figuring out which alternatives you like. That's more of a challenge on Windows, but I have found the e-novative DocBook Environment (eDE) to be extremely easy to use.

Those of you who like HTML documents but struggle with the problem of distributing them by email (you have to attach any images as separate files and then rely on the recipient to manage them properly) might like asciidoc's ability to use data URIs. That means you can embed images inside the HTML file, so you only have the one file to distribute.

While you're looking at asciidoc, check out their examples using asciidoc to produce diagrams with graphviz, to typeset musical notation, and to create Web sites, in addition to simply creating articles and books.

Creating text productively

Most of us spend a fair amount of time creating or dealing with text: email, reports, evaluations, proposals, and the like. Over the years, I've found one tool that consistently has helped me to be more productive at generating text in any format: Emacs (check out their quick guided tour—I learned something new there). It may look like an editor for software engineers, but it's really much more general than that.

I'm not interested in starting an "editor war" with those who prefer other editors (or word processors, for that matter), for it's to some degree a matter of personal fit. I did want to point out that IBM has a tutorial on learning Emacs, for those starting out. So does Emacs, for that matter (it starts automatically the first time you run Emacs); the IBM version has the potential advantage that you can read through it before you install the software, although you will learn more by actually using it.

For those of you who would like to walk through the IBM tutorial (it requires free registration), check out these, or search on their site for more specialized material:

1. Living in Emacs
   
2. Learn the basics of Emacs
   
3. Learn the essential modes and editing features of Emacs
   
4. Advanced Emacs text operations
   

Emacs does run on pretty much any computer platform you might have.

For those of you saying, "But I want nicely formatted documents, not pure text," see Business writing made easier. And for any of you really into text, check out Antiword as a tool to convert a Word document back into text. It's usually faster to open a document in Antiword than in Word.

New tools for writing

From time to time, I hear of people seeking easy ways to publish documents in PDF format. Sure, many still use Word and send their documents along as .doc files, but there's a perception of being complete that comes with PDF files, and PDF files look the same on all computers, unlike Word files.

For many, it's not easy to produce PDFs, though. They could buy Adobe Acrobat, but they can't justify the expense for the number of documents they'd convert in a year. They could do it in LaTeX, but that requires a bit of skill they don't have time to develop.

I recently discovered another approach that many may find easier. Parsewiki takes structured plain text and turns it into various formats: DocBook, HTML, or LaTeX. Then, if you have a DocBook toolchain installed, you can create PDF files quickly. That's doable on Windows, and it seemed trivial on Linux. It's not the tool you want for bigger documents, but it may work quite well for you for the one- or two-page memo or summary you'd like to produce.