Fourth World Logo Fourth World Media Corporation
  Embassy Services Products Resources   About Fourth World Contact  

Beyond the Browser

Rediscovering the Role of the Desktop in a Net-centric World

Richard Gaskin
Fourth World Media Corporation

First draft published: 24 June, 2001

©2001 Fourth World Media Corporation

This document may be distributed freely only in its complete, unmodified form, including this header and copyright information.

While the Web browser may be ideally suited for viewing data, its design is not optimized for creating or manipulating data. With the advent of Web applications, many interface designers have been limiting their work to those systems which can be delivered in a Browser window. Using a wider range of tools, technologies, and protocols, a designer may find some tasks better served through Net-aware desktop applications.

Keywords: web applications, application design, distributed computing, Internet protocols, scripting, systems programming, user interface design.

Many articles have been published extolling the virtues of Browser-
based applications, but few (if any) of these were written in one...”

1. Introduction: The Internet is not the Web

The Internet is used for a wide variety of tasks, from transferring files to sending email. These tasks also include viewing text, graphics, and rich-media content using the World Wide Web. While the Web is a relatively recent newcomer to the range of Internet services, its popularity has eclipsed the other services of the Internet. Today, many lay people think "the Web" and "the Internet" are synonymous.

With the growing ubiquity of the Web, many application designers have felt that the next logical step is to migrate tasks from desktop applications to the Web Browser window. Some tasks are well suited for the Browser, taking advantage of users' confidence with the inherent simplicity of the Browser environment.

But this same simplicity also introduces unique challenges, from interface layout to handling protocols other than HTTP, which can be handled well in traditional application design.

Word processing and many other traditional computing applications involve tasks which are essentially solitary in nature; the files may benefit from being shared among, and even modified by, multiple users, but the nature of the task itself (crafting a spreadsheet, retouching a photo, writing a letter) is generally something one does by themselves.

Then there are tasks which are inherently group-oriented, which take on additional value when connected to multiple computers. Email, for example, has little practical value without other users involved. It is for these connected-computing tasks that the Internet is especially useful, and only a subset of these tasks are optimal when implemented inside a Browser window.

Figure 1 shows a conceptual illustration of various application types. In a modern GUI, all applications are desktop applications, as the desktop is the primary object serving as an enclosure for the user experience. A subset of applications are network applications (NetApps), which use Internet protocols to provide the benefits unique to distributed computing. The Web Browser is one of these, but there are many others, including email, FTP clients, instant messaging, etc.

Venn diagram of application types
Figure 1: Categories of software applications, emphasizing subcategories of network apps.

While the Web Browser will remain a useful option for network applications, the growing popularity of peer-to-peer (P2P) tools like Naptster and the Gnutella network, and messaging tools like AOL Instant Messenger and ICQ, suggest that dedicated applications may be more useful for some tasks.

2. Inside the Browser or Outside: Viewing vs. Authoring

One of the challenges inherent in deciding among alternatives for connected-computing applications is determining which tasks are best served by the Browser and which tasks may be better served by a dedicated NetApp.

Some guidance can be found in the origins of the Browser, examining the specific range of tasks it was designed to support. The Web was invented as a means of allowing researchers to view documents created by other researchers, and with the invention of the graphical Browser these documents could also include graphics and other media. The controls provided in the Browser interface reflect this passive-viewing orientation, focused as they are on tasks involving navigation among Web pages.

With the addition of JavaScript in Netscape Navigator and JScript in Microsoft Internet Explorer, it has become possible to add interactivity to Web pages, allowing both client-side applications like calculators as well as client-server applications such as submitting forms to a CGI application on the server.

The range of user interactions within the Browser have expanded even more with tools like Java and Macromedia Flash. While interfaces created with these technologies may be placed within a Web page, they are not fully integrated into the Browser experience and the disparity between how Browsers behave with HTML-only pages and Flash- or Java-enhanced pages may cause confusion for the user. For example, using the Browser's Back button while viewing Flash media will not take the user to the previous screen layout in Flash, but in most cases it will instead completely remove the Flash element altogether as it loads the previously-viewed page in its place. For this reason, many developers using Java and Flash do so in secondary popup windows which hide the navigation controls, effectively attempting to emulate a desktop application experience within the confines of the Browser.

Such attempts to provide the interaction functionality common in desktop applications meet with a number of limitations. In addition to the disparity between the Browser's inherent navigation functionality and that of the applet residing within it, the designer also faces these considerations:

Controls - Layout

One example of limitations in designing applications in the Browser is dynamic composition, designing control layouts that adjust themselves to fit in windows which can be resized by the user. While common in dekstop applications, dynamic compositions are difficult to implement in a Browser. AOL's New Email form is a good case in point, shown in Figure 2.

Venn diagram of application types

Figure 2: AOL New Email form, shown in the Web version (left) and in the Desktop software.

The limitations of HTML do not allow the primary content region (where the user types their email message) to resize to match the size the user has selected for the window.

Also note that significantly less screen space is devoted to the task the interface ostensibly supports. More than half of the non-task space is altogether unused, with the rest comprised largely of advertisements and other links designed to take the user away from the task at hand. While common in the Web experience, such elements serve to distract from the goal of the page, effectively becomming "anti-features".Another limitation of designing within the Browser is that the while Internet supports a wide variety of protocols for different tasks, the Browser primarily handles only HTTP natively, with some limited support for FTP. Other protocols like SMTP (email), NNTP (newsgroups), Gnutella (file sharing), IRC (chat), and others require Java or a plugin to implement inside the Browser, and are more commonly supported in dedicated applications.

Controls - Behavior

The two implementations of AOL's email interface illustrate another limitation in designing applications in the Browser: many features and controls are difficult or impossible to create using HTML and JavaScript.

While AOL's Web team did a good job of approximating the control layout and essential functionality of the Desktop application, note that the Desktop version supports an array of text styling attributes not present in the Browser-based version (outlined in red).

Other Desktop features not supported in the Web interface include the ability to compress attachments, to have more than one email attachment, and to save an email message without sending it.

Another small but pervasive example of unusual behavior of controls in the Browser is the target area of radio and checkbox controls on Web pages. In desktop applications, both the label and indicator portions of the control are active areas which respond to the user's mouse click, but most Browser implementations limit the target area to the indicator only, as illustrated in Figure 3. This measurably hampers its usefulness according to Fitt's Law, which suggests that "the time to acquire a target is a function of the distance to and size of the target". Only some of the most recent Browsers allow the option for standard target areas for radio controls and checkboxes, and merely upgrading the Browser does not correct the behavior; pages must be rewritten to employ the correct behavior.

Venn diagram of application types
Figure 3: Radio controls, showing the target area outlined in red.


And while users are accustomed to finding commands in the menu bar, in a Browser the menu bar belongs exclusively to the Browser itself. Without the ability for Web apps to modify the Browser's menu bar, designers have adopted a wide range of workaround pull-down menus written in JavaScript. These workaround menus employ a dismayingly broad range of interaction behaviors with little or no consistency between applications, and almost never behave like the "normal" menu bar users are already familiar with. These inconsistencies are compounded by the broadly different implementations of the JavaScript language, as any UNIX or Mac OS user can tell you about their experiences at sites developed exclusively for one platform.

File I/O

The ability to read and write data to files is essential for any application that requires persistent information across sessions. Attempting a modest level of security, Browsers do not normally allow Web pages, or even plug-ins, the ability to read and write to disk. Instead the Browser provides cookies, a mechanism for storing only a small about of data on the client machine which can be used to lookup significant data stored on the server. Each using cookies requires multiple HTTP transactions for each discrete data element delivered to the interface, while a desktop application can access even large amounts of data in milliseconds from local storage.


In addition to the latency introduced by the lack of file I/O support, Web apps are made even less responsive than their desktop counterparts by requiring the interface to be downloaded every time it is used. In contrast, the AOL client provides an excellent balance between downloaded and local components, storing consistent user interface elements on the client machine and downloading new interface elements and timely content as needed.


While the Internet supports a wide variety of protocols for different tasks, the Browser primarily handles only HTTP natively, with some limited support for FTP. Other protocols like SMTP (email), NNTP (newsgroups), Gnutella (file sharing), IRC (chat), and others require Java or a plugin to implement inside the Browser, and are more commonly supported in dedicated applications.

Given these considerations, we can see that applications can work well inside a Browser window, while other tasks can be clumsy or even altogether impractical when attempted outside of an environment dedicated to that task. Many articles have been published extolling the virtues of Browser-based applications, but few (if any) of these were written in one; most were written in a dedicated word processor.

Tasks like word processing, graphics production, and other media-creation tasks provide a useful distinction for the domain of dedicated applications: they involve the creation of data. In contrast, successful Browser applications are more commonly oriented toward the vewing of data.

3. Security Considerations

One of the perceived benefits of choosing to implement an application in a Browser is security. By restricting file I/O, and through encrypted transmissions via protocols like HTTPS, browsers offer a level of security that is percieved as generally acceptable. However, few security restrictions exist for embeded objects like ActiveX controls and Director XTRAs.

In most Browsers, by default the user must explicitely confirm the download and installation of such objects. But doing so changes the discussion of security from anything unique to the browser, and reframes it as a matter of the trust the user feels for the site providing the embedded object.

Given the growing prevalence of excutable code transferred over the Internet, and as illustrated by such OS-specific viruses as Code Red and SirCam, the Browser's role in ensuring security is apparently limited. While many corporations choose Web applications for the perceived security, most of the corporations also choose the Windows family of operating systems, where increasing exploitation of security holes cost those corporations US$2.6 billion cleaning up after Code Red and SirCam alone.

In terms of actual secruity, the informed user should have as much confidence downloading an application from a trusted provider as they would any other object code such as an ActiveX control. Net apps can use the same protocols as Browser applications, such as HTTPS, to provide similar levels of security for outgoing data, and the risks of running such an application are not significantly greater than for many embedded objects commonly included in Web pages.

4. Options for Net App Capabilities: More than P2P

Once we begin to look for development opportunities outside the Browser, we find that most of the press devoted to such alternatives focuses on peer-to-peer file sharing (P2P) exclusively. While Napster and GNUtella have indeed earned significant attention, there's so much more to the Internet than file sharing.

One of the biggest growth categories this last year has been instant messaging, with tools like AOL Instant Messenger (AIM), Microsoft Messenger, Yahoo Messenger, Hotline, ICQ, and others. In addition to providing real-time text exchange between users, most of these applications also provide group chat, file sharing, and other services.

And "push technology", in which users can choose to have specific information sent to them instead of going on to the Web to get it, seems to be on a comeback. While initial proponents of push like Marimba focused on marketing uses, push technology can be even more valuable as a business tool, delivering timely rich-media content to employees.

When designing custom NetApps, you have can mix and match these and other technologies in much more flexible ways than can can be achieved in the Browser. Table 1 provides a brief listing of popular Internet protocols, noting those supported in the most popular Browsers:

Protocol Description
HTTP HyperText Transfer Protocol (Web)
FTP File Transfer Protocol (File transfer)
SMTP Simple Mail Transfer Protocol (Email)
NNTP Network News Transport Protocol (Newsgroups)
IRC Internet Relay Chat (Chat)
GNUtella (File transfer, distributed computing)
Custom New protocols can be developed as needed
Table 1: Popular Internet protocols

5. Tools for Creating Net Apps:

One of the key factors which have contributed to the success of the Web is its inherent platform-independent nature: users can have a similar experience regardless of which operating system they use. Accordingly, any tools used for building NetApps should also run on as many platforms as possible.

Even corporate intranets, where internal staff often determines specific machine configurations, can also benefit from platform independence. It's not uncommon for large corporations to have mostly Windows-based systems, but also have UNIX servers and Macintosh clients in some departments.

Given the many significant differences between OS families, developing multi-platform applications in traditional languages like C++ is cost-prohibitive for all but the largest organizations. In response, new platform-independent languages like Java have emerged. But for the reasons John K. Osterhaut describes in his paper, Scripting: Higher Level Programming for the 21st Century, there are many benefits to using fourth-generation languages (4GLs) for developing Net apps.

Table 2 offers a brief listing of available development tools that provide access to Internet protocols and provide deployment on at least two platforms:

Development Tools
with links to vendor
UNIX Linux Win32 Mac OS

Sun Microsystems

Yes Yes Yes Yes
Yes Yes
REAL Software, Inc.
    Yes Yes
MetaCard Corporation
Yes Yes Yes Yes
Runtime Revolution Ltd.
Yes Yes Yes Yes
Macromedia Director
Macromedia, Inc.
    Yes Yes
Table 2: Net App development tools and languages

If you have a favorite Net app development tool or language not listed here, please let me know.

With all the talk of "Web applications", it seems the role of desktop
applications has been nearly forgotten.

Given the success of SETI@Home, Napster, Gnutella, and the like, clearly
there are still many ways to exploit the benefits of distributed computing
outside of the browser.

Offhand, it seems one could summarize the differences like this:

Web applications
Upside - nothing to download, only need a URL to access
Downside - non-standard UI, no menu bar, limited controls
without resorting to Java or Flash, slower since
the UI must be downloaded and rendered in addition
to content
Ideal for data presentation

Desktop applications
Upside - complete control over UI, generally more responsive
since UI elements generally do not need to be downloaded,
only dynamic media
Downside - requires that the application is installed
Ideal for data manipulation

It seems like there's a good argument here about using the right tool for
the right job: While it's hard to beat the anywhere-anytime quality of a
browser-based app for convenience, for a lot of tasks it's hard to beat the
grace of a dedicated desktop app for a responsive, flexible experience.

While there's been a lot written about the browser replacing the desktop,
few if any such articles were written in a browser. <g> My hunch is that as
things sort themselves out over the next few years there will be a
rediscovery of the usefulness of dedicated apps for data manipulation tasks,
while the browser remains the presentation tool it was designed to be.

Application inside of a Browser window
Desktop applications using Internet protocols
HTTP Yes Yes
Email No Yes
Yes Yes

> --- Richard Gaskin <>
> wrote:
> > I'm looking for two sets of examples:
> > 1. Non-browser network apps that work

>From the table of contents of a Peer-to-peer book on -- O'Reilly site

Part II. Projects

5. SETI@home
David Anderson

6. Jabber: Conversational Technologies
Jeremie Miller

7. Mixmaster Remailers
Adam Langley

8. Gnutella
Gene Kan

9. Freenet
Adam Langley

10. Red Rover
Alan Brown

11. Publius
Marc Waldman, Lorrie Faith Cranor, and Avi Rubin

12. Free Haven
Roger Dingledine, Michael J. Freedman, and David

I suppose you could include MP3 player/rippers (for their link to the
renamed? online music database), and of course the Napster clients. Render
farms? Distributed computing, load balancing server clusters (on Linux)?

Instant Messaging Goes to Work
Better technology will lead more businesses to take advantage of real-time chat applications.,aid,33702,00.asp

You can shove it! Why 'Push' is now ripe (again)
Charles Cooper,
 Senior Executive News Editor, ZDNet News,10738,2685861,00.html

One argument in favor of Browser-based applications is that only the URL need be distributed, while desktop applications must be downloaded, or in the case of larger files delivered on CD-ROM. However, once the Browser-based implementation requires a specialized plugin or large Java object files, this advantage is lost; one could just as easily provide a URL to download a desktop application

6. Resources

- synchinh - multiple devices, web, apps

rich-media authoring - for the post-literate world

Popular Net Apps




Web Sites

putting the web back into perspective as just one of many ways to view the Iternet



Note Most of the assertions in this article are based solely on anecdotal evidence, but not for lack of trying: there seems to be a dearth of published research of the usability differences between the Web and the Desktop experiences. I would appreciate the opportunity to modify this paper based on what I find. If you find interesting papers about this sort of thing on the Web, please send the URL to

J. Ousterhout, "Scripting: Higher Level Programming for the 21st Century"

Excerpt from Chapter 5 in Jakob Nielsen's book Usability Engineering

Response Times: The Three Important Limits

Apple HIG


Code Red cost estimated at $2.6 billion

SirCam worm still a serious threat

[1] B. Boehm, Software Engineering Economics, Prentice-Hall, ISBN 0-138-22122-7, 1981.

[2] S. Johnson, Objecting To Objects, Invited Talk, USENIX Technical Conference, San Francisco, CA, January 1994.
[3] C. Jones, "Programming Languages Table, Release 8.2", March 1996,
[4] M. Lutz, Programming Python, O'Reilly, ISBN 1-56592-197-6, 1996.
[5] Netscape Inc., "JavaScript in Navigator 3.0",
[6] R. O'Hara and D. Gomberg, Modern Programming Using REXX, Prentice Hall, ISBN 0-13-597329-5, 1988.
[7] J. Ousterhout, Additional Information for Scripting White Paper,
[8] J. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, ISBN 0-201-63337-X, 1994.
[9] L. Wall, T. Christiansen, and R. Schwartz, Programming Perl, Second Edition, O'Reilly and Associates, ISBN 1-56592-149-6, 1996.
Sun and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.