RE: seeking online Help technology with specific characteristics

[jgarison -at- ide -dot- com]

Not sure by what you mean when you say "ability to display content based on
one or more user characteristics (different wording in topics, different
wording in TOC, different available topics, etc.) This is probably *the*
most important thing right now".

But ... my company also does a web-based application, and we have just gone
over to using Dreamweaver. Best decision I've made in a long time. It's a
real web-authoring tool - just about anything you can do on the web, you can
do in, with or to Dreamweaver.

My 2¢

John

John Garison
Documentation Manager
IDe
150 Baker Avenue Extension
Concord, MA 01742

Voice: 978-402-2907
Fax:    978-318-9376
http://www.ide.com


-----Original Message-----
From: Chuck Martin [mailto:twriter -at- sonic -dot- net]
Sent: Monday, April 16, 2001 6:34 PM
To: TECHWR-L
Subject: seeking online Help technology with specific characteristics


Hi all,

At my current company, we've developed a web-based application. Online Help
was seen as being essential. As a result (before I came on board), a Help
system was designed and programmed. A tool for doing some maintenance was
also created. However, this tool isn't complete, and it is buggy. It's also
not easy to use.

What I'm trying to do is to research alternatives. I've been doing some
research on my own, but I know that there is so much expertise on this list.
I shoudl note that I am the only content engineer here, so any solutions
would be one that I have to (a) convince management to adopt, (a) work with
programmers to implement and integrate, and (c) work with on a long--term,
day-to-day basis.

That said, the Help technology I seek must have the following
characteristics:

- The ability to display content based on one or more user characteristics
(different wording in topics, different wording in TOC, different availble
topics, etc.) This is probably *the* most important thing right now, one
that existing released technologies can't do (no, HTML Help's Information
Types doens't cut the mustard here; this must all be done with no user
intervention or decisions).
- Content created in well-formed XHTML
- Ability to run and display within an XML framework
- No extraneous tags in topic files (so anything that runs on top of Word is
out)
- No in-file scripting (instead, reference to external files)
- Context-sensitivity from a browser-based appiction (a web page)
- Provide index/keyword searches
- Present content & navigation in a separate window without frames
- Provide future capability for integrated Help (within the browser page)
- WYSIWYG authoring
- Navigation & other features by JavaScript or DHTML, not Java
- Cross-browser functionality (IE5+, NN4+)
- No in-file or in-line styles (all done by an external style sheet)

I think this is an extremely tall order. I've not found this in anything
I've yet seen. As I mentioned, HTML Help's Information Types don't fit the
bill of automatically customized content presentation based on one or more
user characteristics (for example, if the user is sighed in as one of
several types of adminstrators, and end user, or a non-subscribing visitor.
eHelp's WebHelp doens't seem to have this most important characteristic at
all. From what I've seen of the early preview of Microsoft Help 2.0, its
technology looks promising, but I don't think it'll work (yet) for a
browser-based application, and it won't work at all with Netscape (major
bummer here). It's also a long way away.

Being able to work in a WYSIWYG environment is desirable as well, so I can
focus on content development and information design, rather than futzing
with tagging (not that I cna't to that; I just need to be as efficiant as
possible here). Many WYSIWYG environments add, to put it bluntly, a bunch of
crap to their output. This simply can't happen for hat we need. Using a
separate tool (such as HTML Tidy) to do clean up is a bad kludge and is not
desired.

I know that in most HTML-based Help technologies, the presentation is done
in a framed windows. That we cannot use frames is a sticky and challenging
constraint.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27. http://www.pdfconference.com.

---
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.