Copyright 2001-2004 Fourth World Media Corporation
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 dedicated applications.
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.
The term Web app has been used to describe applications that live inside a Browser window. This paper introduces the term Net app to describe Internet-connected applications implemented as independent processes with their own user interface.
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 (Net Apps), 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.
2. Inside the Browser or Outside: Viewing vs. Authoring
When deciding among alternatives for implementing connected-computing applications, it is useful to consider the nature of the task the application will support. The Browser presents unique strengths and weaknesses, and not all tasks are optimally supported once we examine its core functionality.
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. 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
Controls - Behavior
Given these considerations, we can see that some applications can work well inside a Browser window, but 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 creating data. In contrast, successful Browser applications are more commonly oriented toward the viewing 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 perceived as generally acceptable to even large corporations.
However, few security restrictions exist for embedded objects like ActiveX controls and Director XTRAs, and such objects are not unusual on the Web.
In most Browsers, by default the user must explicitly 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 executable 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 unique to that OS family cost those corporations US$3.6 billion cleaning up after Code Red and SirCam alone.
In terms of actual security, 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, including HTTPS, to provide similar levels of security for outgoing data.
In practical terms, the risks of running a standalone Net 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 over the 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 more valuable as a business tool, delivering timely rich-media content to employees.
When designing custom Net apps, you can mix and match these and other technologies in much more flexible ways than can be achieved in the Browser. Table 1 provides a brief listing of popular Internet protocols, noting those supported in the most popular Browsers:
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 Net apps should also run on as many platforms as possible.
Even corporate intranets, where internal staff often determines specific machine configurations, can 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. A number of cross-platform tools exist to allow extremely rapid development of 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.
A collection of additional sources of information related to Net apps is available in the Web version of this document:
Footnote: 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 update this paper. If you find interesting links about this sort of thing on the Web, please send the URL to NetApps@fourthworld.com