Beyond the Browser
Rediscovering the Role of the Desktop in a Net-centric World
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.
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.
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.
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
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.
Figure 3: Radio controls, showing the target area outlined in red.
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:
||HyperText Transfer Protocol (Web)
||File Transfer Protocol (File transfer)
||Simple Mail Transfer Protocol (Email)
||Network News Transport Protocol (Newsgroups)
||Internet Relay Chat (Chat)
||(File transfer, distributed computing)
||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:
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:
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
Ideal for data presentation
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
> --- Richard Gaskin <Ambassador@FourthWorld.com>
> > 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
ora.com -- O'Reilly site
Part II. Projects
6. Jabber: Conversational Technologies
7. Mixmaster Remailers
10. Red Rover
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.
You can shove it! Why 'Push' is now ripe (again)
Senior Executive News Editor, ZDNet News
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
- synchinh - multiple devices, web, apps
rich-media authoring - for the post-literate world
Popular Net Apps
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 NetApps@fourthworld.com
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
Code Red cost estimated at $2.6 billion
SirCam worm still a serious threat
 B. Boehm, Software Engineering Economics, Prentice-Hall, ISBN 0-138-22122-7, 1981.
 S. Johnson, Objecting To Objects, Invited Talk, USENIX Technical Conference, San Francisco, CA, January 1994.
 C. Jones, "Programming Languages Table, Release 8.2", March 1996, http://www.spr.com/library/0langtbl.htm.
 M. Lutz, Programming Python, O'Reilly, ISBN 1-56592-197-6, 1996.
 R. O'Hara and D. Gomberg, Modern Programming Using REXX, Prentice Hall, ISBN 0-13-597329-5, 1988.
 J. Ousterhout, Additional Information for Scripting White Paper, http://www.ajubasolutions.com/people/john.ousterhout/scriptextra.html.
 J. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, ISBN 0-201-63337-X, 1994.
 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.