Screen capture tools

Screen capture tools have improved outta sight since I first started using the PrintScreen key and Windows Paint! My next step was to use PaintShop Pro v4 (!) to capture and manipulate screen shots. But even with PaintShop Pro, capturing screens for display in user documentation or web pages was still a long and tedious process, especially if you wanted to apply any edge effects or similar to your screen shot, or to capture the exact window.

Years ago, various members of my tech writing discussion lists suggested several screen capture programs. I tried out a few and it was a toss up between TNT and SnagIt. I decided I like SnagIt better, but I can’t remember now why I chose it over TNT — they both had features I needed and were priced cheaply enough that if I regretted my decision, I could always invest in the other product.

Today, I’m still a very happy SnagIt user, and I willingly pay for an upgrade each time a new version comes out. It’s my tool of choice for screen captures (all screen shots in this blog are created with SnagIt). SnagIt continues to provide me with the features I need — there’d have to be a really compelling reason for me to shift to any other screen capture program. (SnagIt is available for just under US$50 from TechSmith: http://www.techsmith.com/screen-capture.asp)

That said, I find it sad that many of the (non technical) writers I work with have no idea that they can take a screen capture with anything other than the old PrintScreen trick — or the Snipping Tool in Vista. I’ve tried to use that Snipping Tool, but I find it really clunky, compared to SnagIt.

If you’re ready to move up from PrintScreen or the Snipping Tool, and are looking for a decent screen capture program, check out these resources:

• 27 Useful Screen Capture Tools: http://www.webdesignbooth.com/useful-screen-capture-tools/
• Review of Screen Capture Tools (by Matthew Ellison): http://www.writersua.com/articles/capturetools/index.html (updated January 2010)
• http://techcommtoolbox.com/category/screen-captures/

Most tools have a free trial option, so it’s worth downloading a few and trying them out. If you have more than the very occasional screen shot to capture, you’ll save yourself HEAPS of time just by using the right tool for the job. Just as there’s no point using a sledge hammer or the edge of a spanner to hammer in a panel pin, there are easier ways to capture (and manipulate) screen shots that using PrintScreen or the Snipping Tool.

[Links last checked June 2010; SnagIt have not paid me to endorse their product (I wish!) — I’m just a happy user]

Should I put screen shots in online Help?

This is a perennial question asked by technical writers, especially newbies. When it comes to the answer, seasoned tech writers typically divide into two main camps — yes or no — with some variations within those answers.

My stance is “It depends” (which means I have a bit of a bet each way!) Let me explain further…

Whether I include screen shots depends on:

• what the (internal/external) client/user wants
• what the output is (online, print, or both)
• if online, what screen ‘real estate’ is available
• how complex the software application is
• how difficult/easy it is to get the screen shots required (e.g. before/after code freeze)
• the budget for the project — adding screen shots adds quite a bit of overhead in time (think at least 5 minutes per screen shot), and therefore can add substantially to the cost of producing the documentation, and maintaining it (many screen shots may have to be recaptured for a new release*).

I’ve used screen shots extensively in some projects, but rarely in others. Even within the same project, I’ve used them for the printed output but not the online output.

That said, I almost always have at least one screen shot of the basic screen layout that has a key/legend to describe the various parts of the screen, particularly where the terminology for the various parts is different from applications that are likely to be familiar to the user. (Tip: Do NOT add callout text directly on the screen shot. Instead, use numbers or letters to mark the respective elements, then add a key/legend table in the text below. Why? Because if you have to update the screen shot later, adding all those callouts again is a pain; and if the documentation has to be translated, you’ll save time by not having to create multiple screen shots with callouts in different languages.)

Example of a screen layout, with numbered callouts and a key below the screen shot

I do use images of unfamiliar toolbar icons in my software documentation:

Example of toolbar icons used in text

And I may use other images to enhance understanding. For example, an application I documented contained functions to convert 3D graphical objects into something else (e.g. converting wireframes to 3D solids, trimming triangulations, performing Boolean operations on solid objects, adding/moving/deleting vertices, finding boundaries between complex objects etc.). For each function, I took a “Before” and “After” screen shot of a simple example so the user could SEE what the function did. As I said, this was for a very graphically intensive application, and words only went so far. The screen shots enhanced the learning experience as it showed the user an example of what the function did, without them having to set it up and test it themselves.

Example of screen shots to enhance comprehension

However, in general I don’t use screen shots in online Help. For the few that I might add, I try to use a graphical clue such as a torn edge to show that the image is a screen shot and not the real application. Why? Because even after all these years of working with software, I still get caught occasionally clicking a Close button on a screen shot in the Help! ;-)

I will use screen shots in print if ‘showing’ helps the ‘telling’. The nice thing about Help authoring tools that have ‘conditionality’ and/or variants built in (such as Author-it)  is that you can add screen shots throughout the documentation, and set conditions so they are only published in the print output, not in the online.

* About maintenance: On one project, one of the developers changed the text on a dialog box tab. A simple change for the developer. Unfortunately it wasn’t so simple for me. In addition to changing at least 10 topics where the tab name was written, I had to recapture more than 50 screen shots as that tab name displayed on every screen shot of the dialog box throughout the documentation.

Get crisp, clean graphics from a Word document

Here’s a tip when you need to extract GOOD graphics out of a Word document: Save the document as HTML pages.

You get the text, which you can ignore, and a folder of images in both PNG and JPG formats. If they’re screenshots and the like, the JPGs are invariably scruffy (jaggy, pixellated etc.), but the PNGs are crisp and clear. Quicker than capturing – even with SnagIt – and you get the images at the full size they were saved in the document, not Word’s resized version to fit the page.

Update: 27 May 2008: Save as HTML (File > Save as > Web Page (*.htm, *.html)), not filtered HTML (File > Save as > Web Page, Filtered (*.htm, *.html)). Filtered HTML only gives you GIFs and JPGs; you need ‘straight’ HTML to get PNGs.

Update: 21 August 2008: This behavior seems to be the same in Word 2007. Saving as Filtered HTML only results in JPGs, whereas saving as HTML gives you PNGs as well.