KDE Search Widget

Sat Jan 22 12:16:20 GMT 2005

On Saturday 22 January 2005 7:53 am, Ingo Klöcker wrote:
> On Thursday 20 January 2005 22:44, Benjamin Meyer wrote:
> > On Wednesday 19 January 2005 5:41 pm, Ingo Klöcker wrote:
> > > On Wednesday 19 January 2005 03:51, Benjamin Meyer wrote:
> > > > Here is an idea for a search widget.  The KSearch widget contains
> > > > two widgets, the clear button and the combo box.  The combo box
> > > > supports the ability to list different searches or sub searches
> > > > which the user can choose by clicking on the icon.
> > > >
> > > > The search on the left doesn't have a menu when you click on the
> > > > image while the right does.
> > > > http://www.icefox.net/kde/ksearch/ksearch.png
> > > >
> > > > Source and demo application
> > > > http://www.icefox.net/kde/ksearch/ksearch.tar.bz2
> > > >
> > > > So for example KMail rather then having a whole Quick Search line
> > > > would just have this one widget in the toolbar.  Rather then
> > > > having a Status drop down box it there would be a dropdown when
> > > > you click on the search image allowing you to specify a specific
> > > > quick search. Clean, takes up not much space and is easy to
> > > > recognize.
> > >
> > > I don't see any advantage over KMail's current Quick Search. In
> > > fact I only see disadvantages. Remove the "Search:" label? Why?
> >
> > Because there is a search image.  Why take up all the room of a word
> > when you can use an image which is easier to recognize by a scan of
> > the screen?  Also the search is suppost to always be on the screen
> > (i.e. the point off a quick search) so you don't want it taking up
> > much room, removing the word saves some space.
>
> How many characters do you type in KMail's search? My maximum was well
> below 10 characters. So the space the "Search:" label uses is
> completely irrelevant because here the search line edit is wider than
> 40em. I don't think using a tiny icon instead of a text label will
> improve usability.

I think it would improve usability even if you left the Search text there for 
the simply fact that you don't have to read an image, just view it.  Seeing 
the little search image in the upper part of the screen you will instantly 
know what it is.  Also if every application has it they will most quickly 
recognize that KDE has searching built in (kinda)

> > > And what if somebody wants two dropdowns additionally to the line
> > > edit?
> >
> > Getting kind far away from the whole "Quick" search idea don't you
> > think?  99% of the time the user wont even bother with any dropdowns
> > that are present today.
>
> Yeah, right. Did you make a study about this? Or are you just making up
> those numbers? I refuse to make up any numbers.

Sorry, yes I shouldn't have said 99%.  I pestered some friends who use KMail, 
but that doesn't count.  Also those websites that show what people are 
currently searching for kept coming to mind.  My bad.

> Therefore, all I can 
> say is that I use the Status drop down in KMail far more often than the
> Search line edit. I have to admit that my searching for New/Unread is
> mostly due to the fact that KMail still sorts threads by the date of
> the thread root instead of by the date of the newest message in the
> thread. But I also quite often look for important messages.
>
> > If way to many of the people who search the
> > billions of documents using Google only put in 1 word what makes you
> > think they will do any more then that for some application with their
> > 1000 photos?  If you have more then one drop down then you start
> > turning into a full featured search dialog and if a user is going to
> > go through that effort why not  just pull up the real search dialog?
>
> Okay, I agree. I withdraw my comment about two dropdowns.
>
> > A far better choice is what Juk did and on the right hand side have a
> > button for the real search dialog.
> >
> > > Hide the Status drop down inside the search?  Who is going to find
> > > it there?
> >
> > That goes with a few different ideas.
> >
> > One: this is a quick search.  It should be present all the time by
> > default and thus take up the smallest amount of room on the screen.
>
> "Yes" to the former, "Not necessarily" to the latter. I have a serious
> problem with your proposal to put the quick search in the toolbar.

Just to re-iterate (for the third time in this thread) I am not advocating 
where to put this.  I like both the toolbar and above the lists.  I am trying 
to advocate a simpler *consistant* search look that users will be able to 
quickly recognize.

> The 
> problem is that currently the placement of the quick search in
> KMail/JuK (directly above the message/song list) makes it immediately
> clear to the user that the quick search influences the list view. The
> quick search in Konqueror OTOH is something fundamentally different
> because it doesn't influence the view. Instead it initiates a search on
> the web.

Well actually you can have it search the page by clicking on the Google button 
and selecteding "Find in this page".

> So we are in fact talking about two completely different 
> things:
> - The quick search in Konqueror.
> - The quick search in KMail/JuK which is more a view filter than a
> search.

Very good point.  The two generalized would be:
-Searches for entire window
-Searches on list inside main window.

> Another quick search is in KAddressBook. It's also a view filter. It
> consists of a lineedit + a "where to search in" dropdown (which is
> superfluous IMO) + a "Filter" dropdown (which makes it easy to filter
> for categories and is very useful IMO). Hmm, in fact KAddressBook
> doesn't even seem to have an advanced search dialog. I guess that's why
> there's this "where to search in" dropdown.

Yah KAddressBook is an interesting case.  Its search goes the entire length of 
the application and looks *very* similar to a toolbar (and frustrated me to 
no end when I first tried to hide/move it), but really doesn't go with the 
list, but all the widgets.  Would this be a case where it should be in the 
toolbar because it modifies the entire window?

> > Two: The majority of users, the majority of the time wont filter
> > their search even when it is in front of their face, but will just
> > keep putting in one word searches until they find what they want (or
> > maybe even _two_ words). The status/filter/etc options are advanced
> > search options...
>
> The status option might be an advanced search option but (based on
> personal experience) it's far too useful to be removed.
>
> > Granted if this was to be used on one application it is kinda silly
> > to do that as most users wouldn't know about it.  But if it was used
> > as the basis for all the search widgets in the majority of
> > applications then advanced users would quickly know that if they want
> > options that is where it is and for the rest of the world, they
> > wouldn't care.
> >
> > The key idea is that it is a quick search.  It should always be
> > present, easy to use and take up little to no room on the screen.  If
> > I was able to figure out how to get the Clear button inside the line
> > edit I would advocate that, as it is simpler.
>
> Can you post a screenshot of this? I can't imagine how a clear button
> inside a combobox lineedit with an icon on the left can be anything but
> confusing.

It was actually my wife (who has a iBook) who pointed this one out to me on 
her laptop a simpler way.

Empty search widget: 
http://developer.apple.com/macosx/tiger/images/saved-search.jpg
Search widget with text in it and clear button:
http://images.apple.com/ilife/iphoto/images/organizesearch20051011.jpg

At first I thought it was bad design to have the button show/hide like that, 
but after playing with it for ten minutes I was most impressed with the 
design.  It was clean and intuitive.  When the box was empty I don't need to 
clear it so why present that option to the user?.

Taking small steps would anyone object if I only added the search icon to 
KListViewSearchLineWidget and KIconViewSearchLineWidget?

-Benjamin Meyer

-- 
aka icefox
Public Key: http://www.icefox.net/public_key.asc