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:What to demo? From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Tue, 1 Jun 1999 08:58:02 -0400
Damien Braniff uses <<... Demoshield to produce the CD
front end and the demos of our software... The question I
have is... WHAT to demo. One suggestion has been to
provide a walk through of all the most common features but
I'm not convinced... I feel what we should be doing first is
demos of the not-so-common features that are used once in a
while...>>
My personal preference is to have a nice, neat, _brief_
contextual overview of what I can do with the software. No
bells and whistles: just a simple "this is a frame, this is how
you use it, and this is why it's called FrameMaker" type of
thing. But that's just me; as always, a quick call to your tech.
support people (or a direct call to a few users of the product)
would be a far better way to find out what _they_ want you to
demo. In the absence of that information:
A more broadly useful demo would be one that shows how to
do something that is very visual (and thus, very difficult to
describe adequately with words and static images). Whether
that something represents a common or rare activity is beside
the point: the point is that you should be using motion
(animation) to describe something that involves movement.
You can certainly do that with a sequence of static images in
a book, but then you're requiring the user to glance back and
forth between the screen and the book, which is distracting;
moreover, all that context switching (print to screen and back
again) interferes with comprehension.
Trivial example: Using the mouse to select part of a bitmap
graphic. You can certainly do this as a two-stage cartoon
(image 1: click here and hold down the button, image 2: drag
the cursor to this position and here's what you'll see on the
screen), but that's an awful lot more abstract (removed from
what is actually happening) than actually showing the
selection marquee growing as the mouse moves: with the
abstraction, readers/viewers must fill in the missing
intermediate steps, whereas with the animation, they see those
steps. Filling in the missing frames in sequential images is
tough enough that many people simply don't understand what
has happened in between. You can analyze your own
software to see what the comparable examples would be for
your context, then demo those.