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

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Gustavo Sverzut Barbieri <gustavo () gsbarbieri ! sytes ! net>
Date:       2004-05-25 1:37:44
Message-ID: 200405242237.44678.gustavo () gsbarbieri ! sytes ! net
[Download RAW message or body]

Em Monday 24 May 2004 18:48, Jamethiel Knorth escreveu:
> >From: Dik Takken <D.H.J.Takken@phys.uu.nl>
> >Date: Mon, 24 May 2004 23:15:17 +0200 (CEST)
> >
> >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?
>
> Your example. artist:foo. On my system, this accurately applies to: images,
> videos, and music. There are reasons for having a video search plugin,
> music search plugin, and image search plugin. artist:foo would still get
> the correct results, but only because it would cause the file search plugin
> to check metadata field "artist" for contents "foo". There is no call to a
> separate plugin involved.

What if you want all material about certain artist? You want every music, 
video clip and poster/image/something.
	
I have another (yeah yet another!) idea: the framework should be able to group 
plugins. This way we can have a "All" which groups every active plugin, 
"Media" which search music, images and videos, "Documents" which 
searchs .doc, .txt, .sxw, ...
	What do you think?


> >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.
>
> A problem here is that the results are not always mixable. Not all results
> are just directories. The file search plugin just gives the files. The
> image search plugin will want to return a bunch of thumbnails. The internet
> search plugin gives a title and the snippet which matches the search terms.
> The people search plugin may want to give name, address, phone number,
> email, and have a map field which shows location of the currently selected
> results. The plugins are not always mixable, and making them forceably
> mixable would castrate the more powerful plugins.

Maybe we should come with another view mode for searches... something that use 
"Sections" and each section can display different modes and an easy way to 
navigate through Sections.
	So "Image Section" will show images as thumbnails, "Document Section" would 
show title, author, date and some excerpt in the case of content search. 
"Music" could be just the name, ...
	Section names should be based on Groups of Groups, Groups and individual 
plugins.
	All of this in the same result window... maybe the background color can 
change... but I REALLY like this idea!


> >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
> >  ...

This fit my Section idea! 


> There is room for a "search everything" plugin, but there is a lot of
> reason to not have the system just keep on searching beyond where you asked
> it to. This can be horrendously slow. Searching is a very intensive
> process, often. On my system, doing edonkey searches at the same time as
> any other large amount of work causes noticeable slowdown. Same for local
> file searches, although less-so.

Yes, this may be a problem... however as computers go fast we can have this... 
I know, what about the older... well, disable these plugins.


> >>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.
>
> I'm fairly certain that my examples had all the complex options hidden. In
> the search sidebar, the ones with the most which I did mockups for were the
> local file search and the yellow pages search.

[snip]

> I don't know what else you want hidden behind an advanced options tab.

Think that as "More Options" (Or "Show Every Option"), not "Advanced Options". 
It could be a state widget and it should remember the last state. We start 
withy "More Options" ON, if one knows how to search without it, he can turn 
it OFF.


-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsbarbieri@jabber.org
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
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]