To screenshot or not screenshot? (that is the question)

[BL_N]

I've been reading more and more lately from the perspective that posits screenshots are redundant for application or online help as the user referring to them generally has the application open (hence does not need them). Considering this seems to be a rising trend and also considering how reducing or eliminating them will improve search functionality and allow for tighter task topics (users seeking help want a specific answer, the ability to find it quickly, follow it, and be done), I've been asking myself the question referenced in the subject line a lot of late.

My current client has decided to forego screenshots completely in favor of task topics for 'doing' things as opposed to learning about things. Their logic runs along the lines of 'we aren't giving them online training, we're giving them online help'. (Yes, they do sell training and yes, this was part of the consideration and not unusual in my experience.)

I note that MadCap and a number of other (and well known!) companies have adopted this approach and seem to be doing very well with it. I have also heard opinions that take exception (both at this client location and 'out and about' in the industry), and look as I may, I'm not finding much in the way of 'compelling reasons' to keep screenshots in application and online help; even the 'old school' seems undecided excepting those aspects of Neilsen's work that are somewhat parallel (i.e., graphics and text on the web, scanning versus reading behaviors, etc).

So I thought I'd ask and see what you fine folks have to say on the matter. Are there compelling reasons why screen shots are mandatory parts of your online help? If so, what are they? Do you think screenshots in application and online help are more a matter of expectation and comfort? Have you tested using graphics or not and, if so, what were your findings?

[KevinDAmery]

I don't do many screen shots - I generally only do them in places where it's complex to describe what to do using only words. If I feel that callouts would be helpful, I add a screen shot. There are also times that I make use of image maps so that users can click on a screen shot element and get a popup describing that element's usage.

My feeling is that a straight screenshot usually doesn't add a lot of value in online help, because odds are the user already has the UI open so they know what it looks like. (But to play devil's advocate, if your help is designed with a large skin size, it may be blocking the view of the UI, and making the user toggle back and forth isn't all that friendly.) There are occasions where I include one anyway to make something clear - in most cases, I put those inside a toggler so that users who want to take a look can but those who don't need it can get on to the rest of the topic without undue scrolling.

In the broader world, one of the main reasons that screenshots started to get rare was Microsoft's adoption of the tall thin help window along the side of the Office applications. In a help window of those dimensions, screenshots tended to introduce more complications than they solved. Other companies started following suit (more as a "monkey see, monkey do" kind of thing than anything else, imo). But If your help window isn't shaped that way, obviously there's no reason to follow M$'s lead....

[dwag]

In general, I endorse Mr. Amery's approach.

[LTinker68]

I think it also depends on what you do with the screenshot. If you're just including the screenshot to show which screen you're talking about, then it's not as necessary -- you can just tell the user how to get to the screen and they can do it on their own. However, you could include the screenshot in online help so that you can have popup descriptions of each field (user clicks on the field they're interested in learning about and a popup window appears with the info). On the other hand, if your application windows are large then you're probably having to shrink the screen capture down quite a bit so that the screen can appear in the entire help window, in which case, you may be making it harder for the user to click on field A versus clicking on field B.

Unfortunately, I kind of straddle the fence. I, personally, prefer reading a user's manual with screenshots because I might read it during the commercials while I'm watching TV and I'm nowhere near the computer and the application. On the other hand, having a help window show a screenshot of a screen that's sitting next to the browser or .chm window is kind of redundant.

Long story short... For printed output, I include screenshots, even if you expect them to be sitting in front of the computer when they read it. For online help -- especially help that's launched from the app -- I tend not to use as many screenshots. Generally it's just to show how a screen might have changed after a user action or if I'm showing the layout of the screen (e.g., "1. Navigation pane", "2. Toolbar", "3. Message window").

All my personal opinion, of course.

[SteveS]

If only it were a yes/ no question....

Users with printed documents expect a certain number of screenshots so they can see what they're reading about. Talking about screen layout is easier if the reader can see the features.

Users accessing online help don't need the screenshots, they can minimise the help to see the real thing.

Until the help says something like 'click the X button' and the user can't find the X button. Then they want a screen shot showing the X button.

And that's were conditional formatting comes in - in the online I use a screenshot of the X button instead of refering to it by name.

And togglers are good, too. You can have a toggler to 'show screen shots' in case you have a complete novice who wants to have everything pointed out.

If only it was a yes/ no question

[MikeKatz]

I've moved in the opposite direction to most views here.

First, for manuals, I always have screen shots. I then annotate them to show the main features of each screen. Manuals are overview documents for me, they show users what they can do, not how to do it. And even then, we just show the major features.

With help files, I initially left screens off for all the reasons mentioned, plus another one - the final imagery (icons, graphics, etc.), was invariably so late that there was not enough time to update the help files.

However, we received many complaints about the fact that the screen were not there. Since we have a lots of users, over 150,000 for one package, I think it's fair to say that, for whatever reasons, end-users (of our packages at least) prefer to have screens.

One reason I know of is that power users and resellers are quite prepared to browse through the help in order to learn the package, without running the software.

Another speculation of mine is that I have many links in the package. So, for example, in the help for an invoice line field, I would give a link to the customer maintenance screen where you can set something that impacts that field, and to a system setup screen that also impacts the same field. Jumping to that topic, without that screen showing, removes the "excuse" that the screen is always there anyway.

[KevinDAmery]

Mike brings up a good point: at the end of the day, it's all about helping the customers do their jobs. So if you've got access to customer feedback about what works in your documentation and what doesn't, naturally you'd be best served by taking that feedback into account.

[RamonS]

I am pro screen shot, but mainly only because I like to have many detailed screen shots in the help files that I use. That allows me to understand the features and functions before I attempt to use them in the application. It also allows for exploring various options and learning about what is available even when I currently may not have a use for these features.
In the help systems that I create I add many screen shots and if helpful include small images in the text. Typically, I have some very easy formatting conventions, for example anything that is bold is either a button or a menu / menu command. Anything italic is a form title, and anything in fixed width font is a label or section title. There are some cases where none of these simple rules provide a clear explanation as to what to do with what and in that case I might add inline images. I try to stay away from that as much as possible as it doesn't flow well and is a pita to maintain.

The other option that I tried once for a very small project is to use screen portraits. They lend themselves well when there is still change in the GUI (especially labeling) and when a project needs to be translated. Screen portraits are a lot of work, but one usually has to do them once and then forget about them.

It also depends on what the output is. For example, WebHelp and PDF may need to have plenty of screen shots since the WebHelp can be access directly on the server without having the application running and PDF can either be printed or viewed independently from the application as well.

One other consideration is file size. I once created a WebHelp for an embedded system that was accessed via browser. Due to the limited storage capacity I was extremely conservative in regards to screen shots and for those that I added I used 256 colour PNGs just to keep everything as small as possible. For desktop apps it wasn't uncommon that my help file was three times the size of the executables.

[MikeKatz]

One other consideration is file size. I once created a WebHelp for an embedded system that was accessed via browser. Due to the limited storage capacity I was extremely conservative in regards to screen shots and for those that I added I used 256 colour PNGs just to keep everything as small as possible. For desktop apps it wasn't uncommon that my help file was three times the size of the executables.

Good point. My HTML help file went from 1.8mb to 13mb when I put the screens in.

[KevinDAmery]

It also depends on what the output is. For example, WebHelp and PDF may need to have plenty of screen shots since the WebHelp can be access directly on the server without having the application running and PDF can either be printed or viewed independently from the application as well.

I tend to view PDF as being more like a manual than an online help system. Yes, it is virtual, and yes, it has dynamic elements like hyperlinks, but it also has a definite sequential page structure and is designed to emulate a printed document as closely as possible. So if I was designing a document with the intent of distributing it as a PDF, I would structure it as if it were a print manual rather than as if it were a help system - meaning more screen shots, a more linear communication style where I assume that someone reading page 200 has probably read most of the preceding 199 pages more or less in order, longer sections / chapters, etc. In other words, I would structure it like a book, rather than like a web site.

(Note that this isn't how I do things when my primary deliverable is a help system which I then repackage as a PDF - I'm talking about situations where the document is intended from day 1 to be primarily delivered in PDF format.)

[RamonS]

Yes, Kevin is right and my assumption was that PDF is a side product, not a planned target. I just didn't make that clear in my post.

[KevinDAmery]

An option in that case, of course, would be to make all the screen shots but give them a Print-only condition.

[QBF]

I build Webhelp and virtually all screen shots in my documentation are conditioned for print only. There are a few exceptions such as an unusally difficult screen or dialog box. However, I have have the "print" version as a PDF which is launchable from a button on the Webhelp toolbar. This allows the user both options in one package.

On another note, reading Lisa's post on reading documentaion while watching TV brought back memories of my reading manuals as fun bedtime reading. YIKES!

[KevinDAmery]

On another note, reading Lisa's post on reading documentaion while watching TV brought back memories of my reading manuals as fun bedtime reading. YIKES!

Can't say I ever did that. I was more of the "click this button and see what it does... oooh, nice explosion!" persuasion...

[LTinker68]

I was more of the "click this button and see what it does... oooh, nice explosion!" persuasion...

That's what I do when I'm documenting software, but that's not what I want to see from a product that I purchased.

[KevinDAmery]

I was more of the "click this button and see what it does... oooh, nice explosion!" persuasion...

That's what I do when I'm documenting software, but that's not what I want to see from a product that I purchased.

What? I was playing Counter Strike

[beagley]

Gosh,
I strongly disagree with the prevailing sentiment here.

I put screenshots into everything. Every step of every procedure has a corresponding screenshot. My experience is that people barely ever read text anymore. The screenshot shows them exactly where to click, something words can never do effectively.

This holds up in my own experience: I hate help systems that have no screenshots. I need to see what I am doing, especially when learning a new piece of software, where the terminology may be new to me. I wish, wish, wish that Flare's help had more screenshots.

My readers, also, really really like pictures. In fact, in some cases I've been tempted to cut the WORDS and leave only the screenshots. Which is what a video is. Which is why I've been making more and more quick tutorial videos... they LOVE the videos.

BTW: I do not mean full-size screenshots. I clip and cut each image so that it hones in on exactly the part of the screen needed, and I generally add circles/arrrows when clicking leads to a result.

-d

[BL_N]

Well, there's a pretty big caveat that is implied in all this -- you go with what is best for your users. That said, it doesn't make a lot of sense to present screens when the user is already looking at the screen (of course, this assumes you're VERY exacting in your descriptions) and there are even some studies that indicate having an image by the screen can lead to intermittent confusion.

We are, of course, talking about non-print mediums and that does make a difference. Also, we're talking about 'how to' information, not training, orientation, or learning materials. It's fairly well established that users who want to know 'how to do x' appreciate simple, task-based topics that present 'how to' rather than explain every field, what goes in it, etc.

In the back of my head, that which is training and courseware development is screaming and I fully know and accept that leaving out half of the four learning types is sub-par, but it is a rare client indeed that can stomach the notion of the behemoth that would be a full-scale help implementation to include online, video guides, and example walkthroughs.

Like everything else in life, small steps.