Re: task help

[Roger R Dingledine <arma@mit.edu>]

In message <34A08C9B.4D990983@globalserve.net>, twoducks@globalserve.net writes:
[intro about task help snipped]

Excellent idea. So do we intend to package these taskhelps separately
from the programs they provide help on, or try to get each program to
include a set of taskhelps for itself? (I guess I vote the former, unless
we can somehow make the taskhelp idea a generally accepted standard, and
maybe even then...)

>  For example: The base task documents may include tasks for directory
>  and file management (copying and managing files.) If the user installs
>  a file manager they would want new task files which explain these same
>  tasks through the file manager. What should be done with the old help
>  files? What if more than one file manager is installed? What if the
>  file manager is un-installed?

Ack. Yeah...this soon grows into a hierarchy problem similar to RPMs but
maybe even more complicated. If a program gets deinstalled, we have to know
which taskhelps are affected by that, and then figure out which of the
remaining ones are most relevant to the current combination of software
on that system. The same sort of recalculation has to be done for newly
installed software, providing it comes with its own taskhelps.

What do we want to focus on optimizing here? We should pick a couple
things to fight for when we're looking for the best solution.

CPU usage for recalculation?  Disk space usage for taskhelps? I think
we can safely ignore these two for modern computers.
Number of taskhelps written? Number of *duplicate* taskhelps written?
This would definitely affect the complexity of the algorithm we use to
figure out which taskhelps the user wants to see.
I guess one of the biggest things for SEUL will be combining *power*
with ease of use. I want this thing to be cooler than anything microsoft
can come up with. And I want it to actually be usable too. :)
  
>  This problem is more complex with different help topics.
>  
>  Solution
>  --------
>    The following is one solution which may be used:
>    
>    * Label the help files according to complexity levels: eg 1-5, 5 is
>      least complex (or no max number, indicating things can always get
>      simpler.)

Who decides the complexity level of a given taskhelp? We'd definitely need
some sort of standard, and hope things didn't get out of hand by too many
people misinterpreting the standard. Maybe the xhelp thing would even have
some sort of instafeedback button where you click saying "woah, this
taskhelp was more/less complicated than it said it was", and by some sort
of vague internet voting method the complexity numbers would grow in the
direction of being correct. (Yeesh. Talk about a farfetched suggestion.)
      
>    * Allow the user to display in the xhelp browser only those files
>      which
>      are least complex (so the more complex ones are masked.) The user
>      can also display all help.

How about the ability to choose how complex you think you are -- that is,
a range of taskhelp complexities that you want to see, or even a discrete
list of complexity numbers you're interested in.
    
>    * When new programs are installed (or uninstalled) the new documents
>      may take over the view by being less complex (or stop being viewed
>      by being uninstalled).

Good plan.
    
>    * Naming convention: mytask@1.html indicates mytask of complexity 1,
>      type html.

Again, sounds like a good plan.

--Roger