Screen Captures in Software Documentation.pdf

APPLIED THEORY SUMMARYr Proposes a taxonomy that identifies the roles

and designs of screen capturesr Suggests that screen captures help users switch

attention, develop a mental model of theprogram, verify screen states, and identify andlocate window elements and objects.

Screen Captures in SoftwareDocumentationHANS VAN DER MEIJ and MARK GELLEVIJ

INTRODUCTION

Screen captures have received little attention in theliterature on technical documentation. For exam-ple, Brockmann’s highly regarded handbook doesnot discuss them (Brockmann 1990). Schriver also

does not discuss screen captures, although her book detailsmany principles of visual design and of the interplay betweenwords and pictures (Schriver 1997). Other handbooks like-wise pay little attention to screen captures (Markel 1994; Priceand Korman 1993; Simpson and Casey 1988).

Yet screen captures are probably the most frequentlyused illustration in software manuals (Horton 1993; Hough-ton-Alico 1985). Does this then mean that the lack ofattention in the literature is at odds with common practice?It may. But it is also possible that screen captures are not ascommonly used as practitioners attest. To our knowledge,their impression has never been tested empirically.

We examined the idea that most pictures in manuals arescreen captures by conducting a simple inventory. We ran-domly gathered 100 software manuals and, again randomly,selected a single page from each manual showing one ormore pictures. After coding the pictures, we found that:

r Seventy-six percent of the pages showed one ormore screen captures. Nearly all screen captureswere pictures from the whole screen or program, orpictures from one or two windows of the program.We found only six screen captures showing a singleobject (symbol or icon).

r Twenty-three percent of the pages had a picture inthe form of a schema, flowchart, diagram, or table.

r Fifteen percent of the pages showed an icon or asymbol that identified an information type such as anote, tip, or warning.

r Six percent of the pages showed an icon or a sym-bol of the manipulation device (usually the mouse).These findings strongly support the impression of

practitioners that the most frequently used picture in soft-

ware manuals is a screen capture. It outnumbers otherillustration types by a factor of three or more.

Why is this so? Why are screen captures the dominantpicture? Indeed, why use pictures at all? The answer is thatscreen captures can improve user cognition (that is, knowl-edge and skill) because they can convey some things betterthan other illustrations or words (Horton 1993). Although thisis an important claim about screen captures, there is littleempirical research to substantiate it. In addition, the claimgives no real guidance for creating effective screen captures.Our main aim is to provide a high-level organization or tax-onomy of the roles and designs of screen captures.

Although screen captures can improve user motivation,this is not a core issue in this article because the main argu-ments are not unique for screen captures. For example, Hor-ton predicts that user motivation will increase because screen

Manuscript received 15 April 1998; revised 15 July 1998;accepted 16 July 1998.

TABLE 1: FOUR MAIN ROLES AND DESIGNAREAS OF SCREEN CAPTURES

Roles Screen captures can help the user to:r Switch attentionr Develop a mental model of the programr Verify screen statesr Identify and locate window elements and objects

Designs Screen captures can vary in the followingdesign areas:r Coverager Positionr Sizer Cueing

Fourth Quarter 1998 • TechnicalCOMMUNICATION 529

captures provide visual relief on pages full of text and becausethey enhance the attractiveness of the manual (Horton 1993).These predictions pertain not only to screen captures. Rather,they have also been advanced for pictures in general (Fredette1994; Levie 1987; Peeck 1993).

We suggest that screen captures can serve four cognitiveroles or functions and that their designs vary in four mainareas. Table 1 summarizes these roles and design areas.

The next sections discuss the main roles and designs ofscreen captures. A screen capture can serve more than onemain role, but for clarity of presentation we have ignored thisfact in our discussion. Each section first discusses the effect ofeach function on the user and offers arguments about thebenefits of using screen captures for support. Then, examplesfrom existing manuals are presented to illustrate the variousexpressions or design solutions for each main role or subrole.Each example is considered from within the larger perspec-

tive of the kind of information processing it is intended tosupport (van der Meij 1997). That is, we classify each screencapture and corresponding text as supporting a conceptual orprocedural process. Next, the design areas that are critical toeach (sub)role are discussed. (A description of the four designareas is given in the appendix to this article.) Finally, eachsection concludes with a presentation of findings from em-pirical research.

SWITCHING ATTENTIONThe user of a manual must pay attention to three distinct sourcesof information: an input device, a manual, and a screen. Animportant difficulty in handling these sources is dealingwith theirinterrelationships. Users must regularly switch attention to andfrom input device, manual, and screen.

This is a complex task, and users, especially novices,easily err in coordination. A typical problem of this kind may

Figure 1. Screen captures can prompt users to switch attention to the screen at the right moment and provide a clear point for

reentry into the manual afterwards.

APPLIED THEORYScreen Captures in Software Documentationvan der Meij and Gellevij

530 TechnicalCOMMUNICATION • Fourth Quarter 1998

occur when the user reads an instruction, carries it out, andthen performs the next step, “never checking to see if the stepworked properly, or if anything happened at all” (Carroll1984, p. 126). This nose-in-the-book syndrome is a well-known example of a user failing to switch attention whenneeded.

Screen captures can help the user with switching at-tention by

1. Prompting the user to attend to the screen at theright moment

2. Providing a clear point for reentry into the man-ual after attending to the screen

A screen capture can cue the user that it is time to lookup to the screen, as Figure 1 illustrates. The example showspart of a procedure to add a clip art picture. The two screencaptures (with some text) present coordinative informa-tion, prompting the user to attend to the screen. The pres-ence of a screen capture after each action step also makesit easy for the user to get back to the right place in themanual after having looked up at the screen.

The screen capture in Figure 2 prompts users to switchattention to the screen regularly. The example shows theprocedure to load a file. Text and screen capture convey aset of numbered instructions. The screen capture stimulatesthe user to look up to the screen for each instruction.Leader lines help focus the user’s attention to the relevantparts of the screen, previewing where to look.

Design area(s)A critical design area for switching attention from the man-ual to the screen is positioning. This fact is illustrated inFigures 3 and 4. In Figure 3, the writer chose to separate thedisplay of text and picture. The text conveys the directinstruction to act. The screen capture, in this case an icon,

is not needed to carry out that instruction. In addition, theicon is positioned so far to the right that it is doubtfulwhether it serves any meaningful purpose. The user maysimply fail to perceive it.

In contrast, the icon in Figure 4 is prominently placedwithin the instruction. The visual cue to switch attention isnot only much stronger; it also contains vital informationfor task execution. The user must attend to the icon to carryout the action step. The picture is no longer redundant.

Although only slightly different from Figure 3, Figure 4displays a radically different documentation approach. Byavoiding redundancy, by leaving out the text that wouldcomplete the verbal instruction, this setup strongly empha-sizes the visual object. In addition, it does not require thatusers know its name, just its look.

ResearchOne study with experienced computer users has examinedthe effects of screen captures on switching attention (van

Figure 2. Screen captures in which objects are visibly connected to user instructions support frequent switches to and from the window.

Figure 3. A screen capture that appears after a verbal

instruction may be overlooked by the user.

Figure 4. A screen capture that forms an integral part of an

instruction can hardly be ignored and identifies what the user

should see on the window.

APPLIED THEORYScreen Captures in Software Documentation van der Meij and Gellevij


der Meij 1996a). The study compared the effectiveness ofverbal cues such as “You should now see the Print Param-eters screen” to the effectiveness of presentations in whichsuch cues were accompanied by a screen capture. Theresults favored verbal cueing over a combination of textand picture (28% versus 15%). After a verbal cue, the usersswitched attention from the manual to the screen signifi-cantly more often. Users who had received a combinationof text and picture looked up to the screen less often; theyjust read the information.

The audience selected for the study may have stronglyaffected this finding, however. Experienced users probablyneed little support for switching attention. When informa-tion is given in “armchair format”—namely, a combinedcue of text and picture—these subjects may feel quitecomfortable with merely reading it and not actually per-forming the task.

Interestingly, research has shown that novices use ver-bal cues quite frequently to switch attention. In one obser-vation study, we found that these subjects reacted to be-tween 69% and 79% of the verbal cues by looking up to thescreen (van der Meij 1997).

DEVELOPING A MENTAL MODEL OF THE PROGRAMA mental model is a user’s understanding of how a programworks. It helps the user construct actions and explain whythese actions produce particular results (Carroll and Olson1988). A mental model has to do with structure, with usersbecoming acclimated to the standard layout of the win-dows in a program. Supporting mental model developmentshould not be confused with creating a favorable firstimpression. In sales brochures and the like, screen capturesare presented for marketing purposes, not for building amental model of the program.

Mental models play a critical role in problem solving.Users rely on their mental models and on their thinkingskills for detecting, defining, diagnosing, and solving prob-lems. In addition, a good mental model enables users tohandle novel situations. Experience, training, and imitationall contribute to mental model development.

Screen captures can contribute to the development ofa mental model by

1. Acquainting the user with the main windows2. Explaining the spatial layout of a window3. Developing a sense of logical flow, or progres-

sion, of windowsA limited number of windows define the look of a

program. To acquaint the novice user with the main typesand ensure active processing of each window, it is bene-ficial to present the windows while the user executes basictasks. A screen capture that appears during task executionis a strong prompt for the user to study the window. Theinvestment of mental effort is vital for the development of

a mental model (Peeck 1993; Winn 1993). In Figure 5, theuser becomes acquainted with some important windows inthe course of doing real work. The example is part of aprocedure for saving a file. Figure 5 acquaints the user withthe main windows as they appear in sequence during taskexecution. Windows and the pop-up menu are displayedin their correct proportions to convey the real look of theprogram.

Users must develop some understanding of the designor spatial layout of screens. Without such structural knowl-edge, they would be constantly overwhelmed by the infor-mation presented on the screen. While users obtain somestructural knowledge simply from repeated exposures to aprogram, it is not always wise to rely on such incidentallearning. Sometimes it is better to explain the spatial layoutof a screen.

Figure 6 shows a screen capture that is designed to doprecisely that. The screen capture is part of a procedurethat instructs users to create slides. The picture shows thestart screen. Only the active window, the full window ofthe new slide, is displayed. Leader lines and captions drawthe user’s attention to and give a pointed description of thestructural elements of the window. To keep the user fo-cused on spatial elements, the various objects on the toolpalette and the toolbar are not cued.

The presentation of a series of screen captures thatcatch the logical flow or progression of windows can be avery strong means for developing a mental model. This factis illustrated in Figure 7. The figure shows three main stages

Figure 5. To acquaint novices with a program’s main types of

windows, it is beneficial to present these in the context of real

work.



of processing a signal (a voice waveform) for multimediaproduction. The first window (a) shows the shape of anuncompressed signal. The second window (b) displays thecompression, which leads to a reduction of volume peaksabove a certain threshold. The third window (c) shows theresult after normalization, which makes the sound as loudas possible without distorting it. The pictures show howcompression reduces the variability in volume level of anoriginal signal and how subsequent normalization resultsin a fairly consistent and high volume. Screen captures andexplanatory text effectively convey the technical issue ofsignal-to-noise ratio.

Design area(s)An essential design area for the development of a mentalmodel is coverage. This is illustrated in Figure 8 and Figure9. Figure 8 comes from a visual manual that uses the “stepby step” approach. The example shows the procedure forstarting Explorer. Although there is a screen capture foreach action step, a sense of continuity is not conveyed. Thescreen captures, predominantly partial ones, seem uncon-nected to one another.

The full screen captures in Figure 9 better support thedevelopment of a mental model. The example is drawnfrom a “visual learning guide,” a trademarked method. Theconsistent presence of the desktop creates a stable andshared context for all screen captures. In addition, thescreen captures convey a sense of progression by display-ing the Control Panel as the active window in step two andas the hidden window in the next step.

Figure 6. Explaining the layout of a window contributes to

mental model development.

Figure 7. The presentation of a series of screen captures that

catch the progression of windows can strongly affect mental

model development.



Another important design area for the development ofa mental model is size. A situation in which size canobstruct the development of a mental model occurs whenscreen captures take up too much space (Horton 1993).Figure 10 displays such a situation. The example is part ofa nine-step procedure for setting up and configuring HotJava. What would normally take about half a page con-sumes more than two pages of this manual. The end resultis that the steps are spread so far apart that users easily loseall sense of connectedness.

ResearchResearchers have found it difficult to find a good way tomeasure the development of a user’s mental model. Forwant of a better alternative, we suggest the following def-inition for future research on user documentation. A mentalmodel is the combination of knowledge and skills thathelps users solve problems—both those for which theyhave received training and those for which they have notreceived training—without support from a manual. A scoreon a posttest usually reflects this.

Empirical research indicates that screen captures havea significant effect on the development of a user’s mental

model. In two separate studies, we found that users’ mentalmodels differ considerably, depending on the kind ofscreen captures they encountered during instruction (Gel-levij, van der Meij, de Jong, and Pieters 1998; van der Meijand Jenne in preparation). In both studies, the criticaldesign variation is coverage. Subjects who practiced with avisual manual that consisted only of full screen capturesdeveloped a significantly better mental model than didsubjects who used a visual manual that used predominantlypartial screen captures.

Although these two studies yield empirical evidencethat screen captures affect the development of a user’s

Figure 8. In “step-by-step” visual manuals, each action step is

connected to a screen capture. Because of their design, a sense

of continuity is not conveyed.

Figure 9. The full screen captures in “visual learning guides”

convey a sense of progression.



mental model, one of the two studies offers an importantcaution. The caution is that “bad” screen captures canhave a very negative effect on the user, whereas “good”screen captures may help only a little. That is, Gellevij,van der Meij, de Jong, and Pieters found that subjectswho had trained with a manual without screen cap-tures—a textual manual—scored significantly higher(14%) on a posttest than did the subjects who had usedthe visual manual with partial screen captures. The sub-jects who had received the visual manual with full screencaptures scored 5% better on a posttest than did thesubjects with the textual manual. This difference was notstatistically significant, however.

It is too early to conclude from the above studies thatit is better to err on the safe side and not provide screencaptures at all. For experienced subjects, the support

given by screen captures may be less important than fornovices. In other words, computer experience is proba-bly a critical factor, and in this respect the audiences ofthe two studies varied considerably. The subjects in thestudy by van der Meij and Jenne were novices, whereasthe subjects in the experiment of Gellevij, van der Meij,de Jong, and Pieters were intermediate-to-experiencedcomputer users.

VERIFYING SCREEN STATESFor many people, the computer is still an awesomeapparatus that they approach with trepidation. Bradford(1988) has described the typical user’s initial stage oflearning to work with computers as “fear and loathing,”a stage that only gradually transforms into “what else canit do?” Research corroborates this impression. As peoplebecome more experienced, their attitude toward thecomputer changes, and their self-confidence increases(Gardner, Dukes, and Discenza 1993; Pope-Davis andTwing 1991).

Screen captures can play an important role in alle-viating the novice’s initial apprehension about using aprogram. After pressing a key, new users want to knowwhether they have done the right thing. Screen capturesmake it possible to verify screen states and, thus, confirmor contradict the user’s progress (Horton 1993; Price andKorman 1993). Notice that the assertion refers to a directrelationship between user cognition and user motiva-tion. When the user engages in the cognitive process ofverifying whether the displayed screen capture matchesthe screen state and finds that they correspond, usermotivation (for example, confidence) is positively af-fected.

The contribution of screen captures to verification isnot restricted to the novice or to usage in a learning-to-domode. Users can also profit from this type of support whenthey turn to a manual for reference, when they want to “getin, grab the relevant information, and get out and back totheir work as quickly as possible” (Redish 1998, p. 223).There are at least two situations in which screen capturescan help the user in such a random access approach to thedocumentation.

One situation occurs when the user turns to themanual for help after the appearance of a warning or anerror message. A recent inventory of 60 manuals showsthat an important obstacle to accessing such help is theabsence of any marking of problem-solving information(van der Meij 1996b). Eighty-six percent of the manualsdid not use any form of marking to highlight this infor-mation type. A picture—a screen capture—can alleviatethe problem by catching the user’s eye, signaling infor-mation about the specific problem—or a similar one—that might be useful.

Figure 10. When screen captures consume too much space,

they can obstruct mental model development.



Another situation when users benefit from screencaptures for verification is at the start of a procedure. Invarious situations, the user should heed certain condi-tions before beginning a procedure. For example, usersmay need to view the start screen, have loaded a certainfile, or have verified that the program is in the correctstate or mode. The user may attend to such conditionsthrough verbal means, but a combination of text andpicture more strongly attracts the user’s attention andsimplifies verification.

Screen captures, then, can help users with screen ver-ification by

1. Supporting progress checks2. Facilitating random access entry into the manualScreen captures presented at critical moments in a

procedure mark the user’s progress. Figure 11 exemplifiessuch use. The example describes the procedure for creat-ing a chart. The screen captures make it easy for users toverify whether they have done the right thing.

A screen capture can also be an easy point of entry fora user who browses the manual for help on a particularproblem. Figure 12 illustrates such a situation. The exampleexplains alert messages. The screen capture catches theuser’s eye and supports verification. A quick scan canreveal whether the screen capture is what the user is look-ing for. Thereafter, the cued text wrapped around thepicture invites further reading.

Design area(s)A critical design area for verification is coverage, as illus-trated in Figures 13 and 14. Figure 13 instructs the user tocenter a text segment. The screen captures show the “be-fore” and “after” states. The user can easily perceive theirdifference because the relevant information is focal in thepictures.

Figure 14 is from the same manual, but here the designsupports verification less well. There is a context problem,even though the bottom part of the window has beenremoved. The words “THE JAZZICIANS” and the high-lighted italicized text compete for attention. Users mayneed to take a second look to notice the change.

ResearchPractitioners have pointed out that one of the main advan-tages of the display of screen captures is their support forverification (Horton 1993; Price 1984). For example, Priceadvises the writer to include numerous displays in tutorialsto let users know that they have done the right thing andgotten the right display. Practitioners also assert that thesedisplays do not merely help users verify that they are stillon the right track, but that they simultaneously contributeto user motivation. They have a reassuring effect and theyhelp build confidence.

Research has studied only the contribution of screencaptures on motivation. These studies have not substanti-ated the claim that the presence of screen captures in-creases user confidence, or user motivation in general(Gellevij, van der Meij, de Jong, and Pieters 1998; van derMeij and Jenne in preparation). Users of manuals withscreen captures scored between 4.8% and 6.3% higher thanusers of manuals without screen captures, but this differ-

Figure 11. Screen captures presented at critical moments in a

procedure support verification by marking the user’s progress.



ence was not statistically significant. Likewise, no signifi-cant effects on motivation of design variations for screencaptures have been found. All types of visual manuals ledto comparable (that is, statistically non-significant) out-comes.

It is noteworthy that the novices in the study by van derMeij and Jenne gave high to very high ratings for motiva-tion, including confidence, during training. This speaksfavorably of the quality of the tested manuals, but it poses

a measurement problem known as the ceiling effect. Insuch a situation, real differences between subjects are hardto detect by statistical means.

IDENTIFYING AND LOCATING WINDOW ELEMENTS OR OBJECTSThe windows in many software programs are crammedwith objects that can be manipulated in various ways. Forexample, the start screen of Microsoft Word 6 for theMacintosh displays 63 objects (menu-options, icons, andsymbols) that can be clicked or moved. Their logical orga-nization and the use of icons and symbols reduces but doesnot eliminate the need for explanation.

For example, in one study we asked university stu-dents who were moderately experienced users of Mi-crosoft Word to write down the meaning of the icons andsymbols on Word’s ribbon and ruler (van der Meij 1995).The students gave a correct answer for only 53% of theicons and symbols. In addition, they frequently failed toinfer the meaning of an icon or symbol from similaritycues or proximity cues. For example, knowledge of themeaning of the left alignment symbol was no guaranteethat students could infer the meaning of the other align-ment symbols.

Screen captures can assist users in getting to knowand use a program in various ways. When a screencapture is coupled with text meant to convey conceptualinformation, the section becomes self-contained. That is,

Figure 12. A screen capture can be an easy point of entry for

random access use of a manual.

Figure 13. The right kind of coverage can emphasize the

difference between screen captures that display a before-after

situation.

Figure 14. Context can draw away some of the user’s attention

from the difference between screen captures that display a

before-after situation.



the user can read and study such sections without havingto work with a computer. Indeed, in some visual man-uals the coupling of text and pictures is so strongthroughout the manual that these manuals can be usedas a study guide, more or less.

An important contribution of screen captures to us-ers’ procedural skill development is reduction of taskcomplexity (Sweller and Chandler 1994; van der Meij1998). Screen captures can reduce cognitive load bymaking it easier for the user to identify and locate thepertinent object(s) for task execution. For the novice,this may simply mean that the screen capture focuses theuser’s attention on the relevant part of the window. Insome cases, screen captures enable users to carry outtasks that they would not be capable of completingwithout the visual support. For more experienced users,screen captures are especially helpful when there is arisk of confusion (for example, with two windows car-rying similar names) and for crowded windows. In allthese instances screen captures can speed up task exe-cution and reduce error.

Most software programs are chronically underuti-lized. For example, one study found that 170 users ofUNIX used only 20 of the available 400 commands forabout 70% of their time (Kraut, Hanson, and Farber1984). Another study found “no evidence that morepowerful commands were being used by experiencedusers” (Rosson 1984, p. 174). Both studies are from theearly 1980s, but recent research has yielded comparableresults (for example, Bhavnani and John 1997). Under-utilization is a complex and vexing problem for whichno easy solutions exist.

Screen captures can contribute to alleviating noveltyand efficiency aspects of underutilization. They canmitigate novelty by making users aware of and motivat-ing them to use untried task options. In a similar way,screen captures, more so than text, can motivate usersinto moving from sufficient into efficient usage of aprogram. That is, they can prompt users to use short cuts(for example, selecting an icon rather than a series ofmenu choices), and follow tips and other means forcompleting tasks that they already perform with thesoftware.

Screen captures can help reduce task complexity andalleviate the problem of underutilization by identifying andlocating window elements or objects for the user. Screencaptures can do this by

1. Identifying window elements or objects2. Locating window elements or objects

It can be desirable to support either the process of identi-fication or the process of location when

r One of these processes is irrelevant for the situationat hand.

r A simplification or concentration of attention is ap-propriate.

r The user can actively engage in one of these pro-cesses without being taxed.

Figure 15 illustrates the first two instances. The figureacquaints the user with the objects in the Tools menu ofHyperCard. The joint presentation of the objects supportsthe identification of each object. A text label describes themain function of each tool. In addition, it creates a com-mon language between writer and user by naming thesymbol or icon. There is no information about location.Such information would draw the user’s attention to otherprocesses than identification and thus increase cognitiveload.

Tasks well within the user’s reach also benefit fromscreen captures that support either the identification orthe location of an object. When a screen capture doesnot reveal all there is to know about an object, the useris pushed into a more active role (see Figure 4). Thedesign of a screen capture can be deliberately incom-plete to stimulate the user to process the information onthe screen more deeply (van der Meij 1996a, 1998).

Users who search for a particular tool without know-ing its appearance or location benefit from screen cap-tures that identify and locate these objects. Figure 16shows an example. The pictures are performance sup-port aids, and for this reason they appear on a tear-offcard in the back of the manual. The screen capturesdescribe and position each object. In addition, they givean overview in which users can easily make comparisonsbetween objects. Online help pendants such as BalloonHelp and ToolTips have the advantage of being moreeasily accessible, but they serve the latter functions lesswell.

Design area(s)An essential design area for identifying and locating objectson the screen is cueing. This is illustrated in Figure 17,which shows three list views. The original figure caption inthe manual mentions that the windows display list appears“when ’Calculate folder size’ is turned off (top), when thatsame option is turned on (middle), and when ’Show diskinfo in header’ is turned on (bottom).” However, this doesnot adequately remedy the problem of object identificationand location. Because of the absence of cueing, the designfails to clearly convey the differences between these screencaptures. The example resembles a “seek the differences”problem.

ResearchResearchers have not studied the processes of identifyingand locating objects directly, but there is indirect proof thatscreen captures can have a very substantial effect on these



processes. This proof comes from a study in which expe-rienced users were trained to use a new database program(van der Meij 1996a). In the study, one group of subjectstrained with a manual with full screen captures while an-other group used a manual without screen captures.

The screen captures sped up the subjects’ task com-pletion considerably. There was a significant time gain ofabout 35% for the processing of procedures fully supportedby screen captures. In addition, the screen captures helpedsubjects make 21% fewer mistakes and reduced correctiontime by 24%. The latter differences were not statisticallysignificant, however.

We believe that the effects can be attributed to thepictorial support given to identifying and locating objects.However, we cannot be certain because the study affordsno distinction between the contribution that screen cap-tures make to the process of identifying and locating, andto the process of verification.

CONCLUSIONPractitioners frequently ask us whether we advocate theuse of screen captures in software documentation. Ourresponse is an unqualified “yes.” Screen captures add vi-sual appeal to a document and they can, in our estimation,have a positive effect on fundamental aspects of user cog-nition and motivation. The taxonomy presented in thisarticle suggests various combinations of roles and designsthat could help the user.

We are not daunted by the mixed findings fromresearch because this is what one should expect fromresearch in an area that has not been studied extensively.Early studies such as the ones reported in this articlepave the way. They explore the territory and discoverimportant conditions that must be considered. Effectsthat appear to point “in the right direction” might thusbecome stronger (that is, statistically significant) whendeeper insights developed in time lead to better designsand studies. In short, we believe that there are goodreasons to be optimistic about the roles screen capturescan play in software documentation. TC

Figure 15. A screen capture can support object identification

by a joint presentation of objects, removed from their location in

the user interface.

Figure 16. Unlike some forms of online help, a screen capture can offer an overview to support object identification and location.



APPENDIXDesign areasCoverage refers to the desktop, window, window element,or object displayed in the screen capture. One extremeposition on this dimension is a screen capture that showsthe full screen. The other extreme position is a screencapture that presents a single object (icon, symbol, menuoption) that the user can manipulate with an input device.Examples of such object are window controls, such as the

maximize and minimize button, and menu items in textualor graphical menus. We define screen captures that fall inbetween these extremes as partial screen captures. Exam-ples of partial screen captures are a set of cascading win-dows, a single window, a title bar, a menu, and a dialoguebox.

Positioning designates the placement of text andscreen captures in relation to one another, reflectingtheir relationship or interdependence. Screen capturescan be presented in such a way that they are visiblyseparated from the text, or they may be integrated withinthe text. A separated display always requires a layoutwith two or more columns. A typical example is shownin Figure A1. An example of an integrated display isshown in Figure A2.

Size refers to the reduction rate of the desktop, win-dow, or object in the screen capture compared with itsactual screen size. The choice for a certain reduction ratedepends on considerations such as the consumption ofspace, legibility, company standards, and relationships be-tween screen captures. Practitioners recommend a constantreduction rate of between 50 and 75 percent of actual sizefor all screen captures in a manual (Horton 1993).

Cueing refers to the presence or absence of signalingtechniques that draw the users’ attention to relevantwindow elements or objects. Signaling techniques in-clude the use of (colored) hairlines, circles, callouts, andblurring. A descriptive caption or key word may beFigure 17. The absence of any cueing can turn a set of screen

captures into a “seek the differences” problem.

Figure A1. A separated display of screen captures and

corresponding text.

Figure A2. An integrated display of screen captures and

corresponding text.



presented along with the cue. Cueing should never con-fuse the user as to whether the cue should be part ofwhat is shown on the actual screen. Figure A3 displaysan error-prone example.

TerminologyThroughout this article we have used the word windowto refer to an area within the screen (or on the desktop)with which the user conducts a dialogue with a com-puter system. A window is the fundamental componentof a user interface through which a user can view andmanipulate an object. Generally, there are three types ofwindows:

r An application window, which is the focal point forthe user’s activities

r A document window, which usually appears withinthe application window

r A dialogue box, which is a window with radio but-tons, check boxes, text entry fields, and scrollablelists of choices for the user to choose from (Marcus,Smilonich, and Thompson 1995)

ACKNOWLEDGMENTSWe would like to thank Karel van der Waarde and one of theanonymous reviewers for perceptive and elaborate comments on anearlier version of this article. This work was supported by an STCresearch grant to Hans van der Meij.

REFERENCESBhavnani, S. K., and B. E. John. 1997. “From sufficient to efficient

usage: An analysis of strategic knowledge.” In Looking to thefuture: CHI’97 conference proceedings, ed. S. Pemberton. NewYork, NY: Association for Computing Machinery.http://www.acm.org/sigchi/chi97/proceedings/ paper/skb.htm

Bradford, A. 1988. “Learning to write with a word processor.” InWord processing for technical writers, ed. R. Krull. Amityville,NY: Baywood, pp. 160–169.

Brockmann, R. J. 1990. Writing better user documentation: Frompaper to hypertext (version 2.0). New York, NY: John Wiley &Sons.

Carroll, J. M. 1984. “Designing minimalist training materials.”Datamation 30, no.18:125–136.

Carroll, J. M., and J. R. Olson. 1988. “Mental models in human-computer interaction: Research issues about what the user ofsoftware knows.” In Handbook of human-computer interaction,ed. M. Helander. North-Holland, Netherlands: Elsevier, pp.45–65.

Fredette, B. W. 1994. “Use of visuals in schools (curriculum andinstruction).” In Visual literacy. A spectrum of visual learning, ed.D. M. Moore and F. M. Dwyer. Englewood Cliffs, NY:Educational Technology Publications, pp. 235–256.

Gardner, D. G., R. L. Dukes, and R. Discenza. 1993. “Computeruse, self-confidence, and attitudes: A causal analysis.”Computers in human behavior 9:427–440.

Gellevij, M., H. van der Meij, T. de Jong, and J. M. Pieters. 1998.“Do screen captures in manuals make a difference? Acomparison between textual and visual manuals.” IPCC 98Proceedings. IEEE Professional Communication Society, pp.439–451.

Horton, W. 1993. “Dump the dumb screen dumps.” Technicalcommunication 40:146–148.

Houghton-Alico, D. 1985. Creating computer software userguides. New York, NY: McGraw-Hill.

Kraut, R. E., S. J. Hanson, and J. M. Farber. 1984. “Commanduse and interface design. In Human factors in computingsystems. Proceedings of the 1983 CHI Conference on HumanFactors in Computing, ed. A. Janda. North-Holland,Netherlands: Elsevier, pp. 120–124.

Levie, W. H. 1987. “Research on pictures: A guide to theliterature.” In The psychology of illustration, Volume 1 Basic

Figure A3. Cueing should never lead to a screen capture that

the user might mistake for the real window.



research, ed. D. M. Willows and H. A. Houghton. New York,NY: Springer, pp. 1–50.

Mack, R. L., C. H. Lewis, and J. M. Carroll. 1990. “Learning touse word processors: Problems and prospects.” In Human-computer interaction: Selected readings, ed. J. Preece andL. Keller. Hemel Hempstead, UK: Prentice Hall, pp. 185–204.

Marcus, A., N. Smilonich, and L. Thompson. 1995. The cross-GUI handbook. For multiplatform user interface design.Reading, MA: Addison-Wesley.

Markel, M. 1994. Writing in the technical fields. A step by stepguide for engineers, scientists, and technicans. Piscataway, NJ:IEEE Press.

Peeck, J. 1993. “Increasing picture effects in learning fromillustrated text.” Learning and Instruction 3, no.3:227–238.

Pope-Davis, D. B., and J. S. Twing. 1991. “The effects of age,gender, and experience on measures of attitude regardingcomputers.” Computers in human behavior 7:333–339.

Price, J. 1984. How to write a computer manual: A handbook ofsoftware documentation. Menlo Park, CA: Benjamin/Cummings.

Price, J., and H. Korman. 1993. How to communicate technicalinformation. Redwood City, CA: Benjamin/Cummings.

Redish, J. 1998. “Minimalism in technical communication: Someissues to consider.” In Minimalism beyond the Nurnberg funnel,ed. J. M. Carroll. Cambridge, MA: MIT Press, pp. 219–245.

Rosson, M. B. 1984. “Patterns of expertise in text editing.” InHuman factors in computing systems. Proceedings of the 1983CHI Conference on Human Factors in Computing, ed. A.Janda. North-Holland, Netherlands: Elsevier, pp. 171–175.

Schriver, K. A. 1997. Dynamics in document design. New York,NY: John Wiley & Sons.

Simpson, H., and S. M. Casey. 1988. Developing effective userdocumentation. New York, NY: McGraw-Hill.

Sweller, J., and P. Chandler. 1994. “Why some material is difficultto learn.” Cognition and instruction 12, no. 3:185–233.

van der Meij, H. 1995. “Snapt u de pictogrammen? [Do youunderstand the icons?]” Tekst[blad] 1, no. 2:59–60.

van der Meij, H. 1996a. “A closer look at visual manuals.” Journalof technical writing & communication 26, no. 4:371–383.

van der Meij, H. 1996b. “Does the manual help? An examinationof the problem-solving help offered by manuals.” IEEEtransactions on professional communication 39, no. 3:146–156.

van der Meij, H. 1997. “The ISTE approach to usability testing.”IEEE transactions on professional communication 40, no. 3:209–223.

van der Meij, H. 1998. “Optimizing the joint handling of manualand screen.” In Minimalism beyond the Nurnberg funnel, ed.J. M. Carroll. Cambridge, MA: MIT Press, pp. 275–309.

van der Meij, H., and M. Jenne. In preparation. Do they get thepicture? A study on the effects of screen captures in softwaredocumentation. Internal Report from The Faculty of EducationalScience and Technology, Department of InstructionalTechnology. Enschede, Netherlands: University of Twente.

Winn, W. 1993. “Perception principles.” In Instructional messagedesign. Principles from the behavioral and cognitive sciences(2nd ed.), ed. M. Fleming and W. H. Levie. Englewood Cliffs,NJ: Educational Technology Publications, pp. 55–126.

FIGURE REFERENCESFigure 1. WordPerfect Corporation. 1993. WordPerfect

presentations version 2.0 reference. Orem, UT: WordPerfectCorporation, pp. 46–47.

Figure 2. Servive Consortium. 1998. SimQuest version 2.0tutorial. Den Bosch, Netherlands: CINOP, p. 1–1.

Figure 3. R. Person, L. Laby, and B. P. Merkel. 1995. Webpublishing with Word for Windows. Indianapolis, IN: QueCorporation, p. 239.

Figure 4. WordPerfect Corporation. 1993. WordPerfectpresentations version 2.0 reference. Orem, UT: WordPerfectCorporation, p. 46.

Figure 5. S. Z. Aker. 1991. The Macintosh companion: Thebasics and beyond. Reading, MA: Addison-Wesley PublishingCompany Inc., p. 250.

Figure 6. Microsoft Corporation. 1992. Microsoft PowerPointhandbook. N.p., Ireland: Microsoft Corporation, p. 33.

Figure 7. J. Essex. 1996. Multimedia sound and music studio.New York, NY: Random House, p. 142.

Figure 8. A. Stuur. 1996. Windows 95 voor Kinderen. Een stap-voor-stap methode voor iedereen vanaf 9 jaar [Windows forchildren. A step-by-step method for anyone from 9 years old].



Utrecht, Netherlands: Bruna Informatica, p. 254 (slightlymodified from the original by the authors).

Figure 9. D. C. Gardner, and G. J. Beatty. 1993. Windows 3.1:The visual learning guide. Rocklin, CA: Prima Publishers, pp.245–247 (slightly modified from the original by the authors).

Figure 10. B. LeVitus, and J. Evans. 1996. Cheap and easyInternet access. London, UK: AP Professional, pp. 99–100.

Figure 11. M. J. Norusis. 1993. SPSS for Windows base systemuser’s guide Release 6.0. Chicago, IL: SPSS Inc., pp. 441–443.

Figure 12. D. Goodman. 1992. Danny Goodman’s Macintoshhandbook. New York, NY: Bantam Books, p. 104.

Figure 13. G. B. Shelly, T. J. Cashman, and M. E. Vermaat.1996. Microsoft Office 4.3 running under Windows 95:Introductory concepts and techniques. Danvers, MA: Boyd &Fraser Publishing Company, p. MSW25.

Figure 14. G. B. Shelly, T. J. Cashman, and M. E.Vermaat. 1996.MicroSoft Office 4.3 running under Windows 95: Introductoryconcepts and techniques. Danvers, MA: Boyd & FraserPublishing Company, p. MSW28.

Figure 15. Apple Computer Inc. 1993. Hypercard referencemanual. Cupertino, CA: Apple Computer Inc., pp. 4–10.

Figure 16. J. Heid. 1992. Macworld guide to Microsoft Word 5.San Mateo, CA: IDG Books Worldwide Inc.

Figure 17. D. McClelland. 1992. Macintosh System 7: Everythingyou need to know. San Francisco, CA: Sybex, p. 261.

Figure A1. Sun Microsystems. 1991. Desktop SPARC: Sunsystem user’s guide. Mountain View, CA: Sun MicrosystemsInc., p. 86.

Figure A2. Adobe Systems. 1994. Adobe Photoshop 3.0 userguide. Edinburgh, UK: Adobe Systems Europe Limited, p. 107.



Screen Captures in Software Documentation.pdf

Documents

Transcript of Screen Captures in Software Documentation.pdf