We had MultiSearch through CSA: http://www.csa.com/e_products/MS_main.php, though I’m not sure of the exact version (or even if there are multiple ones?). I tried calling a colleague of mine in our other library, our electronic resources librarian, but he must not be around. I can find out for you later on that one.

Anyway, there are multiple reasons we all didn’t like it, some like I said before, but I thought of another reason. When students would click “Search,” either from the little search box we had on the library homepage or in MultiSearch directly, MultiSearch had the stupidest way of stating that the person had Zero results while MultiSearch was fanning out to actually get the results. It didn’t state that the results were pending or anything, but while it was going to get the results it would just say that you found zero, so instead of waiting for more results to appear, students would click back to the search thinking they had to redo their search, not knowing that it just took a bit for the results to actually appear. So, maybe this has been changed now, who knows, but students weren’t sticking around to use it because it wasn’t as quick at retrieving results as just going directly into a database. It wasn’t extremely slow, but just not as fast as directly using a certain database, and you know how most students want the results ASAP.

Do you mind sharing what Federated tool, and when/what version? (just want a fully stocked toolkit of armaments!)

The thing is, students rarely go past the first page of results, so they’re maybe not even getting to what is really relevant for their topic. And, we teach students that if you get a lot of results when you do searches, you need to re-do your search terms and re-do your search to find a more narrow, focused set of results. What does it say to them when we then have a federated search that retrieves them thousands and thousands of results?

And, you are completely right, it does not help with information literacy where we try to get them to independently think about what sources to use based upon what they want.

Giving them what they want in terms of research isn’t the best all the time. And, just because they are the generation growing up with Google still doesn’t mean they know how to correctly even use Google. They don’t know complicated searches, that are sometimes needed for in-depth research in library databases, so breaking down research to make it seem like it’s as easy as Google is silly.

So, yes, we got rid of our federated search because it sucked…and we got no complaints that it was gone.

As for the decision making process (and this is why I put my name as Anon.), we are currently not involved in it for the most part. We have a new dean and she just does things. If we’re lucky she tells us about them before they go live. We had about a week’s notice with the federated search. And since it went live two weeks before the start of the semester we had little time to work out any bugs or become familiar with the interface ourselves. There’s been no request for our feedback on this or many other decisions, and if we do give feedback it is usually disregarded or belittled. So I guess you can be glad that at least you are having discussions, even if they have a predetermined assumption.

1. Federated searches only do sloppy searches of external indexes. The lowest common denominator (lcd) is used. I’ve been told otherwise, but my test searching in my FedSearch product shows lcd results for each database configured.

3. Google-like searches will not work on dispersed indexes. A true federated search needs centralized indexes for better searching. I would much prefer to be able to NCIP the indexing data, insert it into my own app, and crunch the search myself — providing referring links back to the vendor for content. Faster, easier, *cheaper, by far, for the content vendor,* and a better experience for my users.

6. Arguably, that particular “feature” is fixed. With that said, my experience is that when I want to automagically concatenate all the results from a particular search across databases into a de-duped single list *only the first 10 results from each database are included in this list.* I’m sure that number is configurable these days, but a local index would do it faster, better, and without the arbitrary results cap.

Corrections to my possible misperceptions are welcome. These are only my grumpy deductions from observed phenomena.