[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 15:44:17
Message-ID: 200405251244.17338.gustavo () gsbarbieri ! sytes ! net
[Download RAW message or body]
Em Terça 25 Maio 2004 01:09, Jamethiel Knorth escreveu:
> >From: Gustavo Sverzut Barbieri <gustavo@gsbarbieri.sytes.net>
> >Date: Mon, 24 May 2004 22:37:44 -0300
> >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:
> >What if you want all material about certain artist? You want every music,
> >video clip and poster/image/something.
>
> As I said, that isn't mixing searches, that's all a file search for
> something in one metadata field. The different search plugins usually
> aren't supposed to be separated if they're only that little bit different.
> That's as easy as selecting a different file type from the list in the file
> plugin.
>
> The really different ones search through completely different mediums.
> Internet and local searches are completely different. Internet finds
> content you don't have, local finds files you do have. A search plugin like
> 'yellow pages' finds local businesses, and a search like ebay or froogle
> finds products. They just don't overlap!
What about searching for an artist in p2p, ebay and somewhere else?
OK, this may be pointless... first lets try the simple one and if there are
requests to this we return to it.
> >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?
>
> This sounds to me like it's just getting too complex. What does it
> particularly solve? Grouping plugins seems unnecessary. Perhaps you can
> give an example of what it solves?
You could group file and p2p to search for files. Something in this line...
but as above, maybe let this out for now and if requested we return to this.
> >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!
>
> However, some results types take up a LOT of space. Looking at a screenshot
> of Sherlock, they have an example of how to do a search plugin to make it
> truly powerful. In a search for movie times, they show results including
> lists of movies currently showing, places showing the selected movies,
> times those movies are showing, a short synopsis of the movie, the poster
> for the movie, and a preview which can be played inside the window. Where
> would that fit into a mixed view? However, it's exactly what is wanted if
> searching for a movie listing.
OK, you made me think in something I didn't think about.
Your idea make sense, but it doesn't invalidate my idea, which was based on
Dik, that is to show different results in just one screen, like the local
files + p2p or music + video + pictures from a given artist. Or even music +
video + pictures from a given artist in both local (file), p2p and store
(amazon, ebay).
In the last one we could preset results like:
You have the following media regarding "Artist: Sepultura" in this computer:
Music:--------------------------------------------------------------
Albums:-----------------------------------------------------
[ album cover ] [ album cover ]
[ Chaos AD ] [ Refuse / Resist ]
Songs:------------------------------------------------------
07 - Orgasmatron (live).ogg
...
other files
...
Lyrics:-----------------------------------------------------
Orgasmatron
Images:-------------------------------------------------------------
Posters:----------------------------------------------------
Root Bloody Roots.jpg
Chaos AD.jpg
Covers:-----------------------------------------------------
Chaos AD
Refuse / Resist
The following items regarding "Artist:Sepultura" were found in Amazon.com
Music:--------------------------------------------------------------
Cd's:--------------------------------------------------------
Roots ($XXX) [buy now]
Songs:------------------------------------------------------
Roots Bloody Roots.ogg ($XXX) [buy now]
Videos:-------------------------------------------------------------
Ozzyfest 1996 ($XXX) [buy now]
The following items regarding "Artist:Sepultura" were found in mldonkey
...
OK, maybe there is a technical problem to recognize posters, albums, etc...
but you got the my idea on how to present information.
> I admit that there is call for a plugin which gives mixed results, but
> there should not be an attempt to forceably mix plugins which are not
> necessarily designed for it.
I agree.
> > > 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.
>
> That makes more sense. However, how does it hurt to have the options shown?
> The total options take up very little space. In the search sidebar mock-up,
> the only one to show any extra options, they take up less than 500 pixels
> in height on the largest, and usually far less. Removing them will just
> result in blank space, and the main line will still function with them
> there. I can see some use to them being hideable, but only a little. Also,
> I think the value is counterbalanced by the expense of adding the option to
> hide them, which will take up space.
The only problem I see with every option shown is not space, is about scaring
users. Maybe this doesn't happen, just tests will say.
--
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic