>one thing to keep in mind: it's typically not a good idea to have the >constraint set of a facet change just because some other constraint was >added to the query -- individual constraints might disappear because >they no longer apply, but it can be very disconcerting to a user to >when options hcange on them.... if i search on "ipod" a statistical >analysis of prices might yeild facet ranges of $1-20, $20-60, $60-120, >$120-$200 ... if i then click on "accessories" the statistics might skew >cheaper, so hte new ranges are $1-20, $20-30, $30-40, $40-70 ... and now >i'm a frustrated user, because i relaly wanted ot use the range $20-60 >(that just happens to be my budget) and you offered it to me and then you >took it away ... i have to undo my selection or "accessories" then click >$20-60, and then click accessories to get what i wnat ... not very nice.
Many of the other engines I've work with in the past did this and it was one of the most requested/implemented features we had with regard to facets. That doesn't make it 'right' but it did tend to make product managers and test users happy. The use case that often came up was the ability to dynamically drill inside ranges. For instance my first search for 'computer on a large ecommerce site might yield ranges of 0-500, 500-1000, 1000-2000, 2000+, selecting 500-1000 might then yield ranges of 500-600, 600-700 and so on. There are also many different algorithms that can be employed: equal frequency per facet count, equal sized ranges, rounded ranges, etc. - will
