Monday, April 20, 2009

Creating custom search boxes for library use- 3 different methods

Note : Since I posted about this , Scopus changed their urls which means the example below using Scopus will fail obviously (but the EconLIT/OVID SP example still works), but the method is still sound in general. Moreover a newer post suggests that there might be a slightly more stable method by varying the string sent. But by and large most of the content here remains valid, particularly explanation of how the javascript works.

In an earlier post, i talked about how libraries are attempting to increase accessibility to their databases and catalogues via the use of opensearch plugins, custom toolbars, bookmarklets and even smart keywords.

Another way to improve accessibility is by embedding web widgets. You can embed all kinds of web widgets but here I will talk about web search widgets. Essentially these are javascript code for portable search boxes. I won't sell you on how you can use this, but "but the general idea is to put it anywhere and everywhere your users may be"

By cutting and pasting simple javascript, one can put the search box for catalogues and databases where-ever they want. Users no longer have to go to the official JSTOR page (for instance), just to search JSTOR. In fact, users can even cut and paste the same code and put it on their webpages to get the search box.

Vendors have begun promoting this. Proquest offers an easy to use search widget creator that allow librarians to easily generate javascript code to cut and paste to put where-ever they want on their portal (also CSA Illumnia) Ebscohost also allows this as well.

A barebones version looks like this

Enter your search terms:




Update: Doesn't work when embedded in Blogger?

Note : Scopus takes a different tack and offers desktop widgets via Yahoo! widgets. But here I will focus on simple web widgets - simple javascript that one can cut and paste and put on any webpage.

But what if libraries want to create search web widgets for other databases that the vendors have not yet seen fit to support this? Currently, there are two approaches to handle this, in this post I will introduce a third method that AFAIK has not being mentioned before.

To get you motivated here's one example of what you could do. I embed them into my subject guides
























Approach one : Leveraging on database searches already supported by Conduit toolbar.

The highly innovative and creative librarian from Netherlands Guus van den Brekel is a big fan of Conduit toolbars. As I mentioned in a previous post this is a custom toolbar that can be configured to support quick access to search almost any database.

He realised that once a toolbar is setup to support searching say JSTOR, you can easily convert it to a web search widget. The instructions on how to do so are here.

My main concern with this method are as follows

1) The search doesn't go directly to the database but is routed through Conduit servers, which might lead to privacy concerns.

2) The results shown will be framed. While this is an advantage for users who can quickly switch being databases. Some vendors might frown on sites framing their material.


Approach Two : Leveraging on existing federated search solution

Very recently at the Computers in Libraries 2009 conference, Nina McHale of Auraria Library, gave an amazing presentation entitled "Help your Library become omnipresent without spending a dime" (slides) , talking about what they have done with widgets. Definitely worth reading if you haven't. But her presentation doesn't go much into the technical details except to advise to check with your "web folk". Looking at examples given here and in the slides, one notices/guesses that they are leveraging on their federated search solution from serial solutions? (I might be wrong)

If so I can see two disadvantages with this approach. Not every library will have a federated search solution. More seriously, I believe most federated search vendors charge you for each database you add, so this solution will restrict you to creating search widgets for only these few databases you are supporting.

Is there a better approach?

I have being a big fan of Opensearch plugins since I discovered them and I even created a big bunch of them here for almost every database we support on various platforms.

Once you have created a opensearch plugin, you know exactly what format the url should be sent to get the result. For instance, I know that to send a keyword query to EconLit (OvidSP) with the term TEST, you should send the following string.

http://gateway.ovid.com.libproxy1.nus.edu.sg/ovidweb.cgi?T=JS&NEWS=N&PAGE=titles&SEARCH=TEST.mp&D=econ

How do I know that? For every opensearch plugin, you will have a string in the xml file that says something like the following

<Url type="text/html" template="http://gateway.ovid.com.libproxy1.nus.edu.sg/ovidweb.cgi?T=JS&amp;NEWS=N&amp;PAGE=titles&amp;SEARCH={searchTerms}.mp&amp;D=econ"/>


where {searchTerms} represents the search term that you type in.


Would it be possible to leverage on this knowledge to send the search directly from a web widget? I was pretty sure this was possible, but my javascript knowledge is practically zero, but looking at the sample web search widget produced by the Proquest Search Widget allowed me to figure it out.

Creating a simple web search widget by copying and pasting

After tweaking it a bit, this is what I came up with by modifying the Proquest widget version. It can probably be improved but so far it works fine.

<script type="text/javascript">
function econlitSearchGo(){
var url="http://gateway.ovid.com.libproxy1.nus.edu.sg/ovidweb.cgi?T=JS&amp;NEWS=N&amp;PAGE=titles&amp;SEARCH=";
var url2=".mp&amp;D=econ"
var searchInputeconlit = document.getElementById("econlitSearchInput");
window.open(url + encodeURIComponent(searchInputeconlit.value) + url2);
}</script>

<div>

<div id="enterText" style="position: absolute; left: -1000em; width: 20em;">Enter your search terms:</div>
<input type="text" id="econlitSearchInput" size="30" onKeyPress="handleKeyPress(event,this.form)" />
<input type="button" value="Search" onclick="econlitSearchGo()"/>

</div>



Enter your search terms:

Enter your search terms:
Don't panic!

Okay if you are like me and am not a javascript god, this looks quite scary.
But it isn't really. Look at the line that says

window.open(url + encodeURIComponent(searchInputeconlit.value) + url2);

It just means open in your browser a new window with a url made up of whatever is in

1) the variable url = http://gateway.ovid.com.libproxy1.nus.edu.sg/ovidweb.cgi?T=JS&NEWS=N&PAGE=titles&SEARCH=

followed by

2) the search value entered into the box = For instance say TEST is entered in the search box.

followed by

3) the variable url2 =.mp&D=econ
As such on typing TEST and clicking on the search button, the following url will be opened

http://gateway.ovid.com.libproxy1.nus.edu.sg/ovidweb.cgi?T=JS&NEWS=N&PAGE=titles&SEARCH=TEST.mp&D=econ

and this of course is exactly what you want to type in the browser url address bar!

One more example

Here's one more example, you created a Scopus opensearch plugin. You look into the xml file and you see this

<url type="text/html" method="GET" template="http://www.scopus.com.libproxy1.nus.edu.sg/scopus/search/submit/quick.url?searchtext={searchTerms}&amp;origin=Browse&amp;javascript=t">


So you know the string you need to send is
http://www.scopus.com.libproxy1.nus.edu.sg/scopus/search/submit/quick.url?searchtext={searchTerms}&origin=Browse&javascript=t

So what you do is to just copy and paste the same javascript as above, except to replace with the appropriate values


<script type="text/javascript">
function ScopusSearchGo(){
var url="http://www.scopus.com.libproxy1.nus.edu.sg/scopus/search/submit/quick.url?searchtext=";
var url2="&amp;origin=Browse&amp;javascript=t"
var searchInputscopus = document.getElementById("ScopusSearchInput");
window.open(url + encodeURIComponent(searchInputscopus.value) + url2);
}</script>

<div>

<div id="enterText" style="position: absolute; left: -1000em; width: 20em;">Enter your search terms:</div>
<input type="text" id="ScopusSearchInput" size="30" onKeyPress="handleKeyPress(event,this.form)" />
<input type="button" value="Search Scopus" onclick="ScopusSearchGo()"/>

</div>


Enter your search terms:
Easy as pie. :)

Some notes

1. If the search string ends with just {searchTerms} and there is nothing after it, you can just leave the line that specifies url2 as follows

var url2=""

2. It is not strictly necessary to change the variable name e.g. searchInputscopus instead of searchInputeconlit, if there is one widget per page, but this may cause problems if widgets sharing the same name are on the same page.

3. Note to beginners the examples above incorpoate the ezproxy string that you have to change to your institution.

Advantages

1. Compared to the above two mentioned methods, search goes directly to database.

2. Relatively easy to create search widget once you have the opensearch plugin.

3. Cost nothing. No requirements at all, except client side javascript.


Disadvantage

1.
It is difficult to instruct users on how to create their own search widget for the database they want. It is unlikely the user would want to go through the method mentioned above. One advantage of approach two above (using serial solutions federated search) is that you can use easily understood codes like db=jst to represent JSTOR, making it easy for users to change to whatever search they wanted.

One possible improvement would be to to implement a gatekeeper page, as in "Plug your users into libraries resources with OpenSearch Plug-ins " . Instead of the opensearch string going direct to the database it will go to a special gatekeeper php page that will redirect the search. That way, one could create nice aliases to use, it would go the php page which would then redirect to the correct url. Another advantage is that the gatekeeper page allows one to keep statistics of how often the searchplugin is used, and if the url string needs to be changed, all you need to do is to change the php string and all users will automatically be updated.

Conclusion

So what do you think? Is this a good idea?

The next step would be I think to figure out if this can be extended so that it can be used to create desktop widgets, put on startpages like netvibes, pageflakes, put on social networking sites like Facebook etc by putting it through Widgetbox etc







blog comments powered by Disqus

Share this!

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Related Posts Plugin for WordPress, Blogger...