Web Applications & the Desktop's Future

Life used to be so simple. Back in the old days, we used a Web browser to find a list of links, articles on a certain topic, or an informational Web site for a store. Of course, for real work we would always turn to our trusty desktop installed applications—those stuffy grey windows with lots of icons on the toolbar, such as Excel.

Paul Bleicher

If you worked at a large company, you might have also used a client-server application that worked with a database in the next building. A browser, it was said, could never substitute for a desktop application and had only the most limited of functions when working as a client for a central application/database. All this has changed a great deal, but the most significant changes are still to come.

Striking changes

Today, applications may be installed on a local computer, but many have exchanged their ugly grey shell for bright and shiny "skins" (e.g., the skins of Windows Media Player). Many of the standard desktop programs communicate with databases over the Web and interact with distant applications through Web services and other communication protocols the same way that the client application did in the past.

The client in client-server applications is well on its way to being replaced by the Web browser; many centralized database applications today can be accessed through a Web browser without any compromises in functionality.

These seemingly dramatic changes in traditional desktop applications are being eclipsed by the transformational change in the Web browser experience, and more specifically by the increasing complexity of Web applications.

A Web application is typically located on a central server and is accessed through a Web browser interface. Web applications can totally replace the functionality of a desktop application, while leveraging the greatly enhanced computational power of a server. The pace of the movement toward Web applications suggests that they may eventually replace the desktop application for many of its current uses. To understand this, it is useful to examine some of the typical features of desktop and Web applications.

Let me pause to say that this article will make a number of simplifications and generalizations in describing an enormous scope of information. The world of the Web is complex and Web pages make use of many hybrid and mixed technologies. In addition, those who are not knowledgeable about the technologies discussed would benefit from going to the URLs and trying out the programs mentioned.

Desktop applications

An email client, such as Outlook or Eudora, is a typical desktop application that must be installed on the local computer. The program provides access to emails stored locally on the computer or in a centralized database. In fact, it is often difficult to distinguish whether the program is retrieving emails locally or centrally.

Outlook, like many desktop applications is rich in functionality with many, many options and configurations accessible from toolbars and pulldown menus. We can open many different emails in the program, each occupying a different window, and we can freely switch between these windows. Users expect an almost instantaneous response to any action when they use Outlook—it is a dynamic application. When you click a button or icon to perform an action, there is no delay, and no "refresh" of the screen.

Desktop applications are certainly valuable, and may be irreplaceable for computationally intensive local uses or manipulations of large local files. A good example of this is a sophisticated photo editing program, which would not be useable if each modification of a photograph required a roundtrip to the server and back. However, desktop applications also come with a burden, especially in large organizations.

Each installation of the application may be on different computers, with different installed software. Some software programs conflict with one another, causing computers to crash and creating a support nightmare for IT staff. When a new version of the software is released, it must be installed on each instance of the program, creating a logistic nightmare even when done "automatically."

Connectivity with databases can also be problematic with conventional applications. If these databases are changed, the connection between program and database is broken and has to be rebuilt—again requiring manual intervention.

Enter the Web browser

The first Web browsers were designed to give simple viewing access and limited interaction with databases. Web pages were mostly "static" and any form-based database interaction was somewhat limited. Over time, Web pages began to display more dynamic content, as elements of the pages were embedded in databases and the page itself was assembled by small server-based applications prior to being sent to the Web browser.

In addition to this server-side functionality, the Web client was enriched with Javascript, a scripting language that allowed limited client-side functionality at the Web browser. A typical use of Javascript would be a range check of an entered data value prior to submission to a database.

With the addition of these new server applications and client scripting, the Web experience became significantly richer. Together, they created the first application-like experience for the Web browser, which could function over a low-bandwith, telephone connection. Javascript and server-side applications allowed the development of early eCommerce Web applications like Amazon.com. However, the relatively static nature of the HTML-based Web page did not change much. The rich, dynamic, and fast desktop application far outperform the Web server for typical desktop applications such as word processing and email.

Early Web email programs frequently were no more than HTML or Javascript and connections to an email database. The listing of emails in an inbox looked similar to that in your desktop email program, but if you opened an email or switched mailboxes, the entire page would need to be refreshed. The user experience was a delay of variable time and (especially with slow Internet connections) a slow rebuilding of the page.

There was very little that was dynamic about these Web pages, leading to user frustration. They were good enough for travel, but few were willing to manage a daily load of email in this way. The interface of these HTML-based email clients had a paucity of available functions and customizations. A screenshot of an HTML/Javascript email client can be found at: http://www.netwinsite.com/webmail/walk/index.htm.

Rich Web experiences

Several technologies can come close to replicating the dynamic, rich, and highly functional environment of desktop software on the Web. Interestingly, their paths have taken two different courses: one is on the decline, and the other is on the rise.

The first is the Java applet. While Java is arguably the most powerful and used programming language for server-based Web applications, much of the early interest concerned the Java applet, a program that was downloaded "on demand" to a browser and ran within its own plugin "sandbox" (the Java Virtual Machine, JVM). The Java applet is often recognizable to the user by the dull grey box that precedes its arrival in the Web browser. The applet could create a very rich and dynamic user experience once it was downloaded onto the local machine. A demo of the power of Java applets (especially for NASCAR fans!) can be viewed at: http://www.nascar.com/races/pitcommand/2.0/demo/cup/race/frameset_race_exclude.html.

Despite their potential, Java applets have fallen short of expectations for a number of reasons. First, they arrived early in the history of the Web, when bandwith was very limited to many. The fairly large size of Java applets meant that users sometimes had to wait minutes for a Java applet to be downloaded.

Another reason for the decline of Java applets was the rise of other technologies for rich Web experiences. Most notable is Adobe Flash (and also Shockwave), which provide a very rich, desktop-like environment for the Web browser. Like Java, Flash runs within its own plugin, but the plugin and downloaded program typically require much less waiting time than the Java applet. In addition, Flash uses vector graphics (like gaming applications), which make it possible to display very realistic graphics and movies. Unfortunately, this particular aspect of Flash has been identified and exploited by a wide variety of Internet advertisers, leading to the blocking and interference of Flash downloads by some browsers and "antispam" tools.

Nevertheless, the use of Adobe Flash seems to be on the rise and its use in sophisticated, functional applications is becoming more common. An excellent example of an application that runs in Flash can be seen at http://www.laszlosystems.com/lps/sample-apps/amazon/amazon2.lzx?lzt=html, where a conceptual demo of an Amazon store shows what may be in our (near) future. Try dragging and dropping some records into the shopping cart and checking out. This rich Web experience is beginning to approach that of a desktop application.

Cleaning up with Ajax

In 2005, a relatively simple new technology named Ajax (for Asynchronous Javascript and XML) arrived and created a huge stir in the Web development community. Based in part on older technology, Ajax enabled highly interactive Web pages without the need for a plugin or the download of a large program. The technology allowed the browser to communicate with the server in the background. With Ajax, a Web page could be loaded once and then be modified on the Web browser without the need to refresh. Users could move objects around on the Web page and do database lookups, and screens could dynamically change almost instantaneously.

While many embraced the arrival of Ajax, Google was one of the first to exploit its potential power with Google maps (http://maps.google.com). The maps can be dragged, zoomed, and manipulated in ways not previously possible with static Web pages and without any significant delay. Lesser known perhaps is the Google homepage (http://www.google.com/ig), a personal portal that allows users to drag and drop an endless variety of small applications—all enabled with Ajax.

Office applications on the Web

Finally, we return to email. Gmail is Google's Ajax email client with most of what people need in email, including a highly flexible and fast user interface. It works so well, in fact, that many users have abandoned desktop email clients completely for its Web interface. Although the appearance isn't that far from the original HTML Web email client, its rich user experience is in another class completely.

Google hasn't stopped with email. Recently they announced the availability of a highly functional word processor and spreadsheet, both powered by Ajax (http://docs.google.com). Others have developed Visio-like tools (http://www.gliffy.com) implemented in Flash, and a PowerPoint-like slide program in Ajax (http://www.thumbstacks.com).

While the earliest versions of these programs have limited functionality, you can imagine that this move to bring Office to the Web browser is not escaping notice at Microsoft. These are not merely copies of desktop applications—the Web availability of the documents means that these applications can be much more usable for group collaborations. While desktop applications may always be the choice of power users, it is easy to see that most of us may be even happier with simplified but highly functional Web office applications.

Putting it all together

The best Web experiences today and in the future won't be monolithic examples of a particular Web technology. Rather, they will take the best from each to weave together a rich user experience that meets the particular needs of their users. While one part of a Web page might be a Flash movie, another might be an interactive Ajax form, and yet another might be a sophisticated Java applet. Another trend is the Smart Client, which provides the best of local applications and the web.

If the past is any predictor of the future, we may soon see many more technologies that will continue to transform the personal and corporate computing experience.

Paul Bleicher MD, PhD, is the founder and chairman of Phase Forward, 880 Winter Street, Waltham, MA 02451, (888) 703-1122, paul.bleicher@phaseforward.com www.phaseforward.com.

He is a member of the Applied Clinical Trials Editorial Advisory Board.