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: FrameMaker Menu capture (why do it) From:"Less is more." <yvonne -at- VENUS -dot- SMARTSTAR -dot- COM> Date:Thu, 16 Jun 1994 09:06:13 -0700
Rich Julius writes:
>For example, while dialog boxes may be stable from release to release
>(not all, but usually most), I've often found that menus change.
You lucky guy, it's the other way around for us. Actually, our menus change
quite a bit, too.
I think menu captures are useful as graphic devices for readers who are
scanning the text for information. They can look in the margin for the
item they are trying to use. I don't think of the menu graphic as adding
information, just getting people to the information.
Since menus change and I document an application that runs on Motif,
MS Windows (and Macintosh "any month now"), I don't actually do screen
captures of menus now. I draw them in a drawing package. Menus are VERY
easy to draw and modify -- and they come out looking much cleaner than a
bitmapped screen capture.
Of course, there are still Combo Boxes and other objects that need the
delay techniques already mentioned in order to be screen captured.
P.S. Hope you get your posting problems worked out, Rich.
Yvonne DeGraw
yvonne -at- smartstar -dot- com
SmartStar Corp
Santa Barbara, CA
