Kevin Henrikson

I’ve noticed a few errors in gmail’s new chat interface. The gmail quick contacts are not always up-to-date. Just yesterday I got this this error message:

It’s a new service, so not too surprised that chat is seeing a few bumps. In fact it’s expected. I remember the first few versions of meebo(a web based chat interface for Yahoo, MSN, AOL, and Jabber), and the problems they ran into. One positive aspect of the chat problems are that gmail is unaffected. Email continues to work and is performing well. They’ve integrated it in such a way that quick contacts can fail or be unavailable (like above) but fail gracefully. Many popular web apps, even recent web 2.0 and AJAX apps don’t seem to be designed this way. They fail and fail completely. Designing AJAX apps that can handle partial failures is hard. Many of these app have deep callback stack to get the JavaScript to perform and work seamlessly. There are parallel asynchronous java script calls that need to be requested and handled in whatever order the server responds. So each piece of functionally needs to be carefully crafted to be independent and self sufficient. You need to think about how your app will act if it fails, or worse partially fails. Can it continue to work if it misses a server response or two? Can it error gracefully and continue to work when only a partial set of server functionality is available? This is especially important for companies building desktop replacement applications in which users will rely on for their day to day or even hour to hour work. So take a note from gmail and talk, build apps that are robust to temporary failures. If partial server functionality is available continue to process work and user interaction on the rest of the app. Gracefully poll the server checking for when the full functionality is returned. The error above recovered on it’s own without a reload or restart of the webapp. Impressive to say the least.

On a side note, Gmail itself has been rock solid for me ever since I started using it in June 2004. The spam filters are pretty good, but not perfect (more on that later), and it’s hard to beat the speed of the interface. It’s not the most feature rich mail or collaboration implementation out there but for a small mail volume it does a good job. Works perfect for my personal mail (40-50/day), but I’d have a hard time using it as my primary webmail client for work(200-300/day). I just get too much mail each day for gmail to be useful. It’s missing a few key features to manage extremely large daily mail volume. Saved searches and IMAP support being the first two that come to mind. I need a way to quick search on the same data multiple times a day. Labels work well to automatically categorize and simulate folders but can’t replace a rich search with the option to save. IMAP is a must have for off-line access. POP just doesn’t cut it when you want the server to be your *master* mail store.

Put together an AJAX demo using Amazon’s webservice API. Basically type in an artist name or song title and it’ll return the first 10 hits from Amazon’s music search. It’s using script.aculo.us for the ‘Grow’ effect when the results return. the search itself is triggered via java script, and parsed locally. The result also triggers a contextual AdSense ad. Tried a few different ideas and seems an embedded iframe worked best. My goal was to make it work without a page reload. So to get an AdSense ad that is contextual to the search I needed to generate a url and title string from the query itself. Anything else seemed to lead to generic ads. I’m sure there are ways to improve on it. If you’ve got an idea leave a comment!

AJAX Amazon Music Search

Ran into an interesting problem with JavaScript’s Array.toString() in Firefox.  It’s extremely slow even for a very small array.  Take an array with a single object and you’d like to call toString() to get the type of the contained object.  There are better approaches but for simple uses this might be applied.  In this case toString() of the underlying object simple returns the object’s name.  This is a very common use of toString() on custom objects. In Firefox calling toString() on the Array is nearly ten times slower than calling toString() on the object itself.  In Internet Explorer it’s about three times slower.  Needless to say be very careful with JavaScript’s Array.toString(), as it’s not a transparent call into the underlying objects performance wise.

Internet Explorer 6
anArray.toString() – 1829
anObect.toString() – 625

Firefox 1.5.0.1
anArray.toString() – 3093
anObect.toString() – 375

The full test script is posted below.


var anArray = [];
var anObject = {};
anObject.toString = function() {return “anObject”;};
anArray.push(anObject);

var startTime,endTime,i;
var repeat = 250000;

startTime=new Date().getTime();
for(i = 0; i < repeat; i++) {
anArray.toString();
}
endTime=new Date().getTime();
var arrayToStringResult = endTime - startTime;

startTime=new Date().getTime();
for(i = 0; i < repeat; i++) {
anObject.toString();
}
endTime=new Date().getTime();
var objectToStringResult = endTime - startTime;

document.write("anArray.toString() - " + arrayToStringResult);
document.write("<br/>");
document.write("anObect.toString() - " + objectToStringResult);

YubNub has been around for sometime. I went looking for a Suggest version that would autocomplete common commands. I did a few searches and all I came up with was DashNub which is an OSX Widget.  Using script.aculo.us’s autocomplete code and the XML feed for the YubNub Golden Eggs. My YubNub example now has basic autocomplete.  Any YubNub command can be used but autocomplete only works for the 400-500 Golden Eggs.

Note:
 - It’s only been tested in Firefox 1.5.01

TODO:
 - Test in other browsers
 - Add descriptions to each command
 - Allow selecting with arrow keys

Nate posted an article which coincided with Yahoo’s launch of their UI Library titled "Graded Browser Support".  It appears he first coined the phrase in 2004.  Subsequent google hits all point to Nate.  I must admit it’s quite novel.  He also posted a matrix of browser’s that Yahoo domain applications support.  It’s quite refreshing to see an age old problem explored in a new way and with a catchy new phrase to help coral the thought going forward.  It reminds me of some work in a previous life around WAP browser capabilities. The first generation of tool kits and support for WAP devices included huge switch statements and hacky User-Agent regular expressions.  The second generation and what I belive is still in use today was a framework that detected capabilities.  Rather than look for browser X and apply hacks X, the code would detect capabilities.  For example the ability to support pages greater than 15k (remember we were in the mobile world), or the ability to support a password input field.  The capability matrix kept the code much clearer.  Instead of complex decision trees with User-Agent’s, code was clean with simple if/else statements for a particular capability.  The hard part was contained in a single matrix that maps capabilities to various browsers.  A quick update to the matix and a new handset could be added with little or no code changes.

The same problem has existed in web browser’s for many years.  Most applications simply had isIE() or isNetscape() type checks.  For the most part this worked pretty well as the capabilities being detected were generally split between the two dominant browser’s of the time; Internet Explorer and Netscape.  Today the landscape is very different.  No longer is the browser war a 2 horse race.   For most applications on today’s web it’s at least a 3 to 4 horse race.  In Nick and Yahoo’s case there are 6 different browser’s with a total of 10 browser/version combinations.  This doesn’t even take into consideration the OS side of the equation.  Web application complexity continues to increase.  As applications take advantage of the latest features of new releases the support for capabilities in earlier versions becomes harder to represent.  A simple example is the new native XmlHttpRequest object in IE7.  Assuming it performs better than the ActiveX object in current releases web developers will want to take advantage of the new native object.  In a isIE() type decision tree there would need to be a special case to handle IE7.  However in a capabilities based application IE7 would be defined with a native XmlHttpRequest object such that the code would function without any special cases.