Showing posts with label smartkeyword. Show all posts
Showing posts with label smartkeyword. Show all posts

Saturday, April 4, 2009

Opensearch vs custom toolbar vs smart keyword vs bookmarklet (IV)

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 , Libx) , Smart keyword searches and Search bookmarklets

I already discussed opensearch here, and the various custom toolbars here . In the last part of this series, I will discuss the much lesser used Smart keyword searches and Search bookmarklets.

Smart keywords

This is a feature that some power-users of Firefox might use to create quick searches. Though this feature is not new, later versions of Firefox makes adding smart keywords easier. The details are here

Above, I set up a keyword search for JSTOR, using js. Basically you right click in the search box , select "Add a keyword for this search", then in the dialog box choose a keyword, in the example above I choose "js".

This basically setups a bookmark, which is recognized by Firefox. Libraries can offer bookmarks to be added by users to add smart keyword searches.

Once it is setup, you can do a search for Jstor, by typing js followed by your search terms (singapore river in the example below) in the address bar and clicking enter as shown below.

Personally I don't recommend smart keyword searches as a method due to the following disadvantages

1. Works only in mostly Firefox.

Sadly this feature works only in Firefox. Internet explorer users can turn on this feature, but it's not easy. Opera has essentially the same feature , while you can add a similar feature using keywurls or Safarikeywords

2.Not portable between different kinds of browsers

Sadly, as far as I know though these features look similar in Firefox, Opera and Internet explorer, they aren't portable from one browser to another.

I.e if you create a smart keyword search in Firefox (which exists as a bookmark), moving it to opera does not get you the same feature (setting is stored in search.ini), neither does it work in Internet explorer (the setting is stored in the registry).

This is a lot more clumsy than opensearch plugins, where you can create one plugin for both Firefox and IE.

3. Memory load on users

Powerusers love the fact that you can quickly type the keyword and do a search in the address bar. However most users will find such a method taxing on their memory.


So far all the methods mentioned Opensearch plugins , custom toolbars (Conduit toolbar , Google toolbar , Libx) , Smart keyword searches etc have one huge disadvantage, they don't support Mac users who insist on using Safari!

Safari users are usually a small but vocal minority and possibly you might want to consider some way to include them. Besides keywurls or Safarikeywords , there are also Safari only methods such as AcidSearch and Inquistor.

But is there a way to support all users on all browsers?

In theory bookmarklets would be a way around this. Bookmarklets rely only on javascript, and I think it might be possible to create a search bookmarklet that would work for IE, Firefox, Chrome, Opera and Safari.

Once created, all you need to do is to click on the bookmarklet, and it will pop up a dialog box to enter your search term. Other bookmarklet versions also allow you to highlight some text, click on the bookmarklet and it will search those terms highlighted.

To create a search bookmarklet, you can either use the method here (though the bookmarklet it generates might not work for all browsers) or modify an existing search bookmarklet like the one here which I verified to work for IE, Firefox, Chrome, Opera and Safari (according to the site).

The version here however does not offer the additional feature of copying text and then clicking the bookmarklet to search though. Anyone know of the correct javascript that will work for IE, Firefox, Chrome, Opera and Safari that includes this feature?


1. Requires no installation, light-weight

In many ways bookmarklets are as lightweight as opensearch plugins. Just add the bookmark, and it instantly works without the need to restart the browser (which is required for custom toolbars). Technical issues are likely to be less, though high security settings in IE might prevent the bookmarklet from working.

2.Supports all browsers

If you want to support as many browsers as you can with one method, search bookmarklets are your best hope.


1. Unable to support POST method?

It is possible in theory for bookmarklets to support post method , but I highly suspect it is not possible to make one that works for IE, Firefox, Chrome, Opera and Safari, but my skills are too poor to figure this out.

2. Limitation in length of bookmarklet for IE 6.

See the following page


This comes to end of my series on the four different ways to bring our library searches to the browser. We covered

1. OpenSearch (my review here)

2. Custom toolbars (my review here)

3. Smart keyword search (covered in this post)

4. Bookmarklets (covered in this post)

Each method has their own strengths and weaknesses, but they all give users quick access to our library catalogues and subcribed databases. Personally, I think on the balance, OpenSearch plugins have the greatest potential, though support for users on older browsers (IE 6 and below) is lacking. However as time passes, such users will become a minority, but this still does not solve the problem of Safari users requring support.

Until Safari starts supporting Opensearch, the only workaround I might consider using is creating search bookmarklets.

Opensearch vs custom toolbar vs smart keyword vs bookmarklet (I)


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.

Accessibility problems

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

  1. Go to our library portal (assuming they can remember it)
  2. Search for the database they want on the portal (assuming they can find it among the hundreds we provide)
  3. Authenticate (assuming they didn't forget the password)
  4. Wait for the search page to load, enter the search terms (assuming they don't struggle with the unfamiliar interface with tons of options)
  5. 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

Others include providing custom toolbars ( e.g. Conduit toolbars, Google toolbar (details). Libx and others), Smart keyword searches and Search bookmarklets.

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

* Opera has a similar feature, IE supports this if
configured using the free TweakUI

** 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.

Browsers supported

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.

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...