Drupal's taxonomy system is certainly one if its greatest strengths. The ability to categorize, classify, and/or tag nodes is very powerful and theoretically should make it easy to find similar content quickly. But the "finding stuff" part has been a weakness for Drupal. There have been some recent improvements in the core search functionality and Earl Miles' excellent Views module provides a nice user interface to a complex database query engine that can be used in many different ways.
A client recently had me thinking about how to easily "drill down" in taxonomy to find nodes. Taxonomy browser has the right idea, but this module lists all taxonomy terms whether or not any content has been tagged with this term. Views module's "exposed" filters adds the ability to filter by any views-aware criteria such as node-type, author role, and a bunch of other good stuff, but again shows everything whether a filter item "contains" content or not.
Let's use songs as an example -- you're not going to find any results when narrowing down to "Techno" songs by "the Beatles" on the album "Nevermind". So when you select "Techno" you should only see artists and albums with songs in this category.
Of course, Apple has come up with an elegant user interface for this very example:
But how can we adapt this to Drupal? Again, Views' interface comes close and probably makes a great starting spot for non-AJAX backwards compatibility. By setting filters to "exposed" you get a display like this at the top of your page:
And what's more, by combining this with non-exposed filters, you can provide an interface to filter within "song" content items so that you do not need to burden the user with confusing selections like "node type". But Views suffers from the same problem as Taxonomy Browser in that there is no live feedback to let you know that your filtering will yield results.
My thinking is that a little bit of AJAX could really benefit this system. Imagine that as you click on a selection in the left column, the items in the right columns update to show only those containing content. Each column contains an "all" item at the top and multiple selections would be allowed. Well don't just imagine it. Fire up iTunes and use it for yourself. It's so intuitive that it's transparent. It just works.
In terms of the database query logic, each column represent an "AND", while multiple selections in each column represent an "OR". So if your columns are "Genre", "Artist", and "Album", then you would search could look a bit like this: (Genre = "ALL") AND (Artist = "Rolling Stones" OR Artist = "Clap Your Hands Say Yeah") AND (Album = "Their Satanic Majesty's Request" OR "Clap Your Hands Say Yeah"). Of course that's not proper SQL, but the logic is there. It's also important to note that the logic flows from left to right with each column narrowing what shows up in the columns to its right - hence the "drill down" concept. Also note that the logic for hierarchical taxonomy vocabularies would probably need to be handled slightly differently.