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.
Ashok Mathur asked for additional advice: <<In fact in past I have
used both VBA and Power Point to make prototypes. I have also used
screen shots from other existing software, edited them in Coral Draw,
where the facility to shrink/expand an image (without distortion/
pixalation) exists and then pasted them in Power Point Mock ups.>>
You can even do this in Word, as I noted. Use manual page breaks (or
better still, build them into your level 1 heading style), define a
custom page size equal to the size of the dialog box, and paste in
appropriate graphics. (I find Word's graphics tools appalling, but if
you use tables to position and hold graphics, the frequency of
problems drops enormously.) I played with this briefly, then gave up
on it when I found that Dreamweaver was much easier and more flexible
and powerful... and when we started producing more Web-type stuff.
<<I wonder if you can write a brief note why you gave up working with
VBA.>>
Largely because I found Dreamweaver to be easier to work with. Unless
you specifically hunt down good graphics, the Interfaces produced in
Dreamweaver look a bit cartoony or abstract, but it works just fine
even if you're a graphics incompetent like me*. PowerPoint was also a
better alternative because our graphics guy found it easier to import
the resulting prototype into Flash. I gave up on VBA for another
reason: our developers quickly moved to the Pascal programming
language (Delphi I believe), so the VBA code wasn't all that useful
to them.
* On a good day, I can just about draw a straight line using a ruler--
let's not even mention trying this with software. (Yes, I know the
Shift-key trick. It saves my sanity. <g>) Graphics skills? Me? Not so
much. <g>
<<I also found that while Software developers were very happy to see
such prototypes, they would themselves never make any of them. One
reason could be that these could not be extended further and
represented wasted effort.>>
In my experience, developers tend to look on interface design as an
annoyance (they prefer to play with the actual code) or as something
intimidating (they receive minimal or no training in interface
design). Thus, they're usually happy for our help--assuming, of
course, we have developed credibility with them and a mutually
respectful relationship. (It can take some time to gain that cred.)
A bright manager will also note that by working with you on the
interface, their developers finalize the interface much sooner (less
playing around in the hope that they'll somehow, randomly, get it
right) and can concentrate on the code. A good interface prototype
also focuses developers on the relationships between the working
parts, and that can also make their coding more efficient. This also
has the benefit of freezing the interface much sooner than might
otherwise be the case, which means you can finish the documentation
much sooner.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
