Do Screen Captures make sense?

[RamonS]

There is also tech writer arrogance...like those who rather use Frame and WebWorks than Flare.

[LTinker68]

There is also tech writer arrogance...like those who rather use Frame and WebWorks than Flare.

Or, shudder, RoboHelp.

[KevinDAmery]

There is also tech writer arrogance...like those who rather use Frame and WebWorks than Flare.

... or AuthorIT....

(Boy, we're opening ourselves up to some "look who's talking" criticisms here, ain't we? )

[beagley]

The best documentation is also AVAILABLE. Finished. Public. So, obviously, if doing a good job on images takes too much time, then the images are NOT improving the documentation. Because they might keep the documentation from reaching the public!

This is one of those things that varies depending on your situation. For example, if your help is stored on your servers and provided to the customer over the internet, then you have the flexibility to update the help whenever required: this would let you release the product with text-only help as soon as the product is available, then add the screen shots in over time. OTOH, if the help is installed on the user's machine you pretty much have to have the help ready to go at the same time as the code is released to manufacturing...

IMHO, if I am writing for software or any product where the documentation is "built in" and can't be remotely updated, then I am working on a broken product and/or a broken model of information dissemination. It's 2009!

...And that's another major consideration. We can all theorize about what makes the best help until we're blue in the face, but at the end of the day the only thing that really matters is "what do the customers find helpful?"

...and that point is why Kevin is my favorite genius. *submitting telepathic internet high-five*

-d

p.s. to i-tietza:
I am totally high on life!
...and words.
...and Flare, I guess.
(Mmm. And sweetened black iced tea, right now.)

[KevinDAmery]

IMHO, if I am writing for software or any product where the documentation is "built in" and can't be remotely updated, then I am working on a broken product and/or a broken model of information dissemination. It's 2009!

Our product doesn't do automatic updates, largely because it's deployed on an enterprise level and frequently updates to the application also require a change to the database schema (which is certainly not something you want to do when someone is actively doing something in the solution). As a result, you have to bring the whole solution down to ensure data integrity, which is best handled on a scheduled basis rather than automatically or whenever a user sees an "updates available" notice. Such being the case, it's more reliable to package the documentation updates along with the application updates.

But I'm sure this model puts me in the minority here

[Andrew]

IMHO, if I am writing for software or any product where the documentation is "built in" and can't be remotely updated, then I am working on a broken product and/or a broken model of information dissemination. It's 2009!

Our product doesn't do automatic updates, largely because it's deployed on an enterprise level and frequently updates to the application also require a change to the database schema (which is certainly not something you want to do when someone is actively doing something in the solution). As a result, you have to bring the whole solution down to ensure data integrity, which is best handled on a scheduled basis rather than automatically or whenever a user sees an "updates available" notice. Such being the case, it's more reliable to package the documentation updates along with the application updates.

But I'm sure this model puts me in the minority here

That's rather similar to my situation (ERP software) -- not only do users not want to update right away, many of them do not want to update at all, except for major versions (sometimes not even then), unless they are experiencing a specific bug they know is fixed in a later version. Updating major enterprise software is anything but free to customers (even though the updates themselves are free).

[castle]

Again, this comment is not about what is most useful to users but instead about practicality.

What about localization? Unless the decision is made to have English-only screenshots (which have limited usefulness when they are looking at translated software and translated text), each of those images has to be retaken in every language the software and documentation are translated into--that means extra time and potentially extra money ('cause I don't think I can navigate a Chinese version of software so someone else has got to do it) in getting the product (including docs) to the user.

As for screenshots in general, I try to keep them to a minimum, keeping in mind the question of 'is this necessary for the user to understand the concept, procedure, etc.'. Main interface overviews. UIs that are difficult to understand (and probably should have been better designed). Giving labels to dialogs or screens with dynamic labels (as a techwriter, I hate those--how can I tell the user to edit something in the Edit Template section if the Edit Template section turns to Edit XYZ).

[SteveS]

Hi Castle,

Welcome to the forums

[SteveS]

This is where screen portraits come into their own.

Microsoft use them to good advantage. AndyR has a series of blogs on them here.

I tried them with limited success, but if you are worried about translation they might work for you.

HTH

[i-tietz]

This is where screen portraits come into their own.

Microsoft use them to good advantage. AndyR has a series of blogs on them here.

Advantage: You can start producing them before the GUIs are available.
Disadvantage: They are more complicated to produce - it would mean a lot of time (and money, if you don't do it yourself). Only worth the effort, if you have quite a few languages - applies to Microsoft, so it works for them.