Do Screen Captures Still Make Sense?

By Paul Masalsky, EMC Corporation

Writing more simply helps keep content more manageable and can increase its usability. So why do we continue to litter content with screen captures, which can be difficult to manage and often duplicate what users already see in application interfaces?

To understand potential issues with screen captures, consider a recent case from our XML authoring environment, where a writer tried to insert a screen capture into a table, but our PDF formatter couldn’t make the image fit.

The following activity ensued:

1. The writer spent time reducing the image size and improving its clarity.
2. After modification, the image fit in the cell, but was too small to read. So the writer asked our tools team to increase the maximum table width.
3. We asked the writer to consider removing the screen capture, because developing new conditional formatting for the table could take considerable time.
4. The writer replaced the table with an ordered list, which allowed a larger image, but made the topic structure inconsistent with others in his book.

So what’s wrong with this picture?
The writer spent time trying to fit the screen capture into the table, and ultimately accepted a workaround that introduced an inconsistency. More work could eventually be needed to provide translated versions of the screen capture for localization.

Could the writer have simply eliminated the screen capture while maintaining adequate usability? For this particular situation, my answer was yes. The screen capture appeared within a task step, which is almost always referenced when the user is operating within the application UI. The writer could have added textual content to further identify the wizard step and provided a strong example of proper user input. Therefore the screen capture did not provide enough value to justify its inclusion.

After considering the pros and cons of screen captures (many are listed below), you might also decide to forego creating new ones, and maybe even delete the ones that you already have.

Reasons for including screen captures

• A picture is worth 1000 words. If you can describe interface elements (like a wizard panels or dialog boxes) with the aid of a screen capture, readers can interpret the supporting prose more easily. Screen captures also help to minimize prose, as writers don’t need to describe interface elements in detail (they can simply point to a picture).
• Screen captures can help keep the user’s eyes focused on documentation for longer periods of time (rather than switching back and forth between doc and interface, to make associations), which helps make it more readable.
• If a user does not have the application interface available when reading the documentation, screen captures provide the reader’s only visual image, and therefore might be critical to establishing an understanding of the surrounding prose. Historically, even in cases where the application is available, users have welcomed screen captures because they are helpful if used and not harmful if skipped.

Reasons for excluding screen captures

• They are difficult to manage for localization. In most cases, localized applications are needed to adequately capture localized user interface elements. Therefore you’ll need access to localized application sandboxes (often not available at authoring time). You also must maintain one screen capture image for each language, conditionalizing their inclusion or exclusion based on locale. Because there are so many versions to maintain, they could easily get out of synch with application interfaces and thus become inaccurate. Sometimes it is acceptable to localize only surrounding text and leave screen capture in the original source language. But how will this help users who don’t understand the original source language? It could also negatively impact usability by making users struggle to associate elements in the screen capture with those in their localized applications.
• They can occupy a lot of space. In our content management system, the average size of a JPG image is about 40KB. Adding 25 screen captures of this size to an uncompressed help system (for example, webhelp) can add a 1 MB disk space requirement to an application’s install footprint. Customers are always demanding that application install footprints occupy less space. So it makes sense to minimize the size of help systems, both through compression (if possible) and minimalization of content. The elimination of screen captures can often make a help system a lot “leaner and meaner.”
• They can duplicate application interfaces. For most use cases, users will read documentation while following along in an application interface. With a screen capture, they often see exactly what is seen in the UI. Although it helps to have a capture for validation, one could argue that there is little value in duplicating the UI in the documentation. Well-written prose is often sufficient to support the user interface.
• For years, writers have included screen captures to provide support for textual content. But we have also used screen captures as a “crutch” to avoid writing better prose that can “stand on its own.” If screen captures are removed, chances are we’ll write better textual content.

Summary – What should I do?

Because writers are being asked to do much more work with fewer resources, simplicity wins when considering standard processes for dealing with screen captures. I recommend the following:

1. Ask yourself, will users still be successful in performing their intended task and find the information useful, without the presence of one or more screen captures?
2. Do one of the following:
   • If yes to #1, do not include the screen capture(s).
   • If no to #1, make improvements to the surrounding prose (and possibly the application UI). Then proceed to #1.

After experimenting with this process for a while, you might discover that screen captures are not vital to usability, and find your content to be much more simple and manageable as a result.

About the Author

Paul is software engineering manager and information architect at EMC Corporation. He is responsible for implementing a corporate-wide XML authoring environment at EMC. He has over 20 years experience in software as a developer, technical writer, trainer, and manager.

Similar Posts:

None Found