Re: general intuitiveness and user-friendliness of GNU Info [was Re: Bug#78504: info: Impossible to scroll just a single line]

[Josip Rodin]

On Mon, Dec 11, 2000 at 09:12:21AM +0200, Eli Zaretskii wrote:
> > > [defensiveness skipped]
> 
> That's a strange way of encouraging volunteers to burn their after
> hours on improving a program.
> 
> > Hey, I didn't say anything bad about info :)
> 
> Only that it looks like no one has tried to make it intuitive and easy
> to use.

_From_ _a_ _user_ _standpoint_. Some users feel that way, not me.

As they say, don't shoot the messenger!

> > You have to press the down arrow key up to 25 times to get it to scroll
> > down by a line.
> 
> Sorry, I don't understand: Info doesn't let you scroll by a line at
> all, unless you set scroll-step.  Did you mean by a page, perhaps?

Right, I meant s/by a line//.

> If so, PageDown should work, doesn't it?
> In any case, I'd expect users to use PageDown and PageUp, not cursor
> motion, for scrolling, if they are unhappy about SPC.

But that's what _you_ expect. :) To some users it seems perfectly obvious to
first try the Down arrow key for scrolling. After seeing how the arrows
behave, yeah, these people will try another way of scrolling, but in their
mind that's -1 point for info's intuitiveness, if you see what I mean. :)

> > You have to use the left and right arrow keys up to 80 times to
> > get to a link (and then back to the bottom of the page to scroll). (No,
> > <tab> isn't very obvious, nor are ^A or ^E.)
> 
> I thought TAB and BackTAB were widely used in all GUI programs to step
> through all the ``interesting spots'', such as fields in a dialog.
> 
> What would you suggest as a more obvious way of getting to a link?

There are two ways: either make {Up,Down} arrow keys to scroll between
links, like they do in all the console web browsers (and pinfo), or get <TAB>
more advertised. The first idea probably requires lots of work, and the
second idea depends on the /usr/info/dir file somewhat, because it's the
thing people see on first entry.

Speaking of dir file, our (Debian) default dir file has this:

  This (the Directory node) gives a menu of major topics.  Typing "d"
  returns here, "q" exits, "?" lists all INFO commands, "h"  gives a
  primer for first-timers, "mTexinfo<Return>" visits Texinfo topic,
  etc.
  Or click mouse button 2 on a menu item or cross reference to select
  it.
  --- PLEASE ADD DOCUMENTATION TO THIS TREE. (See INFO topic first.) ---

In Debian Linux, Info `dir' entries are added with the command
`install-info'.  Please refer to install-info(8) for usage details.

* Menu: The list of major topics begins on the next line.

<end quote>

Probably not the best introduction... I'll see if I can get it fixed.
The dir-example doesn't seem much better to me, you might want to add a few
more instructions.

> > There's no convenient <Ins> and <Del> two-line scrolling, like in
> > lynx.
> 
> I never heard such a feature being suggested, and I don't use Lynx
> myself.

Well, lynx and links CLI web browsers have it, <Ins> moves two lines up and
<Del> moves two lines down. Kind of intermediate mode, between one-line and
one-screen scroll modes.

> However, DEL is already taken, it scrolls back a screenful...

Hmm, problem.

> Info is modeled after Emacs, as far as key bindings are concerned.  If
> we want it to behave radically different, we will probably need a set
> of entirely different key bindings, activated by a command-line
> switch, like --vi-keys does.

Which brings up the question -- why does it have to be modelled after Emacs
in that aspect? Emacs users ought to be better off using the info mode, so
it would seem better to adjust the info keybindings to be (remotely) similar
to the keybindings of other CLI applications.

> > The top status line can span lines which looks somewhat confusing. The
> > footnotes are displayed both in the bottom window and at the end of the
> > page in the top window. It's especially hard to read anything in the top
> > window when the bottom window (with the footnotes) takes three quarters
> > of the screen.
> 
> I'm not sure I understand what do you suggest as a remedy for these
> problems.

The top status line should strip off extra characters (perhaps replacing
"some long thing here" with "some long...") that could get expanded by
pressing some key or just moving the pointer onto the line.

Three ideas for the second point:
  * the new window for footnotes shouldn't be created at all, or
  * the top window shouldn't contain the footnotes
or
  * the footnotes could be displayed on a new "page", like a new node.

The bottom footnotes window should never be larger than the top window.
If necessary to scroll it, that should be possible. Somehow :)

> > When you press ? for help the bottom window doesn't disappear.
> 
> Why should it?

Because the footnote is off-topic, you want to read the help screen now that
you pressed ?. (The `l' key should then go back to the page including the
footnotes window, not just the main window, of course.)

-- 
Digital Electronic Being Intended for Assassination and Nullification