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: Future use From:nhickman <nhickman -at- GVI -dot- NET> Date:Fri, 6 Mar 1998 18:15:24 -0600
An essential question is, how will users know that they have the version
that has the enabled feature? Do they just ping the feature, wondering
if they have it?
If there is a version number that is available on a splash screen or
what not, you could say, "upcoming version" (in which case, you're left
with this note in your doc, which may discourage users from accessing an
enabled feature) or "version 2.2" or "post-release" (vague, but not as
potentially discouraging as "upcoming version").
You could issue update information separately until you can prepare the
next release of your doc. There's no one solution, but I hope that these
help.
-- Nancy Hickman
Kimberly Green wrote:
>
> Marci,
>
> We use "Not available in Version 1.1" (the version number for the
> release we are documenting). This is not a positive selling phrase, it
> just states the fact and does not promise anything.
>
> I am in a very similar situation. I am trying to document a constantly
> changing software product with changing priorities and changing
> schedules. Does anyone have any tips for working effectively in this
> situation?
>
> Thanks,
> Kimberly
>
> ----------
> From: Marci Abels[SMTP:mabels -at- CSIKS -dot- COM]
> Sent: Tuesday, February 24, 1998 8:34 AM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Future use
>
> Hello,
>
> I know this has been discussed before, and I've looked in the
> archives
> and am still looking for a better way. We are documenting a
> developing
> software package. Several features are not yet operational,
> though they
> are planned for future implementation, some features are on the
> menu but
> not operational because they are now obsolete, as far as the
> programmers
> are concerned, and some features are still up in the air
> regarding
> future implementation.
>
> In the past, I used "For future release" which served us well.
> This
> iteration, however, we have several features that will go away,
> some of
> them were operational in the past but are no longer so. Some
> were
> planned for future implementation, but have been dropped from
> the
> planning schedule for various reasons. And sill others will
> eventually
> be implemented, as soon as the programmers have time. I tried
> "Implementation currently under review" but we have some people
> who
> dislike that. So, I am looking for a statement to use that holds
> no
> promises for the future, but says "Don't bother with this, it
> doesn't
> work now." Of course, we wnat something more positive than the
> simple
> truth, that the feature is not operational and we don't really
> know if
> it ever will be. :-)
>
> I'm on digest, so if you have any ideas for me, please send them
> to me
> and I will summarize for the list.
> --
> Marci Abels
>http://www.geocities.com/Heartland/Acres/2592/
> CSI, Inc,
>http://www.csi.com
>
> Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
> Search archives at:
>http://listserv.okstate.edu/archives/techwr-l.html,
>