Re: seeking online Help technology with specific characteristics

["Chuck Martin" <twriter -at- sonic -dot- net>]

Well, Information Types, in a way. But Information Types, as designed in
HTML Help, aren't associated with topics themselves, but with the TOC
entries for those topics.

For those who have seen the Microsoft Help 2.0 pre-release information, the
idea for what we need is there. All sorts of information about the
topic--the metadata--is withing the topic itself (which means that the TOC
and index entries inherit that metadata).

Unfortunately, Help 2.0 currently will work only with standalone
applications, not web-based applications--and most definitely not with
web-based applications that will run on browsers other than IE.

--
--
"I don't entirely understand it but it is true: Highly skilled
carpenters don't get insulted when told they are not architects,
but highly skilled programmers do get insulted when told
they are not UI designers."
     - anonymous programmer quoted in "GUI Bloopers"

Chuck Martin
User Assistance & Experience Engineer
twriter "at" sonic "dot" net      www.writeforyou.com

<jgarison -at- ide -dot- com> wrote in message news:102031 -at- techwr-l -dot-  -dot-  -dot- 
>
> Sounds like you want some sort of Information Type associated with topics
> (doable in HTML Help if I'm not mistaken), or, as you imply, doable with
an
> extended tag set.
>
> I suppose if you wanted to create your own DTD for XML (or whatever the
> correct equivalent is) that also would work.
>
> I am not "up" on the latest XML tools - that'll be one of the things I get
> to when we ship this release - but it sounds to me you need some sort of
> conditional text or tag to operate on.

>
> -----Original Message-----
> From: Chuck Martin [mailto:twriter -at- sonic -dot- net]
> Sent: Thursday, April 19, 2001 8:24 PM
> To: TECHWR-L> Subject: Re: seeking online Help technology with specific
> characteristics

>
> It means that users can be from different companies, or can have different
> roles (such as different administrative roles). The Help available (as
well
> as where they can go in the application), is based on those
characteristics.
> For example, a user who has no administrative roles would not see Help
> topics that describe administrative functions. Or wording in the
application
> might be different depending on what the company is, so different Help
> content is used for each.
>
> Dreamweaver, even Dreamweaver 4, does not produce valid XHTML, one of the
> requirements we have.
>

>
> <jgarison -at- ide -dot- com> wrote in message news:101397 -at- techwr-l -dot-  -dot-  -dot- 
>
> 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.

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

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