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

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Dik Takken <D.H.J.Takken () phys ! uu ! nl>
Date:       2004-05-24 21:15:17
Message-ID: Pine.OSF.4.60.0405242229130.472409 () ruunat ! phys ! uu ! nl
[Download RAW message or body]

On Mon, 24 May 2004, Jamethiel Knorth wrote:

>> > For this to work right, all search plugins that have artist option 
>> should
>> > use the exact same name for that option. If one plugin calls the option
>> > 'Artist:' and another plugin uses the word 'Performer:', it won't work.
>
> This assumes that all plugins will be written by the KDE team, which would 
> only be true if KDE's market share stagnated.

For the moment, this assumption is quite valid. That's why the KDE team 
will create a standard for names for search options. Users will be used to 
the fact that entering "artist:Pink Floyd" will find music. If third party 
plugin developers would want to deviate from thise standards, their search 
results will simply not appear when the user uses the standard keywords.

As long as we set the standard first, others will only want to stick to 
that.

If KDE passes 5% of desktops, 
> Google will likely write a search plugin. They're already doing a desktop 
> search tool for Windows, directly competing with what Microsoft is planning 
> for Longhorn. Likewise, every P2P app out there will want its own search 
> tool.

See my argument above why this is unlikely to turn into chaos.

> That's one reason why plugins should be kept separate. Another reason is that 
> a user would have a more difficult time knowing exactly what to expect from a 
> search, since they might get results from other plugins accidentally.

Can you please give an example?

I do have some ideas to give the user more control about the search 
results, just some ideas to take your worries away:

* All plugins have a user-adjustable rating. High rated plugins are 
searched first, their results are the first displayed. Unknown (third 
party) plugins get a low default rating.

* To prevent users from having too many options and getting confused, 
users should be able to activate and de-activate search plugins. Plugins 
that are deactivated show no icon in the search application and yield no 
results. By default, KDE should offer only a minimal set of plugins.

Apart from this, I see no problem in getting more than you ask for, as 
long as the results are presented very clearly. First of all, the results 
of different plugins should be displayed seperately, like this:


The following files in your home directory match your criteria:

  file://File A
  file://File B
  ...

The following files on the E-Donkey P2P network match your criteria:

  ed2k://download link for File A
  ed2k://download link for File B
  ...



> I think it would be reasonable to allow the entire name of a plugin to be 
> given on the line, even to the point of allowing multiple searches in one 
> line. So, maybe I could give the line, "[music] foo artist:bar length:<4m 
> [files] foobar size:>20k<20m [people] baz" and get a whole lot of info I 
> happen to want all at once. But, I would shy away from just straight-out 
> mixing plugins.

I guess the 'General Search' plugin is not meant for you then. Just 
de-activate it in the settings dialog and use more specific plugins. 
Anyway, I see to fundamental problems regarding the general idea. Besides, 
I can imagine many people liking 'General Search' very much, and that's 
why we need to invent it, even when we would not use it ourselves.


> And, in the places where people expect proper results (the full program and 
> any search inside of one directory), just start with the index then do a full 
> search. So, the progress indicator in the search program might have text and 
> say, "Searching file index," and then, "File index searched, doing full 
> search," and then "Full search completed". Something along those lines.

We could implement this by introducing two plugins, one doing indexed 
search and one doing full search. Give the indexed search the highest 
priority such that it will be the first to output it's results. Other 
plugins could be temporarily de-activated when the only goal is to find 
files in a specific directory, like in the KFileDialog.

> We need to all remember that people rarely look at help, and even when they 
> do look at it they don't actually 'read it' they just 'glance at it'.

Hence my suggestion to put an attractive help button next to the query bar 
that links directly to some quick examples.

> The 
> point of search is that, without having a clue what to do, they can figure it 
> out quickly.

When you have multiple special purpose plugins at your disposal, you don't 
need to know any special commands to find stuff. If you want to search for 
music by Pink Floyd on your local harddrive, you just take the 'Find 
Local Music' plugin and enter 'Pink Floyd'. Yes, you might get better 
results by entering 'Artist:Pink Floyd' but that's only meant for the one 
who takes the time to take a short look at some query examples.

In my opinion, there is still no need for checkboxes and stuff, except 
from maybe behind a 'Advanced Search' button.

Cheers!

Dik
_______________________________________________
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]