I’m writing this while watching Stephen Graham making a statement as Al Capone in Boardwalk Empire. So I shall make one too. Now about that fellah’, the INFAMOUS Internet Explorer 6. A friend of mine recently showed me a site of his making where he directs the IE6 users to a deadend page where he encourages them to upgrade. Sweet. I totally agree. Then he tells me that IE6 is a plague. It sure is, still agreeing. Then that it’s been alive that long because of all the conciliatory developers like him and me that worked, harder an harder as new standards like transparent PNGs came along, to ensure IE6 compatibility. And that’s where I disagree.

He sure is right if you don’t look at the big picture. IE6 couldn’t have stayed alive for that long without us, hard working developers. But if you go a bit deeper, you’ll agree that us, hard working developers, are taking “orders” from project managers, who take them from account managers, who take them from clients. And for a client, as well as for an account manager, when still 30% of the population uses IE6, you’re faced with the prisoner’s dilemma: will you refuse to support it knowing that you competitor might? Probably not.

But the rabbit hole goes deeper than that. Why was 30% of the population stuck with IE6 not so long ago? To me, it’s a combination of two major factors: the Windows Genuine Advantage, and Windows Vista failure.

According to Wikipedia, “the Windows Genuine Advantage is an anti-piracy system created by Microsoft that enforces online validation of the licensing of several recent Microsoft Windows operating systems”, starting with Windows 2000 Pro, and including Windows XP and Windows Vista. While I can’t be against their motives — they’re a proprietary software business, they’re in for the money, and that’s alright, we need them as much as we need open source if you ask me, but that’s another debate — I’m against the fact that they denied browser upgrades to pirate Windows installation. Sure, these users are pirates, outlaws. They don’t deserve upgrade. But we do! That decision contributed to two things: keeping the net unsafe and slowing standards adoption by preventing a majority of dummy users (read: not smart enough to get they should install FireFox or Chrome, and that’s still fine, it’s not their fault, the internet success resides in its mass adoption, not it’s adoption by the early adopters, but again, that’s another debate) to seamlessly upgrade to a safer and more modern browser.

The Windows Vista failure was just an aggravating factor. Until Windows 7 started shipping late 2009 (and even after that, until people realized it was a lot better than Vista), people where still ordering computers with Windows XP. Unfortunately for us, web developers, that included “cheap” people who wanted to save a few (hundred) bucks on a (not so cheap) operating system. Internet Explorer 6.0 was released on August 27th, 2001. Almost 10 years ago. But people were still having fresh Windows XP installs no more than 2 years back because Vista known to be crap.

So yes, in the end, we web developers are responsible for not refusing to build web sites compatible with an obsolete and insecure browser. But to me, the whole IE6 mess we’ve all got to cope with is Microsoft fault. Not because they tried to enforced their right to be paid for copy of their operating system that’s being installed, but because they did so regardless of internet safety and standards adoption. The net would be so much farther without that decision. But we’re where we’re at, and IE6 doesn’t have enough market shares to rule the world anymore. Google opened the march not long ago. Please, let IE6 rest in peace, so we can get rid of IE7 while hoping that IE9 will be a bliss. Hate it? Drop it, for the sake of us all.

But so much things are cacheable: pages, images, CSS, JavaScript, even many REST web services! Yes, even in this social web era where content changes faster than you can write, there’s still plenty of slow changing information, such as home pages, or lists of countries, regions and cities.

Efficiently using caching translates into:

• Better response and loading time
• Decreased load on the server
• Better user experience

This article aims to present a simple explanation of the HTTP protocol and proper use of HTTP caching.

The HTTP Protocol basics

The HTTP protocol is a communication scheme between two or three actors: the server, the browser, and the often forgotten proxy.

First, to see the implicated headers, let’s have a look to the typical request …

GET / HTTP/1.1
Host: www.tommylacroix.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
If-Modified-Since: Thu, 17 Jul 2008 16:11:24 GMT
If-None-Match: "a9432-fc1b28423-cb122da"
User-Agent: Mozilla/5.0 (...) Gecko/2008052906 Firefox/3.0

… and response …

HTTP/1.1 200 OK
Date: Thu, 17 Jul 2008 16:11:24 GMT
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Etag: "a9432-fc1b28423-cb122da"
Last-Modified: Thu, 17 Jul 2008 16:11:24 GMT
Cache-Control: private, must-revalidate, max-age=0
Vary: User-Agent
Content-Type: text/html; charset=UTF-8

<html>...</html>

Basic Caching

The response headers returned by the server give the browser and the proxy information to make caching decisions.

First, the Cache-Control header tells if the content is cacheable or not. If they’re not sent, it’s cacheable by default. Consider the following headers:

Cache-Control: public, max-age=86400

It basically says that the page is cacheable in a public scope, and that the content shouldn’t be kept in the cache without revalidation for more than 1 day (86400 seconds). The scope can be:

• public: Cacheable by browsers and proxies, even if authenticated
• Private: Cacheable by browsers only (and proxies, but only for requests from the same clients)
• no-cache: Cacheable, but revalidation is required every time.
• no-store: Not cacheable at all.

In addition, there are a few other keywords that you can add to your Cache-Control header. Keep in mind that you must separate multiple keywords by commas.

• must-revalidate: Some proxies can be configured to ignore the Expires and maxage. This keyword forces them to always act like the resource was expired.
• proxy-revalidate: Same as must-revalidate, but only for proxies.
• s-maxage: Same as maxage, but only for proxies.

Finally, for HTTP/1.0 compatibility, you should send a Pragma header when using the Cache-Control no-cache directive.

Pragma: no-cache

Browsers and proxies cache resources based on their URL. You can take advantage of this in many ways at the design stage of your web site or web application. For example, you should put non private REST web service parameters (such as language, or country) in the URL:

http://www.somesite.com/webservice/regionslist/country/usa/language/en

Browsers and proxies also store three important information about the page: the Expires, Last-Modified and Etag headers.

• The Expires header tells the browser and proxy, along with the max-age component of the Cache-Control header, until when this version of the content should be valid.
• The Last-Modified header tells the browser and proxy the date and time of the last modification to this page. It isn’t always provided.
• The Etag header, which stands for Entity Tag, gives the browser and proxy a unique identifier that describes the content it returned. If a page’s content changes, its Etag changes as well.

When you requested this page, your browser (and the proxy in the middle if there was one) did check if the page is cacheable, and since it was, stored a copy of the page associated with the URL, and the three metrics above. For subsequent requests, the server might use this cached copy.

Might? Yes, because the cached page won’t be good until the end of times. At some point, the browser (or the proxy) will check with the server if the page it has in cache is still valid. This is called revalidation, and the Expires HTTP response header along with the max-age component of the Cache-Control header control it.

When the browser or proxy revalidates a page, it sends information about its version: the Etag, and the Last-Modified the server sent when he cached the page. These are sent as If-Modified-Since, and If-None-Match, respectively:

GET /some-cachable-page HTTP/1.1
Host: www.tommylacroix.com
If-Modified-Since: Thu, 17 Jul 2008 16:11:24 GMT
If-None-Match: "a9432-fc1b28423-cb122da"
User-Agent: Mozilla/5.0 (...) Gecko/2008052906 Firefox/3.0

The server then compares this information with the Etag and the Last-Modified of the up-to-date page. If the browser’s cached copy appears to be valid, the server replies with the Expires and Etag (if available), headers, and no content:

HTTP/1.1 304 Not modified
Date: Thu, 17 Jul 2008 16:11:24 GMT
Expires: Wed, 11 Jan 2009 05:00:00 GMT
Etag: "a9432-fc1b28423-cb122da"

If the browser’s cached copy appears to be out-dated, the server replies with the whole page, as usual.

Specific Cases

Now, here comes the tricky cases. For the sake of clarity, I’ll use the following plot for the scenarios below:

« Bob, Alice and Gregg work in the same office. Their office is equiped with a caching web proxy. Bob and Gregg share the same computer with the same user (ok, not credible, so lets say it’s a under-financed non-profit organization), and Alice has her own (she’s the boss).  »

Scenario 1: Secure sessions

« Bob goes on his SuperSocial profile page, at http://www.supersocial.com/profile/. His browser and the office proxy will check if the page is cacheable, and it is. They both store a copy of the page associated with the URL.

But what happens when Gregg or Alice log in his/her SuperSocial’s profile page right after? The browser will give him/her Bob’s page! »

The Cache-Control, Expires, and the Etag headers. Setting the Expires header in the past and the max-age to zero will cause the browser to revalidate the content each time. If the cached content is valid, only a header with no content will be sent. This is slightly slower than full blown caching, but no as much as no caching at all.

We could also set the Cache-Control scope to private, as each copy of the page will obviously only be valid one user.

We should also use Etag, as the content returned for the same URL isn’t the same for Bob and for Gregg, so the Etag will change, and the browser will reload the page for Gregg.

Scenario 2: Content optimization

« The three unproductive workers browse a news site that has a wicked design. So wicked that the guys behind it had to make browser specific optimizations. Therefore, when you’re with Internet Explorer, the page is IE optimized, when you’re with Safari, some in-line CSS styles are different, and when you’re with Firefox, you get the regular page because this beauty is standard-compliant. Standard-what? Lets not digress…

When Bob and Gregg browse the site with IE from the same computer, it’s fine. But when Alice accesses it a short while after with Safari, she gets an ugly page as it’s IE optimized. The reason is, the server sent the IE version to Bob, and the proxy cached it. When Alice requests it, the proxy sends the IE page, thinking that it’s all fine. »

The Vary header. When the content of a page changes based on miscellaneous headers contained in the request, the server must tell the browser and the proxy using the Vary header. The Vary header basically says: If you cache this content, beware that if this header changes, the content might change as well, so use the URL with these fields to make sure you serve a valid version later.

Here’s an example. The request…

GET / HTTP/1.1
Host: www.tommylacroix.com
User-Agent: Mozilla/5.0 (...) Gecko/2008052906 Firefox/3.0

… and response …

HTTP/1.1 200 OK
Date: Thu, 17 Jul 2008 16:11:24 GMT
Expires: Wed, 11 Jan 2009 05:00:00 GMT
Last-Modified: Thu, 17 Jul 2008 16:11:24 GMT
Cache-Control: public, max-age=86400
Vary: User-Agent
Content-Type: text/html; charset=UTF-8

Code Snippet

Here’s a code snippet I wrote quite some time ago. It’s not pretty, but it works so I think it’s a good basic practical example.

/**
* setCacheHTTPHeaders
*
* @author	Tommy Lacroix
* @param	string	$privacy		Scope: public, private or no-cache
* @param	int	$lastModified		Unix timestamp of last page modification (optional)
* @param	int	$maxage			Maximum caching time before revalidation (optional)
* @param	string	$etag			Entity tag, page-content specific (optional)
* @return	bool				TRUE if content need to be sent, FALSE if no content need to be sent
*/
function setCachePolicy($privacy = 'public', $lastModified = false, $maxage = false, $etag = false) {
	// Sanitize privacy
	switch ($privacy) {
		case 'privacy':
		case 'public':
		case 'no-cache':
			break;
		default:
			$privacy = "public";
			break;
	}

	// Calculate expiry and max-age
	if (is_string($maxage)) { // Expiry is a string, interpret
		unset($m);
		if (preg_match('/^([0-9]+)([smhdwy])$/', $maxage, $m)) {
			$maxage = $m[1];
			switch ($m[2]) {
				case 's':	break;
				case 'm':	$maxage *= 60; 		break;
				case 'h':	$maxage *= 3600; 	break;
				case 'd':	$maxage *= 86400; 	break;
				case 'w':	$maxage *= 604800; 	break;
				case 'y':	$maxage *= 31536000; 	break;
			}
		}
	}
	if ($privacy != 'no-cache') {
		header('Expires: '.gmdate("r", time()+$maxage));
	} else {
		header('Expires: '.gmdate("r", time()-31536000));
		$maxage = 0;
	}

	// Send ETag headers
	if ($etag !== false) {
		header('ETag: "'.$etag.'"');
	}

	// Determine wheter we need to send content or not
	$outputContent = true;

	// Check ETag
	if ((isset($_SERVER['HTTP_IF_NONE_MATCH'])) && ($etag !== false)) {
		if ($_SERVER['HTTP_IF_NONE_MATCH'] == '"'.$etag.'"') {
			header($_SERVER['SERVER_PROTOCOL'].' 304 Not Modified');
			$outputContent = false;
		}
	}

	if ((isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) && ($lastModified !== false)) {
		$ifModifiedSince = strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']);
		if ($ifModifiedSince >= $lastModified) {
			header($_SERVER['SERVER_PROTOCOL'].' 304 Not Modified');
			$outputContent = false;
		}
	}

	// Remove content if output has been disabled
	if (!$outputContent) {
		// Return false: You don't need to send content
		return false;
	} else {
		// Send other headers
		header('Cache-Control: '.$privacy.', must-revalidate, post-check=0, pre-check=0, max-age='.$maxage);
		if ($privacy == 'no-cache') header('Pragma: no-cache');
		if ($lastModified !== false) header('Last-Modified: '.gmdate('r',$lastModified));

		// Return true: you need to send content
		return true;
	}
}

Conclusion

The caching HTTP headers are simple to implement, and provide a huge performance bonus. If done properly, this convert into a better user experience, as there’s less waiting, and more browsing.

Shall you like me to add other scenarios, feel free to drop me a line and I’ll see what I can do.

Further Reading

• Caching in HTTP, at W3
• HTTP Caching in Mozilla, at Mozilla

• Big impact, small changes on Amazon (04/03/2008)
• Effective text only emails (04/03/2008)
• A Refreshing Take on Usability (04/03/2008)

Shall you stumble on great usability pages, feel free to leave me a comment and I’ll give it a look.

Big impact, small changes on Amazon (April 3rd, 2008)

You probably didn’t notice unless you’re a savvy Amazon shopper (whether you shop for books or for usability practices) , but Amazon recently made subtle but great changes to the design. They improved readability of key information elements, and redesigned the up-selling space. Check the link below for a great before/after comparison (that I didn’t feel comfortable to rip even if I was going to credit the author).

Via: Future Now’s blog

Effective text only emails (April 3rd, 2008)

Text emails don’t have to be bad and boring. Okay, they’ve got to be boring. But still, when HTML emails aren’t an option, or even just to provide a text alternative for all these new non-HTML cell phone email readers out there, there are ways to make text emails look better:

• Put links on new lines
• Uses lists with asterisks as bullets
• Try to keep it short
• If you can’t keep it short, divide in sections
• Call to action

Via: Shape Shed

A Refreshing Take on Usability (April 3rd, 2008)

This is more a funny heads up than a news, but it shows how well one can use available information to improve user experience.

Via: B#

• Is Customer Experience Recession-Proof? (03/14/2008)
• eCommerce Usability Review: Advanced Search Pages (03/13/2008)
• 11 Ways to Fill Your Shopper’s Cart (03/12/2008)
• Google to start to implement site performance metrics in SEM Quality Score (03/07/2008)

Is Customer Experience Recession-Proof?

Apparently, when consumer spending drops, the fight over the remaining dollars intensifies. A new report from Forrester goes in that direction. According to the summary, “more than 80% of respondents said that improving the usability, usefulness and enjoyability of the online experience is more important this year.” Respondents forecast increased spending in Web Analytics (68%), Usability (53%) and Behavioral Research (51%).

Via: Research Central @ CIO Insight

eCommerce Usability Review: Advanced Search Pages

Yesterday, Varien published an advanced search page attributes review, that is somewhat a sequel to usability review on search page attributes. Same concept as before, the folks take a couple of very good, good and bad pages to display what advanced search engine pages out there allow the user to do. I’m particularilly a fan of the “refine search” concept,
as it is in harmony with the progressive disclosure principle.

Via: Varien’s eCommerce Cache Blog

See also: Usability of gift registries, also at Varien

11 Ways to Fill Your Shopper’s Cart

I liked this one as it helped complete my eCommerce site functionality checklist. Most of Stoney deGeyter’s tips are obvious if you already designed a few eCommerce sites (search engine, product comparison guides, product reviews, etc.), but the list is brief and well assembled, which makes it a good reference tool to save you some thinking time.

Via: Search Engine Guide

Google to start to implement site performance metrics in SEM Quality Score

Earlier this week, Google released a post indicating that they will start to consider the landing page load time in the calculation of the Quality Score. The guys at Traffick see it as the beginning of a trend, and I tend to agree after reading Yahoo’s usability patent filling last week.

Via: Traffick

• Jakob Nielsen’s reports usability ROI decline(03/04/2008)
• Yahoo Automates Usability Consulting (03/03/2008)
• Study: Introductory Paragraphs and Tabs Don’t Aid Reading Comprehension Online (05/03/2008)
• Measuring satisfaction: Beyond the usability questionnaire (03/03/2008)

Jakob Nielsen’s reports usability ROI decline

Jakob Nielsen reports that average the usability ROI of web sites declined from 135% (2002) to 83% (2008). Nielson gives a few explanations to the decline. Two of them are :

We have now harvested most of the low-hanging fruit from the truly horrible websites that dominated the lost decade of Web usability (approximately 1993–2003). In those early years, Web design was abominable — think splash screens, search that didn’t find anything, bloated graphics everywhere. The only good thing about these early designs was that they were so bad that it was easy for usability people to be heroes: even the smallest study would inevitably reveal several immense opportunities for improvement.

Via: Little Sprint Design

Yahoo Automates Usability Consulting

A recent Yahoo patent application lists usability factors a search engine could use to determine how usable a web page is. Why would Yahoo be interested in knowing? Quoting the authors of the document :

It can be important to make web pages easy and pleasing to use, which can be particularly important for web pages it is desired to monetize.

This may include, for example, advertisement-containing web pages (of a so-called “web portal,” for example), for which an advertiser pays money when a user views the web page and activates a link of the advertisement.

If such web pages are not easy and pleasing to use, the money-making potential of those web pages can be jeopardized. One conventional indication of whether a web page is easy and pleasing to use is called “clutter.”

I personally crave for a usability test engine to replace my old boring evaluation checklist. Next step would be a Google Analytics module that would analyze the browsing patterns.

Via: SEO by the SEA

Study: Introductory Paragraphs and Tabs Don’t Aid Reading Comprehension Online

A recent study by the University of Washington analyzes the impact of introductory paragraphs (presence of the paragraph, and presence of links in the paragraph), and tabbed navigation.

Cutting to the chase, users apparently like tabs, but introductory text might have no effect on comprehension. Anchored text is helps increasing comprehension — especially on how the concepts relate to each other — but decreases user satisfaction, especially when there’s no tabbed navigation present. I strongly encourage you to spend 5 minutes to read Faithful Web summary.
Via: Faithful Web

Measuring satisfaction: Beyond the usability questionnaire

David Travis from UserFocus describes the criticism-reluctancy problem in rational usability testing, and provides a method to overcome this problem.

This is very similar to a few focus group interview techniques used in marketing research, but applied to usability testing.

Via: UserFocus

I’ll try to briefly cover every step we — at Quantik Solutions — do to ensure the delivery of a web site that meet the client and the user needs. This being an overview, I will try to develop each step in a separate post later on.

Step 1. Market, history and present situation analysis

This basically consist in look to the client’s past and actual web site, and its competitors. The objective is too get a list of do’s, keepers and don’t, either from the functionalities of the analyzed sites, or from functionalities that are missing from the sites. We analyze available web statistics to get quantitative information about what informations the visitors seek the most and the less.

This step also consist in finding the characteristics the major personas:

• What are their demographics? (age, sex, education, revenue, etc.)
• What is their internet knowledge? (often based on their demographics)
• What information do they look for on the site, in the first 30 seconds, in first 2 minutes, in the first 10 minutes?
• What is their technological profile? (ie. which browser, JavaScript support, Flash version support, screen resolution, etc.)

Step 2. Needs and requirement gathering

Usually — but strange enough not always — the redesign or refectory of a site is triggered by new requirements or new needs. The objective of this step is to get a list of all of them, but also to discover latent needs and requirements, or to convert requirements to strategies. We also try to get an idea of the client’s budget.

For example, a client could require to improve its web sales by 10%.

• A latent requirement could be that the checkout process is simpler, as it has 10 steps right now ;
• His 10% improvement requirement could be converted to an immediate or delayed up-selling strategy.

It might look like rocket science, but all the answers usually come quickly and easily after the market analysis at the previous step.

Step 3. Information architecture

This basically consists in grouping related information in sections. We use the card sorting technique I’ll cover later in another post.

Step 4. Functional planning

This stage consists of drawing annotated wire frames of the major interfaces. We do a first version on paper or on a white board at first (that we scan or capture with a digital camera for archives), then using Visio and UXD wire frame template/stencils.

We try to separate this from the design to make sure that we don’t end up with a nice looking but unusable web site.

Our main usuability guidelines are :

• Learnability: a user who doesn’t know the web site design, functionalities and information architecture must be able to find what he looks for quickly.
• Memorability: a user who knows the site must be able to quickly remember its functionalities when he returns to it after a prolonged period.
• Efficiency: a user who knows the site must be able to find what he looks for quickly, and be able to use more advanced features (search engine, related content boxes, etc.) to do so.
• Errors: a user must make as little browser mistake as possible, and misleading elements must be remove.
• Satisfaction: a user must enjoy browsing the site.

Step 5. Technical planning

This step consists in planning the software architecture behind the site. Database models are drawn, SQL queries are written, programming guidelines are outlined, browser compatibility and hosting requirements are stated, and speed/load objectives are identified and quantified.

Step 6. Cost analysis

At this step, we know exactly how the project is going to be done. Hence, a precise cost analysis can be made. We base the cost analysis on previous project and client history. We add a budget for quality assessment and client communication and management, both based on internal and client-specific historical ratios (some clients are high maintenance, some are low maintenance).

Step 7. Design

We don’t do any web design at Quantik Solutions because it isn’t our strength. We rely on experience web designers instead. So they typically draw two front pages, then one is picked by the client; then they draw one to three sub pages, that are adjusted following the client’s feedback.

Step 8. Integration, programming, and quality insurance

Integrate, code, test. The requirements, functional and technical analysis are used to make sure no deliverable has been forgotten.

Step 9. Production postmortem

What did we do well, and what didn’t we? Most of the time, the answer to improving your processes and workflow are right under your nose in everybody’s head. We make sure it gets out and ends on paper. The objective of this step is a bullet form or keepers and goers.

Step 10. Project postmortem

After a few weeks or months, we update the information collected during step 1.

• What did the client think of the development process?
• What did the client hear from the users about the new site?
• After web statistics analysis, what actually seem to works and what doesn’t?
• Did the client and user needs change? If so, in what way?

Often, this leads to a micro iteration where minor changes are brought to the site (revision of step 3 to 8), or to a complete iteration (steps 1 to 10).

Conclusion

This process isn’t perfect, and we keep on learning on how to improve it. Therefore, we make sure that we get our folks’ and clients’ opinion and ideas about it.

It can also be too heavy for some small projects. Thus, some steps are sometimes driven in an informal way, or using a template that fits the typical project with minor adjustments.

Further reading

In theory and technologically, we could determine what timezone the user is in by:

• Using a geo location database to guess their longitude and latitude, and then find the probable timezone from it ;
• Using JavaScript to read the user’s workstation clock and calculate the probable timezone from it. You can see a live demo here.

Geo location, while pretty simple nowadays with free databases floating around, leaves us with a problem: the free databases are often not good enough to pin point a precise longitude and latitude, which will cause garbage in and garbage out when trying to translate it to a timezone. Moreover, the non-free and precise databases are pretty expensive compared to the added value of timezone detection, and are most likely not worth buying just for this purpose.

JavaScript clock reading on its side offers a pretty simple yet functional solution. The two downsides are:

• It is impossible to detect the timezone for users who disabled JavaScript (a very few in the AJAX world).
• The precision depends on the exactness of the users’ computer clock settings, as its the piece of information we base our calculation on.

Here are the three macroscopic steps for the detection:

• Try to detect the user’s timezone through JavaScript, then send it via an XML-HTTP call to a script that will save it either as a cookie or as a session. Alternatively, you could use the JavaScript setcookie function.
• If detection is impossible (JavaScript is disabled), try to read the previously detected timezone in a cookie.
• If no timezone can be detected, use a default one (or chain in the geolocation method).

The detection code itself is:

function setTimeZone() {
 	var xmlhttp;
 	timezone = "EDT";	/* Initialize httpRequest object */
 	if (window.ActiveXObject) {
 	 	xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
 	} else if (window.XMLHttpRequest) {
 	 	xmlhttp = new XMLHttpRequest();
 	}
 	xmlhttp.open("POST", "/timezone-controller.php",true);
 	xmlhttp.onreadystatechange=function() {
 	 	if (xmlhttp.readyState==4) {
 	 	 	// Do nothing
 	 	}
 	}

 	xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
 	var visitortime = new Date();
 	xmlhttp.send('epoch='+visitortime.getTime()/1000+
 	 	'&timezoneoffset='+visitortime.getTimezoneOffset()/60);
} setTimeZone();

I personally prefer to use the epoch value rather than the timezoneoffset one, as, in my experience, local timezone settings are more often incorrectly set than local time.

In conclusion, it is possible to detect your users’ timezone in a fairly simple way using JavaScript, so you can present them dates and times relative to their location, without having to ask them.

However, the method being imperfect, the safest way to determine their exact timezone will always be to ask them. Thus, the implementation of this method shouldn’t replace the parameter in their profile.

World timezone map found on netschool.de.
Article previously published in French at Quantik Solutions.
Code distributed under the LGPL license.

Check out Factory Joe’s examples of everything from tag clouds and video players to headers and footers.

Founds on UE&D blog (see blogroll).