Communications from DMN 

Dealing with Bad Software - January 22, 2007





This is Communications from DMN for for the week of January 22, 2007.

Scott

I'm Scott Nesbitt.

Aaron

And I'm Aaron Davis. Thanks for joining us this week. 

Scott

We're counting down the days to the eighth Annual Documentation and Training Conference, April 18th to the 21st in beautiful Vancouver, British Columbia. Aaron and I are working on the outline of our talk, which is called "Getting a Foothold: Using Basecamp to Improve Productivity and Collaboration." We're really excited about this conference and hope to see you there. To find out more, visit www.doctrain.com.

Aaron, what are we talking about this week?

Aaron

..something that we've all experienced before, unfortunately - bad software. Recently, Reuters ran an article that talked about hard to use software and suggested that programmers are to blame. As technical communicators, we know that hard to use (or just plain bad) software can be a product of a variety of causes - poorly defined requirements, rogue development, lack of business analysis, and that general hubris that "we know best what the user needs".

We've all been there before. The initial design and analysis stage has come and gone. Remember that feedback that you gave on the consistency of the interface text? A distant memory by now. You have lunch with the usability analyst and trade horror stories about the unnecessary complexity of the prototype UI. You shudder to think at how the user is going to react. All the while, development plods along. As a technical communicator, what do you do?

Scott

The answer often depends upon whether you are a full-timer or a contractor. In the freelance world, it's less of an issue. Once you finish delivering the help or PDFs or multimedia content, you're finished. If the product succeeds, it's a great reference. If the product fails, it's still a reference - you delivered. If you're a full time employee, though, things are very different. That's mainly because you're going to be the one living the nightmare of future product iterations.


Sometimes, the results of fixing previous development missteps create a product that was even worse than the original. One thing is for certain - you have a lot of writing to do.

Aaron

At this point, the ship is too far into the voyage to turn around. Development is well underway. Management is satisfied that the project is progressing on target. You are faced with an ugly reality - you are going to have to document software that is considered sub-par in conception/design/analysis/execution/all of the above. If you're a user advocate like we are, you're challenge is to improve the user experience by producing effective focused content for a half baked product.

Scott

You are going to have to go the extra mile and log extra hours because of the extra effort required to elegantly communicate how to use an inelegant solution. For example, you'll probably have to spend extra time structuring information in order to accommodate procedures that have a less than logical flow. Or you will have to include more screen shots than normal to illustrate a process or task. You will likely spend more time with development asking questions and clarifying functionality. The fact is, you really have to care about a product at this point.
Aaron
 On the other hand, what if you don't care?
Scott
 That's a tough one. Really, you have a few choices. The first is to lobby to make the software more usable. You'll have to make a really, really convincing argument to the powers that be -- one that quantifies the shortcomings of the software in terms of a dollar value. Why? Making changes for usability will require a major re-write of the application. Something that most developers will loathe. Expect to run into a lot of resistance, which could ratchet your frustrations up several more notches.

Or, you can just document the software without worrying about the user, about the software being counterintuitive, or anything like that. That's the easy way out, and a technical communicator who is truly a professional won't be happy with doing something like that.

The last option is to get out of there. If you don't care, then you're job's going to be a chore and you're going to be unhappy. Your unhappiness will really reflect in your work. There's no shame in cutting your losses and running. I know, that sounds harsh. But that's the reality of things from my perspective. If you're a professional, you take pride in your work. If you can't do that, you need to find something else.
Aaron
 No argument there. Scott and I would really like to hear from our listeners out there on this topic. We're hoping to start a dialog with other technical communicators that could one day become the foundation for a manifesto for the new technical communicator.

If you've had to document bad software, either as a contractor or a full-time employee, we'd love to hear your story and how you dealt with the situation. Add a comment to the blog entry, or shoot us an email at podcast@dmncommunications.com. We're hoping to start a dialog with as many different voices and viewpoints as possible.

Scott

Now it's time for our Pick of the Week. Each week we choose a book, Web site, or blog that we find interesting and useful and hope that you will, too. This week, we look at a little utility called FastStone Screen Capture.

Aaron

Screen capture software can really draw out strong emotions in technical communicators. Some of us swear by SnagIt. Others want a screen capture tool that's also an image editor and death ray. Scott and I, though, tend to prefer something simple. And that best describes FastStone Screen Capture.

It's a small download, weighing in at a little under a megabyte and a half. But it does what it's supposed to do, and does it well. Like many of its rivals, FastStone Screen Capture can take snaps of full application windows, objects, your entire screen, or portions of a screen. You an also do a freehand selection of what you want to capture or take a snap of scrolling windows or Web pages. You can save your screens in several popular image formats, including PNG and TIFF. Or, you can send the image to an editor or email it.

FastStone Screen Capture is really easy to use. You set up a hot key, and it sits in your system try. When you hit the hot key, it takes the screen capture and prompts you for a location to save it. Quick and simple. And cheap -- a lifetime license costs only $24.95, and the company takes payment via PayPal. The trial version is fully functioning, and has no nag or ad screens.

For more information, and to download the software, visit www.faststone.org.

Scott

That's all we have for this edition of Communications from DMN. Join us next week when we devote the entire discussion to tools. We're going to cover the Robohelp 6 vs MadCap Flare, why MadCap supports Adobe better than Adobe and where Word 2007 fits in.


Thanks for listening. If you have any questions, comments, or suggestions for future podcasts drop us a line at podcast@dmncommunications.com. And don't forget to visit our Web site (www.dmncommunications.com) and our blog (www.dmncommunications.com/weblog).

Have a good week.