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 06:16:31PM +0200, Eli Zaretskii wrote:
> > > 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.
> 
> Strange, I would expect them to use PageDown and PageUp, not the arrows.  
> Arrows typically move by lines, not by pages.

Yeah, but the user just wants to move down.

> > > > 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.
> 
> TAB is advertised in the help screen popped by `?', but I guess some 
> people won't have the patience to read the first few lines...

But it's only on the second page of the help screen ;) Just kidding

Seriously though, although nothing will help people who don't read help at
all, making sure people have noticed something by putting it directly under
their noses can't hurt. (This is where colors or just using bold or
underlined characters would be useful, perhaps.)

> > The first idea probably requires lots of work
> 
> Actually, it's very easy to change the key binding of the arrow (see 
> infomap.c), but I'm afraid some users out there will want the old 
> behavior.

Right, but changes like that can be circumvented with command line options.

> > and the second idea depends on the /usr/info/dir file somewhat, because
> > it's the thing people see on first entry.
> 
> The Texinfo distribution cannot have any real influence on what DIR files 
> look like on end-user systems.  In addition, I'd expect users to run Info 
> like this:
>               info emacs
> 
> in which case they don't even see the DIR node.
> 
> I think the only resonable way to advertise important commands is to 
> usurp a couple of screen lines near the bottom and display the commands 
> there at all times.
> 
> Would that be a good idea?

I think it would.

> Can you poll your users?

A quick inquiry among my fellow Debian developers showed that there's a bit
of discontent with info. Here are some excerpts:

"it expects people to be emacs users and remember arcane key bindings, much
the same argument people have with dselect"

Note: dselect is despised|abandoned by _many_ Debian users, mostly because of
weird keybindings and one particular misfeature regarding the Recommends:
package field. :(

"I use pinfo.  It makes it manueverable, but doesn't help in finding info."

There's nothing as quickly accessible reference index in info docs, at least
"apropos and man somehow makes it easier." Though this might need to be
resolved in the info documents themselves, not the info viewer.

"I'd be happy with a little util to unfold my entire info tree into a
serialized doc for egrepping."

(So searching through a whole hierarchy of info documents would be a useful
addition.)

"the fact that FSF has been killing man pages in favour of info should be
treated as treasonous"

(Let's ignore the above comment for now :)

I'll see if I can get any `normal users' to comment on this; surprisingly
enough, my questions about this went unanswered on an IRC channel with 189
people. (It may just mean none of them was interested to talk about it...)

> > > 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?
> 
> Because Emacs's Info reader was the first one written; the stand-alone 
> version came later, and thus was written to emulate Emacs.

That may not be a positive thing :)

> > it would seem better to adjust the info keybindings to be (remotely) similar
> > to the keybindings of other CLI applications.
> 
> We can have the cake and eat it, too: let's define a new set of key 
> bindings, suitable for those who are used to those other applications.  
> Can you, or someone else, come up with a suggestion for this set?  
> infomap.c is a place to start, I think.

I'll see what I can do.

> > 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.
> 
> I don't like invisible parts of displayed text which magically appear and 
> disappear.  Users won't have a clue that they need to move cursor there 
> in order to see the missing parts.
> 
> Hmm... what exactly do we want to fix here?  Do we want to prevent 
> line-wrap?  If so, perhaps removing the current file name and node name
> from the header line is a better idea?  After all, they are already 
> written in the mode line.

I'd agree with this.

Additinally, what's the purpose of "Subfile: foo.info-2.gz" in the mode
line? It doesn't seem very useful to me...

> > 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
> 
> This is only relevant when the Info file was created with 
> "--footnote-style=end".  Is this how Debian generates Info files?  The 
> files I have on my system are mostly generated with the `separate' style,
> which puts each footnote on a separate node.  Then they do not appear 
> in the main window.

I haven't changed the .deb makeinfo in any way; I noticed this behaviour
with "info grub overview".

> > The bottom footnotes window should never be larger than the top window.
> 
> This is easy to arrange.  However...
> 
> > If necessary to scroll it, that should be possible. Somehow :)
> 
> Exactly.  I expect users to have grave difficulties discovering the M-C-v 
> key.  I don't know what to do about that.

Indeed! Perhaps also bind it to Ctrl+Tab or something like that?

> > > > 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 ?.
> 
> How do we know that the user wants help for the main window, not for the 
> footnote?

Is the help screen for footnotes different from the one for the main window?
(I've never seen it)

-- 
Digital Electronic Being Intended for Assassination and Nullification