Screenshots: Analysis

[Jennifer Maitland <jlm -at- kwi -dot- com>]

Hi Everyone,

Well, I think Beth Kane said it best:

"As with everything, the answer to whether to crop is 'it depends.'"

I've included most of the posts I received about cropping vs. resizing, and
screenshots in general, and first off, I have to say thanks to everyone
who's sent them to me. Everyone seems to have their own guidelines for
screenshots (very sensible ones in each case) and I can see now that perhaps
I was getting a little too heavy on the cropping when I should have been
just putting a little more effort into making nice looking resized
screenshots. 

A few people sited some research and various articles, which was excellent.
Most of the articles said that resizing was the preferred method, unless of
course there was some specific information that could do with a little
highlighting etc. 

And of course there were people who thought that cropping was a good
practice because it adds emphasis. 

Anyway, what I learned was that I probably wasn't putting the time into
processing my images (which means I'm a lazy ass considering I used to be
real graphic guru) and that I should use my skills to make nice looking,
uncropped, re-sized screenshots when possible. I also learned that cropping
isn't always the wrong route and can be extremely effective for emphasis,
provided it's done well. 

Thanks again to everyone who has contributed - once again this list proves
to be an outstanding resource!

Bon weekend!

Jennifer




****************************************************************************
******

My "guideline" is pretty simple:

For "context", where the section of the screen needs to be shown in relation
to
the entire interface, I resize. This might be places where I'm pointing out
a part
of the interface that shows results, or where one thing is in relation to
another.

Everywhere else I crop to show only the relevant fields/controls. If the
resulting
cropped image is still too big to fit my layout, I resize _just_ enough to
make it 
fit.

Occasionally, if needed, I make a "callout" where there's a smallish "full
screen" in the background (set 75% transparent) and  the detail section is
"zoomed" in - so I can show both the details and the context.

****************************************************************************
******

I have no set rule, but if the screen shot is assure the user that they're
in the right place, try to use the whole screen. See if you can reduce the
number of screen shots by providing the name of the screen that opens during
a procedure without the graphic. If the user is do something in the new
window, use a cropped view or cropped views of the screen to clarify your
instructions. I don't think it would help the flow of the document to go
from portrait to landscape too often just for the sake of putting the screen
shots in. Once in a while, if the screen shot is crucial, it is okay.
****************************************************************************
*******************************************************
I would not crop a screen shot, in most cases. If it goes outside my text
margins, that's fine. One company where I worked for 5 years produced lots
of STC award-winning books that had screen shots bumping out of the left
side of the text margins all over the place. (Our templates had plenty of
white space on the left.)

The size of our screen shots was dictated by the readability of the text
inside them. We tried to keep all of them showing the text around a certain
size -- quite small, but still readable. The size of the windows/dialog
boxes in our GUIs varied a lot. 

If it's a truly gigantic screen shot that would take up a whole page or
something to still be readable, then I guess I would have to crop it, and
discuss each pertinent section of the screen one at a time. It sounds like
that might be the case in your GUI.

Cropping runs the risk of the screen shot not looking totally recognizable
to the user. So when you have to crop, it's best to prominently state that
you're showing just one section of the xyz window (upper left, lower right,
upper half, center, first column, etc.). I've also seen a lot of people
place some sort of ragged-edge graphic on the edges that are cropped.

As with everything, the answer to whether to crop is "it depends."

****************************************************************************
******
First, I think you're right to identify that the purpose of the screenshots,
in this case, is to ground the user, rather than portray an accurate picture
of the application.  I think this means you can be slightly more flexible
about how you choose to do it. 

Second, I think you _can_ have shrunken _nice looking_ screenshots.  Realize
that lots of different programs offer the ability to resize an image: some
will do it better than others.  Also realize that certain graphic formats
resize better than others.  You should be able to resize screenshots and
have them still look just as nice - at the very least, for print.  It may be
trickier for screenshots viewed on-screen, but should be possible there as
well.  Play with various image processing programs and see.

I know this doesn't completely answer the question, but I've always been
able to get my shrunk screenshots to look just as clear as the full-size
versions, so I wanted to throw it out there.

****************************************************************************
******
Here're my three simplistic guidelines:
If the look of the screen is reassuring (I'm in the right ballpark) 
I'd use a SMW (shrunken messy window).
If the data entered is quite specific to the application (use 'NA' 
here, not 'n/a' nor 'N/A') I'd use cropped views for emphasis.
If the placement of the documented field is vague or confusing, and 
the information entry is rather unforgiving, I'd use a SMW for 
establishing location with a callout to a 'magnified view' for 
optimal readability. I'd overlap the magnified view so that the 
origin could be discerned. If I had time, talent, software, etc. and 
a penchant for melodrama, I'd use 'swoosh' marks to indicate the area 
being enlarged.

****************************************************************************
******
I might handle this a couple of ways, depending on the nature of the
application.

1. CROP - If the app has a big footprint (like yours apparently does) but I
am focussing on one part of the screen, I would neatly crop it to show only
the part that needs emphasis. Otherwise all my screenshots will look alike
and require the user to look more closely.

2. Resize - If the user will likely have the application open and could
recognize important elements "from afar," I might resize and try to get by
with some detailed callouts.

3. Combo approach - It's a lot more labor intensive, but you could have the
resized complete screenshot in the background with a cropped closeup, offset
and maybe with a drop shadow, of the area of emphasis, with a little border.

4. The tear away - If the screenshot is long but not high, consider chopping
out the middle and through in a section break, like a jagged gap, to
indicate that this is not the whole thing. I've used this for long menus
when I just want to point to one command on it.

****************************************************************************
******
Each option depends on each unique situation. If I am faced with an awful,
blurry, resized screenshot, sometimes (space permitting) I will resize the
screenshot smaller so that the user can see what the screen looks like, and
then I will "call out" a particular area of the screen. When I do this, I
crop
the full size to retain detail. Then, you can visually identify what the
section of the screenshot it is, and supply detail at the same time.This, of
course, only works in some instances, but if you have the space, it's worth
a
try. I've found that it can make dry boring images seem (design-wise only) a
little more interesting.
****************************************************************************
******
Another point to make, building on the postings that have already come 
forth, is the *purpose* of the screenshot in your text, as well as the 
nature of the screens themselves.

For example, with a complex UI that changes sections of the screen display 
based on input criteria (including the appearance/disappearance of several 
screen controls), it can be helpful to have a (possibly shrunken) 
"establishing shot" that shows the whole screen, labeling dynamic sections 
with callouts, and then follow it with cropped shots of the specific 
sections that change, at those points in the description that deal with 
specific permutations.  Legibility is not compromised in the "close-ups", 
but their position in the grand scheme of things is not lost, either.

For oversized screenshots and their captions, I'd personally have to agree 
that some form of left-hand alignment would probably be better than 
centered, but consistency will make the biggest difference there.
****************************************************************************
******
Mark Gellevij works on a PhD dissertation on the use of screen captures in
software documentation. In a recent presentation, he mentioned that (for the
purpose that you describe) complete captures work better than cropped ones.
I can't remember the exact context of this statement, but if you want more
information, you can contact him at gellevij -at- edte -dot- utwente -dot- nl

He also published an article in Technical Communication, which looks at the
roles and design areas of screen captures:  Van der Meij, H. & Gellevij,
M.R.M. (1998). Screen Captures in Software Documentation. Technical
Communication. 45, 529-543. If you're an STC member, you can access this
article through the STC archives on their website.

****************************************************************************
******
A long time ago I took a Visual Literacy course from William Horton. As I
recall (I don't have the information handy), one of the info tidbits was
that screen shots in a manual serve only to orient the user, to reassure
them that they are in the right spot in the procedure. They are *not* there
to show actual detail of what should be on the screen.

He referenced research that differentiated between screen shot sizing,
between 100%, 75%, 50%, and 25%. The amazing thing was that, even at 25%,
users were able to get the information they needed. At 25%, pretty much no
detail is discernable. The conclusion was that users don't actually try and
"read" anything in a screen shot.

When I'm doing manuals, I typically resize screen shots to 50%. That usually
makes it about the right size for the page.

There's nothing wrong, either, with cropping screen shots to remove
irrelevant or distracting information. For example, if you want to identify
the icons on a specific toolbar, a screen shot of the whole window really
isn't necessary. But if context is important, then use the whole window
(which can be resized or configured before the screen shot is taken, if
necessary.
****************************************************************************
******


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.