saal@floyd.ATT.COM (Sam Saal,1A-110,6956,Cap Gemini) (02/22/91)
Sorry this is so long; please respond via email as I don't read all the newgroups. I'll post a summary after a week or so. My project is considering implementing a Hypertext interface to our documentation. We will have to convert several documents to Hypertext and I have some questions about it. From my understanding about Hypertext, what works best is information "chunks" no larger than what would fit on (at most) a couple of screens. Further, each of these chunks should maintain P/PI (Page/Paragraph Independance). That is, because the Hypertext developer may not know how the user got to a screen (which link, sequential or otherwise), each screen must give enough of a context to keep the user from having to start back at an earlier point in the Hypertext document. This is especially important for supporting information (as opposed to the root document). IN addition to the significant effort level necessary to convert existing traditional documents to Hypertext, this presents some interesting problems For example: Some of the documents are deliverables, "legal" definitions of requirements. Converting them implies rewording some things and that means the Hypertext version could not be used for arbitrating issues we'd normally be interested in. That is, by having two different versions, and someone needing to decide whether a requirement was being met, we could not use the on-line, convenient, Hypertext version and be sure we had the official requirement. With that huge introduction, here are my questions: Is the problem I mentioned really something to worry about? How important is it to maintain the small chunk-size? What experience do people have converting existing documents to Hypertext? Is it worthwhile to convert documents one at a time? If you do it that way, each time you add a document to the Hypertext you'll have to go back to each document already in the system to add links to the additions. If existing traditionally published documents are converted to Hypertext and then reissued, are there fast/easy ways to redo the links in the new issue or must youstart all over? One possible solution to a few of these probelms is to look to a CASE tool as hybrid solution. CASE has some of the links between source documents, although they are far more structured than what you'd expect in Hypertext - hierarchical instead of "random." The problem with this solution is that we're looking for a documentation system that would be useful to us as well as to our customers. CASE's main use seems to be for developing a system. Can anybody recommend a system that allows an exportable read-only subset that can be delivered as an on-line documentation system? Does such a beast exist? Does it make sense? I'm sorry this has gotten so long. Please respond via email as I don't read all these groups on a regular basis. I'll post a summary of responses to the groups listed after a week or so. -- Sam Saal saal@floyd.att.com
Dan_Jacobson@ATT.COM (02/23/91)
>>>>> On Fri, 22 Feb 91 15:43:33 GMT, saal@floyd.ATT.COM (Sam Saal,1A-110,6956,Cap Gemini) said:
Sam> Followups-To: comp.text
Isn't that supposed to be in the header? :-)
Sam> My project is considering implementing a Hypertext interface to our
Sam> documentation.
Perhaps consider GNU Emacs' TeXinfo, a marriage between
two great quazi public domain tools: GNU Emacs and TeX. Hundreds of pages of
tree/menuized manuals are as close as
$ emacs -f info
to many users as we speak.
[Admittedly I don't read alt.hypertext and lack other hypertext knowledge.]
There even is a LaTeXinfo, and standalone info browsers using this
format. Tune in to the gnu.* and comp.text.tex groups for more info.
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364