Re: Search keyword dialog box in Mosaic 2.0pre0?

Tony Sanders <sanders@bsdi.com>
Errors-To: sanders@bsdi.com
Errors-To: sanders@bsdi.com
Message-id: <9307221640.AA03569@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Search keyword dialog box in Mosaic 2.0pre0? 
In-Reply-To: Steve Putz's message of Thu, 22 Jul 93 08:46:04 PDT.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Thu, 22 Jul 1993 11:40:10 -0500
From: Tony Sanders <sanders@bsdi.com>
Status: RO

> > Having to go through the extra step of opening the dialog box
> > before typing in a keyword seems a bit extraneous to me
> 
> I agree.  I have some applications that make heavy use of the search
> keyword feature.  It is already a problem for many users that the mouse
> must be inside the small search keyword box for type-in.
> 
> I would prefer the old style, and it would help if all type-in to the
> document area is directed into the keyword box.  I am willing to lose
> the menu keyboard short-cuts.

Hmm, I sort of agree with you but I don't want to lose the keyboard
short-cuts.  Some heavy UI thinking needs to be done to make this work
right.  Having a short-cut ('/' maybe though I wish that were search) that
warps the mouse in to the keyword field would be ok with me.  Note also
that NCSA Mosaic does have:

warpPointerForIndex: Boolean 
   If true, the pointer will be warped to the keyword entry area when accessing a
   searchable document.  (Since NCSA Mosaic is point-to-focus, this automatically
   gives input focus for searchable documents.) Default is false.  

(which can be annoying sometimes so I don't think it's the right solution
but it's nice as an option)

Also, I agree with a previous comment about having words highlighted that
appear in the "search keyword" box.  I sort of believe this is the
responsibility of the server though because the data in arbitrary
and the browser wouldn't always get it right.  This means we need a
new style <EMPH TYPE="keyword"> that means this is only important
as the result of a search.

It does seem odd to have two search dialogs and I would be interested
in efforts to unify them.

Maybe a group can splinter off and brainstorm some at the Workshop
about how to do the UI for these features.

--sanders