Creating custom search boxes for library use- a second look

A couple of months back , I wrote a post entitled Creating custom search boxes for library use. This is one of my top 10 most popular blog posts and also one of the posts which I’m most proud of because it is one of my few posts that I feel is pretty original.

In that post, I figured out a way to create search widgets/boxes for practically any database, which can be embedded in many places including subject guides.

However since then, circumstances have conspired to make the post a little out-dated

Firstly the example given on Scopus, no longer works as Scopus changed their urls. That of course is easily fixed. Secondly, I figured out a slightly better way to improve the stability of the widget.

A more stable search widget?

You can read through the original post again on how to create a custom search-box for EconLit (via OVIDSP). At the risk of quoting myself
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

Creating custom search boxes for library use

The slight improvement to this would be to send the following string instead,

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

Both methods should work, but I’m told that the later string would avoid caching problems.

So the rest follows as before and so the final code you should use is as follows

<script type=”text/javascript”>
function econlitSearchGo(){
var url=”
http://libproxy1.nus.edu.sg/login?url=http://gateway.ovid.com/ovidweb.cgi?T=JS&NEWS=N&PAGE=titles&SEARCH=“;
var url2=”.mp&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>


nter your search terms:
ter your search terms:

If the javascript above looks tough to understand, refer to the original post again, it isn’t really that hard to understand and modify.

Conclusion

So there you have it, my improved custom search widget. If you know a bit more javascript you can do more fancy tricks, for example selecting 2 or more searches from a list and search them in different tabs comes to mind.

Make library search widgets with Widgetbox, Clearspring and netvibes

In my last post, I showed you three different ways you can create a portable web search widget for almost any arbitrary database you want. My preferred method used only simple Javascript with no other requirements and allowed you to generate a basic search box that you can put on any webpage.

In most cases you can just copy and paste the code to any webpage that accepts html and it will usually work. But what if you want to move it to a startup page like igoogle or netvibes? Or make it into a Bebo or Facebook application? Or even convert it into a Vista gadget, Google desktop gadget or Yahoo! widget to put on the desktop? Even Mac users are not left out! All these require the widget to be written in quite different formats.

This is where Widget distribution platforms come in. They allow you to upload Widgets in one form and then allows you to offer to users the same widget in different formats with one click.

Widget from Clearspring

Examples include Widgetbox (pro version exists), NetVibes, Clearspring, iWidgets, Sprout (not free). Also see Popfly and Dapper .


Many of them also provide analytics, tracking the number of users who have embeded the widget. This is of course important for measuring the impact of widgets.

Statistics from Clearspring showing usage

Such services also provide ease of use, in many situations the user doesn’t even have to copy and paste the code, also he needs to do is to click on the version he wants and it will be automatically linked to the account and added with a few clicks. For instance, one can quickly add a widget to one’s blogger sidebar with a few clicks.

In this post, I will talk about using Widgetbox, Clearspring and NetVibes to distribute the javascript web search widget we created in my last post. The others mention before require that you input the widget in Flash format or from a RSS feed (Dapper) and hence cannot be used as we are starting from javascript.

Widgetbox

I’ve also embedded this widget (created using Widgetbox) in a sidebar at the bottom right of this blog.

Widgetbox is a very powerful and useful Widget maker, that allows you to input your Widget starting from a Widget made from Javascript/html, Flash, a remote widget or as a Google Gadget. If you don’t have a widget at all, you can create one out of RSS feeds, producing a widget that displays the content of the RSS feed.

In this instance, based on the Javascript from the previous post, we can obviously choose the Javascript/html option. Alternatively, using the remote widget option one can upload a webpage of the web widget onto a server and point the widget there.

Steps to create a widget using Javascript/html option

1. After registering, log-in and click on “make a widget”

2. Select html/Js option

3. Select blank widget, name the widget and click “continue”.

4. Copy and paste the html you used to create a web search widget into “Widget code” section

Two notes about the javascript code. If you link to any site, make sure you ensure the link will open in a new window (see example). Also any images should be uploaded to a server and then linked to with the full path.

5. Click “apply changes”

6. On the same page adjust the size of widgets in widget settings

7. Check “ Developer Agreement,Content Guidelines. ” and press “Save widget”.

8. The next screen allows you to further test, edit your widget, check analytics (how often your widget is downloaded) etc. But for now just click on submit to gallery.

9. Fill in as many details as you wish and then submit to gallery and you are done!

Alternatively, you could upload the widget as a webpage, then select “Remote widget” and insert the url. For example you can use this.

Use of Widgetbox is pretty straight forward, there isn’t really much to say beyond that. Once imported into Widgetbox, one can export to Blogging platforms (e.g. Blogger, Typepad,Facebook), Social networking sites (Bebo, Ning) Startup pages (e.g. netvibes, igoogle, Pageflakes) . All user needs to do is click on “Get widget”

Clearspring

A sample of this widget created using Clearspring can be found here

Clearspring is almost identical to Widgetbox. Clearspring however allows you to insert your widget into even more places from including Facebook application, Yahoo! widget etc.

This post is already very long, so I won’t go into details on how to use Clearspring, but it’s very similar to Widgetbox. You can use the following webpage as a template.

Netvibes

A sample of this widget created using Netvibes can be found here

Another widgetmaker you could try is NetVibes. Converting to NetVibes widgets is a bit more complicated and requires that you put in certain extra tags to comply with their UWA (universal Widget API). The documentation is here.

If this looks too scary for you, you can take a look at the example I created here. I myself modified it from the following example created by Guus Van Den Brekel from here. Just edit the appropriate fields, replace the javascript and it will work.

NetVibes is actually worth the trouble because it allows you to add widgets to Opera, Apple Mac OS X dashboard and Vista gadget which covers two of the major desktop widget formats.

Conclusion

Much of what I shown is still experimental, and you can spend a lot of time tweaking, customizing the look and feel. That’s all for now.

Aaron Tay

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.

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>

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>

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