Skip to main content

From Amarok Wiki

Contents

Screenshots

To get an impression of what I am thinking of...have a look at how I implemented it (as a fourth tab in context browser, which is not an option):

  • Screenshot 1
  • Screenshot 2

Discussion

Some aspects that I would like to have discussed (or at least documented) before integrating the new search interface:


Does the amarok team want this feature to be integrated?

  • + fuzzy search is quite a powerful feature demanded by some people (see the links below)
  • + I (oN) have made very positive experiences with such a feature in Yammi, for both power users (who can access an arbitrary song within less than 5 seconds) and unexperienced users (who quickly get comfortable with the way the search feature works)
  • - it's another feature, so it does make amarok's interface more complicated

There seem to be different people requesting this feature, see for example

=> after using Yammi for quite a while I can't live without a fuzzy search anymore, so I want it to be integrated (oN)

Where do we want the search interface?

  • merge it into the music tab within the context browser
    • introduce another "mode" into the music tab:
      • standard mode: "current track mode": context info for current track (default, always updated when played track changes)
      • already existing: "statistics" when no track is played
      • already existing: "related artist mode" when clicking on related artists
      • new: "search mode": search results when search term is entered
    • + all modes use the same look'n feel and allow pretty much the same interactions via drag'n drop or context menu
    • + for finding and enqueuing songs, user does not necessarily have to switch to other than the context tab
    • + from search results, you could also jump (eg. via context menu) to lyrics (found track) or wiki tab (found artist), that would allow to access this info without playing that track (you could even show the info normally shown for "current track" for one of the found tracks
    • - when in search mode, user has to switch back to current track mode manually (you don't want to automatically switch mode on track change when user is just about to look at the search results)
    • - introducing another mode makes the use of the music tab more complicated (but more powerful)
  • merge it into the collection sidebar, maybe besides "tree view" and "flat view" as "smart view"?
    • - fuzzy search may in future not only be limited to the content of the collection
    • - filter term is interpreted in a quite different way in tree/flat view vs. smart view
  • additional tab "search" in sidebar => not an option
    • - space in sidebar is also expensive, 5 tabs already enough
  • additional tab "search" in context browser => not an option
    • + search interface has same visual appearance as context browser
    • + technically easier to integrate there (but that should not be the main reason)
    • - strong objections against introducing another tab in the context browser

=> I think I'm getting more and more in favor doing it the latter way... (oN)

=> I'd say either on the Music Tab, or on a tab on Collection Sidebar. We don't want to add new tabs to Context Browser, we used to have four (after adding wikipedia support), and it wasn't very good. (Untouchable)

=> I'd vote for the Music Tab in the context browser as a search feature there would make it unnecessary to use the collection browser at all. When nothing is playing, I suggest Music Tab to show a search line together with recent additions/changes in collection. And of course everything should be able to be clicked and cause appropriate action like browsing or playing. I'd also like the Music Tab to have a line of buttons at the top (just like Lyrics & Wikipedia) to browse back/forth, switch to context for current track, to search, ... (aumuell)


implement as Qt widgets or as HTML

  • Qt widgets
    • + faster "rendering" of results
    • + all power and flexibility of the Qt widget set + subclassing
  • HTML
    • + same look and feel as in context browser
    • - slower to render results
    • - sometimes ugly to code
    • - interaction limited to what is possible with KHTML (but context browser works alright so far, doesn't it?)
    • + skinnable
    • + easy to add new search modules
    • + possibility to include html code without interpreting it first (eg. from google music search)
    • + scripts or web interfaces could make easy use of the HTML search results page
    • + reuse of the code fragements of the context browser

=> the prototype shown in the screenshots was done with HTML in relative short amount of time


Show the match factor or not?

ie., if an entry matches 90%, we can use the same bar which is used for visualizing the rating of a song, as can be seen in the screenshots for search module "artists"

  • - could be confused with rating of song
  • - gives no real information, just unneeded clutter (it's only important if the song is found or not, imho) --Tony 12:26, 3 January 2006 (EST)
  • + gives quick feedback about how close the found matches are

=> I'm indecisive about this one (oN)

=> IMO it should be shown, but in a different way than score and rating. (Untouchable)

=> Maybe use color coding. Green to red backround, or maybe barcharts like this idea in the new Excel: (stepz) http://www.isamrad.com/dgainer/3_12-20-2005_thumb.png

short cuts

  • keyboard shortcut to go into and clear the search field
  • possibly a global shortcut, which also opens the amarok window when it was minimized or in the panel
  • a dcop call?


use cases

Fuzzy search is necessary when you don't know the exact name of the artist/album/track you want to find (when you do know one of these things, it's easy to browse the related info with the existing collection browser).

But often you only remember pieces, like in the following use cases (maybe take these as reference when measuring performance?):

  1. Wasn't there an artist that you liked called "arrowsmith"? => finds artist "Aerosmith"
  2. I heard a song today called something like "oios asi", I don't know who sang it => finds song title "Ojos Asi"
  3. What was the name of that album, something like "ab gehts"...ah, can't remember the name of the group now => finds album "Jetzt Geht's Ab"
  4. The song must be called "rides like the wind" or similar => finds song title "She's like the Wind" (and also the song title "Rides like the wind", but I was looking for the other one)


Search modules

Ideas and/or implemented search modules, with some measurements how long they took on my machine (oN, I think it's an Athlon 2400+) - just to get an idea

track title

  • status: implemented
  • results: list of tracks
  • actions on results: track context menu, draggable (like in Music tab)
  • performance measure: arrowsmith, 3500 songs: 0.23s

artist name

  • status: half implemented
  • results: list of artists, each artist a collapsible list of tracks (TODO)
  • actions on results
    • on artist: context menu (TODO):
      • lookup artist on wikipedia
      • enqueue all songs of this artist
    • on track: usual track context menu + draggable
  • performance measure: arrowsmith, 3500 songs: 0.14s

album name

  • status: implemented
  • results: list of albums (with covers), each a collapsed list of tracks
  • actions on results: album context menu + track context menu
  • performance: arrowsmith, 3500 songs: 0.057s

streams

  • status: idea

playlists

  • status: idea

lyrics

  • status: idea
  • results: list of tracks whose lyrics match the search term

internet

wikipedia, ITunes store, google music search, ... => probably not fuzzy

  • status: idea


Configuration

I would like to make that feature available without introducing another configuration option...

Some things that *could* be made configurable: (but I hope that we can find reasonable defaults)

  • threshold for showing entries (per search module)
  • maximun number of entries to show (per search module)
  • which search modules to acitvate (this could be the same way as the context menu to enable/disable the sections in music tab)


Technical things

  • any performance issues? (on my machine with 3500 songs it's less than a second, but someone should do some more extensive tests)
  • how to submit the patch
  • Idea: refactoring (parts of) HTML rendering into a separate class (to make it better reusable and maintainable)
Retrieved from "http://www.amaroklive.com/wiki/Amarok_1.4/Proposals/New_Search_Interface/New_Search_Interface"