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.
<<Does anyone have any experience with writing for web applications and how
they differ from software applications?>>
Hi-
Yep, I've been doing that for about two years now, as an editor and
writer... The other post I saw apparently has had bad experiences with web
app development. I haven't had the same experience--the development groups
I've worked with have been committed (more or less) to producing a
spec'd-out, carefully developed, and well-tested application...with only
one significant exception, apps had some last-minute changes, but no more
than on a regular desktop app.
So, web-app specific tips/observations for documentation?
-- As the other poster mentioned, you'll probably be producing online
help (possibly instead of print, but most likely at least as the primary
doc) -- I recommend (RoboHelp's) WebHelp because it's already in .htm
format and is easily integrated & made context-sensitive. If the "web app"
you're documenting is a Java/Swing app, you might also consider JavaHelp,
but I think I've heard rumors that JavaHelp has limitations that WebHelp
does not. FWIW, I've successfully integrated WebHelp with Swing apps, so
it can be done.
-- Make sure the developers decide *early* which platforms & browsers
will be supported, and make sure you use the app on as many browsers (if
not platforms, too, esp if they're as different as W2K and Mac) as
possible. Things will look a little different, but that's very easily
taken care of with one or more notes saying so and explaining any important
differences. I suspect that users are familiar with the display
differences (esp Mac users) and won't worry about this one too much.
-- Encourage the developers to develop the UI first, then plug the
functionality behind it. This is (objectively, though if they don't wanna,
they'll tell you otherwise) easy for them to do, and it also goes over well
with managers and demo-givers, who are pleased to see at least *something*
they can play with. You can also imagine how much this will help you get
started. Failing this, get them to at least get a portion of the app
completely working before moving onto the next thing. I speak from recent
experience on this--although development on one of the products I have to
document is coming along well, there is nothing at all to show for it yet,
because they've left the UI to last. Argh.
-- Get familiar/knowledgeable with the web technologies. They're
(really and truly) pretty easy to learn at a "familiarity" level, and the
developers will appreciate your attempt and the added value you provide in
testing and feedback. I'm also always a lot more comfortable suggesting UI
changes when I know how easy they are to make--and if I can do them myself,
so much the better!
-- Provide a Help stub (and regular updates) to your developers early
in the process, so that Help is integrated seamlessly and
context-sensitive-ly ... I've found no resistance to this whatsoever...I
guess I've been lucky, but it's been my experience so far that developers
are thrilled to have "real, live documentation" for their
applications...they (rightly, I think) believe that the doc makes the app
more professional, usable, and complete. So don't be shy about it!
That's all I can think of off the top of my head....Good luck!
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.