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

[Brady Montz]

Per Abrahamsen <address@hidden> writes:

> Actually, I believe the trend in HCI research is to avoid or minimize
> the use of dialog boxes.  They really _are_ in the way, also in a GUI.
> This doesn't mean the current (X)Emacs interface is good, it certainly
> isn't intuitive to a new user.

I HATE dialog boxes. Even if they are done OK (you actually CAN do a
search in a program with the dialog box without the box getting in the
way) it still irritates to have this thing flashing in my face. And
don't forget the programming effort for creating and maintaining all
those dialog boxes.

> So I think we really ought to forget about dialog boxes, and instead
> concentrate on making the minibuffer interface more accesible.
> 
> Here is some suggestions:
> 
> 1. Put the minibuffer in the top by default.  It is more visible
>    there, and users of MSIE or Mozilla (and apparently some modern
>    IDE's) will not be surprised to find an input field there.

This seems a good idea. If it's in a clearly seperate "bar" then it
could make the screen less confusing when you have multiple windows
sharing a single minibuffer. 

We also might be able to use this region to clearly show when a
recursive edit is going on. Perhaps a little stack or such.

> 2. Add some strong visual clue (color, animation, whatever) when focus
>    change to the minibuffer.  The toolbar should probably also change
>    to "relevant" buttons for the action, and for those actions that
>    are relevant, a 
> 
> 3. Maybe even have a dialog box (!) pointing to the minibuffer when
>    activating a menu entry that traditionally pop up a dialog.  The
>    box should have an "OK" and a "Don't pop up next time" button.
> 
> 3b Alternatively a "novice" mode, where an arrow point to minibuffer,
>    and a tooltip like message explain what is going on.  Many games
>    teach their UI in that way.  (What a cool way to organize the
>    standard (X)Emacs tutorial!  But I digress).

I think I prefer 3b, preferably after some tooltip sorta
timeout. After 10 seconds of a patiently waiting minibuffer (or if
there's incorrect input), it might be time to give a hint.

I do think that emacs needs a major GUI overhaul if it's to thrive. I
don't know if the minibuffer is the worst offender (IMHO - it's the
ascii art), and I'd rather see a comprehensive rethinking of the GUI
over piecemeal improvements (a dialog here, a menu reorg there). 

Things I would like:

1. actual widgets, with an abstraction layer that allows a single lisp
   spec of them to work on multiple backends - gtk, qt, cocoa,
   vt100. This might restrict them to be fairly simple, but that's not
   necessarily a bad thing. I think speedbar and customize are good
   examples of us straining against the limits of text.

2. one of the things I LOVE about emacs is how easy it is to find
   stuff. "hmmm, I need something to sort a region, what could that
   be." C-h a and there you go. MUCH better than trying to figure out
   something in word, for example. But this assumes a LOT of knowledge
   about emacs. (like "region"). I do think emacs the pack here, but
   it's got SO much stuff to find I believe it needs to make another go at
   advancing the ball.

   I can imagine something where functions not only have a doc string,
   but enough info for a more cleverly interactive browser/searcher
   than M-x apropos to easily find them (we may not need much more for
   that), easily connected to the customize options relating to that
   function, and ideally a mini-tutorial or example code for those
   functions/variables.

   I'd like something where someone can enter a "what do you want to
   do" sorta thing, get a nicely scrollable/searchable table, where
   then can click on each item to customize, read about, or see it in
   action. That would rock.

3. we have a nice set of tools for managing which files/buffers you
   have open and how to switch between them: ibuffer, iswitchb,
   various things like desktop.el, speedbar, buffer-menu, ...

   It might be good to settle on one or a few different ways of using
   all of these and making them more obvious for beginners. Again,
   this plays into an emacs strength. I've used no other editor where
   I could have 200 files open and stay sane. The faster I can find,
   open, and switch to and between files, the happier I
   am. Unfortunately, most beginners I've seen never figure out what
   emacs can do here.

I think all four (including the minibuffer) of these items are
examples of both irritating user-interface deficiencies and great
strenghts emacs has. I love the minibuffer, the ability for simple
little lisp programs to have an interface, having lots of stuff to
find, and a wide variety of file/project management tools. We don't
have to change, damage, dumbify emacs to make it "easier" to use; we
can do a lot to make it easier to use emacs's best features.

My personal interests are (1) and (2). I've been swamped with work for
the last few months, but I'm really wanting to be able to have an
aquafied emacs for my mac. So, I have a lot of personal interest in
working on the "yet another toolkit" issue. And (2) just seems really
neat to me. 

-- 
 Brady Montz
 address@hidden