Re: [Usability] Standardizing Find and Replace windows

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Jul 03, 2003 at 12:17:08PM +0100, Calum Benson wrote:
> On Wed, 2003-07-02 at 12:40, Alan Horkan wrote:
> 
> > On Wed, 2 Jul 2003, Jeff Waugh wrote:
> > > 
> > > Would a standard Find toolbar make sense?
> >
> > Not everyone is willing to give over the screen space, a modal dialog is
> > preferable.  (There was a bug against abiword stating exactly that).
> 
> I don't know if that was a typo or not[1], but a modeless Find window is
> much more useful than a modal dialog... it's hugely irritating to find
> something and then not be able to overtype it without closing the Find
> window first :)

I disagree.

Consider just finding the next occurance of the word with the keyboard:

   Common Steps:
     Ctrl+F - dialog or window opens and text field is focussed.
     type   - each character moves the document closer to the goal

   Modally:
     Escape - dialog closes, the document is in full view,
              focus is returned to the document.

   Non-modally:
     Either:
       Alt+F4: window closes, the document is in full view,
               focus is returned to the document.
       Alt+F6: (doesn't work yet)
               focus is returned to the document
               window lies over the document, because it's transient-for
    or Alt+Tab: (works for now because groups are broken)
                focus is returned to the document
                window lies over the document, because it's transient-for

Yes, I've assumed that, no matter modality, the window should be
transient-for. The effect of this, assuming the window manager hasn't a bug,
is that the Find window stays immediately above the document for which it
is a transient. Without this, the window:
  1) takes up space on the window list,
  2) may be lost underneath the document window,
  3) may appear to be associated with another window, and
  4) doesn't minimize when the document window is minimized.

(However, Problem 4 can be corrected without transient-for. If the window sets
 its group leader as the document window, and the window manager applies
 actions on the group leader to the whole group, then minimizing the document
 window will minimize the Find window.)

In either case, you must press some keys to return to the document window
after finding what you want. With a Find dialog (i.e., modal) the path is
clear: press Escape. It's also just one key, not a combination of keys.

In either case, you must do something to get to the Find window.
If it's modal, then Ctrl+F brings it back up. If it isn't, then either
Ctrl+F, or Alt+{F6 or Tab}. (Depends on which is working that day for that
app). Without the mode, the user has more equivalent choices before him
and must take time to decide. If the user chooses once and for all to always
just use Ctrl+F, then non-modality only gives him a cluttered screen.

(And even if he's made and automatized that choice, it's still there.
 I would not be surprised if an MRI showed the decision making process
 occurs subsconsciously when the other window is visible.)


With the mouse, not much changes. You still have to move from one window
to the other. With the dialog (mode), you have to click the Stop button.
Indeed, this is a smaller target than the document window. The transience
of the window is more of an issue now. Still, if it is transient and
non-modal, it will obscure the document window. But now, if it's not
transient and thus falls underneath the document window, then the user will
have to execute eccentric maneuvers to get it back in focus: either moving
windows around, moving to the window list, or finding some still-visible
edge. The mouse path through the menus exists for both modal and non-modal
cases.

Some combination of mouse and keyboard may make the non-modal window easier
to use. But which one, and how will the user learn it? And how does that
benefit the user contrained to only one of those devices?


> [1] I presume it probably was since you mentioned the not unreasonable
> possibility of being able to dock it as a toolbar, and a modal toolbar
> would be kind of unusual :)

Not really. Gnumeric has one: it's input bar. Nautilus has one: if the
location bar is normally hidden, then Ctrl+L will show it and going on to
a path will hide it. The "Find in statusbar" proposals are basically
proposals for a modal toolbar. A modal toolbar could be done as Gnumeric's
input bar, Nautilus' location bar, or Emacs' mini-buffer. It could also be
done as an in-window overlay similar to the image toolbar of MSIE.  This
last method is my current preference, even though it obscures part of the
document. A permanent toolbar reduces the available space. A transient one
like Nautilus' requires movement of content. The statusbar version is hard
to see.

However, exactly what the alternative to a dialog should be is far from
obvious. So I refer you to my "Now and then" message:

  http://mail.gnome.org/archives/usability/2003-July/msg00019.html


Cheers,
Greg