Amarok/Archives/Proposals/FuzzyFilter: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 8: Line 8:
I tried to implement a mechanism to make the existing filter work in a fuzzy way, following these requirements. For the flat view in collection browser, it now works more or less...
I tried to implement a mechanism to make the existing filter work in a fuzzy way, following these requirements. For the flat view in collection browser, it now works more or less...


But now I decided to give up (not without having learned something, see below)
But now I decided to give up (not without having learned something, see below)
 
=why I gave up=
1.the filter mechanism of amarok is quite powerful (OR, AND, field specifications, exclude, greater than/less than, scope(to which fields does the filter apply)), whereas a fuzzy search as envisaged is much more simple (no AND/OR needed, no exclude, no greater than/less than, fixed scope (artist, title, album))
#Requirement 3: how would you interprete a complex search term such as "enya OR enia AND album:"memory of trees" score:>60?
#such a search term may not make sense for the normal user, but it is possible with the current filter, so it has to be interpreted in some way when operating fuzzy
2.scope: on which fields does the search operate?
#in the current filter that depends on the view (tree vs. flat), on the visible columns and on the filter (comment:bla)
#I think the scope is sometimes not even transparent for a normal user (for a power user: yes, and for complex queries it is even needed) or he has to take care of being in the correct mode and having the correct columns visible to find items
        a fuzzy search for its primary use case should operate on artist, title, album (maybe comment). not more, not less.
    performance problems
        due to the fact that the filter is so flexible, but fuzzy filtering cannot be done with SQL constructs, in some (not even absurd) cases the database query results in 50.000 results which now have to be filtered by the fuzzy algorithm => resulted in 5-60 seconds on my 3500 songs collection (highly depending on the scope, see above)
    implementation/documentation problems
        implementing it was harder than expected, although it is less than half finished (in tree view it becomes even more complex than in flat view)
        due to the complexity of scope and search constructs, documenting this feature would not be easy (which parts of a complex query are interpreted fuzzy on which scope...), although fuzzy search can be implemented in a really self-explanatory way
    ordering of results
        when filtering, the ordering should not be affected by the filter
        in fuzzy mode, the results should be ordered according to their match factor
    tree view is good for browsing, but often not ideal for presenting search results (you may have to open up nodes before you see the relevant results)
 
=> from all these points I learned that fuzzy search and collection/playlist filter can not be merged easily into one thing
 
=> my consequence (oN) would be to add fuzzy search as a distinct, self-explanatory feature (as envisaged in my first attempt)

Revision as of 18:41, 10 January 2013

making the current filters work in a fuzzy way

Requirements

  1. should work on both the collection browser filter (both in flat and treeview) and the playlist filter
  2. a slider could determine the grade of fuzzyness in 3 or 4 steps (eg. exact - slightly fuzzy - very fuzzy )
  3. should work as close as possible on the current google-like filter syntax (so you can first search in an exact way, and then "widen" the search by increasing the fuzzyness)

I tried to implement a mechanism to make the existing filter work in a fuzzy way, following these requirements. For the flat view in collection browser, it now works more or less...

But now I decided to give up (not without having learned something, see below)

why I gave up

1.the filter mechanism of amarok is quite powerful (OR, AND, field specifications, exclude, greater than/less than, scope(to which fields does the filter apply)), whereas a fuzzy search as envisaged is much more simple (no AND/OR needed, no exclude, no greater than/less than, fixed scope (artist, title, album))

  1. Requirement 3: how would you interprete a complex search term such as "enya OR enia AND album:"memory of trees" score:>60?
  2. such a search term may not make sense for the normal user, but it is possible with the current filter, so it has to be interpreted in some way when operating fuzzy

2.scope: on which fields does the search operate?

  1. in the current filter that depends on the view (tree vs. flat), on the visible columns and on the filter (comment:bla)
  2. I think the scope is sometimes not even transparent for a normal user (for a power user: yes, and for complex queries it is even needed) or he has to take care of being in the correct mode and having the correct columns visible to find items
       a fuzzy search for its primary use case should operate on artist, title, album (maybe comment). not more, not less. 
   performance problems
       due to the fact that the filter is so flexible, but fuzzy filtering cannot be done with SQL constructs, in some (not even absurd) cases the database query results in 50.000 results which now have to be filtered by the fuzzy algorithm => resulted in 5-60 seconds on my 3500 songs collection (highly depending on the scope, see above) 
   implementation/documentation problems
       implementing it was harder than expected, although it is less than half finished (in tree view it becomes even more complex than in flat view)
       due to the complexity of scope and search constructs, documenting this feature would not be easy (which parts of a complex query are interpreted fuzzy on which scope...), although fuzzy search can be implemented in a really self-explanatory way 
   ordering of results
       when filtering, the ordering should not be affected by the filter
       in fuzzy mode, the results should be ordered according to their match factor 
   tree view is good for browsing, but often not ideal for presenting search results (you may have to open up nodes before you see the relevant results) 

=> from all these points I learned that fuzzy search and collection/playlist filter can not be merged easily into one thing

=> my consequence (oN) would be to add fuzzy search as a distinct, self-explanatory feature (as envisaged in my first attempt)