In this article I described how important the scoring factor settings are in ranking search results. I also demonstrate that it is useful to have the scoring factor controls available directly in the advanced search form. This allows users to decide for every search whether recency, number of comments, page views, or keyword relevance is most important to them. Since these values are only applied at search time, not when the index is created, there is no performance overhead for exposing this feature. If the user doesn't choose to use the feature, the administrative defaults are used.
This patch takes the approach of storing the values in the user's session between the two requests, and deleting the session values when the search is actually run. This makes it so that the search URL doesn't become polluted with scoring factor query information, but also makes it so that bookmarking such a search will not capture the scoring factor information. This point is open for debate and I'll be happy to rewrite the code if it is deemed better to have them in the query string (in fact, that is how I initially wrote the code).
The patch is currently rolled against D5, so it will probably need to be re-rolled for D6.
Comment | File | Size | Author |
---|---|---|---|
advanced-search.patch | 5.64 KB | robertDouglass | |
Comments
Comment #1
dmitrig01 CreditAttribution: dmitrig01 commentedWell, we would need an admin setting
Comment #2
Steven CreditAttribution: Steven commentedHmm, I think we should consider encoding them in the URL. This could be done using a score:1,2,3,4 syntax or something. This is how the other search stuff works at the moment. The only problem there is again the conflict between the form controls and the text box. It's a hairy problem.
The tricky part is that for some things (like phrases or or), there is no reverse mapping from an arbitrary query string back to the controls. So, we have to clear these boxes after inserting the result in to the keyword box.
However, for terms and type restrictions, we could really remove these from the text box and fill out the form options correctly. The same could be done for the search results. This would keep the URLs clean and readable, while keeping the form as usable as possible.
Of course this could be considered a bit outside of the scope of this patch, but as we pile on more search features, this rapidly becomes an issue. Any takers?
I'm also thinking it should be styled better/more compact. Maybe even some jQuery slider magic like MSN search had at one point.
Comment #3
Dries CreditAttribution: Dries commentedPersonally, I'm not convinced that we want to add this functionality. Do we really have to expose this level of control (and internal details) to the user? Shouldn't the search "just work"?
In general, I'm +1 for advanced filters (like we have now) but -1 for controls that manipulate the order of the search results.
What the article tells me is that we might want to change the default scores.
Comment #4
Steven CreditAttribution: Steven commentedDries: yes, it is a bit of cruft, but on the other hand, this isn't that much of a change. It's just some numbers internally that change. With the right UI (e.g. sliders) and the right search data set, this can be a very useful feature.
Hacking it in via a module is kind of hard, because the node search is not extensible that way. These weights appear in the SQL query that calculates scoring... it woud be piling abstraction layer upon layer upon layer already, and too much would slow down performance or result in insanely complicated UIs. If we had a more robust query builder in core, this would be different, but that's no reason to work on this today.
Improving the default set of rankings is a different issue and in fact applies to all scoring factors in search module. The weights given HTML tags are purely arbitrary for example and based only on intuition and minimal testing.
For me, this can go in, provided it is improved as suggested.
Comment #5
robertDouglass CreditAttribution: robertDouglass commentedI would suggest that (as a separate issue) we boost the keyword relevancy to 7 or 8 by default.
Steven, do you have a slider that I should use?
Comment #6
yan CreditAttribution: yan commentedI definitely want to support the idea of this issue. Beeing able to control the output of search results in my opinion is really important for users. Maybe not for all of them, but when I visit a website that doesn't offer this option, I like it less.
Comment #7
Dries CreditAttribution: Dries commentedMoving to D7.
Comment #8
coupet CreditAttribution: coupet commentedWe could try the following:
Sort search results (descending to ascending, or vice-versa) by clicking on the currently selected column header. as follows:
Relevance, Activity, Rank, Date published, Latest Comments, # of Comments
Comment #9
birdmanx35 CreditAttribution: birdmanx35 commentedNo surprises here, but this fails against Drupal HEAD:
$ patch -p0 < advanced-search.patch
patching file modules/node/node.module
Hunk #1 succeeded at 1219 with fuzz 2 (offset 352 lines).
Hunk #2 FAILED at 1240.
Hunk #3 succeeded at 1875 (offset -663 lines).
Hunk #4 succeeded at 1932 with fuzz 2 (offset -663 lines).
1 out of 4 hunks FAILED -- saving rejects to file modules/node/node.module.rej
Comment #10
douggreen CreditAttribution: douggreen commentedLIVE FROM THE MINNESOTA SEARCH SPRINT, I agree that some minimal UI for sorting within a results set would be helpful. This needs to be re-rolled, but should wait until #145242 is committed.
Comment #11
alexanderpas CreditAttribution: alexanderpas commented#145242: refactor search node_rank with hook_node_rank scoring factors has been fixed.
Comment #12
geerlingguy CreditAttribution: geerlingguy commentedI patched—ahem—'hacked'—Drupal core to rank results by Date. This is something that, imo, should be a link that a user has exposed on the default search page... along with other options for sorting.
You could just have a block that an admin could enable for the search page with the following:
Sort search results by:
-keyword
-date
-number of comments
-etc.
Heck, you could even have the options be in a checklist, so the admin can choose which sorting rules are allowed. This would improve Drupal's search results a ton.
Another +1 if you can let the administrator choose the default sort by date...
Comment #13
yan CreditAttribution: yan commentedActually that already is implemented: Just go to admin/settings/search and you can change the priority where it says:
This discussion here is about exposing these settings to the user.
Comment #14
geerlingguy CreditAttribution: geerlingguy commentedYan - true, but it would be nice to also have the ability to set the default sort by date (maybe adding that as one of the sortable options with a weight in the admin interface).
Comment #15
geerlingguy CreditAttribution: geerlingguy commentedYan - true, but it would be nice to also have the ability to set the default sort by date (maybe adding that as one of the sortable options with a weight in the admin interface).
Comment #16
yan CreditAttribution: yan commentedgeerlingguy, don't you see the three options "Keyword relevance", "Recently posted", and "Number of comments" there? Just set "Recently posted" to 10 and the other two to 0 and the search results should appear sorted by date (descending). The settings are very limited but at least basic options are available.
Comment #17
geerlingguy CreditAttribution: geerlingguy commented@ yan - I had that set, but it still didn't sort by date first, then other rankings... I had to modify node.module to add a sort to the search, and even then, it's not easily configured (except by me). If, during the search, there was a "Sort by Date" link somewhere near the top, that would be quite nice.
Comment #18
sun.core CreditAttribution: sun.core commentedComment #19
jhodgdonI'm moving this to the search queue, since it's a search feature (and yes I realize it's currently in the node module, and node-search-specific, but I am hoping in Drupal 8 to decouple node.module's search stuff out of node.module and search.module)... we'll see. Anyway, Iam trying to keep all search feature requests together. Hope that is OK.
Comment #20
jhodgdonSince 8.0.x-beta1 has been released, our policy at this point is No feature requests until 8.1.x. See #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Sorry, it's just too late for 8.0.x at this point, so even if we had a viable patch, the core committers would not commit it.