[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Search dialog vs. search bar
From:       Sébastien_Laoût <slaout () linux62 ! org>
Date:       2005-02-16 14:01:14
Message-ID: 1108561299.2998.32.camel () localhost
[Download RAW message or body]

Le mar 15/02/2005 à 19:51, Jason Keirstead a écrit :
> - It is at the bottom of the screen rather than the top. This is not so bad, 
> once you are usaed to it. but if this is the first time you have ever 
> searched in this browser, and you are expecting CTRL+F or Edit->Find to bring 
> up a search dialog, it is a *bad* place for it to be. The first time the 
> introduced this new behaviour, it took me probably 2 minutes to figure out 
> what was going on (I did not see the box at all ). 

This is not so bad because it helps to not make the interface flicker
when showing/hidding the toolbar (ie. not move the page area a little
more below or a little more above).

Hum... In fact this flickering can be partially avoided: have anyone
ever tryed MS Office. Yes, a bad program, but it have an interesting
usability feature: if another row of toolbar is added on top, the
content area don't move below: it's just scrolled a little more below...

Euh... A little picture is better than a long discour:

The current way of KDE/other desktops:
 Before:                          After:
  ==toolbar1============           ==toolbar1============
  The content area with            ==toolbar2============
  some content in it, as           The content area with
  it is a content area!            some content in it, as
  That was a good name,            it is a content area!
  isn't it?!                       That was a good name,

Whole page is moved one line below: quick flickerring.

And the way of MS Office do:
 Before:                          After:
  ==toolbar1============           ==toolbar1============
  The content area with            ==toolbar2============
  some content in it, as           some content in it, as
  it is a content area!            it is a content area!
  That was a good name,            That was a good name,
  isn't it?!                       isn't it?!

The user just see a new toolbar: just this little area is changed, and
not the whole screen.

If the window is full screen maximized (a browser often is), it's a big
area that don't flicker and seem to work seamlessly.

And theorically the Firefox toolbar flash (in yellow) 5 times the first
time it is shown/used.
So, users who expected a dialog would not see it but would see a thing
flashing on bottom of theire screen and then see the toolbar.

But, yes, eyes are more often looking on top than on bottom, and all
other search bars in KDE are on top.
So, as long as it is a toolbar and I can move it on bottom myself I'm OK
to put it on top.

> - It does not automatically remve itself after you are done searching. Now, I 
> realize that it is hard to know *when* you are done searching with this setup 
> (with a dialog, you just tab to 'Close'), but IMO this is another serious 
> flaw. Basically, you can't get rid of this dialog easily once you are done 
> with the search, you need to *again* grab the mouse and click the X. Either 
> that or hit TAB a million times to reach the close button (because you are 
> searching, so the text focus is currently inside the browser window)

No: you can hit Escape to hide the toolbar!
Or (I haven't tryed) press again Ctrl+F.

And "Edit > Search..." could be replaced by a toggle button:
"Edit > Show Search Bar"
"Edit > Hide Search Bar"
Or this toggle button can just be added below the current item, so user
can choose the way he prefers.

> - Because the search is no longer a modal dialog, other modal dialogs coming 
> from the browser will **actually inturrupt the search**

Is it a problem?
Why the search should be modal?
You're trying to search a thing, you start to type some characters, the
incremental search then say you that those characters can't be found (no
need to type the whole expression and press Enter => feedback is
immediate). Then you know the page don't contain what you wanted, so you
can do anoter thing. It does nothing if the search bar is still open.
Again: if you search a link, you find it quickly with incremental search
and you can click it without closing the modal search dialog: the search
bar is hidden automatically when going to another page.

> - No way to search backwards without, once *again*, moving your hand to the 
> mouse.

Ever tryed F3 and Shift+F3 ?
Of course, it should be in the menus...
Or it should also be in the tooltips of the buttons.

Shift+F3 doesn't work with Konqueror, tough (not tryed 3.4).

And one good thing of Firefox is that it highlight results.
So, there is no more need for F3 / Shift+F3, we can see results visually
at a glance (for small pages, of course).
That's another feedback I would want to see in Konqueror too!

> Now, I am not toally against the idea of asearch bar - I really love the one 
> in KMail. but I don't think that the one in Firefox should be used as an 
> example. It is probably the worst search tool I have ever used in my whole 
> life.

At least, the Firefox bar is a better start than the current Konqueror
incremental search.

But I think we all agree (according to the other replies to this tread)
both systems (dialog and live search) should stay.
I personnaly tryed to convert some users to using the toolbar but they
returned back to the dialog.

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]