TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: When to Use Screenshots From:carthur <carthur000 -at- sympatico -dot- ca> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 17 Feb 2005 8:55:10 -0500
Hi,
The documentation we write is for an internal audience so I've been able to do a document review at the end of projects to obtain feedback from our users. The users are often reading our docs for advance information - before they have a working copy of the software.
One of my questions for the users was about the use of screenshots, because we have a relatively new Web app with lots of associated procedures. The less sophisticated users, and those new to the company, really liked lots of screencaps. More experienced users didn't see the need for screenshots for routine procedures, but wanted to see a screenshot of new screens. All the users are often working in the middle of the night.
Our solution has been to develop a core manual that explains the basic procedures and includes screenshots of most steps in the basic procedures. It also explains the main screens. Experienced users can skip this part. The procedures for specific tasks use no screenshots, but document it using something similar to "Select web app>screen 1>button name>screen 2" - which is very lean and requires familiarity with the interface.
For new releases, I include a screenshot of both the old and new screen, with callouts showing the changes. These are supported by text descriptions where necessary.
Somewhat related to this is the use of flowcharts. Previously, there were none in the documentation. I always had to draw out new data flows because I am a more visual learner - and if I drew it for myself I put them into the docs. All of my users thought the flowcharts were very helpful - most of my users seem to find visual diagrams/photos/screenshots very useful.
Lastly, the web app has been hugely improved for the next release by adding notes about values and using dropdowns instead of expecting the user to type in the values correctly. As a writer, I edit xml files that are pulled into the app to display notes where needed. The xml can then be used to create hardcopy docs that support, and are consistent with, the software. This is the best solution so far.
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more! Download your free trial today at www.componentone.com/techwrlfeb.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
