Wednesday, September 06, 2006

SFX integrated in search results

Yes, another TICER-inspired post! FastSearch's Bjørn Olstad made a few interesting remarks in his talk. One of those I heartily agree with: search results should be rich enough so the user won't have to open each line to see if it is actually what he was looking for.

This, now, is where OpenURL resolvers such as SFX can shine. As currently implemented, SFX is Yet Another Button, a separate action - and thus a burden to the user. I don't have the statistics handy of UvA-Linker (the name we gave to our SFX - by the way, why does everybody have to give SFX its own name? It's very unhandy in spreading the word to users. But I digress.) I know we had to upgrade our server hardware, so it is used; however, I am positive it is still not used as much as it could, and that's a bloody shame, for it has so much potential.

And then, if the button is clicked, the services offered are pretty boring. Useful, sometimes; but not inspiring. Why offer links to google and amazon searches? They are a dime a dozen, you get those with your cereal. And as a current student, I probably googled already before I looked at the library's search service.

It could be so much better! SFX should work as a web service instead, that can be integrated wherever objects are displayed. Imagine a search results page (for instance in Metalib or an OPAC) where the results are enriched with SFX services! A little AJAX magic will do to insert a few lines. Direct link to fulltext. The first lines from the abstract, with a little button to display the remainer directly inline (again with AJAX). If available, the cover image from amazon or a dozen of other sources. Cited by links. Citation ranking. For chemical articles, graphic molecule displays. And who knows what other services the future holds.

Not just two clicks and a long wait away (not to mention all those new windows, ugh!) - instantly. It shouldn't be that hard for the current generation of openURL resolvers to add a web service interface (provided they *cough* have a simple and straight architecture for the publishing side).

I'm very curious what the SFX community thinks of this idea. The SFX conference is actually happening this week in Stockholm, so I'm a little late for that. When our SFX people are back from Sweden though, I'll see if I can convince them...

PS: I'm aware I am mixing the terms OpenURL Resolver and SFX liberally in this post, which strictly speaking is not correct. I must confess that I don't know what other players there are on this market besides Ex Libris. Note to self: check this out.

2 comments:

André Keyzer said...

At the University of Groningen we already did some things you suggested in our new LiveTRiX system.
LiveTRiX was built on the X-server of Metalib and has (among other things) SFX information in the results pages.

It is still in beta, but if you want you can take a look at:
http://livetrix.ub.rug.nl

Andre Keyzer

Driek said...

Yes, that is indeed what I would like it to look. Looks good, great work on keeping a powerful interface simple.

It builds on top of the X-server though. What I visualize would be a service that would return SFX info as, say, JSON objects, that could easily be used by standard AJAX (javascript-)libraries. Such service could run on top of X-server, but ideally would be part of the standard SFX package.