I'd Rather Be Writing » richard hamilton

Upcoming Books from XML Press: Richard Hamilton at the STC Summit in Dallas, #stc10

Tom Johnson — Fri, 07 May 2010 13:47:02 +0000

In this video, I talk with Richard Hamilton, founder of XML Press, an imprint focused on technical communication, to share details about the upcoming books he is publishing. Richard also comments on how he identifies topics and trends for the technical communication publishing market.

Blog Sponsors

Reinventing Yourself Through Your Blog

Tom Johnson — Mon, 02 Nov 2009 04:10:21 +0000

The other week, while I was at the WebWorks Roundup conference in Texas, where I was one of the featured industry speakers, I was sitting next to Anne Gentle during one of the panel sessions, and I asked her about branding. It seems like once you become branded through your blog, it’s hard to reinvent yourself.

I was speaking at WebWorks on blogging and web 2.0. More than anything else, my blog has branded me as a blogger. This brand has led to numerous speaking invitations at conferences and chapters. The more I speak about blogging, the more I become branded as a blogging expert –- it’s a cycle of branding that perpetuates itself.

At the conference, I learned that although some people have branded themselves online in certain ways, they can be much different in person. For example, online you know Richard Hamilton, founder of XML Press, as an entrepreneurial publisher focusing on the technical communication market. You may also see Richard as an experienced manager through his recent book Managing Writers. And you may gather that Richard is a careful, analytical thinker from his lengthy conference write-up posts. That’s how Richard has branded himself — as a publisher and manager.

But Richard has another side to him as well. He’s a pilot and previously owned his own airplane. He loves reading literature, especially mysteries. For example, he has read Sue Grafton’s mystery series (A is for Alibi, B is for …) series up to G. His whole face lights up when he starts talking about mystery novels with another mystery aficionado.

He boots his computer in Ubuntu and prefers to write everything in DocBook XML. He also seems to enjoy long car drives (for example, he drove from Colorado to Texas and back for the conference). More than anything, Richard is one of the most warm, friendly, and conversational people you will ever meet.

Alan Porter is even more of an interesting figure when it comes to branding. Online you know Alan as the head of WebWorks (or VP of Operations). You read his blog as an expert in the tech comm industry, especially with wikis. His forthcoming book, Wikis: Grown Your Own for Fun and Profit, will only solidify his wiki branding. He also blogs about trends in user behavior, from observing, for example, the way his teenage daughter approaches her homework.

But in person, you’ll find that, like Richard, Alan has another side to him entirely. A cowboy-boot wearing Englishman, Alan is an avid comic artist. Mention conferences like Comicon and Dragicon and his ears perk up. He regularly writes the stories, dialog, and scripts for the comic book CARS.

In addition to his drawing talents, Alan has also written books on James Bond, Batman, Star Trek, and the Beatles. He has strong feelings about the importance of storytelling. In fact, Alan works only 30 hours a week so he can focus on his writing.

Alan has written a mystery novel set with NASCAR racing and another novel about Shakespeare pretending to be Christopher Marlowe, which an agent of his was shopping around Hollywood for a possible movie. Alan is also a consultant for Tedopres, a company focused on simplified technical English. He can fly out to your location and train your employees on simplified technical English techniques.

Alan understands the importance of recording presentations. He records all major WebWorks conference sessions, making them available at first on a limited basis and then eventually opens them up to everyone. He’s allergic to gluten, is married to a court reporter, and when you mention his competitor’s products, such as Flare, he breathes a deep sigh.

I’ve gotta say, Alan is one of the most interesting people to meet, because unless you know this other side of Alan, all of this comes as a complete surprise. It’s a surprise mostly because Alan has chosen not to brand himself this way online. In fact, he has a policy that he will not write about either his company’s products or his competitor’s products on his blog.

Blogs provide you with an opportunity to brand yourself with an identity you want to be known by. But you have to be careful what you blog about, because that brand then stays with you. You become known for that brand, and it can be hard to change.

Reinventing yourself with a new identity isn’t impossible. It just requires you to shift your focus, to start writing about a new topic.

I mentioned at the beginning that I’m not so eager to be branded as a blogger (and podcaster and WordPress person). Ideally, I would like to be a screencaster and wiki expert as well. To make that happen, I’ll have to shift the focus of my blog — for about the next 200 posts.

I could make the shift, but I think I prefer to let things happen in a more natural way. It’s more interesting to let water flow in the direction it wants to. And then every once in a while look up to see where you are.

Blog Sponsors

What Users Don’t Care About

Tom Johnson — Sun, 12 Jul 2009 03:45:45 +0000

It seems most of the conversations in our industry today revolve around value. If you go to stc.org, the large graphic at the center of the site says “The Value of Technical Communication.” (Given the recent events in the STC, to me the graphic really reads, “The value of the STC organization.”) At any rate, technical writers have been talking about demonstrating value to employers in quantifiable ways for years.

Technical writers frequently talk about value, but much of the value is invisible to users

Part of the problem in our attempt to demonstrate value is that our help deliverables look the same as they did 15 years ago, more or less. Online help and a PDF manual. It’s not a format that engages users. The web marches forward with innovation after innovation, while the technical communicators are figuratively hunched over keyboards, staring at CRT monitors, wearing 1950s horn-rimmed glasses, typing away. At times it seems the technical writer is a relic of a past tradition, a figure barely hanging on to the rapid pace of technology in the 21^st century. Or so it would seem.

Although that’s the general impression, actually technical communication has had considerable innovation lately. DITA has provided an advanced XML architectural standard for single sourcing that all technical communicators can implement. Even putting aside DITA, single sourcing technologies with help authoring tools have become more common. The old method of copying and pasting to produce multiple deliverables is a primitive practice no longer typical. We’ve moved into an age of efficient authoring. We can now generate seventeen deliverables from just one, original source. Brilliant!

But whatever methodology has changed in our creation process, the value of our industry’s innovation only trickles down to the user, and in an almost unnoticeable way. You may have single sourced your documentation from a large snippet library, breaking up your topics into granular chunks that you’re cleverly reusing through your topics, and pulling it all together with conditional builds. But to the user, it’s the same old online help and PDF manual.

The user could care less whether the PDF manual is single sourced. Keith Anderson (on Twitter, @suredoc) writes,

I personally believe you can argue the merits of DITA or single sourcing all day long, but the dirty little secret of our industry is simply that users don’t care. They just don’t care. They do know how they want information and will consume the information in ways that are comfortable or familiar to them (“Sheep, Chaos, and User Experience”).

In other words, it doesn’t matter to users how you created the documentation. What matters to them is what you create. We have a somewhat similar policy at my work. It doesn’t matter whether you work 20 hours or 80. You just have to get the job done. Our CIO even says we can leave to go watch our kids’ soccer games at 2 p.m. if we want, as long as we get the job done. (He doesn’t mention that it’s nearly impossible to finish all your work.) But the focus is on the output, the deliverables, not the clever or cruel process we endure to create them.

Here’s another example. Did you happen to read Richard Hamilton‘s Managing Writers? It’s formatted in Doc Book, did you know? Doc Book streamlined Richard’s printing process, enabling him to stylize the format in different ways without altering the source. He can print a news article format, a booklet format, and a book format from the same source by just altering a stylesheet. He can also generate the content as HTML, ePub, CHM, or PDF without any additional work.

Despite the innovative format, to most of us who read it, it’s still just a book. It looks like all the other books on our shelves. I think most of us, in reading the book, might admit that we don’t really care how he created the product (except from a professional curiosity perhaps). Our primary purpose is in the product itself, the content, not with the way it was made. I don’t really care if Richard stayed up past midnight every night for two years writing the book, or if he wrote it on the bus, or whether he piecemealed from a private wiki, or published by typing with two fingers on a netbook sitting in a café in Italy while eating plum pastries. What I care about is the end product.

Because users value the product rather than the process, and tech comm’s innovation has been in the process, technical communication comes across as stagnant, without innovation, and stuck in the past, while web technologies march forward. The evolution of the web, from static pages in primitive HTML to rich, audiovisual, dynamic content you can interact with by commenting on, subscribing to, trackbacking, aggregating, and mashing up demonstrates tangible progress. It’s an advancement in value that you can see and feel in every way, unlike the invisible advances in tech comm.

The frustrating part is that innovation in technical communication—however invisible—does actually benefit the user in a number of ways. According to my colleague Paul Pehrson (@docguy on Twitter), because of DITA and single sourcing, users now have more consistent documentation. Previously, with the copy and paste method, multiple deliverables would invariably be out of sync—updates would be made to one but not the other. Copying and pasting would also exhaust technical writers, and last minute changes were a nightmare.

Now with single sourcing, synchronization issues are no longer a problem. Last minute changes can easily be accommodated. Topics in multiple sources are the same because they’re generated from the same source. Translation costs are also reduced.

Because of single sourcing, we can also provide more custom, role-based guides. Rather than delivering one enormous reference manual, we can deliver smaller guides for each role. And we can provide all of this information more quickly, with fewer resources producing it. One person can really generate 17 guides, and even update them nightly through an automated build process each time he or she makes a small change to the content during the day. The reduced time decreases the cost of the product overall, making documentation both cheaper and more accurate.

Still, despite these advancements, the user still holds a manual in hand and thinks nothing has changed in decades. This is perhaps the flaw of DITA: no noticeable increase in value in the deliverable. In fact, the plain formatting and generic style may even appear to be a decrease in value. Without any tangible, immediately felt benefits to the user, the deliverables seems stagnant and lacking innovation. It’s a misunderstanding, though—somewhat like the poor, overworked employee who puts in 80 hour work weeks but has nothing extra to show for it.

Blog Sponsors

Anne Gentle on her Forthcoming Book, Conversation and Community: The Social Web for Documentation

Tom Johnson — Wed, 27 May 2009 13:00:39 +0000

Download MP3
Length: 9 min.

In this podcast, I talk with Anne Gentle about her forthcoming book, Conversation and Community: The Social Web for Documentation. Anne explains how we’ve transitioned from the Age of Information to the Age of Interaction, using social web tools to find the information we need. She builds on her experiences with One Laptop per Child, Book Sprints, and her experiences as a corporate blogger for BMC software. In her book, she talks about the future of documentation, the writer’s role, community and documentation, commenting and connecting with users, structured authoring with wikis, and more. The book will be published by mid-summer 2009. Keep updated about the release of Ann’s book by following her blog, JustWriteClick.com.

Blog Sponsors

Richard Hamilton’s XML Press Imprint

Tom Johnson — Tue, 26 May 2009 03:51:45 +0000

Download MP3
Length: 9 min.

In this podcast, I talk with Richard Hamilton about his new publishing imprint, XML Press. Richard started XML Press to serve the needs of technical communicators, publishing books on topics that may not get traction from large publishing houses due to the limited audience, but which perfectly fit a smaller, niche technical communication audience. Focusing on practical topics that technical communicators can use to improve their jobs, XML Press already has one book available and two forthcoming:

Managing Writers: A Real World Guide to Managing Technical Documentation, by Richard Hamilton
Wiki: Grow Your Own for Fun and Profit, by Alan J. Porter (coming soon)
Conversation and Community: The Social Web for Documentation, by Ann Gentle (coming soon)

Richard is looking for topics related to technical communication and XML. If you’re looking to write a book on technical communication, be sure to check out XML Press. Richard also has a blog called Managing Writers.

Blog Sponsors

Managing Writers: Interview with Richard Hamilton (podcast)

Tom Johnson — Tue, 24 Mar 2009 03:13:38 +0000

Download MP3 (to download, right-click and select Save Target As)
Length: 35 min.

Richard Hamilton is the author of Managing Writers: A Real World Guide to Managing Technical Documentation. His book, published in 2009, is one of the few books written specifically for managers that addresses the diversity of issues that managers face today – everything from hiring and firing to motivating, metrics, outsourcing, localization, content management, and more.

Managing Writers

Richard describes the book as follows:

Managing Writers is a practical guide to managing technical documentation projects in the real world. It is informal, but concise, using examples from the author’s experience working with and managing technical writers. It looks beyond big project, big team methodologies to the issues faced by smaller, less well-funded projects.

I actually met Richard Hamilton at Doc Train West 2008. At the time, he was still writing his book, but he handed me a brochure describing the book title and its contents. I’m glad to see that some months after our conversation, he published it.

A few weeks ago, Richard sent me a review copy, so I decided to interview him for a podcast. In our conversation, we cover the following:

Hiring and firing employees
What to look for in resumes
Danger points in interviews
Motivating your team
Rating and ranking
Overcoming differences about tools
Measuring success with metrics
The importance of documentation plans
Getting involved early in the software development process
Ensuring proper allocation and balance across your team
Evaluating whether writers need managers

For more information, see Richard Hamilton’s book, Managing Writers. You can also read Richard Hamilton’s blog. He has made a sample chapter available here: What Doc Managers Look for in a Resume.