increasing the usability of search dialogs

[Kurt Pfeifle]

On Monday 15 May 2006 15:14, Luciano Montanaro wrote:
> On Monday 15 May 2006 09:05, Thomas Zander wrote:
> > On Saturday 13 May 2006 10:15, Marc Schoechlin wrote:
> > > mozilla-firefox is not in general a masterpiece of usability - but I
> > > really like the search-dialog of this program :-)
> >
> > I do remember a thread on kde-usability showing how badly this 'dialog'
> > of firefox actually performed in the real world.  Its nice for
> > developers, but most people didn't get it.
> 
> I think I started that thread... I still think people *do* get it 
> eventually. Especially if it's used pervasively. It has a steeper learning 
> curve, but it has its advantages. And since it has been in firefox (and 
> konqueror) for a while, there may be users who could prefer to use the same 
> interface elsewhere. 
> 
> Actually, API wise, the windowed panel and the docked panel should not need 
> to differ. And we don't really want both the "Find" and er.. "QuickFind" 
> item in the menus. So, if the windowed interface is to be mantained, I'm 
> afraid the user will have to make the choice through a global option.
> 
> By the way, I understand to a point the aversion for more global options, 
> but if with a number of global options we could reduce the overall number 
> of settings, wouldn't it be an improvement, on the whole? 
> 
> >
> > > Positive aspects of the firefox search dialog compared to the common
> > > look of a search-dialog in kde:
> > >
> > > - It does not use a separate search-window. This is very useful
> > >   because in most cases the first action after entering a
> > >   search-pattern is to relocate the search dialog to a position
> > >   which doesn`t overlap the text-block which should be examined.
> > > - It supports "highlighting" of matches.
> > >   In my point of view this is very user-friendly, because this
> > >   eases the user`s eyes to identify matching strings.
> >
> > Funny you point those out as different to KDE since in KDE those things
> > certainly are already solved.
> 
> Well, we could say it's solved for konqueror, but the implementation is not 
> as good as the firefox one: it's hardly discoverable (you have to know the 
> shortcut, which is not in the menu), and the feature activation is not even 
> as evident as the firefox implementation. 

Yes; the FF implementation has the easy to discover options to enable
"Highlight all", "Match case", "Find next" and "Find previous". (This
assumes you know at all how to start the search in the first place.)

However, what stands out most, is that you can more easily correct 
typos in your search string, since it is a visible editable field.

If I mistyped the very first character, in FF the backspace empties
the search field and keeps it open for a few seconds so I can re-type.
In Konqui, using backspace to delete the first character immediately
disables searching (message displayed is "Find stopped." To restart it,
I need to hit "/" again. At least some kind of short timeout should
keep the option open to re-type the search string, like in FF.

> Oh, there is also KPDF that has a similar feature. Again different 
> implementation. This one has the advantage that the search box is somewhat 
> more evident. 
> 
> In the end, we have at least three UIs for the same basiv feature, each one 
> with different limitations and highlights. 
> 
> Luciano

Cheers,
Kurt