How to convince others of the importance of documentation

If you've been a writer for long, chances are you've had to convince someone of the importance of documentation. It just comes with the territory. People often don't see the value of well-documented information. They don't get that documents can be a life or death matter.

So how do you convince them?

Here are a few tips for arguing the importance of documentation.

Refer to the bottom line

Writing technical manuals saves money. It reduces Support calls, decreases accidents, and improves each user's experience with the product. Your first tactic in convincing others of the importance of documentation, especially developers and business managers, should be to show them how it makes the company profitable.

Show how documentation makes the product more usable

When arguing with developers or engineers, point out how writing technical manuals helps more users take advantage of advanced product features. Educated users will be more effective at completing tasks. They'll also have a greater appreciation for the design of the product. Appeal to the engineer's ego. They'll see the importance of documentation if you show them how it makes users have a fuller appreciation of the product's usefulness.

Carry the burden

Often a developer, engineer, or manager isn't arguing so much about the importance of documents. Instead they simply don't have time to make it a priority. They are often bound to a product release cycle that doesn't include time for writing technical manuals.

Lighten their burden and you might find them more receptive to working with you on documentation. Offer to schedule an information gathering interview so that you can pick their brains in one session, and then use that time wisely. Ask smart questions. Then get to work writing the documentation and try not to be a pest.

Gather user feedback

A lack of user feedback can often lead to doubts about the importance of documentation.

Think about it. How often does a user tell you that they've had a successful experience with the help or manual? It's usually the other way around. You hear from users when they can't find the information they are looking for.

If you want to convince someone of the need for documentation, try implementing a feedback system in your help or asking the Customer Service or Support staff if they have any positive stories from users regarding the documentation.

Write something useful

Some people do not understand the value of documentation because they've had too many negative experiences with poorly written doc. These folks are tough to win over. You just have to buckle down and keep writing useful content, and over time they will gradually catch on to the value added by a good technical manual. Give them enough good experiences to make up for the bad.

Whenever you try to argue the value of documentation, remember to point out that a successful documentation experience is one that you probably will never hear about. Happy users are quiet users.

Good luck!

How to write when you're tired

Technical writing is difficult enough when you are fully rested. When you're tired it can be downright tedious. How can you spot an outdated GUI reference, write a coherent procedure, or judge whether a help topic is indexed properly when you can hardly stay awake?

Here are a few tips to help you stay focused when you're feeling drowzy.

Save heavily conceptual work for another day - Some tasks, such as categorizing content, making decisions with far-reaching implications, and writing procedures from scratch require a lot of brain power. You simply have to be coherent to do these things. To make your technical writing job easier when you feel tired, flag these conceptual tasks as To Do items for another day.

Focus on simple and clearly defined tasks - Many technical writing tasks, such as spell-checking documents, validating HTML topics, and incorporating straight-forward comments from reviewers can be done on autopilot. Try to stick to such tasks when you are tired. That way you can feel productive without running the risk of making mistakes you'll regret later.

Watch what you consume - Eat a small lunch, and don't drink too much coffee. Carbohydrates and caffeine can cause serious fluctuations in your energy level.

Ask for a peer review - If you must do heavy duty technical writing when you're feeling drowzy, ask another technical writer to peer review your work. A second set of eyes can only make your documentation better.

Take frequent walks - Technical writing isn't exactly a high-impact sport. Get up and take a walk now and then to get your blood flowing and clear your head.

Put on your headphones - Most technical writing jobs require a quiet environment, but the silence can put you to sleep if you are already short on energy. Put on some headphones and blast an obnoxious tune now and then. Like rolling the windows down when driving for long periods, the music can jolt your brain back into an alert state for a precious few minutes.

Chat with a coworker - A good conversation now and then will help reset your brain to an alert state. It also helps you stay connected and in the loop. Chat about a project that you are working on, or just talk about your weekend. Either way, you'll be building positive relationships with your team.

Find a fun project - Some technical writing tasks are tedious by nature, but others can be a lot of fun. By focusing on the more exciting tasks and changing your routine, you'll find you are able to muster more energy and attention. Skip editing the copyright page of your manual until you are more alert. Instead, work on the tutorial you are developing using the latest multimedia tools.

Take some time off - Maybe your body is trying to tell you something. Technical writing is hard and stressful work, and it can really tax the brain and burn you out. Take a vacation and give your mind a rest. You'll feel much more alert after a week of soaking up the sun on a sandy beach.

Take a long lunch - If you can't take a vacation, just take a long lunch. Go to the golf course, take a bike ride, or go shopping. An extended lunch break will help get you through a long day.

If all else fails, just pay a coworker to stop by and give you a good shake now and then.

9 tips for writing better FAQs

Frequently asked questions, or FAQs, are an important part of your product documentation. Writing well-targeted and thorough FAQs allow users to quickly find the answers they need so they can be more productive when using your product. Here are some tips for writing FAQs that will get your users on track quickly and help reduce Customer Support calls.

Phrase your questions like a user - Users must recognize that an FAQ answers their particular question. The title of your FAQ should phrase the question in the same language a user would. Ask your Support department for feedback; they talk to users on a regular basis and can assist you with the words users choose when asking questions about the product.

Refer to existing procedures - When answering user questions, leverage your existing documentation. Your answers should point to procedures that guide users through the tasks they need to complete. By leveraging existing documentation, you avoid writing duplicate content and dealing with consistency issues later on.

Implement a feedback system - Use feedback forms in your help so that users can help you fine tune your content. This allows users to tell you if your answer glosses over an important detail, or if there are related questions that aren't covered by your FAQs.

Talk to Customer Support - You can fill in the holes in your FAQs by talking to members of you Customer Support team. They are on the phones with users regularly, and can tell you the kinds of questions users ask on a regular basis. Chat with them often and evaluate whether your FAQs need to change based on changes in the product or user behavior.

Group related FAQs - Organize your FAQs by subject matter, and use a topic list with subheadings to group them. This allows users to find particular questions quickly, and spot related questions that they didn't think to ask.

Include cross-references to related FAQs - Conclude each answer with a list of related questions. Users may not think to ask about important details that are related to the FAQ they are currently reading. By listing related FAQs, you put those issues on their radar and save them later trips to the documentation.

Restate the question in the answer - Begin each answer by rephrasing the question. That way users can clearly see that your answer is indeed going to provide them with the information they are looking for.

Index FAQs by subject - Be sure to index your FAQs. While readers will often access your FAQs from an FAQ list, you can also help users find this information by indexing it under the appropriate subject.

Refer to user-generated documents - Leverage your user community by including a reference or link from each FAQ to the knowledge base or user forum for your product. Often these user-generated resources are updated faster than your manuals and help. Also, by encouraging use of the forum or knowledge base, you gather more user feedback that can be used to flesh out your existing documentation.

Follow these tips for writing great FAQs, and your users will thank you.

Why write instructions that no one is going to read?

Ouch. That's a tough one. Is technical writing worth the effort? Hmm...

Ok technical writers, it's time for some motivation. Everyone take a deep breath, grab some comfort food, and follow my lead.

Now repeat after me.

"My work is useful."

Seriously. Technical writing is useful.

Now before you start to doubt, keep in mind that I'm aware of the situation. I know that no one knows how to program their microwave properly, sync their PDA, or use their on-board auto navigation system to its full potential. I'm aware that not a single person on the planet earth knew how to program their VCR from the time betamax was popular to the time digital video made VCRs obsolete.

I know that a lot of people never read instruction manuals or online help.

But you know what? Some people do.

For every mechanic that learns by trial and error, there's one with all of his fingers still attached who read the repair manual. Or one that disconnected the negative battery cable before digging under the hood as your manual advised. He's the one that didn't get burned. He's the one that understands the importance of documentation.

What about the accountant stuck in her office at 7p.m. who figures out why her calculations are off by reading your troubleshooting topics? Do you think she appreciates your work? How about her husband and kids who get to eat dinner with her because she made it home on time? To her technical writing matters.

And how about the kid on the playground who gets an extension on life because his mother read the instructions for using an epinephrine auto-injector? To that kid, technical writing matters.

Do I sound a bit dramatic? Good. Because for every room full of joe-schmoes who don't read the manual, there's one like I describe above.

That one user is the reason we get up each day. Forget everyone else and write for that user.

Do not underestimate the importance of documentation. The world needs you. And it needs technical writing.

-If you enjoyed this post, you might also like How to convince others of the importance of documentation.

How to become a technical writer

Technical writing is sort of a jack-of-all-trades profession. It requires diverse skills, so a lot of people stumble into technical writing by chance. I've personally met technical writers who used to be lawyers, educators, and published fiction writers, and I've heard stories of many other professionals drifting into the field. Their past careers required writing, teaching, or technical abilities, and these skills helped them segue into a technical writing job.

Of course, some people take a more direct and intentional path. They work their way through a college technical writing program and start networking and making connections. This is a great way to get into the field, and there are many quality technical writing programs available. Also, you can meet some wonderful people at a college English department; these folks may turn out to be life-long friends and professional contacts.

Maybe it would help if I told you how I became a technical writer.

I'm dating myself here, but why not...

Once upon a time there was a computer company called Commodore. Back in the early 80's, when I was in the fourth grade and had accumulated an entire collection of Masters of the Universe action figures, they released a computer called the Commodore 64. It was awesome. It used floppy disks the size of textbooks and made crunching noises when the drives couldn't find what they were looking for. (It also booted instantly to a command prompt; no waiting for things to load.) And it ran the best video games I'd ever seen, in full color and with awesome sound.

One day I played Archon on a C64 at my dad's friend's house and was blown away. I had to get one.

I can still remember standing in the computer store three days before Christmas helping my dad fill a box with all the components we'd need. (No monitor; it just plugged into the TV.)

When I got the thing home I started reading the manual. No kidding. (Back then home computers were just a hobby; therefore, it was assumed that if you bought one, you planned on learning how to program it.) The C64 manual had the most incredible tutorial on BASIC programming I've ever seen. It still stands up as a great example of technical writing. I learned about pixels, drive sectors, arrays, and all kinds of stuff I never thought I'd use again. It really made me appreciate the importance of documentation.

I had a friend that read the same science fiction books I did and his dad ran a computer business out of his basement. We'd spend days writing sci-fi word games on his dad's computers and learning how to write code. And when we were burnt out on computers, we'd play baseball and swap books.

As I grew older, the usual distractions (dating, trying to stay out of trouble, and a Kramer electric guitar that I still own) scattered my attention.

By time I entered college I had no idea what I wanted to do with the rest of my life. I picked a major in English Literature because I liked to read books. After I earned a BA in Literature, my advisor pointed me to a Masters Degree program in Professional and Technical Writing. I knew my chances of becoming a beat poet or rock star were slim, so I jumped on the opportunity.

My experience as a graduate student enlightened me to the fact that I actually had some marketable computer and writing skills. Through perseverance my professors managed to pound some very useful theory into my head, and they involved me in some school projects that helped hone those skills. I also learned to further appreciate the importance of documentation, and that technical writing could be a decent and enjoyable way to make a living.

Then, one fateful day, my technical writing professor told me about a job opportunity that sounded promising. My wife and I were just married. College was expensive. So I took the plunge and entered the 9-5 world. I became a professional Technical Writer.

That was nearly a decade ago, and I haven't looked back since.

When I started college I had never heard of technical writing. Now, I can't imagine myself in any other career. I just sort of fell into it through my love of books and computers, and the guidance of some great teachers. And the rest is history.

So that's my story. That's one way of becoming a technical writer.

What's your story?

10 brilliant help ideas from Microsoft Office 2007

If you're looking for some new user assistance tricks to enhance your product, you might want to take a close look at the Microsoft Office 2007 help. The technical writers and developers at Microsoft have put together a help system that is incredibly user-friendly and accessible. (Why can't I be as smart as those guys?) Here are just a few of the help features that caught my eye.

Instant search - When you launch the help, the cursor immediately appears in the Search field. This allows users to find the information they need using their own words. This is a stark contrast to three-pane layouts that default to showing an index or table of contents. While such navigation features offer strengths of their own, they require users to map their thoughts to the terms that technical writers have hard-coded into the navigation. The Search feature lets the computer handle such conceptual mapping.

Browse list - Under the Search field is nicely-organized menu of help topics for users who prefer not to use Search. This menu is sparse and high-level, and can be scanned quickly. Although it takes some clicking and guessing to dig down to specific information, the menu does a nice job of complimenting the Search without overwhelming users.

Topic icons - Microsoft uses icons for different types of help topics. When a list of available help topics appears, the icon next to the topic tells users whether the topic is part of the locally-installed help, or whether it accesses information on a server. This is great for users who aren't connected 24/7, or those who don't want to wait for information to download.

Look and feel - The help has a light, airy feel to it. Even dense procedures seem welcoming and easy on the eyes. At times the color of headings and text is a bit too light, and might be hard to read for those with poor eyesight. But overall, the use of white space and lighter colors is soothing and makes reading the help a much more enjoyable process.

Breadcrumbs - Office 2007 help offers a great example of how to use breadcrumbs effectively. Whether you reach a topic via browsing or from the Search field, the breadcrumb navigation gives a strong sense of where you are in the help. I often find myself clicking the last link in the breadcrumb path to go up a level to conceptually related help topics.

Demo labels - Topic titles for software demos are clearly labeled. The word "Demo:" precedes the title of each. This makes it very easy to find the demos when browsing the help, and see that you are about to download something when you click the link to the demo topics.

Screenshots - Office 2007 help has some of the most attractive and useful screenshots I've ever seen. Many are cropped with fancy Bezier curves and sport drop shadows. While you might think such things would distract readers, they are actually quite appealing and add to the pleasant look and feel of the help. Also, most of the screenshots have very useful captions, and are effectively used for illustrating concepts in the help. I can't imagine how much time the technical writing staff put into these shots. Well done.

"In this article" links - Many lengthier help topics in the Office 2007 help are preceded by "In this article" menus that link to subsections of those topics. These menus serve as useful tables of contents for seeing what material each topic covers, and accessing that content quickly.

User-friendly feedback form - The server-based feedback form at the bottom of most help topics is both elegant and unobtrusive. The form itself only appears after you click one of the "Was this information helpful" buttons, so it doesn't distract your attention from the content. Also, the form is smart enough to realize which button you've clicked, and asks you for appropriate feedback based on your choice.

Tags - Office 2007 help topics often contain a list of tags. These tags are used to group similar content that is available via Microsoft Online. The help topic "What are tags?" implies that the tags are generated by other people, but I'm not sure if this means other Office 2007 users, or technical writers at Microsoft. (Does anyone happen to know the answer to this one? If so, please share by leaving a comment.) If the tags are user-generated, I have to give Microsoft kudos for adding them to the help.

Again, this list just scratches the surface. The help for Office has improved vastly over previous releases, and I was really impressed by the way help was implemented. So if you want to learn a few tricks for your technical writing bag, spend a little time in Office 2007 and grab a few ideas from the smart folks at Redmond.

11 tips for writing incredibly useful procedures

Procedures are the meat and potatoes of technical writing. They help users get the job done. Follow these tips for writing clear and useful procedures that your users will appreciate.

Fill in the holes - Ask yourself if your existing procedures cover all of the tasks users need to complete. You may be missing a few, especially if features have been added to your product. If you have a set of well written FAQs (and you should!), make sure there are procedures for addressing the details of each FAQ.

State the goal - Unless it is already obvious, begin by telling users the reason for performing the procedure, and in what conditions it is applicable.

Break it down - Lengthy procedures are harder to follow. Break these behemoths down into smaller chunks and use hyperlinks to guide users from one granular task to the next. Aim for 10 steps or less in each procedure.

Don't assume - Read carefully through your procedures and ask, "Is there anything a user would need to know that I've left out?" Don't assume that users know everything you know about the product. Technical writing is all about acting as a user advocate.

Use warnings - For each step in your procedures, carefully consider whether there are any potential risks or dangers that you haven't documented. A good technical writer will put user safety first.

Link related procedures - Whenever possible, especially in help, use cross-references to point users to related procedures. Most users need to perform multiple related tasks in order to complete their goals. For example, a procedure about using the Print Preview function in your software should be linked to procedures for the Print function.

Tell users what to expect - Consider whether the results of each step need to be documented. Good candidates are those that result in changes in the state of the product (e.g. an important prompt appears in the software, or the blades on the lawnmower begin to turn). Your description of the result should immediately follow the instructions for that step.

Watch for branches - Often a step in a procedure can have multiple results. If your procedure branches, consider making each branch a separate procedure. Use links or cross-references to guide users through.

Combine small steps - Usually it is best to write only one instruction per numbered step. However, small steps can often be combined. For example, "Click the save button" and "Close the application" can be combined into "Click the save button and close the application." Combine multiple small steps only when the concepts are simple enough for users to think of them as one.

Give users an overview - Use a flowchart, list of links, or other visual cue to help users see how procedures are related. This will provide users with an overview to guide them through a complex series of tasks.

Follow up with results - At the end of the procedure, clearly describe the results so that users can assess whether they were successful in completing the task. The more complicated the task, the more assurance users will need. Good technical writing should leave users feeling comfortable about their experience with the product.

If you enjoyed this post, you might also enjoy How to write training manuals.

Resource: How to Write Policies, Procedures & Task Outlines

Can I change my HTML help scrollbar stylecolor?

Sure. Whether you are developing Microsoft HTML help (.CHM) or browser-based help that is coded in HTML, you have full control over the style and color of your scrollbars.

To change your HTML help scrollbar stylecolor, either edit the styles defined in your CSS stylesheet, or use a <style> tag in the head section of your HTML code to define a style.

Scrollbar color is defined using the SCROLLBAR-BASE-COLOR attribute. You should apply this attribute to the HTML element that will contain the scrollbar. In most cases this will be the BODY element of your page.

Example: body {scrollbar-base-color: red;}

You can also change the color of individual parts of the scrollbar using the following CSS attributes.

scrollbar-3dlight-color
scrollbar-arrow-color
scrollbar-base-color
scrollbar-darkshadow-color
scrollbar-face-color
scrollbar-highlight-color
scrollbar-shadow-color

Just don't overdo it. Pick a color that compliments your design and doesn't distract your users.

Enjoy!

Where can I find a good sample of technical writing?

If you look closely, you can find a good sample of technical writing just about anywhere. The next time you microwave some popcorn, take a look at the instructions on the back. You'll find clear procedures and helpful illustrations. Product manufacturers are getting smarter about putting instructions and warnings in obvious and useful places.

For a great sample of technical writing, check out any of the Haynes auto repair manuals. You can find these in any auto parts store. These manuals are filled with carefully written procedures, reference information, and illustrations. If you've ever repaired your own vehicle and referred to a Haynes manual, you know how great they are.

If you happen to have Microsoft Office installed on the computer you are currently using, just open an Office application and choose Help from the main menu. Microsoft's help is well written and organized in an easy-to-navigate manner. It offers quick answers to users' questions, and makes a great sample of technical writing if you want to learn a thing or two about writing help for software applications.

Our .CHM files don't work anymore. Why?

If you are delivering your help from a network location and you notice that .CHM files don't work anymore, don't be surprised. Recent Microsoft updates include tighter security for .CHM files. After installing the updates you can no longer run .CHM files from a network location. However, you can still run a .CHM file on your local machine.

Many help authors have solved this problem by converting CHM help files to browser-based help.

Details on the security updates that caused this issue are available from the Microsoft Knowledgebase at http://support.microsoft.com/kb/902225/.

If you need to deliver help over a network, you may wish to consider help authoring tools such as Flare, AuthorIt, Doc-To-Help, and RoboHelp that are capable of producing browser-based help that has navigation features similar to a .CHM. If you are compiling your .CHM files without the use of a help authoring tool, you may have to develop your own help structure and navigation features using HTML and some custom scripts. However, a good help authoring tool will make your life much easier.

Good luck!

Should I switch from RoboHelp to Flare?

Not necessarily. Unless you have a specific need for features in Flare, there is no major pressure to making such a change. The whole RoboHelp vs Flare discussion isn't as significant as it seems for most of us.

Many technical writers considered switching to Flare because of fears that the RoboHelp product line would be discontinued. However, RoboHelp was then acquired by Adobe, who alleviated writers' concerns by improving the product and offering continued support.

The general consensus in the technical writing community is that if you're happy using RoboHelp, there's no reason to switch tools. Both Flare and RoboHelp have their share of quirks, and switching tools requires a great investment of time and a significant learning curve.

If you are choosing a product for the first time, you might appreciate the advanced features the Flare team has built into the product. Paul Pehrson has some nice things to say about Flare over at the Technically Speaking blog. Check it out.

The whole RoboHelp vs Flare issue is now a race to implement features. More significant, I think, is the race to build a complete set of technical writing authoring tools that integrate seamlessly. Both Adobe and Madcap have put together some great tools, and you might be better off comparing how the entire suite would impact your workflow instead of just focusing on help authoring. (However, I'm still curious about which vendor will be the first to release some embedded user assistance tools.)

In short, stick to the tool that works for you. Both Adobe RoboHelp and MadCap Flare are great help development tools produced by smart people who are committed to making your job easier.

Characteristics of technical writing

Good technical writing should...

• Be accurate.
• Explain difficult concepts in an elegant manner.
• Address problems that users actually experience.
• Use clear language, avoiding jargon whenever possible.
• Consider what users already know and pick up where that knowledge leaves off.
• Be organized in a way that allows users to quickly find specific information.
• Balance task-based information with reference information, using each where appropriate.
• Use images instead of text when images convey information more efficiently.
• Provide clear warnings and put user safety first.
• Use language and formatting consistently to reduce confusion.
• Anticipate users' questions and then answer those questions.
• Follow standard formats to reduce reader confusion.

Writing technical manuals is primarily about understanding your users and communicating the information they need as clearly as possible. If you can pursue these qualities listed above in your technical documentation, your users will appreciate it.

Feel free to leave a comment if I missed any other important characteristics of technical writing!

If you enjoyed this post, you might also like:

• 11 tips for writing incredibly useful procedures
• How to write a disaster recovery plan
• Great examples of technical writing

Can I download the Microsoft Manual of Style for free?

See also: Free technical writing authoring tools

The Microsoft Manual of Style is an essential reference for those writing software documentation, and should appear on any list of important resources for technical writers and software developers. Even if your company follows a different style manual, the Microsoft Manual will serve as a compliment and cover subject matter that your other manuals do not.

If you are building a reference library to further your technical writing knowledge, the Microsoft Manual of Style for Technical Publications is a great book to start with.

For as little as a few bucks (used) you can purchase a LEGAL copy of the printed 3rd edition of the Microsoft Manual of Style for Technical Publications from Amazon.com.

Unfortunately the Microsoft Manual of Style for Technical Publications is no longer available as a free download.

For a while the manual was available as a downloadable .CHM file. Many pages on the Internet still refer to the free download. However, the web page these references point to has been removed by Microsoft, and the manual does not appear in the results when you search the Microsoft Downloads site. (Perhaps this is because .CHM files don't work anymore when delivered via server, although it seems like downloading the file should still be possible.)

How can I make our product's help more useful?

Remember rule number one for technical writers: focus on your users. Most of them are trying to complete a task and need help figuring out how. Give them a quick solution to their problem so they can get the job done.

Start by listing all of the tasks users can complete with your product, both at a global level and from within each dialog. Now take a good look at your procedures. Are all of the tasks covered? If you are writing software documentation, be especially thorough because features often change from one release to the next. (For tips on writing procedures, see 11 tips for writing incredibly useful procedures.)

Now access the help via your Help menu (or click the main Help button depending on your interface). Are the most common procedures immediately available in the help topic that appears? They should be within a click or two so that users can access them quickly.

Try pressing F1 from within each of your dialogs. Do relevant procedures appear? Your context-sensitive help topics should focus immediately on the tasks that users will perform in each dialog. Reference information and feature descriptions should take a back seat to task completion.

Does your navigation include full-text search? If so, give the search feature a high profile. Unlike an index or table of contents, search lets users tell you exactly what they are looking for in their own words.

If your help allows users to quickly find relevant procedures, and allows them to search in their own words, you're in good shape. Your users will visit the help more often and leave with a positive impression.

Which XML editor should I use?

Choosing an XML editor can be a tedious process. As with most technical writing authoring tools, you need to find one that fits your specific documentation needs.

First, make a list of your requirements. Do you need a tool with user-friendly features and extensive help that will allow for an easy transition? Or are you looking for a slim and trim XML editor for some serious hand-coding? Perhaps you need a full-blown content management system, or a tool that supports a specific schema or DTD?

The good news is that you have plenty of options. Whether you're looking for a proprietary tool with an extended customer support plan, or an open-source editor that will help your budget, you should be able to find an XML editor that meets your needs.

Here is a rundown on some of the more popular XML editors.

XMetal

Cost: $695 - $1395 depending on version

Strengths: Full DITA support, Documentum integration, collaborative editing, user-friendly WYSIWYG interface, extensive language support, simple publishing to various output formats.

Oxygen

Cost: $225

Strengths: WYSIWYG editor, DocBook and DITA support, Eclipse IDE support (for Java users), support for multiple XSLT processors, query support for XML and relational databases.

Cooktop

Cost: Free

Strengths: Great bare-bones XML editor (no WYSIWYG), small download size, customizable library of snippets, works with most XSLT engines.

Altova XMLSpy

Cost: $499 - $999 depending on version

Strengths: Graphical schema designer, database integration, plugins for Visual Studio .NET and Eclipse, support for Office Open XML documents, editor with multiple viewing options.

Open Office

Cost: Free

Strengths: Office suite and XML editing in one package, extensive user community, familiar word-processing environment. (Note that Open Office documents can be saved as XML, but does not handle translation or other tasks. You'll need to either create your own translation process or invest in one of the other more robust editors mentioned here.)

Arbortext Editor

Cost: Call Sales (likely differs quite a bit depending on whether you want the full-blown CMS)

Strengths: CMS integration, content reuse, translation, dynamic content, familiar word processing interface, support for DITA and other standards, highly configurable.

A free trial version is available for most of these. Download those that you think might meet your requirements and give them a test drive. With DITA and single-sourcing on the horizon, an XML editor may quickly become one of your primary technical writing authoring tools.

Good luck!