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.
--- dmbrown -at- brown-inc -dot- com wrote:
>
> "Sanderson, Leanne" <lsanderson -at- iccohio -dot- com wrote:
> >
<snip>
>> be moving from this stand-alone desktop application
>> to a web application in the next 18 months.
>> One of the reason's they want to document the app
>> now, is to get down on paper everything the
>> application does, to aid them in converting the
>> application to a web app.
<snip>
>
> A previous repondent suggested that you completely
> ignore the request to
> document the desktop application--!!?!--but I assume
> you can't do that.
Based on the time for development and the reason being
to obtain knowledge of how the FAT APP works, I would
not recommend, if possible, that a book be used to
define the spec for any application.
> (Most of us wouldn't work for long, if we didn't
> do what our clients and employers asked of us.)
Most. Not all.
>
> Lectures about how desktop apps are different from
> web-based apps are
> unhelpful when the person who hands you your check
> is waiting for an answer.
An answer. But is is the correct one?
> Besides, it's quite possible to create a
> web-based app that
> works--from the user's point of view--exactly like a
> desktop app,
> especially when the desktop app is already there to
> serve as a model.
I have found that it is possible, but hardly ever the
reality. When development start to design the WEB APP,
all sorts of things change.
>
> Identical behavior may even be a requirement of the
> web-based app.
Behavior under a browser is not the same as a FAT APP.
Sometime more clicks are required, sometimes less.
Functionality can however be duplicated. Then again,
any company that develops an application for 18 months
and does not add functionality is very rare.
> Even if it's not, the company's users need
> documentation for the
> existing app, during the 18-month development of its
> replacement.
they live until now without it. Why all the rush. I
think it's more the lack of an SRS that is the
problem.
>
> Assuming that you do need to meet this request, I'd
> recommend using an
> HTML-based help format. If the existing desktop app
> runs only on
> Windows, you can easily use the HTML files to create
> HTML Help.
You may also try XML.
<snip>
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
