Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless <link@pobox.com>]

Alfred M. Szmidt <ams@kemisten.nu> 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.