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.
Some things to keep in mind when writing help for Web applications:
- You often have the opportunity to hook your own HTML-based help system
into the Web app. While this requires alot more work than just writing in
Frame and outputting a PDF, it lets you be more creative
- You should include links to online resources whereever possible since you
can assume that your users (usually) have internet access -- links to RFCs,
API docs, and helpful, topical web sites
- You can get access to how users actually use the application by analyzing
clickstream data (if it is available to you). This is like having usability
test studies at your fingertips. Check out log analyzers like WebTrends.
- There are still differences between the browsers (Netscape and IE), so you
should be mindful of that. And there are still differences between the
operating systems that the same browsers might run on, so be mindful of that
as well.
- You have a better opportunity to deliver up to date help files, FAQs and
whatnot through a web-app. Try getting the developers to build a help page
that will hook into a synchronization scheme so that help content can be
updated on the fly by the users.
HTH, matt
>>-----Original Message-----
>>From: bryan -dot- westbrook -at- amd -dot- com [mailto:bryan -dot- westbrook -at- amd -dot- com]
>>Sent: Thursday, November 29, 2001 12:06 PM
>>To: TECHWR-L
>>Subject: RE: Web Applications
>>
>>
>>One nice thing about it is that you can safely assume that
>>they know how to use the browser (and even if they don't
>>it's out of the scope of your documentation to teach them
>>that). I usually start with giving them the URL for the
>>application and trusting them to find their own way to it
>>(though I'm writing mainly on an intranet and also include
>>a link to open the application in a new browser window).
>>
>>As for the appearance issues, I use the standard default
>>color scheme because if they have changed their system
>>colors, that's should in theory mean that they at least
>>understand that they can be changed and will understand the
>>difference between the graphics and their screen.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
---
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.
