Laserfiche WebLink
tight deadlines for software and data product updates, it was not possible to keep the on-line <br />documentation up-to-date with the actual products. Additionally, it was expected that the preliminary <br />versions of the on-line documentation would be to guide users in the use of the development copies of <br />software. Consequently, documentation for software was updated regularly during development but was <br />not put into a more polished form until final review by the State. <br />Features of the on-line documentation that were not specifically scoped but which are of special note are: <br />? <br />An effort has been made to use a graphical banner at the top of each on-line page to <br />distinctly identify the page as being part of CRDSS. This graphic is implemented as an <br />image-map and could be updated to have touch-sensitive hot-links in the future. <br />? <br />The footer for each page indicates the email address of CRDSS support. Currently this is <br />webmaster@cando.dwr.co.gov. The footer also typically shows the date on which the <br />documentation was last updated. <br />? <br />Each on-line document is stand-alone, meaning that it can be viewed separate from the web <br />server, if necessary, and can therefore be transported and hooked into other web servers. <br />? <br />Each on-line document has a short-cut table of contents at the top so that the reader can <br />quickly jump to each section within a document. <br />Subtask 2. Update the hard-copy versions of the CRDSS documentation to reflect updates in <br />CRDSS software. <br />As discussed in the previous section, a decision was made to make the hard-copy documentation <br />resemble as much as possible the on-line documentation. This meant that some of the features available <br />for on-line documenation were not used and that the wording of documents became media-neutral. For <br />example, although it is possible to construct on-line documentation where many links exist to other <br />documents, a more linearly-reading on-line document needs to be implemented to allow it to be printed <br />and still make sense. Also, phrases such as ?press here for...? needed to be replaced with neutral phrases <br />like ?See the xxxx documentation for...? <br />After the decision was made to make the hard-copy documentation resemble the on-line documentation, <br />a further decision was made to use tools that allow one master copy of each document to be maintained <br />and from that be able to generate both the on-line and hard-copy forms of the documentation. After <br />rtftohtml <br />testing several approaches, including use of the conversion program and several add-ons to <br />WordPerfect and Microsoft Word, RTi decided that the best product available was the Georgia Tech <br />GTHTML macro package for Microsoft Word, which is in the public domain. Although there is <br />understandably quite a market for a product that allows HTML to be generated from a document- <br />formatting package, other products reviewed either lacked the needed features or were unworkable <br />(crashed word processing systems). <br />Once the conversion software was chosen, the task of document updating and conversion began in order <br />to deliver the Year 2 products. This meant that all documents were implemented in Microsoft Word as <br />the hard copy master and on-line documentation was generated from that master. The master document <br />therefore followed project documentation conventions such as fonts, headers, footers, and on-line banner <br />graphic. Documents that were originally in Microsoft Word needed fairly minor revisions to come up to <br />standard. However, documents that were originally only in HTML, such as software documentation, <br />needed to be converted to Word and then back to HTML using the GTHTML package. It was decided <br />3 <br />a320/taskmems/ 2-12-01.doc 01/03/97 <br />