RE: Info tutorial is out of date

[Drew Adams]

    Good morning, Drew!

Good morning, Alan!

    >     So we cannot dispose of the structural navigation keys.

    > No. The proper conclusion is that we cannot dispose of *structural
    > navigation*. This does not necessarily have anything to do
    > with *keys*.

    Just like travelling by car doesn't necessarily have anything to do with
    the steering wheel or brake pedal, you mean?

No, just like traveling doesn't necessarily have anything to do with
traveling by car or using a steering wheel or a brake pedal. There are other
ways to travel than by car. (Or, perhaps it would be a closer analogy to say
that traveling by car doesn't necessarily have anything to do with using a
clutch.)

    > Anyway, no one proposed to dispose of either structural navigation or
    > structural-navigation keys. The proposal was to *postpone*
    > (not dispose of) *teaching* about structural-navigation *keys*.
    > Each of those 3 qualifiers is important.

    This is what gets up my nose about what you're proposing.  All your
    proposals would marginalise keyboard use.  Please recognise this, and
    acknowledge that it isn't just a minor side effect, it's a critical and
    essential feature of your proposed change.

First, not "all" of my proposals - only the discussion about structural
navigation. Again, gray, not black or white, all or nothing.

Second, those proposals about not teaching structural navigation would
marginalize (make unnecessary, because already unnecessary) keyboard use
_for following the Info tutorial_. That's all.

And not even that - just the first part of the tutorial. I'm in favor of
adding a lesson at the end about navigating quicker using the keyboard.
Think of it: call it "Advanced Navigation" or "Improved Navigation" or
"Super Navigation" or whatever, and newbies will be dying to learn about it.
It's just that learning that first gets in the way of learning the real
subject matter of Info: getting information from the manual.

    You've described me and a few other people as "mouse haters".  This is
    uncalled for, since my only "hate" is the resentment at being forced to
    use the animal myself.

Sorry. I'm sure you don't hate mice. And I assure you that I don't want to
force you to use a mouse.

You are not the target of the Info tutorial. And I don't even want to force
the target audience, beyond the first few tutorial lessons. And I don't
think of it as _forcing_ them, even for those first few lessons, because it
is what they are already comfortable doing. It's really not about you, Alan,
any more than it's about me. It's about Emacs newbies, who are, for the most
part, mouse oldbies.

The mouse and menu use is, in some ways, the lowest common denominator - not
in terms of platforms and hardware, but in terms of newbie knowledge. That
doesn't mean that newbies will stick with the mouse; it means that they can
rapidly appropriate & absorb the essentials of an application using the
mouse, without having to first learn other (perhaps better) ways of
interaction.

    It would be more apt to describe the "other side" as "keyboard
    haters":

Well, I'm not sure who is on that "other side", then; I'm not, in any case,
as I think I've made clear. I use the keyboard almost exclusively in Info
(for example), though I do click the occasional link, and I've stated
repeatedly that we should recommend to users that using the keyboard is
better (for N reasons etc.). I've pronounced in favor of keeping `n' etc. in
the tutorial, just moving that lesson out of the way from the beginning of
it.

    they are steadily erradicating keyboard use for
    anything other than typing letters and numbers.  Firstly, they move the
    documentation of key sequences away from where people will see them (as
    in Gnome),

I'm ignorant of all this (I don't use Gnome, unless I'm unaware of doing so
on Linux - is `gt' gnome terminal?). I'm in favor of showing shortcuts next
to menu items, and I even suggested that we could (though I stopped short of
saying that we should) add them next to "Next:" etc. buttons in Info: "Next
(`n'):".

    then they make them unusably clunky (SuSE 8.0's installation
    program was like this - that was the last SuSE I ever bought), thirdly
    they leave them non-functional, presumably by bolting them on as an
    afterthought and not testing them (there are lots of
    proprietary programs like this).

As I say, I'm ignorant of this trend. I do recognize that most apps except
Emacs don't treat shortcuts with the respect they deserve, but I can tell
you that professional users of an (old and old-fashioned) application that I
use everyday, Framemaker, use the shortcuts, simply because, well, they're
shortcuts. Some Framemaker pros don't, but most do.

I suspect this might be the tendency in apps (those that provide shortcuts):
new users use the menus (menubar, popup), toolbar and such. As they become
more familiar and proficient with the app (and the menus help them learn the
lay of the land - *very* helpful in learning), they start using keyboard
shortcuts. I know I'm like that, as are all of my colleagues. Call us lazy
or ignorant, but that's how we proceed. Almost anyone who uses an app a lot
will look for shortcuts (in the general sense of the term, not just keyboard
shortcuts), but s?he might not do that the first day.

It's important to make things easy for newbies, make them feel comfortable
and feel as if the app is not too complex and intimidating. (This is all the
more true of Emacs, which has a reputation of being complex.)

Seeing the topography of an entire app through a menu - even if you don't
use all of the menu items right away, is an important part of getting to
know the app and feeling comfortable with it. It's like reading the Emacs
manual about things that you might not use right away: you learn what's
available. A menu can serve as a feature list, and it is even hierarchically
organized - it is an outline of available features, to some extent.

Anyway, I don't mean to "push" the utility of menus too much here; my point
in saying this is that this is how, I think, most newbies (and that's all of
us, for some apps) explore and learn what an app can do. It's not
necessarily how they end up doing things with the app. Give people credit:
if they do some operation a lot, they will find the quick, efficient way to
do it. Yes, if they don't do some operation a lot, they might stick with an
inefficient, but obvious (visible) way to do it. There's no great harm in
that, IMO.

    You're proposing the first of these things.  If you "postpone" their
    description to a place where it costs readers effort to find, that's
    hardly better than leaving them out altogether.

I recognize your argument, really I do. It's true that if the Info tutorial
starts out with a lesson on using the keyboard and why it is preferable,
instead of leaving this until later, then keyboard use is emphasized more.

But that's just why I want to move it until later - yes, I want to emphasize
it less - _relative_ to what's important to teach about Info. If we accept
your argument about order, then doing it your way, by your logic, would mean
that people would give up on the real lessons on Info. If the meat of the
tutorial is "postponed" "to a place where it costs readers effort to find",
then "that's hardly better" than leaving the real meat of the tutorial out
altogether. That's your argument, as well as mine: what comes later is
emphasized less.

And that's precisely my point, from the beginning. Yes, I'm trying to favor
the teaching of Info over the teaching to use the keyboard instead of the
mouse. I think that's appropriate. It doesn't mean I don't want to teach use
of the keyboard and recommend it over mouse use. It means I want to teach
Info first. I don't apologize for that priority preference.

    I can assure you it is
    maddeningly frustrating to read about some interesting feature described
    with mouse actions, then have to search out a node called "Keyboard
    Shortcuts", scan through a long, long table to find what could be this
    feature, try it out, then somehow get back to the original node.

I'm sure it is, although I think you overstate the frustration.

On the other foot, isn't it maddeningly frustrating to have to search out a
node about how to look look up a topic in the manual, and plod through
relatively uninteresting lessons on `n' and `p' to finally get to the heart
of the matter?

    The structural navigation keys need to be described together with
    structural navigation.  Surely?

As I've said several times, I would not teach structural navigation,
_except_ as a later lesson that introduces `n', `m' etc. IOW, yes, not only
describe them together, but describe *only* key bindings for structural
navigation - I would not teach any other way to navigate structurally.

Ah, but you'll say, "Drew, you might not teach structural navigation with
the mouse explicitly, as a lesson, but you're teaching it implicitly, by
using it while teaching the important stuff."

Mea culpa. It's not a conspiracy, believe me; it's just an attempt to cut
down on teaching stuff (explicitly) that isn't a prerequisite to getting to
the heart of the matter. We can teach it (explicitly); readers will get to
it, but they will learn the more important stuff first. We might disagree on
what's the most important stuff to teach about Info; I'm not sure. If we
don't, then perhaps the only disagreement is whether we should start with
the important stuff or start with `n' etc., to make sure that readers don't
miss learning the latter.