Creating web search widgets for any database – 3 different options

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.

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.

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=”;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=”;NEWS=N&amp;PAGE=titles&amp;SEARCH=“;
var url2=”.mp&amp;D=econ
var searchInputeconlit = document.getElementById(“econlitSearchInput”); + encodeURIComponent(searchInputeconlit.value) + url2);


<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()”/>


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 + 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 =

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
As such on typing TEST and clicking on the search button, the following url will be opened

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=”{searchTerms}&amp;origin=Browse&amp;javascript=t”>

So you know the string you need to send is{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=”“;
var url2=”&amp;origin=Browse&amp;javascript=t
var searchInputscopus = document.getElementById(“ScopusSearchInput”); + encodeURIComponent(searchInputscopus.value) + url2);


<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()”/>


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.


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.


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.


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

One thought on “Creating web search widgets for any database – 3 different options

  1. Pingback: Make library search widgets with Widgetbox, Clearspring and netvibes | Musings about librarianship

Leave a Reply