AJAX Blog Posts

By now everyone has heard that Google has taken the wraps off of it's "GBrowser" project and released a public beta of Chrome. While many people speculate that Chrome is a rekindling of the browser wars, the reality is that Chrome is a move to accelerate the development of advanced Web applications, Cloud Computing and the SaaS market in particular.

Let's first acknowledge and then move beyond the "Google is reacting to XX" hypotheses:

1. Google is reacting to IE 8 - basically Google sees IE 8 as a threat to the open web and is releasing a browser that is secure, speedy and will adhere to web standards.
2. Google is reacting to Adobe Flex/Air - Adobe has been trying to position Flex as a more capable replacement for AJAX and Java. The Chrome browser promises uber-competitiveness with  AJAX super-responsiveness and it's own Air-like solutions. Moreover it uses open standards so it ends up leaving Flex and Air to be proprietary also-rans.

These are both very reasonable rationales for Chrome. But I believe Chrome is actually an aggressive/offensive and strategic move by Google to speed broader adoption of SaaS and Cloud Computing.

Chrome feature set is geared toward Web apps

Here are some of the more relevant Chrome technical specs:

• Web applications/sites run in tabs as their own process and can run in parallel (like modern desktop apps)
• New multi-threaded (i.e. process several JavaScripts at once) and fast (compiled) V8 JavaScript engine designed to run full applications rather than just tiny widgets
• Each tab is sandboxed so it is more secure and crash-resistant (e.g. a problem in one tab/web application won't bring down the whole browser)
• Gears toolkit, included in Chrome, lets developers create applications that can be used offline, synching data with the Web when an Internet connection is available - blurring the line between Web-based applications and desktop applications
• Designed with WebKit (same as used in Android Mobile OS, Safari on desktops and iPhone, Adobe Air, and several Nokia phones) so it is desktop and mobile savvy
• Memory management, garbage collection, etc.

An engine to speed broader adoption of SaaS and Cloud Computing

Essentially Google is upping the performance, security, stability, and sophistication ante. The ultimate goal of Chrome isn't to be a standard web browser, or as some have speculated, a Web operating system. Rather it is intended to be an engine for the next generation of enterprise Web applications.

Chrome will not displace IE or FireFox as a browser for displaying pages - most consumers cannot even be bothered with updating from IE 6 to IE 7, let alone downloading a new browser to read their favorite blogs! But for Google the browser has been the weak link between the user and it's powerful data centers. By retooling with Chrome, they create a multi-tasking web application engine for professional users, that can make Web apps virtually indistinguishable from desktop apps. And it can also do double duty as your everyday browser.

The lure of web applications that are high performance, cross-platform, cross-device, and secure (process separation and filters for malware) will be sufficient to move many more corporate or SMB applications "into the cloud". And since Chrome is still using JavaScript, applications developed with Chrome in mind, will still perform well with "traditional" browsers.

Google is not alone

I should point out that Google is not alone in this move to high performance JavaScript. Apple is upgrading WebKit with the SquirrelFish bytecode JavaScript interpreter. FireFox 3.1 will incorporate the Tamarin JIT-compiling JavaScript virtual machine. Both will increase JavaScript performance by an order of magnitude to enable complex applications that were previously impractical over the web. With Chrome available as open source, I would not be surprised to see both Apple, FireFox and even IE, embrace and extend Chrome capabilities into their own platforms.

Regardless of Chrome's ultimate market penetration, the release signals a compelling shift away from thinking about the Web as a collection of pages, to a cloud platform for running enterprise-level web applications and SaaS.

I recently updated my laptop to a top-of-the-line system with an Intel Core 2 Duo running at 2.5+ GHz. This is technically five times faster than my laptop a few generations back. But while it is certainly zippier, it doesn't feel five times faster.

This type of mismatch between raw technical performance and perceived responsiveness is actually very common in the computer world. While the processor and bus speeds increase, there are many other factors that go in to how we perceive actual performance.

One of the most significant factors affecting perceived performance is how responsive the computer is to our actions. A system seems to grind to a halt when an application doesn't respond to our mouse clicks. With two applications, both taking the same amount of time to complete, the one that blocks user input or displays a blank screen reloading will definitely be perceived as having poorer performance and be less usable.

The discrepancy between technical performance and perceived performance can be especially notable with web applications, and SaaS applications in particular. Perceived performance is not a linear function of the speed of the CPU, the power of the software architectures/hardware, or the speed of the internet connection. Rather perceived performance is dependent on how effectively a SaaS enables users to complete high value tasks.

The study 'The Truth About Download Times' clearly supports this tenant. It found that users do not rate the download speeds of Web pages based on the actual stopwatch-clocked download speeds. "There was no correlation between these (the actual speeds) and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds)." The authors noted that perceived speed was dependent on how well "users successfully completed their tasks on a site."

Even if you get the technical parts right

In the case of designing for SaaS, the perception of performance can be controlled by several factors beyond getting the technical platform right. For example (in no particular order):

• streamling the work flow (not just making it efficient, but actually finding out what users want to do, and making that efficient)
• using AJAX or Flex RIAs (Rich Internet Applications) to minimize the need for complete page refreshes and reloads
• using RIAs to incrementally add information and functionality to a page, based on an analysis of how users process the information
• using RIAs to progressively download data locally to avoid round-tripping to the database
• validating designs (visual, information, interaction and architectural) to determine where users perceive performance vs. where they get slowed down and wait
• enabling queries or actions to be canceled
• adding reliable indicators of progress on activities (i.e. don't let users get frustrated in front of a screen not knowing how long something will take)

More than a magician's sleight of hand

These are not just "tricks" to create the illusion that the system is running faster. A well designed SaaS application truly enables the user to perform real work more productively. For SaaS, where customers can easily switch to another provider, user satisfaction is critically important. Low perceived performance can lead to low satisfaction and high customer churn. High perceived performance can result in high customer satisfaction and stability.

Optimizing perceived performance also brings another benefit to SaaS. SaaS applications designed to deliver high perceived performance can scale (i.e. add more users) without necessarily increasing infrastructure costs. As described in a previous post, scalability is the key to SaaS profitability.

There was plenty of coverage the past week about the new SproutCore HTML/JavaScript framework that was used by Apple to develop their MobileMe site.  “A SproutCore application is a JavaScript application that runs entirely in the web browser. It can often run on its own, without even needing support for a web server except when it makes sense for the application. This frees the server developer to focus on the things the server can do very well such as saving, restoring and aggregating data and performing expensive operations. Meanwhile the ‘thick’ client running in the web browser can handle the task of presenting the user with a friendly interface that is fast and intuitive,” from the SproutCore Web site.

What is interesting is that the description of SproutCore applies to any RIA stack - HTML/AJAX, Flex, Silverlight, Curl or any new flavor that comes along.  RIA is now the defacto standard for web application deployment.  This applies to applications ranging from simple e-commerce sites, to desktop widgets, to full blown enterprise applications delivered as SaaS.  The particular application develop platform an organization should choose should depend on two things:

1. The core technology for your application (typically .Net or Java). The core technology is driven by a much broader set of issues than just the presentation layer. If you already know what the core technology will be, put a stake in the ground to constrain your evaluation of RIA platforms. We have seen very few teams be successful in delivering an application within the required scope and schedule requirements when the team had to change to an entirely new technology base.
2. The primary device and platform where you plan to deliver your application (e.g. public web, in-house, iPhone, desktop widget, combined off-line and on-line interaction)

Lately we’ve done a lot of work with Adobe Flex because it met specific client needs (e.g. bidirectional network sockets), it is very good at media handling, it is fast to prototype and develop, and it is scalable. For SaaS, we can build smart, adaptive, and reusable interface and data handling components. These can be used in the core application as well as with all the supporting services delivered in software (e.g. billing, provisioning, configuration and support).

Most of our financial services, insurance and banking client work has used GWT and BackBase.

As we develop more applications specifically targeting mobile devices in the enterprise, we will be adding SproutCore to our list of AJAX/HTML solutions.

Regardless of the platform or technology, this is an exciting time to be developing enterprise applications.  The business value of user experience is no longer a hard sell.  Companies get it!  The success or failure of an enterprise web application or SaaS deployment is dependent on using RIAs to deliver compelling, addictive and productivity-enhancing user experiences.