Nicolas Schudel » Javascript

Linking a Site’s Search Function to the Browser’s Search Bar

Nicolas — Fri, 30 Oct 2009 18:56:02 +0000

The search bar has become a common feature in modern browsers since it was introduced by Firefox in 2004. Users have gotten so used to finding the search bar in the upper right hand corner of the window, that many sites adapted their layout to place their own local search in the same area.

A lesser known feature of browsers, such as Firefox 2 or Internet Explorer 7, is that users can add search functionality to the browser’s search bar directly from within a page. The data structure containing the search information has (so far) been agreed upon as OpenSearch. Since the format is open, any browser software can implement this functionality.

The Firefox search bar with a linked OpenSearch example on the bottom.

The Internet Explorer search bar listing an OpenSearch example.

When to use OpenSearch

OpenSearch makes sense on any site that provides search functionality. When active, Firefox and Internet Explorer include an option to add the site’s search in the search bar.

In my opinion, adding a notice or a link on the page to enable the search functionality is overkill for most sites. I personally wouldn’t use it for my own weblog. On the other hand, an online store with thousands of products could greatly benefit from this feature as a brand touchpoint; And informing the user about this functionality would be worthwhile. Once a user adds a site to their browsers search bar, it is a constant reminder of the site’s existence. Every time a user activates the search bar drop-down menu, that site will be there.

Implementation

Versions of Firefox before 2.0 had a different way for adding search to the search bar. It was similar, but included a different XML structure. The data was saved in files ending with “.src”. I decided not to add this method anymore, since it is specific to a small user base (who still uses FF 1.0?).

Only two things need to be done to add OpenSearch:

Create an XML-File containing data about the search engine;
Link to the XML-File in the head of the site’s HTML.

The XML, for example, would be structured as follows; Simply adapt the URLs for your site. To get the correct search URL, perform a search on your site, copy the URL and replace your search term with “{searchTerms}”.



	OpenSearch Example Name
	OpenSearch Example Description
	UTF-8
	http://yoursite/favicon.ico

This file could then be saved as “search.xml” to the root folder of the site and linked to by placing the following code in the HTML header:

Including an OpenSearch Link to the Page

Optionally, the search plugin can be installed via a link using Javascript. Both Firefox and Internet Explorer use this:

window.external.AddSearchProvider("search.xml");

An unobtrusive way to add the link, is to first check if the browser supports the AddSearchProvider function before adding it. Further details can be found on Mozilla’s developer site.

OpenSearch not supported

Possible Future Browser Features

I have a hunch that the usability of web-browsing in general, would be enhanced if the browser could detect OpenSearch and enable it temporarily in its search bar. The use case could be:

A user visits a site and the browser toggles the search bar to the site’s search. Instead of looking for a search form in the page, the user enters the query via the browser. Upon leaving the site the search bar switches to the new site’s search functionality, or defaults to the preferred search engine.

The search bar could be highlighted with another color to indicate that it’s linked to the current site.

For this feature to be useful, OpenSearch would have to become more commonly adopted. But I think sites would follow quickly once a browser vendor starts pushing the feature.

Conclusion

In my opinion, the creators of OpenSearch got it right. The specification is clear and it blends in perfectly with the existing technologies, HTML and Javascript. Plus, it is quick and easy to implement. I could recommend any web content management system with search functionality to enable this feature as standard.

I would also recommend adding a favicon to the OpenSearch XML, so the site stands out more in the browser’s search bar.

Download the Code

Making Sign-Up Forms That Much Easier

Nicolas — Mon, 18 Feb 2008 13:23:22 +0000

I watched a useful presentation about form design by Ryan Singer a while back and he makes a point that user input should be kept to the bare minimum when signing up. An article by Luke Wroblewski titled Sign Up Forms Must Die seconds the notion.

However, sometimes it is required for the user to do the leg-work and fill in lots information. Like registering at an online store for instance. Gotta at least know where to send the purchased goods! For users that don't have auto-fill plugins such as the Google Toolbar, Javascript can help filling in the necessary information - not just validating the user input. It would, for instance, make web forms simpler for users if their city would be filled in automatically upon entering their postcode. I timed myself typing my city of residence as quickly as possible and it took me about 3 seconds. So, all in theory of course, the improvement would skim roughly that much time off filling in a form. It's not a lot, but the users level of tolerance towards HTML forms isn't much either.

I'm now going to talk about how I “auto-fill” the city information based on the entered postcode in a HTML form using PHP, MySql and Javascript.

Setting Up the Database

First I needed to get the postcode information from somewhere. For Switzerland I found the data via the Swiss Post.

Then I needed to get it into the database somehow. To do this I imported the downloaded text file (it is tab delimited) into Excel and then exported it again as a CSV file. I only imported the columns I needed which are the ones containing the Town name and the postcode.

Next I put on my white programming gloves and wrote a quick PHP script that connects to the database and runs two SQL statements to import the CSV file. Change the variables to fit your setup and be sure to have the CSV file in the same folder when you run the following example.

$link = mysql_connect('localhost', 'root', 'root') or die('Could not connect: ' . mysql_error());

mysql_query(&quot;CREATE DATABASE IF NOT EXISTS test
DEFAULT CHARACTER SET latin1 
COLLATE latin1_swedish_ci;&quot;
);

mysql_select_db('test') or die('Cannot select database');

mysql_query( &quot;CREATE TABLE postcodes (
code SMALLINT(4) NOT NULL ,
city VARCHAR(27) NOT NULL ,
PRIMARY KEY (code)
) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_swedish_ci&quot;
);

mysql_query( &quot;LOAD DATA LOCAL INFILE 'postcodes.csv'
INTO TABLE postcodes
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\r\n'
(code, city);&quot;
);

if(mysql_error()) echo mysql_error();
else echo &quot;Done!&quot;;

mysql_close($link);

Special characters where also an issue with importing and exporting so be sure to check the city names in the database. I used the windows text format for importing.

Creating a Web Service

We now need some server side code to provide us with the data from the database. I am using the insanely cool JSON gateway included with AMFPHP to provide the client with data. So with AMFPHP set up I could just write a simple PosteCodeFinder class and plop it into the AMFPHP's services folder. Otherwise a simple way to get the correct name would be a PHP script like this:

mysql_connect('localhost', 'root', 'root') or die('Could not connect: ' . mysql_error());
mysql_select_db('zencart_shop') or die('Cannot select database');

if (isset($_GET['code']) &amp;&amp; is_numeric($_GET['code'])) $code= $_GET['code'];
else die ('Only numbers please! The URL should look something like: postcodefinder.php?code=1000');

$query = &quot;SELECT city FROM postcodes WHERE code =&quot; . $code . &quot; LIMIT 0 , 1 &quot;;

header(&quot;Content-Type: text/javascript; charset=utf-8&quot;);
echo json_encode(utf8_encode(mysql_result(mysql_query($query), &quot;city&quot;)));

The code connects to the database, checks the input to be numeric, retrieves the city name and spits it out as JSON.

I had to use utf8_encode() inside the json_encode() function because it would otherwise mess up my character encoding. "Genéve", for instance, would be truncated to "Gen". It was reported as PHP bug #43941.

The Client-Side Code

On to the Javascript! I am using the Prototype library here to make programming AJAX bearable.

FormController = {
	previousResponse: "",
	
	postcodeHandler:function(el) {
		var code = parseInt(el.value);
		if (code >= 1000 && code <= 9999 && $F('country') == 204) 
	  	new Ajax.Request(
			"json.php/PostCodeFinder.find/" + code, 
			{
	  		method: "get",
	  		onSuccess: FormController.updatePostCode.bindAsEventListener(this)
	  		}
		);
	},
	
	updatePostCode:function(transport) {
		var jsonObj = eval("(" + transport.responseText + ")");
		if (jsonObj != undefined && ($F('city') == "" || $F('city') == previousResponse)) {
	   	$('city').value = jsonObj;
			this.previousResponse = jsonObj;
	   }
	}
}

Event.observe(
	window,
	'load',
	function() {
		new Form.Element.Observer('postcode', 1, FormController.postcodeHandler.bindAsEventListener(this));
	}
)

Download all the code here.

Conclusions

Usability Gain

Considering the amount of time it took me to implement, I can only recommend the postcode optimization as a final improvement to a form. Other factors, as mentioned in Singer's video for instance, should be considered first to get the most bang for the buck.

Character Encoding

Most of my time was not spent with programming the scripts but with playing with the character encoding. Having UTF-8 all the way through form the original text file, to the database, to the PHP script, to the client side Javascript and finally the HTML document itself was easier said than done. I found a PDF on the UTF-8 development practices by Matthias Kerstener, that helped out with some of the issues. Still, character encoding issues makes me not want to be a web developer any more.