From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Terje Bless Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sun, 21 Apr 2002 17:41:49 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <873cxpz436.fsf@lgh163a.kemisten.nu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1019407354 1822 127.0.0.1 (21 Apr 2002 16:42:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 16:42:34 +0000 (UTC) Cc: Michael Toomim , Eli Zaretskii , bradym@balestra.org, xemacs-design@xemacs.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16zKQ6-0000TH-00 for ; Sun, 21 Apr 2002 18:42:34 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zKQO-0002f3-00 for ; Sun, 21 Apr 2002 18:42:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zKPt-0000vH-00; Sun, 21 Apr 2002 12:42:21 -0400 Original-Received: from mail.wavelan.no ([217.144.228.111] helo=isa) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zKOA-0000li-00 for ; Sun, 21 Apr 2002 12:40:35 -0400 Original-Received: from [217.144.228.69] by isa (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.1)); Sun, 21 Apr 2002 18:42:59 +0200 Original-To: "Alfred M. Szmidt" X-Priority: 3 In-Reply-To: <873cxpz436.fsf@lgh163a.kemisten.nu> X-Mailer: Mailsmith Prerelease (Blindsider) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2944 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2944 Alfred M. Szmidt wrote: >* Michael Toomim writes: >>There's a thing called "user-centered design". In modern times, it is >>generally accepted to be good. > >Maybe you should call it "new user-centred design"? Because it surely >doesn't make any sense on changing the name of such a basic concept like >"buffer" to "document" or "file" when you are already familiar with >Emacs. The whole terminology is so hard coded into Emacs that it would >be a pitta to change, and would cause more harm than good. Think of all >the old time users, they would still call buffers for buffers, and new >users would ask what a buffer is. > >Maybe the entry in the Emacs manual (Glossary) should be fixed to >describe what a buffer is so that it makes more sense to a user, but >changing it to something totally different? No. That would be like >rewriting Emacs. I think I may have confused the issue rather more then I helped. Sorry. My (rather ineptly explained) point was rather that good UI design should focus on the task the user wishes to acomplish instead of how the feature is implemented. The buffer/file dichotomy was merely an example, and possibly a poor one at that. The main idea was that when I'm working using XEmacs I don't think about performing operations on a buffer; I think about the task as opening a file and editing it. Forcing me to think in terms of loading data into a buffer, and performing operations on that buffer before writing it back to disk, imposes an additional cognitive burden on me. I'm not suggesting you do a global search and replace of "file" for "buffer"; only that you take this point of view into account when designing and architecting all aspects of the application. I'm advocating abstracting the user interface away from the implementation details. This does mean there is an abstraction between UI and implementation that will be a burden for those developing it. That may be too expensive a tradeoff for the developers, but I'd hoped not, as many other developers manage this without too much pain. Of course, the Emacsen are somewhat unique in this respect. I do not (not not not!) suggest dumbing down XEmacs! I'm suggesting _smarting_ it up! That is, provide more friendly and helpfull features for those that need them while staying out of the way of those that do not.