Re: Proposal for Nautilus help display

[László Kovács <laszlo kovacs Sun COM>]

> > 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.

Right now we display all the sections about a doc as part of the content
list. I guess this is hardly completely zoomed out. I would imagine this
like by default the content list contains one entry for each doc and
then when selecting a doc and zooming in we get the subsections. I see
two problems in the short term:

1. Gnome docs are small so they don't really justify this
implementation.
2. Currently the Content List panel is implemented, while the zooming is
not. Zooming would need some extra effort that I am not sure we can
afford now.

I suggest we leave that for now as it would need extra work on top of
the suggested implementation. It can be done later on. Btw there are
already Zoom buttons in Nautilus, it should be tied to that probably.
 
> 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.

This could be done with the current content list approach by selecting
the right doc. If we implement zooming then it should be like this.
 
> > 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.

Yes, this is how it should be.
 
> > 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.

Again, this is something extra that sounds nice, but we don't have the
time. We might be able to do it in which case we add some buttons that
allow saving and restoring saved selections. This is clearly an addition
to the current design, it does not alter it in any way so I suggest
we'll see when this is done about how much time is left.

> 
> > 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.

Nope:-) I know searching on content list entries is something you always
liked, but this searches in the index only. I actually never saw a help
browser that searched on the content list (maybe I haven't looked hard
enough) so I couldn't really imagine how to add that. And I do not think
it is a core help browser functionality. I can't even see really how we
combine all sorts of different searches in a unified GUI, although I am
not a HCI designer. It can be done on top of the current design later
on, although as long as this GUI is part of Nautilus it looks more and
more awful as we add more GUI items.

Laszlo