How can libraries encourage the “google generation” to use anything else besides Google? I have no clue either but for sure increasing accessibility to such searches is a key.
Think about it. How many users do you think know the library portal url straight off? How many bookmark it? In my experience precious few (most in my institution seem to know the university homepage url and access the library portal from a link there). Compare this to the number of people who do not know the url for google (KISS is a good idea!). Worse yet the availability of Google toolbar, default google searches in browser toolbars makes accessing google even easier.
It is difficult enough to convince users that they might like to try say Scopus instead of Google. Even if they were convinced to try Scopus, would users be hardworking enough to
- Go to our library portal (assuming they can remember it)
- Search for the database they want on the portal (assuming they can find it among the hundreds we provide)
- Authenticate (assuming they didn’t forget the password)
- Wait for the search page to load, enter the search terms (assuming they don’t struggle with the unfamiliar interface with tons of options)
- Enter the search term and finally wait for the results
We can’t do anything about #3, but there are methods to mitigate #1, #2, #4 and #5 , and as usual the commerical world has gotten there before us.
One method would be to provide Opensearch plugins
What these methods share in common is a way to search your favourite database or search engine with any arbitary search term, from whatever page you are on, without needing to go to the search page first. This solves #1 and #2.
They also share in common the following feature, the search they carry out goes directly to the search results page (using the search options defined earlier) bypassing the search form.
For users who just mostly use the default search at first anyway, it is a waste of time to display the search web form for them to set options. They just get confused anyway. This solves #4 and #5
Oh sure, there are times this is a disadvantage, because you want to set special search options, turn on limits etc, but chances are 9 out of 10, for a quick dirty search the general basic default search would be sufficient, and if it isn’t you can easily refine your search later right?
Comparison of methods
I know for many of the readers the use of opensearch, Libx/conduit toolbars is old hat. However, I hope in my future posts about my experiences using them will be of interest.
|Browsers supported?||POST Method supported?||Popularity|
|Opensearch||IE7+, Firefox 2.0+, Chrome****||Firefox only||High|
|Conduit toolbar||IE6+, Firefox||Yes||Low|
|Google toolbar||IE 6+, Firefox||Yes||High|
|Libx||IE 6+, Firefox||No?**||Low|
|Smart keyword||Firefox only*||Yes||Low|
|Search bookmarklets||In theory all browsers||Yes***||Low|
** Post method only works for some “custom catalogues”.
*** Possible but complicated but see this
**** Limited support, your offered opensearch plugins will create a smart keyword. Also see this.
Obviously, it is important for the method chosen to support as many browsers as possible. In this area the custom toolbars , Google toolbar, Conduit toolbars and Libx, support the two major browsers Internet explorer and Firefox.
Custom toolbars add an additional searchbar, unlike Opensearch plugins which utilize the already existing searchbar in IE7 and Firefox. As a result, opensearch plugins are not usable with IE 6 and older browsers as they do not come with a searchbar. This can be an issue if many systems are still on IE 6. On the plus side the new rising browser Chrome by Google is supported! (limited though, your offered opensearch plugins will create a smart keyword. Also see this).
Smart Keywords are perhaps most limited, supporting mainly Firefox, though it is possible to support it using the free TweakUI.
So far, Mac users who insist on using Safari, are out of luck. However, it is potentially possible for the same search bookmarklet to work even all browsers even those as different as IE and Safari.
Post method supported?
Search engines can use two different methods to send queries. One is the “GET” method and the other the “Post” Method. (see details) . I have found that while a vast majority of opacs and library subscribed databases use the “GET” method many don’t (i.e. Pubmed, Lexis etc). Unfortunately, not all methods support the POST method, and in the case of Opensearch in though there is a provision for it, Microsoft in their infinite wisdom decided not to support it in IE 7/8 although Firefox does!
There are work arounds though, certain search engines actually work if you convert it to work with GET, you can do this using the frmget bookmarklet first, before trying to create the opensearch plugin.
In future posts I will share further thoughts on each of the methods, their strengths, weakness, the problems I faced creating searches for subscribed databases.