[Nautilus-list] Re: Proposal for Nautilus help display

[Dan Mueth <d-mueth uchicago edu>]

On Thu, 12 Jul 2001, Mary Dwyer wrote:

> hi
>
> I have been working on the Scrollkeeper project to provide index extraction for
> help documentation.  Following on from that I am now working on providing index
> display/search capabilities for the Nautilus Help Browser.
> Calum Benson, a Gnome HCI engineer here at Sun, has produced a design for an
> enhanced GUI for the display of help contents and index/search for Nautilus.
> You can see the proposed design at:
> http://www.gnome.org/~gman/nautilus-help/proto.html

This looks really nice.  Many thanks to Mary, Calum, Laszlo, and anybody
else who helped out.

> The Contents tab is for navigation of installed docs and it is exactly
> the same as the current content list pane in Nautilus.

One thing I was hoping to add to this is the ability to zoom in and out of
the tree.  You can think of this as either "zooming" and "unzooming", or
just "pan left" and "pan right".  For example, we might have two little
arrows (left and right) (or two magnifying glasses with + and -) at the
top or bottom of the pane.  The default view right now is what I would
consider all the way zoomed out.  If one has a document or section
selected, as they zoom in they lose information about other
documents/sections and probably see more subsections of the given
document(s).  This follows the way people navigate for documentation,
starting at a broad scale and then focussing in on a given part of a given
document.

We also have to consider what happens when the user goes the other way -
they click the help button in an application to open the browser to a
given page of a given document.  In this case, we probably want the
contents pane to be zoomed in on the TOC of the particular document.  If
the user decides they want to navigate outside the scope of the given
document, they hit the little left button (or - magnifying glass) and zoom
out of the context of just the single document.

> The Index tab displays an index depending on the toggle setting of "Show
> indexes for:". If "Selection on Contents tab" is selected then it
> displays the index of the doc selected in the Contents tab. The natural
> way of events should be that the user selects a doc in the Contents pane
> and then switches to the Index pane. This will select the toggle
> "Selection on Contents tab" and display the selected doc index.

If the help browser is brought up by a help button in an application, we
should have the document selected in the contents list and the "selection
on contents tab" button checked.  This way they are just searching within
the given document by default.  It sounds like this should work similarly
to your case above.

> If "All documents" is selected then indexes of all docs that Nautilus
> knows about will be displayed. If "Specific documents" is selected then
> the user will have to click on the button near the toggle, this will
> replace the index view with a content list view (different from the
> Contents tab) and the user will have to select docs or groups of docs
> there (this is the third screenshot). When returning from that only
> indexes of selected docs will be displayed.

It would be nice to be able to have a list of pre-defined and user-defined
document groups.  With the current design the user can specify the group.
We would just need to add controls to save/load/delete groups.  Some
default groups we may want to include are GNOME, KDE, and Linux.
Distributors are likely to create a default group for the distribution's
documentation.

> The second set of toggles in the Index pane allows filtering the indexes
> displayed. It is self-explanatory, and very simple, no boolean
> combination of several keywords is allowed. Typing more than one word
> and searching for them as they are should be ok though.

Just to be clear, this would just search on document and section titles -
ie. what shows up in the contents pane, right?  We may eventually want it
to also consider searching the keyword metadata for a document some time
down the road.  I'm guessing this would be post-2.0.

Dan