Re: ANNOUCE: gTrouble - New project

["Jacques Du Pasquier" <jacques dtext com>]

Do it do it do it do it !! :-)

And don't do anything else in the meantime, you have enough deep
thinking to do before you start implementing. :-)

A few thoughts in no order :

Are you sure you want to restrict this to trouble shooting ? It seems
to me that trouble shooting structure is not very different from
how-to structure.

Suppose the trouble guide establishes that some support application
must be installed. It'd be nice to call at that point another similar
guide that will walk the user through the install, also asking
questions, etc. But installing an app is not specifically trouble
shooting.

So I would focus on the more general "step-by-step guide" notion,
rather than arbitrary restricting it to trouble shooting.

Also, mind the "modularity" part, so that ideally many people can
write little guides for simple goals and all combined they can walk
the user through anything he wants to do. I think it's only if the
modularity is well designed that it can actually become useful.

Otherwise, you would need huge guides, and the guides would also be
impossible to write, with a very complicated structure, that would
lead you straight to IA expert systems, and then you would get border
and trash the whole thing :-).

Maybe you could imagine a set of standard guides that should accompany
every application ? Like

- installation
- trouble shooting
- configuration

So if a series of apps supposed to work together all have doc
implementing the Tom standard for hand-holding documentation, you can
be sure you can make them work together, easily, just following any of
them.

To make modularity better, maybe you can allow guides to receive
parameters when called ? A parameter could be a directory where
something should be installed, or a specfific configuration.

When you call a guide B from a guide A, often you will already have
established in guide A things useful in guide B, so it's nice if you
can provide this information. In fact, if guide A establishes that a
software must be installed in a certain way or at a certain place, it
shouldn't have to explain that to the user so that he can provide the
info to guide B. Etc.

Of course there is a problem of knowing the interface (receivable
paramters) of other guides, and also of guide versions.

Some of these parameters could be standardized, the same for any
application. Other special parameters of guide B you could use from A
only if you specifically know the guide for B.

Also, if the triggering of actions is not exceptional but natural in
your model, maybe guides can progressively turn into automatic
process, only assisted by the human. (with all nice unexpected effects
when it goes mad!!)

Maybe, if the guide comes to a dead end, it should be able to dump the
info gathered in a mail message to be sent by the user to the apps
author to get help (and the author can now hack a new version of his
guide handling the situation).

Also, don't restrict it to Gnome. Don't go for docbook, either. Do
things from scratch, and conquer the world :-). Well, define a
language maybe within SGML or XML, implement the browser function in
gnome-help-browser, but do it in a way other people will be happy to
implement a browser for the same language. Don't make it
Gnome-specific.

IN fact do it in XML and it will appeal to more people. Make it the
first real XML killer app :-).

Maybe some of this is a bit ambitious (or crap), but hopefully you
find something usable.

Jacques




Dennis Lee a écrit (22.9.1999/19:36) :
> Tom Gilbert wrote:
> 
> > Agreed. I was just browsin' the gnome-help-browser source, and all the fun
> > just plain drained out of me ;)
> > 
> > Ok, well, I'll think on, I'll go see how Moz is getting along, and
> > start thinking about something else to do in the meantime...
> > 
> > Tom.
> 
> If your looking for something to do....
> 
> How about a plugin for Gnome Calendar that uses a Gnumeric module to
> keep your check book, pay bills, print checks......
> 
> Dennis Lee
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 
>