| Java >
Guidelines Home Page > Java Look and Feel Design Guidelines >
Part II: Fundamental Java Application Design >
3: Design Considerations
Early in the development process, you must decide if you want to create a standalone application or an applet that is displayed in a web browser. The following figure shows the different environments for running applications and applets.Figure 16 Environments for Applications and Applets
When deciding between an application and an applet, the two main issues you need to consider are distribution and security, including read and write permissions. If you decide to use an applet, you must also decide whether to display your applet in the user's current browser window or in a separate browser window. (It is possible, with a moderate amount of effort, to ship a program as both an applet and an application.)
For an example of an application that uses the Java look and feel, see MetalEdit Application. For an example of an applet, see Retirement Savings Calculator Applet. For a list of additional reading on applets, see Design for Applets.
One solution is the standalone application, distributed on a CD-ROM disc or a floppy disk and installed on the end user's local hard disk. Once the application is installed, users can easily access it. In an enterprise environment, however, maintenance can be complicated because separate copies of the application exist on each user's local computer. Distribution of the original application and subsequent updates require shipment of the software to, and installation by, multiple users.
In contrast, applets are simpler to distribute and maintain because they are installed on a central web server. Using a web browser on their local machines, users can access the latest version of the applet from anywhere on the intranet or Internet. Users, however, must download the applet over the network each time they start the applet.
If you are creating an applet, make sure that your users have a browser that contains the JFC or that they are using Java TM Plug-In. That way, users will not have to download the JFC every time they run the applet. (The HTML required to run an applet differs for plug-in and non-plug-in configurations. Consider providing both options to the user.)
Another issue to consider is whether your software needs to read and write files. Standalone Java applications can read or write files on the user's hard disk just as other applications do. For example, the MetalEdit application reads and writes documents on the user's local disk.
In contrast, applets usually cannot access a user's hard disk because they are intended for display on a web page. Generally, a user doesn't know the source of an applet that has been downloaded from the web, so standard security procedures include preventing all applets from reading and writing to the hard disk. Thus, applets are better suited for tasks that do not require access to the hard disk. For example, a web page for a bank might offer an applet that calculates home mortgage payments and prints results, but does not save files on the customer's hard disk.
You can also use an applet as a front end to a central database. For example, the Retirement Savings Calculator applet enables company employees to select funds for their retirement contribution and update the amount of their contribution in the company database.
The current browser window is well suited for displaying applets in which users perform a single task. This approach enables users to perform the task and then resume other activities in the browser, such as surfing the web.
Applets generally cannot predict which mnemonics are (or are not) in use in the browser itself. Therefore, determine which top-level mnemonics are used in expected browsers and in their associated environments and avoid their use, so no conflicts occur. Examples of top-level mnemonics are menu title names (such as File and Edit).
If your applet involves more than one task or if users might want to visit other web pages before completing the task, launch a separate browser window and display the applet there. This approach enables users to interact with the applet and maintain the original browser window for other activities. Users can open multiple browser windows to do several tasks simultaneously. Navigating to another web page in the original browser window, however, does not affect the applet in its separate browser window.
Designing an applet for a separate browser window is simpler if you remove the browser's normal menu and navigation controls. Doing so avoids confusion between the browser's menu and controls and the applet's menus and controls. You also avoid potential conflicts between mnemonics in the two windows.
|Java Look and Feel Design Guidelines, second edition.
Copyright 2001. Sun Microsystems, Inc. All Rights Reserved.