Tuesday, February 14, 2006

The Flex

Flex 1.0 introduced a new programming model to allow enterprise developers to create rich client interfaces to strategic applications. Flex 1.5 updated and expanded the core programming model and server. In future versions, this model will support a range of functionality important to these types of applications. Includes additional core technology, tools, and solutions based on the Flex platform. In the core technology, Flex 1.5 adds features in two key areas: more expressive applications are possible with new charting components and improved Data Grid and List components, and easier styling and skinning. Development is streamlined with faster performance, easier layout, and more deployment options. Flex 1.5 also adds Macromedia Central support so you can deploy your applications in the browser or on the desktop. In the future, Macromedia will release a .NET version that allows the same Flex code to run natively in the .NET environment. Also in future versions, Flex will allow developers to easily build occasionally-connected clients with data synchronization and offline access to data, Flex will include enterprise portal integration and offer tools for application monitoring and tracking usage of Rich Internet Applications. Beyond these future plans, Macromedia is committed to growing the Flex platform to embrace key performance improvements, more connectivity options, and deeper integration with other desktop applications.

Flex and Standards

Macromedia contributes to and supports industry standards. Flex extends the following industry standards:

J2EE and .NET platforms. Flex runs on Java application servers. Future versions will also run natively in the .NET Common Language Runtime (CLR).

XML. MXML is XML-based and consistent with related standards initiatives, such as W3C XForms.

XML namespaces. The xmlns attribute is an MXML tag that specifies an XML namespace. XML namespaces let you refer to more than one XML tag vocabulary in the same XML document.

The Flex event model. The event model is a subset of Document Object Model (DOM) Level 3 Events, a W3C working draft. DOM Level 3 defines an event system that allows platform and language-neutral registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event.

ECMAScript/JavaScript. Macromedia ActionScript tightly based on the ECMAScript profile 262 edition 4, the same standard that JavaScript is based on.

Web services. Flex applications support web service requests and results that are formatted as Simple Object Access Protocol (SOAP) messages and are transported over Hypertext Transfer Protocol (HTTP). Flex also supports REST web services.

Cascading Style Sheets (CSS). MXML styles are based on the CSS standard.

Java objects. MXML tags interact with server-side Java objects, including plain old Java objects (POJOs) and JavaBeans.

Scalable Vector Graphics (SVG). Flex applications render SVG vector drawings.

SWF. Flex applications are compiled into the Macromedia Flash file format, SWF, which is a published specification.

Flex and Macromedia Flash MX 2004

Flex opens up Rich Internet Application development to enterprise IT developers who prefer a code-based approach. The Flex presentation server and Macromedia Flash MX 2004 are highly complementary, and the most successful application development teams will use both products together. Flash developers will work collaboratively with Flex developers to create graphic assets, custom components, and component skins for highly branded content. Flex can embed SWFs compiled in Flash MX 2004, and because Flex and Flash share a common component format (the SWC file format), developers can create highly customized components in Flash MX 2004 and use them in their Flex applications. Since most Flex developers are more comfortable using code rather than the drawing tools in Flash MX 2004, developers can create components from scratch or skin them with a custom look and feel, entirely within Flex code. Since most Flex developers find this a more natural way to work, this is the suggested approach for building components for Flex.

Flex and Macromedia ColdFusion MX

Many ColdFusion developers seeking to build Rich Internet Applications using a code-based approach may want to use ColdFusion and Flex together. Many organizations will find that using ColdFusion to rapidly create server-side data access logic and web services and Flex to create a rich client user interface is the fastest way to deliver Rich Internet Applications. The Flex presentation server can be installed separately on the same physical server as ColdFusion or within the servlet engine that is embedded in ColdFusion MX 6.1 Enterprise.

Flex and Flash Remoting
Macromedia Flash Remoting offers a connection between Flex applications and your Java objects, using the Action Message Format (AMF) or AMF encoding. In addition to SOAP and XML over HTTP, AMF serves as an alternative method for sending data between Flex and the Flash client. Flex includes Macromedia Flash Remoting with each Flex license. A Flex client application can communicate with the server using XML over HTTP, SOAP, or AMF, the Flash Remoting binary protocol. Because it is a binary protocol, AMF can improve the performance of your application, especially when manipulating large result sets.

Flex Benefits


Drive ROI from better end-user experiences by enhancing the impact of the presentation tier. Deliver applications that increase revenue and reduce costs with intuitive, compelling user interfaces, reduced network and server utilization, and enterprise integration.


Develop Rich Internet Applications with an intuitive programming model, work with your IDE of choice, and keep your current web development workflow intact. Leverage industry standards for interoperability, including XML, SOAP, and ECMAScript. Build great end user experiences while capitalizing on existing skills, tooling, and technology.


Use a robust programming model, comprehensive tooling, and runtime services to rapidly create Rich Internet Applications that deliver enterprise-class performance and high ROI.

The Flex Application Framework features a powerful programming model, an innovative class library, and comprehensive extensibility.

Flex development is open and flexible, letting you work with your tool of choice. Take advantage of powerful debugging, profiling, and monitoring capabilities to deliver high-performance, high-quality applications.

Powerful runtime services help you access and use enterprise data as well as build, test, and deploy on your current infrastructure. Deliver experiences without compromise.

Sunday, February 12, 2006

Introduction to web 2.0
Web 2.0 is a term referring to the ongoing transition to a full participatory Web, with participation including both humans and machines. Web 2.0 is characterized by the following themes:

The Read/Write Web: In which the Web is seen as a two-way medium, where people are both readers and writers. The main catalyst for this is social software, allowing communication and collaboration between two or more people.

The Web as Platform: In which the Web is seen as a programming platform upon which developers create software applications. The main catalyst for this is Application Programming Interfaces, or APIs, allowing communication between two or more software applications.

It is important to recognize, however, that "Web 2.0" is not anything other than the evolving Web as it exists today. It is the same Web that we've had all along. But the problems, issues, and technologies we're dealing with are in many ways different, and so using the term "Web 2.0" is recognition that the Web is in a constant state of change, and that we have entered a new era of networked participation.

Web 2.0 provides a dynamic behavior of an application. This means you can include the BBC’s latest news headlines on your site. It means people can keep track of your job vacancies on their desktop. It means instead of having a static map on your contact page you can include a map from Google that can be annotated, dragged around, and zoomed in and out. Ultimately, it means people will no longer need to get your information directly from your web site.

The Original Web 2.0 Companies
The Four Horsemen of Web 2.0
These four companies known for amazing innovation best demonstrate the essence of Web 2.0. Instead of suffering the fate of the other Dot Coms, they thrived through the downturn by leveraging the principles of Web 2.0. Their success is so widely known that it is now taken for granted, while their databases of customer information have become a growing privacy concern.

Google provides many characteristic Web 2.0 services: Blogger, Adsense, Maps, Search, Base, Gmail, GTalk, Reader, and Statistics. Each of these services either exploits the read/write Web or the Web as Platform.

Nearly all of the services that Yahoo provides leverage Web 2.0 principles: Mail, Music Downloads, Movie Recommendations, Shopping, Maps, Local.

Amazon's Affiliates program, Reviews, People Who Bought This Also Bought..., and wish list sharing were early and influential Web 2.0 services. Their new Mechanical Turk service is another Web 2.0 gem.

eBay provides many buyer and seller services that aim for greater participation. Their API is one of the most successful, and the network effects they enjoy from their large user base are unrivaled.

New Exemplars of Web 2.0
New companies and services embracing the principles of Web 2.0.
These companies are by no means an exhaustive list, but are leading the pack. They provide popular software and services that have proved their worth among the competition.

Flickr is a fast-growing photosharing service that provides a collaborative user interface as well as a powerful API to its content. (Recently acquired by Yahoo!)

Del.icio.us is a popular social bookmarking service. Joshua Schacter, the founder, characterizes his service as a way to remember things. (Recently acquired by Yahoo!)

Jotspot provides several services: Jotspot - the Application Wiki, which allows users to create and share wiki-like web pages. JotLive - a live group note-taking application.

37Signals provides several services: Basecamp - a project collaboration tool and Backpack - a collaborative tool to create sharable web pages.

Digg is a content aggregation service. It provides a mechanism for its many users to "digg" a piece of content, and aggregates them like votes to bubble up the most popular content to its widely-viewed pages. In this way Digg culls the actions of its users to provide value.

Writely is a web-based service that allows for the creation and sharing of documents in a sophisticated word-processor-like interface.

Feedburner is an RSS publishing service. Sites can direct their readers to a feed at Feedburner instead of hosting it themselves; taking advantage of Feedburner's advanced tracking capabilities to provide insight into who is reading your feed.

A practical example: Google Maps
Released in early 2005, Google Maps is a web service from the ever-present search company. On the surface it looks like a web site that has some clever maps you can drag around, zoom into and out of, and so on. But there’s something extra-special going on behind the scenes: Google Maps has an API.

Stafffinders’ contact page, complete with maps.
This allowed Mercurytide to do something special in a recent web site redesign for Stafffinders, a recruitment company. On the contact page we use Google Maps to show the locations of their offices. The maps sit in the middle of the page and fully look a part of the Stafffinders site. For a few hours’ work Stafffinders have highly-detailed maps that people can play around with: you can zoom out to see their offices in relation to one another, and you can drag the map around to find the closest railway station or to see how far the office is from your home. This is Web 2.0 in action.

Friday, February 10, 2006

Avalon is the code-name for the presentation subsystem in "Longhorn." Avalon provides the foundation for building applications and high fidelity experiences in Longhorn, blending together application UI, documents, and media content, while exploiting the full power of your computer. The functionality extends to the support for Tablet and other forms of input, a more modern imaging and printing pipeline, accessibility and UI automation infrastructure, data-driven UI and visualization, as well as the integration points for weaving the application experience into the Windows shell.
Composition of Visual Elements
In computer graphics, composition is the process of combining multiple images into a single image. It can mean anything from the very simple process of showing two pictures next to each other right up to the sophisticated techniques used in the cinema industry, where each frame may be made up of hundreds of images combined using a wide range of visual effects.
All windowing systems support some level of composition. The image you see on your computer screen is composed from many discrete elements. For example, a web browser window typically has many toolbar buttons, an address field, a menu, and a status bar, as well as the main browsing panel. These elements are combined with the window title bar and borders supplied by the OS to form the appearance of the whole window. This in turn will be the composed with any other windows that are currently visible to form the image on your screen. The set of composition techniques a windowing system offers influences the way in which user interfaces can be built. Avalon offers much more sophisticated graphical composition than has previously been available under Windows.

1) Basic Composition in Windows
2) Pseudo-Transparency in Windows XP and Windows Forms
3) Off-Screen Composition
4) Retaining the UI

The new composition model in Avalon removes many of the visual design constraints that applied to most Win32 applications. It also improves performance by making more effective use of modern graphics cards, reducing the frequency with which the OS has to call the application back to keep the display up to date, and enabling a much higher quality of user interface.

One of Longhorn's most interesting technologies for developers is its new XML-based markup language, codenamed XAML (short for eXtensible Application Markup Language, and pronounced "Zammel"). User interfaces in Longhorn applications are typically built using XAML. In this article, we look at how XAML relates to the underlying support provided by WinFX.
XAML user interfaces are built in much the same way as HTML web user interfaces -- you simply create a document with tags for each of the user interface elements you require. Here is a simple XAML user interface: Hello World
This particular example displays a Text element and a Button element, using a FlowPanel to arrange them on screen. These are all classes defined by Avalon, WinFX's user interface framework. The Text and Button elements are self-explanatory. The FlowPanel is an example of a panel. Panels are used to arrange elements according to a particular layout approach. The FlowPanel arranges elements on screen in the same way that text is typically formatted -- elements "flow" through the available space from left to right, moving onto the next line when no more space is left on the current line. The results are shown below. (The first picture shows a window wide enough to contain both elements on one line. The second shows what happens when the window is not wide enough -- the FlowPanel splits the elements across two lines.) Avalon offers a variety of panel types for different layout techniques, including fixed layout, docking, and column-based text flow.

Why a New Markup Language?
You might be wondering why Microsoft decided to invent a brand-new markup language for building user interfaces, rather than using HTML or SVG. One of the reasons is functionality -- Avalon provides many sophisticated user interface features that are not available in HTML, such as scaling and rotation of both text and graphics, and animation. Also, HTML has been developed primarily for use on the Web, whereas XAML's principal target is applications that run directly on Windows (i.e., "rich clients" or "smart clients"). But this still leaves the question of why Microsoft didn't use SVG (Scalable Vector Graphics -- a graphically rich, XML-based markup language.) After all, SVG addresses many of HTML's shortcomings as a rich-client markup language. However, the most powerful reason for devising a new markup language is the very close relationship between elements in a XAML file, and objects at runtime. Unlike any previous markup languages, XAML is designed to integrate directly with WinFX.
XAML is a simple but powerful way of building trees of .NET objects. Because it is based on XML, it is straightforward to create XAML-based markup. This not only makes it easy to build user interfaces by hand, it also makes it relatively straightforward for tools to generate XAML -- in the future, design tools will emerge that are able to export documents and drawings in XAML format. It is also easy to use technologies such as XSLT to transform XML data sources into XAML documents. XAML enables a clean separation of user interface from code through the use of code-behind files, while its close integration with WinFX makes it very easy for code to manipulate the user interface elements defined in the markup.

“WinFX: An All-Managed API”
In Longhorn, Win32 will no longer be the principal API. It will, of course, continue to be supported; 20-year-old DOS applications still run on the latest version of Windows, and likewise, Win32 applications will also continue to work for the foreseeable future. But just as DOS and 16-bit Windows applications were superseded by Win32 applications, so in Longhorn will Win32 become the "old way" of doing things. In Win32's place is a new API called WinFX (pronounced "Win Effects"). WinFX is a significant milestone in the history of the Windows API, as it puts .NET at the center of the platform. While Win32, the main API for previous versions of Windows, is a C-style API, WinFX is designed primarily to be used by .NET languages. In other words, it is a managed API. Moreover, it is a superset of the existing .NET Framework.
Judging by the discussions on various newsgroups and mailing lists, many seasoned Windows developers seem to have a hard time believing that Longhorn's new APIs really will be pure .NET. The topic has come up almost every day on the various WinFX Microsoft newsgroups since the API's announcement, and it seems that many people think that a .NET-only API cannot possibly exist, and that there must be a 'real' Win32 API underneath it all.
The idea that Win32 must be lurking somewhere beneath the covers presumably originates in part because of the way today's .NET Framework is implemented. Many of the classes in the Framework Class Library are wrappers on top of Win32 functionality. For example, Windows Forms puts a .NET face on classic Win32 features such as HWND, MSG, and WndProc. Likewise, the various classes in System.Net and System.Net.Sockets ultimately wrap the services provided by the Windows Sockets API in Win32.
Pure Managed Functionality
The ability of WinFX to link directly to system services, bypassing Win32, is not the only way in which new Longhorn features can be exposed in WinFX but not Win32. Many features will be implemented entirely in managed code with no need for any help from lower levels of the platform at all.
There are already many examples of pure managed features in the shipping versions of .NET Framework. For example, you can make extensive use of the XML functionality in the current versions of .NET without the framework ever making a call into Win32. Likewise, although ASP.NET integrates with IIS in the Win32 world, the vast majority of the value that it adds over the unmanaged ISAPI extension mechanism is implemented in managed code. The ASP.NET page caching mechanism has no Win32 equivalent; neither do the key parts of its object model. (HttpRequest, HttpResponse, and friends may look reminiscent of the classic ASP objects, but they are not wrappers. They were designed to look very similar to the ASP object, in order to ease the transition to ASP.NET, but they are all implemented entirely in managed code.)
The same will be true for much of the new functionality in Longhorn. There will, of course, be some things which involve new platform features all the way from WinFX's public API right down to kernel mode-- the new 'Avalon' graphics model being the most obvious example. However, there will be many more features implemented entirely in managed code. For example, although Avalon relies on platform support at all levels for performance reasons; a considerable amount of its functionality will reside entirely in managed code. (It would be rather inefficient if every single interaction your code had with Avalon objects caused calls all the way down into the lowest levels of the OS.)

Wednesday, February 08, 2006



AJAX, an acronym for Asynchronous JavaScript and XML, is the latest technology buzzword. Asynchronous means that you can make a request to a server via Hypertext Transfer Protocol (HTTP) and continue to process other data while waiting for the response. This means, for example, that you can make calls to a server-side script to retrieve data from a database as XML, send data to a server-side script to be stored in a database, or simply load an XML file to populate pages of your Web site without refreshing the page. However, along with all of the benefits, AJAX sparks some unquestionable debate over issues with the Back button.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

The traditional model for web applications (left) compared to the Ajax model (right).
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

AJAX & Interface Design

When any new technology undergoes fast and widespread adoption, there’s always an opportunity for unintended misuse. So it’s no surprise that the World Wide Web has seen its fair share of mishandled technologies:
• Download-heavy Java applets for simple page navigation
• Flash movies for superfluous intro animations
• Frames that disable simple book-marking and URL-sharing
• The overuse of images when simple HTML text would do
Some of these technologies have been permanently scarred by excessive misuse. Flash is synonymous with Skip Intro and Java applets within Web applications are often shunned.
Now as a flurry of interest in AJAX sweeps the Web, it’s worthwhile to consider the design implications of this technology lest we end up with “Skip AJAX” in the future.

• Fast & Incremental

AJAX enables faster, more responsive Web applications through a combination of asynchronous Javascript, the Document Object Model (DOM), and XMLhttpRequest. What this means for Web interface designers is that a DHTML-based Web application can make quick, incremental updates to a user interface without reloading the entire screen. In the AJAX model JavaScript calls to the server can update a single element in the UI with data retrieved from a server. Because the full screen does not need to be reloaded, the application is much more responsive to user actions.

Of course updating only certain elements of a Web application interface is possible without AJAX. If an application is designed using frames or iframes, specific content within a frame can be refreshed with server-side data without affecting the rest of the interface. But with AJAX, just about any element defined with the DOM can be dynamic and data can be loaded in the background without user action –making it readily available if needed. (The poster-child of this process is Google Maps, which loads potentially useful map images behind the scenes.)
AJAX allows every element within a Web interface to be individually and quickly updated without affecting the rest of the interface. This, of course, is not what most Web users are accustomed to. Initiating an action within most Web sites triggers the inevitable blank screen and page loading process. Though not very responsive, the full-page update makes it very clear to users that their action has resulted in a reaction and that a response will be available as soon as the page is refreshed. Because AJAX-based updates are very fast and incremental (often affecting only a small portion of the UI), users may not notice them -especially when they are used to seeing full-page rewrites.

• Communicating Change

In order to communicate content updates to users, many AJAX applications have adopted attention-getting techniques to highlight interface changes. Color change and animation are two of the most common approaches.

Using color alone to indicate change requires establishing significant contrast between the updated element and the rest of the interface. Colors that sit opposite each other on the color wheel (referred to as contrasting colors) are good candidates for creating contrast. When used with equal brightness, these colors have a tendency to compete with each other for attention (a phenomenon referred to as simultaneous contrast). As a result, they can be used effectively to bring attention to areas of change.

Animation is also effective because of our instinctual attraction to motion. Incorporating a simple animation in an interface lets users know something is happening in response to their action. 37signals’ yellow fade technique (below) uses a combination of both color change and animation to highlight updated interface elements. Animation can also be used to slow down an interface update to make sure users notice it. Though this approach may seem to contradict the responsiveness that makes AJAX applications great, if users don’t know their change has been made they may assume “no responsiveness”.

In addition to communicating to users that an update has been made after they have taken an action, it’s also practical to communicate pro-actively and let them know what response their action will trigger. Jamie Hoover’s form groups (below) define the area where an update will occur through a single-pixel bounding box. Change the value of the drop-down menu and the bounded area is updated.

It’s also useful to note that quick updates within a Web application may be too pronounced. When a large amount of content is added to a Web page, the screen may “jump” (to use Eric Costello’s term) to make room for the new elements. This behavior may result in a loss of context for users as they find themselves needing to scroll up and down to find their place again. Minimizing the amount of screen “jumps” helps to retain valuable context.

• Lessons from the Desktop

Though communicating change in the interface before and after a user action may seem a bit excessive, it is a direct result of Web applications absorbing more of the rich interactions that have been available in desktop applications for years (drag and drop, auto completion, responsive & incremental updates, etc.) coupled with the fact that Web users are not accustomed to such interactions online.
In 2001, I wrote a paper titled Design Considerations for Web-based Applications that tried to bridge the gap between Web application and client application interface design guidelines. Client application graphical user interface (GUI) guidelines did not cover the interaction possibilities available on the Web (hypertext, etc.), nor did they take into account the conventions and behavioral patterns that emerged as the Web became widely used. Available Web usability guidelines, on the other hand, were not flexible enough to accommodate the new levels of interaction needed within Web applications and often were not appropriate because a Web applications user's motivation differs from a Web site users' goals. The inadequacies of these existing guidelines, in my mind, necessitated the development of new Web application-specific interface design principles.

Though the guidelines themselves have become a bit dated, the underlying principle is valid: a lot of the interaction problems that come up when designing AJAX and other types of Rich Internet Applications have been solved before in desktop applications. And the right solution is often a marriage of existing client and Web interface guidelines or patterns.

Though some might argue that Web application guidelines will emerge organically online via mimicry, we run the risk of “standardizing” non-optimal interactions: not confirmed with user testing and not leveraging years of client application design. For instance, Jeff Veen brought up the difference in documenting Web site designs (as pages) and Web application designs (as states, sequences, etc.). As Dave Heller pointed out, desktop application design documentation can be effectively leveraged to meet this need.

• Keeping Conventions
While leaning on client application interface design solutions is valuable, we can’t lose sight of exiting Web conventions when developing Web applications. Though auto-saving form elements is possible with AJAX (each input can be sent over to the server as a user fills it in), removing the Submit or Save button is likely to cause users to question whether or not their data was stored. Likewise, because Web users have the back button available to them at any time, ensuring changes they have made to content via AJAX are visible when they navigate back is important.

As AJAX applications become more widespread and users begin to expect more of the rich interactions they enable, some of the over-communicating happening today may not be necessary. Until then, however, it’s necessary to consider the expectations users have and meet them accordingly.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Is Ajax the right choice for your Internet Application?

Ajax is a methodology for making Rich Internet Applications(RIA) using proven technologies. It combines the strong points of Javascript, XML, CSS, XSLT and most importantly: the XMLHttpRequestObject. It becomes really powerfull if you combine it with a serverside scripting language and a database. If you never have made a Internet Application this may seem a long list but don't worry about that. You will need most of them anyway if you are serious about developing Webapplications.

Ajax biggest competitor in the RIA-community is Flash. Flash is around for a few years now and will probably stay here, but it has some big disadvantages. The Macromedia product doesn't let you manipulate every element on the page, only the elements in the Flash applet. And another big disadvantage is that Flash is owned by one company, this is known by economist as a lock-in. If they decide to not longer supper a feature that you use, you will have to be very creative. However the graphics of Flash are superb and Flash is very wide spread as you can check for yourself here. Ajax on the other hand allows you to manipulate every object on and of the screen and is also cross-browser compatible. The biggest disadvantage is that it is only supported by the latest browsers. You can always check the latest information about the browsersupport here. For me the biggest advantages over Flash are that I have one communication file that I use for every application I make and it is really easy to integrate in your CMS. Recycling at its best, isn't it?

If you use Ajax properly it can greatly reduce the size of communication between your server and the client. You will only need to send information of a couple of hunderd bytes whereas downloading the whole page with one imaga will cost you at least 30 kB. This will lead to more speed. And speed as you know,is a very important factor for user comfort. In fact researchers at IBM found that you have less then 10 seconds to hold the full attetion of the user. Beyond 10 seconds users would try to engage in another task, such a reading a magazine, while also using the webapplication. But even worse, you only have a split second for maximimum productivity of your user. The end conclussion is faster is better and this is the specialty of Ajax. Immediate respons at user actions. Given the fact that it is difficult to draw with Ajax I would recommend you to use Flash if your site is heavily build on animation. In the other case use Ajax, and you're lucky combine the strength of both of them and you will have a really good Rich Internet Application.

Why is AJAX so hot?

Google deserves the credit for that. Google has kept surprising users with amazing user interfaces on Gmail, Maps, Suggest and what not. We saw GMail, we said "Wow this GMail interface is awesome!", assumed that the Google guys had worked very hard on their Javascript and forgot about it. We knew there was some bigger explanation to it, but we didn't care.

However once this Google approach got a name and a following, it could not be ignored. It now became something that every techie had to atleast be aware of.

As most developers would know, even making a basic HTML + CSS app work the same way across Opera, Firefox, Netscape and IE, is no mean task. If you want to support multiple versions of each browser, things become even worse. Now if my HTML + CSS is struggling, how am I supposed to make my complex javascript work across browsers? And that too when there currently are no standards behind AJAX.

With many users moving to fast broadband connections, making server trips isn't as bad today, as it was a few years back. So making the app use XMLHttpRequest and reducing old fashioned server trips isn't much of a benefit if is going to mean that my development time will go up significantly. Also for serverside development, I have compilers, debuggers, IDEs, components that I can plug in and so on...for client side development there isn't much available. So it is very likely that I could end up creating 100s or 1000s of lines of irrepairable Javascript mess.

Will AJAX Prevail?

Despite the cross-platform challenges -- and some developers point out that there is little reason for Microsoft to make its browser completely compatible with Firefox or Opera -- this new model shows promise. AJAX applications can have much if not all of the functionality of client-side applications. Many programmers react with surprise when they see editors such as Bitflux, FckEditor, or Kupu written entirely in JavaScript, but applications such as these are likely to become commonplace, and even more features are bound to emerge.

Some companies see an opportunity here. Thomas Lackner's development group at ModernMethod is rolling some of its development efforts into an open source library Lackner calls SAJAX, short for Simple AJAX. JackBe, on the other hand, sells a collection of small libraries that abstract away many browser incompatibilities. A programmer can add Excel-like spreadsheets or forms to a Web page and the JackBe libraries will handle much of the interaction with the client.

Which brings us back to the future as the Web finally discovers what Eich and the original team at Netscape imagined long ago. When asked what held it back, Eich speculates, "It was hampered by incompleteness, a rush to standardize, the browser wars killing Netscape, and a dependence on Java to do 'real graphics' and 'real network input/output.'" Now that JavaScript has matured beyond those problems, Eich is enthusiastic to see what comes next.

Pros, Cons & Criticism


• Interactivity

Ajax applications are mainly executed on the user's machine, by manipulating the current page within their browser using document object model methods. Ajax can be used for a multitude of tasks such as updating or deleting records; expanding web forms; returning simple search queries; or editing category trees -- all without the requirement to fetch a full page of HTML each time a change is made. Generally only small requests are required to be sent to the server, and relatively short responses are sent back. This permits the development of more interactive applications featuring more responsive user interfaces due to the use of DHTML techniques.

• Portability

Ajax applications utilise well-documented features present in all major browsers on most existing platforms. Though this situation could feasibly change in the future, at the moment, Ajax applications are effectively cross-platform.
While the Ajax platform is more restricted than the Java platform, current Ajax applications effectively fill part of the one-time niche of Java applets: extending the browser with lightweight mini-applications.

Cons & Criticism

• Usability Criticisms

One major complaint voiced against the use of Ajax in web applications is that it might easily break the expected behavior of the browser's back button (see Jakob Nielsen's 1999 Top-10 New Mistakes of Web Design). The different expectations between returning to a page which has been modified dynamically versus the return to a previous static page might be a subtle one. Users generally expect that clicking the back button in web applications will undo their last state change and in Ajax applications this might not be the case. Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that populate the history used by a browser's back button. Google Maps, for example, performs searches in an invisible IFRAME and then pulls results back into an element on the visible web page; it is possible to track user behaviour via callbacks which are called whenever the back button is pressed, restoring the application state that existed at the time.
A related issue is that the use of dynamic web page updates makes it difficult for a user to bookmark a particular state of the application. Solutions to this problem have likewise begun to appear, many of which use the URL fragment identifier (commonly known as the anchor, or the portion of the URL after the '#') to keep track of, and allow users to return to, the application in a given state. (Many browsers allow JavaScript scripts to update the anchor dynamically, which allows the Ajax application to update it in parallel with the contents of the display.) These solutions also address many of the issues related to lack of back button support.

• Response-time concerns

Network latency — or the interval between user request and server response — needs to be considered carefully during Ajax development. Without clear feedback to the user [1], smart preloading of data [2], and proper handling of the XMLHttpRequest object [3] users might experience delay in the interface of the web application, something which users might not expect or understand. [4] The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to these latency issues.

• JavaScript must not be disabled
While no browser plug-in is required for Ajax, it requires users to have JavaScript enabled in their browsers. This applies to all browsers that support Ajax except for Microsoft Internet Explorer which additionally requires ActiveX to be enabled along with ActiveScript. The XMLHTTPRequest object used in Internet Explorer is ActiveX. Security settings might cause Internet Explorer to not support Ajax (e.g.: ActiveScript or ActiveX might be disabled). It is possible to use inline frames (IFRAMEs) to avoid this ActiveX problem.

As with DHTML applications, Ajax applications must be tested rigorously to deal with the quirks of different browsers and platforms. A number of programming libraries have become available as Ajax has matured that can help ease this task. Likewise, techniques have been developed to assist in designing applications which degrade gracefully and offer alternative functionality for users without JavaScript enabled .

• Criticism of the Name “Ajax”
There have been some critics of the term Ajax, claiming that Adaptive Path (the consulting firm that coined the term [5]) or other proponents are using it as a marketing vehicle for previously-used techniques [6] [7] [8] [9].


Using Ajax technologies in web applications provides many challenges for developers interested in adhering to WAI accessibility guidelines. Developers need to provide fallback options for users on other platforms or browsers, as most methods of Ajax implementation rely on features only present in desktop graphical browsers.
Web developers use Ajax in some instances to provide content only to specific portions of a web page, allowing data manipulation without incurring the cost of re-rendering the entire page in the web browser. Non-Ajax users would optimally continue to load and manipulate the whole page as a fallback, allowing the developers to preserve the experience of users in non-Ajax environments (including all relevant accessibility concerns) while giving those with capable browsers a much more responsive experience.

Browsers that support Ajax

• Microsoft Internet Explorer version 5.0 and above, and browsers based on it (Mac OS versions not supported)
• Gecko-based browsers like Mozilla, Mozilla Firefox, and Netscape version 7.1 and above
• Browsers implementing the khtml API version 3.2 and above, including Konqueror version 3.2 and above, and Apple Safari version 1.2 and above
• Opera browsers version 8.0 and above, including Opera Mobile Browser version 8.0 and above
• iCab version 3.0b352 and above

Ajax Mistakes

Ajax is an awesome technology that is driving a new generation of web apps, from maps.google.com to colr.org to backpackit.com. But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.

I've compiled a list of the many mistakes developers using Ajax often make. Javascript itself is a dangerous UI technology, but I've tried to keep the list to problems particular to Ajax development:


1. Not giving immediate visual cues for clicking widgets.
If something I'm clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn't trigger the normal web UI for new page loading.

2. Breaking the back button

The back button is a great feature of standard web site user interfaces. Unfortunately, the back button doesn't mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app.

3. Changing state with links (GET requests)

Ajax applications introduce lots of problems for users who assume GET operations don't change state. Not only do state changing links cause problems for robots, users who are accustomed to having links drive navigation can become confused when links are used to drive application state changes.

4. Blinking and changing parts of the page unexpectedly

The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don't want to concentrate on harkens back to days of the html blink tag.

5. Not using links I can pass to friends or bookmark

Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I'm seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason.

6. Too much code makes the browser slow

Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially poorly coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn't mean the problem has disappeared.

7. Inventing new UI conventions

A major mistake that is easy to make with Ajax is: 'click on this non obvious thing to drive this other non obvious result'. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that's not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.

8. Not cascading local changes to other parts of the page

Since Ajax/Javascript gives you such specific control over page content, it's easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don't replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.

9. Asynchronously performing batch operations

Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.

10. Scrolling the page and making me lose my place

Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I'm reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place.

What's next after AJAX

The rapid spread of the term AJAX (Asynchronous JavaScript and XML) -- from Weblog to Wall Street Journal within weeks! -- might lead developers to assume it's a breakthrough that heralds the death of desktop applications. There's certainly a kernel of truth in that: The recent spate of new Web applications under the AJAX banner have redefined end-users' expectation of what's even possible within a Web browser by offering smooth scrolling, incremental updates, and more responsive input forms (see " AJAX breathes new life into Web apps").

Nevertheless, so-called fat-client UIs still retain one fundamental advantage over Web UIs: real-time event notification. AJAX alone does not address IM, stock tickers, and other collaborative applications that require "push" data streaming.

The key goal of AJAX-style applications is to decompose jarring transitions that download an entire new Web page into a series of smaller, more frequent transactions. Developers consider AJAX to be "asynchronous" because data can be updated without interrupting the user. For example, Google Maps dramatically reduces the perceived latency of scrolling a map by only downloading the newly visible tiles and moving the rest.

In the middleware community, however, the formal definition of asynchrony refers to the ability to send a message at any time, in either direction. AJAX provides the upstream direction, but HTTP would appear to make server-initiated transmission impossible.
Fortunately, clever developers have exploited a loophole in HTML to address this. Browsers are designed to display pages incrementally while downloading pages from slow Web sites. Using hidden frames and JavaScript tags, HTTP can be (ab)used to hold open a long-lived response connection, allowing an application to stream data into the browser.

The simplest way to exploit this is to turn the browser into a 21st-century "green screen" dumb terminal. Manuel Kiessling's open-source ARSC (A Really Simple Chat) uses AJAX techniques to send input lines upstream, whereas a modified HTTP server that holds open thousands of simultaneous connections rebroadcasts the chat stream to other users. Another example is KnowNow's SpeedReader product, which is useful for alerting employees to relevant RSS news items.

The subtler and broader implication of combining AJAX with asynchronous event notification is to extend publish-and-subscribe application integration across the Internet. Several open-source platforms provide powerful abstractions for connecting fully interactive Web UIs to enterprise applications and Web services. Nevow (nee Woven LivePage) and Pushlets extend the event loop familiar from model-view-controller GUIs for Python and Java, respectively. Mod_PubSub is designed as an event bus that uses URL path names as topics to implicitly invoke programs written in a wide range of languages. Commercially, KnowNow's LiveServer provides enterprise-class scalability (and even connects to and from Microsoft Excel spreadsheets).

The clear benefits of migrating desktop applications to the Web in terms of maintenance, security, and scalability must be weighed against the costs of slower response times, limited interactivity, and less-than-beautiful graphical interfaces. With AJAX, push technology, and the ubiquitous plug-ins for PDF and Flash, the Web is closer than ever to becoming a viable default platform for application development.