Chris McDonough wrote:
I've gotta weigh in here, too; the breakage induced by this change will be large. Give that what *real* users expect is *neither* a Boolean "AND" *nor* a Boolean "OR", but instead a DWIM/Googlesque "affinity" search, I don't think the win is clear enough to warrant the breakage:
I think long term, the Catalog machinery should support such "affinity" searching.
* "AND" searches return *small* result sets; non-programmers will be surprised by the often-empty lists they get back, and won't have any clue how to broaden their search. False negatives suck.
I think most people are getting used to narrowing their search by adding terms. Google, Yahoo, Lycos and the like have trained them to do this. I think the idea that folks, even nonprogrammers, don't know to do this in the post-1995 world may be a little flawed.
I rarely find myself using any explicit boolean operators when I use Google. And even when it returns 657,340,269 pages, the ones I wanted tend to be in the top 30. I think "OR" searching is fine if the result scoring can be done intelligently somehow.
Given that any site manager can override the policy trivially, using only two lines of DTML, should we really be switching the (admittedly arbitrary) existing polciy embedded in the core?
No, I suppose not. I'll change it back. :-( Not happy about it.
I still say a toggle in the Catalog management interface is the best solution. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>