Re: jrb's help ideas

[Eric Baudais <baudais okstate edu>]

On Mon, Sep 03, 2001 at 04:58:25PM -0400, David Merrill wrote:
> On Mon, Sep 03, 2001 at 03:52:50AM -0400, Jonathan Blandford wrote:
> > "Rebecca J. Walter" <rjp mail tele dk> writes:
> > 
> > > i have one addition.  this help browser should be capable of loading an
> > > average help file in under 15 seconds on a typical user machine.
> > 
> > <snip>
> > 
> > I don't think anyone wants to wait 25 seconds for a help-browser to
> > popup.  Recent versions of nautilus are much improved speed wise.
> > Nonetheless, I think that there is likely to be lighter help browser
> > available so that people have an option if needed.  That's the point
> > behind the spec.
> 
> The whole `help browser' concept is flawed. Why can't the help be made
> available via http so any web browser can be used? Hell, you could
> write it in perl or python if you wanted.
> 
> I'm both a gnome and a kde user -- I go back and forth depending
> on what I'm doing. I don't want to see my system help changing
> depending on which desktop I'm using. I really don't want to learn two
> help systems. And, I'm often not using a desktop at all, and I still
> need to get to help on the console.
> 
> Providing help at the console is *not* *optional*.
> 
> We need a system level server that provides access to a help database
> that is not so gnome or kde specific. It should be able to serve any
> document in the scrollkeeper database transparently to any browser can
> supports html and http post/get.
> 
> Not only is this faster (lynx is gonna beat anything you can do in a
> gui) but also more flexible and powerful.

A long time ago this idea was put forth and rejected for some very good 
reasons which still apply today.

1) Most people don't have a very good connection to the internet.  This 
is applicable to many home users in the US and most users in foreign countries.
I live in Oklahoma and the two biggest cities don't even have good coverage 
of cable modems or DSL of any sort.  Only by attending college do I have a 
fast network connection.  Ask Telsa about internet connections in England if 
you don't believe this.

2) Help needs to be local.  This argument goes back to many people not having 
a good internet connection.  If I want help on a certain application, I expect 
to click the help button on the application and a window will pop up showing 
me at least some basic help.  If my network connection is slow, that help 
could take one minute or more.  This will infuriate users because they are 
already frustrated with the application and making them wait so long for the 
help file to be downloaded will make them more angry.

I don't think you understand what we are trying to do with the "help browser."
The object is to make a browser that is fast and can directly convert and/or 
display DocBook (the DTD the GDP's help is written in).  Now we have a backend 
to convert DocBook into HTML.  From that HTML you can use any web browser you 
wish to display the help.  The problem is the integration of the help files 
isn't seamless.  What the GDP is trying to do with the "help browser" is to
make the integration of the help files seemless.

Nautilus is the only program which integrates the help files seamlessly.  The 
specification being written is to determine a minimum a web browser needs to 
integrate the help files seamlessly.  This will hopefully lead to a lightweight
browser to be modified or created.  A lot of the specification is based on how 
Nautilus integrates the help files.  The goal is the specification is to 
encourage other web browsers to integrate GNOME's help files seamlessly.

The problem with a local help file server is port 80 will need to be opened 
to listen for requests from the web browser.  This is a huge potential security
risk.  Many crackers test port 80, among others, for weaknesses.  A help file 
server provides a potential weakness.  I believe that a good system 
adminstrator can reduce this risk, but the target GNOME user (newbie with 
minimum computer knowledge) will not even know a potential security risk 
exists.

I hope all this is correct and right.  Please correct me if anyone feels these 
are not our goals.

Eric Baudais