From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Info tutorial is out of date Date: Tue, 18 Jul 2006 08:28:19 -0700 Message-ID: References: <20060718093844.GA1397@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1153236649 13331 80.91.229.2 (18 Jul 2006 15:30:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Jul 2006 15:30:49 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 18 17:30:49 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G2rWf-0005sd-Lw for ged-emacs-devel@m.gmane.org; Tue, 18 Jul 2006 17:30:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G2rWe-0000Rm-OC for ged-emacs-devel@m.gmane.org; Tue, 18 Jul 2006 11:30:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G2rWN-0000PH-OF for emacs-devel@gnu.org; Tue, 18 Jul 2006 11:30:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G2rWM-0000O9-QT for emacs-devel@gnu.org; Tue, 18 Jul 2006 11:30:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G2rWM-0000Nv-MB for emacs-devel@gnu.org; Tue, 18 Jul 2006 11:30:02 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G2rZH-0005yk-AR for emacs-devel@gnu.org; Tue, 18 Jul 2006 11:33:03 -0400 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6GMnnZP020294 for ; Tue, 18 Jul 2006 10:29:59 -0500 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-80-94.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1584120361153236503; Tue, 18 Jul 2006 09:28:23 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20060718093844.GA1397@muc.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57276 Archived-At: 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.