Re: Req. for comments/Help system

["P.D. St. Onge" <pete_st_onge@iname.com>]

Well, my two cents are below. Let me say that I'm really glad to see a good
team working on such a project - I look forward to seeing this project
develop, and wish you the best in your endeavors.

Hope the comments help.

	Pete

Pete St. Onge - McGill U. Limnology - Fun with Ropes & Buckets
pete_st_onge@iname.com 				        ICQ: 4322052


> REQUIREMENTS. Draft version 0.1. Dec 2, 1997.
> 
> Following  is  a  preliminary  listing  of  the  existing   critical
> requirements.     Any    and    all    comments,    criticisms   and
> additions/subtractions are welcome.   This  is  a  first shot at the
> most important requirements, intended to get them out on  the  table
> where  others  may  know of them, and influence them.  They are most
> definately not set in stone.
> 
> I.   Help Browser
> ====================
> 
>   i. Two main graphical components
>     a. A main frame.
>     b. One or more display plugins.
	I take it these plugins would allow for help files in pretty much any
format. Does this mean that several of the other modules could be written
in C or C++ (or whatever other Linux-friendly language), and when these
modules make calls for the help files, the main help window will come up
and get the appropriate help file and viewer?

>   ii.  Main frame performs several tasks:
>     a. Document history.
>     b. Document navigation.
>     c. Display plugin management.
>     d. Document window management.
	Does 'Document History' mean that certain help pages could be bookmarked
to permit rapid retrieval of help pages which are particularly pertinent?
In other apps I use (SAS, for instance) I am often returning to certain
pages when I want to look up the specifics of the procedure.

>   iii. Display plugin performs the following tasks:
>     a. Loads and displays documents of a specified format.
>   
>   iv.  Display plugins are controlled by the main frame.
>   
>   v.  Interfaces between components  allows  any  components  to  be
>        rewritten   and   replaced  by  other  components  and  other
>        languages.
>   
>   vi.  Help access only spawns one main help process.
>   
>   vii. The main process may handle many display windows.
	I like this - I tend to (try) to look up several help docs at any given
time, and it would be wonderful to be able to keep more than one help doc
on screen as I work through them.

>   
>   viii. Every  display  plugin  (for  each  display)  has  its own
>         process.  This allows plugins to be language independent.
> 
> II.  Help Interface
> ====================
> 
>   i.  The direct help interface is  through fifo pipes, to allow for
>        language independence.
>   
>   ii.  A c/c++ dynamic library is supplied for simpler access.
>   
>   iii.   A command line interface provides the basic services to any
>        language and direct use by the end user.
> 
>   iv.  The  interface  between  the  main  program  and  the display
>        plugins are fifo pipes, which allows the display  plugins  to
>        be written in any language.
>        
	Unfortunately, my familiarity with the Unix / Linux world is cursory at
best and so this doesn't mean much to me yet.


> III. Help Documents
> ====================
> 
>   i.  Documents may be written in any format (though  a  plugin  may
>        not  exist  for  some  formats and would therefore have to be
>        written.)
>        
>   ii.  Existing documentation will be used wherever possible.
>   
>   iii. New documents  will  be  written  to  help  achieve the SEUL
>        ideals.
	Perhaps one of the greatest sources of information and assistance are
other users. As I work with a program, particularly when I first start to
use it or when I use features or procedures I am not familiar with, I tend
to put this info in a text file and refer to it everytime I need it.
	With some programs (SAS, f'rinstance - sorry to all you SAS-philes!) the
help files are clunky and not terribly intuitive.
	Keeping these two points in mind, it would be great for end-users to be
able to 'build' custom help documents which would have hooks to other help
docs (and bring up the necessary viewers).
	Anyhow, I'm sorry if this last explanation leaves much to be desired - I
am certainly willing to write more about it. 

	Hope this helps!

	Cheers,

	Pete


Pete St. Onge - McGill U. Limnology - Fun with Ropes & Buckets
pete_st_onge@iname.com 				        ICQ: 4322052