Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Brady Montz <bradym@balestra.org>]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: Brady Montz <bradym@balestra.org>
> > Date: 22 Apr 2002 09:54:09 -0700
> > 
> > I see very little in the UI which makes these various
> > options obvious, and the biggest single struggle I have helping emacs
> > beginners is helping them learn how to find out
> > information. Currently, people have suggested three ways to get to
> > sort-paragraph from sort-lines: open sort.el (my fallback approach),
> > apropos, or Info-elisp-ref, and putting xrefs in the doc strings.
> 
> These all (and more) are under "Help" in the menu bar.
> 
> If you are saying the the menu bar is not obvious enough, then please
> suggest practical ways to make that more obvious.  The problem with
> help functions is that, IMO, a user should generally request help
> explicitly, or make some sign that she needs help.  Otherwise, if we
> stick the help info into her face when it is not requested, we risk
> ending up with the equivalent of that annoying MSWord-style paper
> clip.  So if the menu bar is not enough, please suggest the ways Emacs
> should use to decide that the user needs help (and perhaps what kind
> of help as well).

Yes, can't have clippy. I much prefer a passive approach where
everything is unobtrusively at your fingertips over clippy's obtrusive
sticking fingers in your eyeball.

As for the menu bar, I don't know what emacs 21's looks like. since I
moved to xemacs back when emacs was at 19. 

I don't think that, for this particular scenario, the xemacs help menu
bar is at all obvious. Asside from the terminology issues (will a
novice understand the difference between lookup command and lookup
function, and "apropos" is the epitome of obscure) which is being
covered elsewhere, it's certainly not obvious to me which of those
menu items is the best thing to select to show me what's similar to
the command I currently have open in a help buffer.

For this particular example, a popup menu of common "what you might
want to see after reading this help text" actions might be the best
menu modification. 

I dislike relying on having things like only in a menu though, since
it's not obvious to right-click when you want "more." A little "click
here for more" button is more to my liking.

> > Back to my example. So far, three people have suggested three
> > ways. First, not all of these ways work for every function (for
> > example, C-h C-f gnus just failed for me)
> 
> Is "C-h C-f" supposed to show the Info node for a command you type?
> If so, the equivalent command works for me in Emacs with gnus.

Yeah. I was referring to Stephen's usage of that. 

Doesn't work on my xemacs installation, so it's probably just an
install issue.

> 
> > nor for every situation
> > (for example, starting from a keybinding instead of a function name)
> 
> "C-h K" does that for me in Emacs.

Exactly. My point which you responded to was that for my example
(sort-lines), the three (maybe four) methods people gave for getting
the list of related commands don't work in all situations. For the
related situation where you know the key command but not the name, you
need yet another method (C-h k, followed by some others).

So, we have a situation where there's approx. 14 useful C-h commands
worthy of mention in the xemacs help menu, and I don't think it's
immediately obvious which to use when (oh, I know the key so I use C-h
k. I want the related functions and because this function is nicely
named C-h a will probably do the trick. I want a general overview and
this is a stable core function so the info page is probably good let's
try C-h C-f, this really should be in the info index so let's get to
that with C-h i, this is a function so C-h f, no wait it's a variable
C-h v, dammit I just want the key binding so C-h w).

Help shouldn't require help.

Here's what I'm starting to come to after this discussion - I'd like
an abstraction layer or interface between me and the
help/configuration systems. Not a wizard, but a unified interface that
wouldn't require a wizard.

I think we already have all the info we need in the various docs and
source code, and most of the functionality is already there. It's a
matter of presenting more efficient interface to it all.

> > none of them are apparant from the UI
> 
> Help->More Manuals->Find Key in Manual and Find Command in Manual do
> that in Emacs.

Just because they are in the menu does not mean that it's apparant to
the user than when he's reading about sort-lines in a help buffer, he
should select those items to find out about related commands.

It is reasonable expect a user to figure out that the "find command in
manual" might do that (but only for things with an info page). I don't
see anything in the interface of that help buffer pointing me to
that. The menu bar is about the furthest thing from my mind while
reading that text. It's out of band.

> > So, time to experiment with some code. I'd like to know any idioms
> > that people have for finding information. In particular, I'd like to
> > know the situations in which those idioms are used.
> 
> It depends on what you are looking for, I think.  If the goal is to
> find quickly a description of some subject, then a keyword-based
> search (a user types several keywords, and Emacs finds the appropriate
> documentation) is IMHO the best.  The `i' command in Info gets pretty
> close to that (it's normally the first or second method I try when
> looking for things).

I'm thinking a better search mechanism would be really nice. Just
having better searching of the info pages would be huge.

> This could be inappropriate for people who want an introduction to
> some broad issue, though.
> 
> Another idea is to try the hierarchical approach: a user is asked a
> series of questions about the subject she wants to read about, which
> (the questions) progress from general to more and more specific, until
> the subject is determined and its documentation displayed.  With each
> question, the user is given a small number (like 4) of possible
> responses that should narrow the search in the next stage.  Some
> knowledge bases on the net are organized in such ways.

Yeah, I'm not so sure about that one though. I've never found those to
be particularly useful. I think the info pages do a nice job for
that. Just prefix each item or section with a "I want to" or "what is
a" and it seems it's about as close as we could hope to get.

There might be some really nifty knowledge base lisp engines out there
that we could benefit from though.

> > For example,
> > knowing a fair bit about emacs, I generally start with my comfortable
> > turf which is a known similar function, then I apropos, search the
> > info pages or source, or a known phrase (generally with nice emacs
> > terms like buffers, regions, yank, that are stirring up so much
> > trouble elsewhere on this thread :)), and I google search.
> 
> A suggestion for a procedure that uses Emacs facilities in a certain
> order (derived from experience) can be found in the node "Help" of
> the latest Emacs user manual (shipped with Emacs 21.1).

I'll check that out.

-- 
 Brady Montz
 bradym@balestra.org