In a previous post, I discussed the different ways, one can add support to searching OPAC and other library subscribed databases. The four methods were Opensearch plugins , custom toolbars (Conduit toolbar , Google toolbar and Libx) , Smart keyword searches and Search bookmarklets
I will begin with Opensearch.
This is by far the most popular method. Many libraries have used them (see this) . This became possible only when browsers began to include a built in search bar. The idea was simple, instead of just hardcoding search engines in the searchbar why not allow users to add their own?
For a time sherlock plugins (which worked like opensearch plugins) were popular with the Firefox/Firebird/Pheonix crowd but it was strictly meant for power users because of the lack of support for Internet Explorer.
The future of opensearch seems secure as IE 8 adds various features like web accelerators and newer versions of opensearch (don’t worry your existing ones will continue to work) that further enhance use of opensearch plugins.
Various powerful firefox extensions exist that further enhance use of opensearch plugins.
Try Add to searchbar (makes adding new search providers a snap) , Firefox search sidebar (search several search providers at one time) , search on engine change (becomes IE7 like, switching engines will automatically search), searchwith (adding searches to your context menu) and much more.
I won’t go into how to create basic ones because there are many guides available (e.g this guide) as well as opensearch plugin builders (mycroft, enhanceie ,Microsoft’s etc) where all you need to do is to follow basic instructions without programming.
I do recommend the following testing scheme
1. Create the opensearch plugin. Include favicon if required (I prefer to link it locally).
2. Clear your browser cache, cookies etc, log-out, restart your browser and test the opensearch plugin again.
3. Wait an hour or so, and retry the opensearch plugin again.
Step 3 is recommended, because often, the url string includes a sessionid, and the url you send will continue to work for a period until the server starts to reject it. With experience you can spot it quickly (usually long random string), but until you can, including #3 in your testing is a good idea.
Also be aware of the slight differences in the way IE 7, IE 8 and Firefox handle opensearch plugins.
I have personally tested this method more than the other methods, and I find that I can create working opensearch plugins for roughly 90-95%% of our subscribed database including our OPAC.
Many databases are harder to create for because they use post methods (which do not work in IE7/8 because Microsoft in their infinite wisdom refuse to support them, though Opensearch does provide for them and Firefox supports them) or are doing some quirkly refreshing of screens so it is hard to capture the actual url.
Workarounds I know of to solve problematic databases
Use this to convert the form to use GET method instead of POST method. Though many forms are by default using POSTmethod, they work fine when converted to Get method. To do this, Click on the frmget bookmarklet before capturing the url as per normal.
2. Use Needlesearch (a Firefox addon)
Some databases, do some quirkly refreshing of screen, and the final url you see is not the one you need. There are many methods to capture the actual url you need but I use Needlesearch (a Firefox addon)
3. Find a direct Url
Often steps #1 or #2 (or even #1 and #2 combined) will cut through any difficulties. But some will require special handling beyond that.
Many databases add a sessionid key that causes problems when you try to create a opensearch plugin using the normal method. Fortunately, they also provide a directurl, or jumpstart url you can use. I will list the ones I’m aware of. Most came from the excellent blog, Library toolbars
1. Well supported
There are many sites offering lists of opensearch plugins for use (few library related ones though), and lots of well designed mechanism for easily creating plugins.
2. Supports both IE 7+ and Firefox as a built-in feature in.
This means it does not require user to install large clunky toolbars, which can cause technical support problems.
For example some security programs like anti-spyware programs don’t like Conduit due to privacy concerns, firewalls might block toolbars from “phoning home” etc.
Another minor concern is that IE 7+ and Firefox already have searchbars, so adding third party toolbars just makes the browser cluttered. (Yes, I know you can remove the default searchbars in Firefox and Internet explorer..)
3. Greater ease of use.
1. Firefox version does not support Searches using post method.
I had to use workarounds (see above)
2. Does not support IE 6 and older versions, much less Safari, Opera.
Expect lots of complains from Mac users who love Safari even though Firefox works fine.
There’s a lot more to say about opensearch which I predict will become huge (e.g Microsoft support in Windows 7 , using program launcher like FARR to search ) but next up are the custom toolbars. Conduit toolbar , Google toolbar and Libx