There is a new feature on the GMail login page: Gmail: Latest News from the GMail Blog.

I first noticed this last month when the GMail login page was reacting very slowly. The page froze for about 6 seconds in Firefox. I noticed the missing content in the lower left corner of the page appear immediately before the page unfroze, allowing me to then enter in my login credentials.

The latest News from the GMail Blog update is:

A need for speed: the path to a faster loading sequence

Posted May 13, 2008

Great performance has always been an obsession at Google and it's something that we think about and work on everyday. We...

The GMail blog talks about how the GMail team worked to reduce the number of overall requests, make more of the requests cacheable by the browser, and reduce the overhead of each request.

HTML Source

The HTML source code of the GMail login page contradicts that with:

• three external script tags, loaded over a secure connection
• fourteen img tags
• twelve inline script tags,
• four inline style tags, inline style attributes.

One of the external script tags is duplicated, but with a different query string, so even though the response is the same DetectBrowser code, it is un-cacheable and downloaded twice (bug).

Two of the script tags (urchin.js, inline) use javascript to document.write more external script and image tags.

This is all beautifully wrapped up in a nested, automatic table layout (not fixed).

Biggest Bottleneck

Despite the resource problems, the News from the GMail Blog on the GMail login page appears to freeze Firefox for roughly 1-6 seconds, depending on latency and connection speed.

This feature is slow because the page isn't completely rendered until the external JSON is downloaded, then transformed to HTML, then rendered on the page.

Solution?

News from the GMail Blog should be included in the server response for the login page, as HTML (if it is to be included at all).

Blog entries about acheivements are useful when they are informative and specific. This:

To do this, we used a lot of different web development tools, like Httpwatch, WireShark, and Fiddler, plus our own performance measuring systems

Comes off as a bit self-aggrandizing; especially in contrast to the source code of the GMail login page.

The google guys have developed a neat feature for Googlecode. It verifies the form for you, to make sure you're data is OK. If their script thinks you've correctly filled out the form, the submit button gets enabled.

This has got to be one of the dumbest things I've seen in a long time...

See that Create Project button up there?

It's disabled, isn't it? Yes, it is. And if you're using Webkit, it will stay disabled.

User Experience and Usability

There is JavaScript code in Google's "create project" page that enables the button. Since it doesn't work in Webkit, the website is unusable.

Surprised?

It's nothing to be surprised about. The new GMail is just as buggy in Safari as the old one was; sometimes the message gets only half-sent (truncation). Google Groups does the same thing; sends half a message sometimes (embarrassingly horrible code there). Groups' "search this group" feature doesn't work in any browser if you have language pref (link). Groups also has the same problem with the button becoming disabled when it is clicked, which doesn't work so well on a wifi remote connection if you got disconnected.

A Reputation to Live up to

Bolstered by financial growth, Google churns out project after project. Bearing the Google brand name seems to add to the hype, regardless the quality of the products.

(1) Got an iPhone? I bet it came with Google's lame mobile search instead of the better Yahoo Mobile search.

(2) Google docs and spreadsheets, an acquisition, is developed and maintained by recent grads and contractors. No surprise that even after nearly 4 years it's still almost completely unusable.

Source Code

The inline <script> tag for Google Code contains the relevant button-enabling code. No type attribute on the script tag, missing var keyword for most of the variables (which are all top level). The obvious point is the accessibility issue: Users who don't have a browser Google supports are blocked.

<script>
 _exposeExistingLabelFields('edit');
 var submit = document.getElementById('submit');
 submit.disabled='disabled';
 var projectname = document.getElementById('projectname');
 var licensekey = document.getElementById('license_key');
 var summary = document.getElementById('summary');
 var description = document.getElementById('description');
 var cg = document.getElementById('cg');
 projectname.focus();
 var solelyDigits = /^[-0-9]+$/
 var hasUppercase = /[A-Z]/
 var projectRE = /^[a-z0-9][-a-z0-9]*$/
 function checkprojectname() {
 name = projectname.value;
 feedback = document.getElementById('projectnamefeedback');
 submit.disabled='disabled';
 feedback.style.color = 'red';
 if (name == '') {
 feedback.innerHTML = '';
 } else if (hasUppercase.test(name)) {
 feedback.innerHTML = 'Must be all lowercase';
 } else if (solelyDigits.test(name)) {
 feedback.innerHTML = 'Must include a lowercase letter';
 } else if (!projectRE.test(name)) {
 feedback.innerHTML = 'Invalid project name';
 } else if (name.length > 50) {
 feedback.innerHTML = 'Project name is too long';
 } else {
 feedback.innerHTML = '';
 feedback.style.color = '';
 
 checksubmit()
 }
 }
 function checksubmit() {
 submit.disabled='disabled';
 if (projectname.value.length > 0 &&
 licensekey.value.length > 1 && 
 summary.value.length > 3 && 
 description.value.length > 3 && 
 (cg == undefined || cg.value.length > 1)) {
 submit.disabled='';
 }
 }
 checkprojectname();
</script>

Looking at the Mess

Notice the: submit.disabled='disabled';, well that's pretty odd. I can guess what the author was trying to do. The browser might do a boolean conversion on the 'disabled', to get a value of true, but that is not guaranteed. I'm guessing there's code somewhere else that says submit.disabled = "" or submit.removeAttibute("disabled")

Localized error messages appear in a series of if else statements in the checkprojectname function. Certainly not a good mark of internal quality.

There have been many, many, articles and discussions that eschew browser detection, yet it continues.

Despite all of this information, browser detection can be seen in most of the popular JavaScript libraries including Prototype, YUI, Dojo, jQuery, and is present in applications such as the newly refactored GMail:

For a better Gmail experience, use a fully supported browser.

Browser detection is bad for many reasons:

1. Browsers change.
2. The User Agent string does not represent the browser reliably.
3. Even if it did, the browser doesn't represent feature support (See #1).

Browser detection is unrelated to the problem it is trying to solve.

Browser detection makes code hard to maintain. It accomplishes this by requiring that the next version of [insert_browser_name] will also have to be tested and special-cased in the code.

Alternative: Feature Detection

For example, does the browser support opacity? This can easily be determined:

if("opacity"in el.style) { }

Support of opacity has nothing to do with whether that browser actually is an IE version, nor is the reverse true: IE does not imply support (or lack of support) for opacity.

Detection for feature support does not suffer from maintenance problems when Internet Explorer decides to support opacity. Capability detection takes feature detection one step further.

Once the code has been properly designed and tested, it should not be a problem to maintain.

I have learned this the hard way and have tried to remove browser detection from my drag code, though evidence of my mistake is still present. I had to refactor my drag code in specific cases where it checked for browsers identifying with an Opera User Agent string (removed checks to ua.opera). My code still contains one conditional branch that needs to be refactored, As is, the script works in all of the modern browsers (this is subject to change).

With browser detection, the internal quality of the code suffers, even if the code works. This is because it introduces a dynamic aspect that must be maintained as the browsers change. Implementation Matters.

ToBoolean

Be careful when testing for values of properties. Some values may evaluate to false in a boolean context.

// Error-prone, scrollTop may be 0, which would evaluate to false
if (document.body.scrollTop) {
    // statements that work with scrollTop property
}

The new GMail

New code should definitely not rely on browser detection

GMail, which was recently redesigned, still uses browser detection and also punishes users with the performance hit of a misused HTTP redirect (HTTP/1.x 302 Moved Temporarily), or, if GMail finds your browser's User Agent header unsuitable, it two HTTP redirects.

In fact, when developing for mobile phones, I have found Chris Penderick's UserAgent switcher useful. Unfortunately, this confuses GMail, messing up the rendering and even encoding of messages.

GMail seems to be predominantly developed with a windows-centric mentality. This is evidenced by the lack of support for Command + S to save in Mac, and the Safari and Opera bugs witnessed in earlier versions of GMail.

Google Groups

Google Groups also relies on faulty browser detection to block certain features.

Google Groups Browser Error, in a Draggable, Floating DHTML Pane

This feature is not supported in your browser. Download a copy of Firefox or Internet Explorer to upload your picture.

I find it ironic that my browser can be assumed to support the draggable, floating pane, and not suitable for uploading a picture. The floating pane is draggable from anywhere inside it, so it is impossible for a user who gets the error to select the error message text.

Acknowledgements

Google deserves proper recognition for providing a clear example of why browser detection is a bad practice.

Contrasting Example

For proof that an effective Ajax application can be developed without browser detection, have a look at Google Reader.

Browser Detection is mostly a bad idea.

In the meantime, I'm looking for a decent mail application that runs in the browser. Both Yahoo mail and GMail fall short of my expectations.