Patent Application
20050172018
The invention relates to data management and communications, and particularly to providing access to secure data and communication management tools for an enterprise to a plurality of customers over the Internet which is an insecure communications network. The enterprise described is a telecommunications network, and the tools include management and reporting tools to enable the customers of the telecommunication network to manage and obtain reports and data pertaining to their business on the network.
1. Introduction
Computer user interfaces have undergone dramatic changes over the past forty years, evolving from the simple, line-oriented, prompt-response systems of teletypes, to the forms-based interfaces of dumb terminals, to today's graphics-based, windowing interfaces like Windows 95. The genesis of the modern GUI paradigm in fact dates back some thirty years to work done at the Xerox Palo Alto Research Center which pioneered the usage of the WIMP (Windows, Icons, Menus, and Pointing Devices) interface. The introduction of Apple's Macintosh computer in 1984 brought the WIMP interface to a growing population of personal computer users. The WIMP's evolution from research project to universal standard culminated in 1990 with Microsoft's release of the 3.0 version of Windows. In the many years since its introduction at Xerox PARC, the WIMP interface has been enhanced and refined by decades of human factors engineering, and today's computer users enjoy the benefits of an interface paradigm that has been highly optimized in terms of efficiency, ease-of-use, and intuitive operation.
In 1992, CERN's Tim Berners-Lee conceived of combining a hypertext browser that interpreted a page description language retrieved from document servers accessible by name over a simple network protocol, and so created the framework for the Worldwide Web (take a look at his original vision document, dated somewhere around 1991 or 1992, at http://www.w3.org/pub/www/Summary.html). Shortly afterward, Mark Andreeson (who would later found Netscape) created a GUI-based HTTP browser called Mosaic that set the current standard for browser interface design. Prior to Berners-Lee's innovation, data resident on the Internet was accessible only via arcane utilities such as FTP, Gopher, and WAIS, making it inaccessible to most people. Hypertext proved to be the perfect medium for navigating the disparate datastores of the Internet, and for the first time made Internet-based data accessible to casual computer users.
While this particular application of hypertext was new, hypertext itself had been around for quite some time. The Mosaic interface was in fact quite similar to interfaces commonly used by on-line help systems and computer-based training (CBT) software. The explosion of websites and Internet users however brought hypertext-based information access to a massively greater audience than ever before, and the web browsing paradigm has proven so usable by novice computer users that many aspects of today's browser-based interfaces are being incorporated into the design of transaction processing and decision support systems.
This Application Style Guide details the elements comprising today's user interface standards, and explains how they may be best used to create highly usable application interfaces that offer consistent operation across multiple software application suites.
1.1. User Interfaces and the Web
Browsers have been developed using the standard interface elements of current GUI environments, but have specialized the ways in which those elements are combined to navigate and view hypertext documents. Browsers provide an environment that tightly and seamlessly integrates multiple unrelated applications and have eliminated many key aspects of the standard GUI desktop metaphor.
Web-based applications may be partitioned into four general classes as shown in FIG. 1.
While pure browser-based interfaces are excellent for document retrieval, navigation, and simple forms input, they greatly limit the power and flexibility needed for ease-of-use in transaction processing applications. For complex data entry and editing tasks, simple form entry quickly becomes inefficient and cumbersome to use. For tasks requiring the concurrent manipulation of multiple data views, the flat, document based interface of browsers entails extensive switching between pages, and does not readily support the side-by-side viewing of information gathered from multiple sources. Additionally, form processing is batched, i.e., the user fills out a form and then submits it to a web server for processing. This model does not allow for the far higher, more granular level of interaction required for extensive data manipulation.
In addition to user interface requirements, the web application spaces also differ with respect to network bandwidth constraints as summarized in FIG. 2.
Web browsers have been designed for hypertext document navigation and viewing, an application requiring relatively infrequent user interaction. In hypertext applications, the user retrieves a page, views it for some period of time, and then requests another page some time later. For these types of applications, the batched input model works extremely well. Transaction processing and data manipulation systems must support nearly continuous interaction with the user. For these applications, the batched input model is very slow and inefficient, especially over low bandwidth connections. These applications can provide far speedier and extensive user interaction by integrating local interaction with locally cached data.
Finally, it should be noted that a trend is under way to trim down front-end systems into “thin” clients. In the extreme case, the front-end system provides no data manipulation capabilities whatsoever, but simply collects data from the user and forwards it to the back-end for all processing. These systems are quite similar architecturally to the pseudo-conversational programming techniques employed within IBM's CICS transaction processing environment. In pseudo-conversational programming, the completion of form input triggers the execution of a program that processes that input and terminates immediately after sending the next input form to the user. This style of programming has proven to be far more complex than simple “event-driven” programming in which a continuously running program provides continuous interaction with the user. This complexity arises from the necessity of employing complicated schemes to carry data from each user interaction to the next. In event-driven programs, such “state” information is constantly maintained and updated without need to constantly save and restore after each user interaction.
In summary then, web-based transaction processing systems require elements of both the desktop- and browser-interface paradigms.
1.2. GUI Toolkits
Over the years, the major computing environments have each developed their own user interface standards and software libraries called “toolkits” which allow developers to create applications that conform to these standards, and integrate with the platform's window manager or desktop.
Although these standards differ in specific areas of look-and-feel, they each implement essentially the same user interface and interaction model. All employ the same set of standard user interface elements. (In fact the Java AWT API provides an abstraction for this common interface standard and is implemented over each of the native toolkits so that Java applications assume the look and feel of whatever platform they run on).
Employing a consistent set of user interface elements across an application suite achieves a very high degree of look-and-feel standardization.
1.3. Standard User Interface Elements
As previously mentioned, GUI toolkits share a common vocabulary of user interface elements. The following table lists the most common ones. (A complete treatment of this subject may be found in any of the several user interface style guides listed in the References section of this document.)
1.4. Extended User Interface Elements
In addition to the standard user interface elements, several elements have evolved outside of most GUI toolkits and converged on a common model for presentation and usage. Although not included in the primary GUI toolkits, these elements are widely available from third party providers.
1.5. Web Interface Elements
Web browsers created a specialized user interface standard for hypertext navigation. Although no truly new interface elements were introduced by the web browsing paradigm, the navigation paradigm has proven applicable to a wider range of tasks than simple traversal of hyper-linked documents.
1.6. Key Website Design Concepts
1.6.1. Site Layout
Websites are typically organized in hierarchies, rooted at the site's “home page.” Site layout is quite similar to the organization of documents or outlines where chapter overviews or headings introduce or summarize sub-sections and document detail.
1.6.2. Navigation Bar
Navigation bars are similarly formatted and located in the same relative position on each page, (e.g., on the top, on the left, or on the bottom), providing the user with a consistent set of links to major sections of the site.
1.6.3. Hierarchical Navigation Links
For hierarchically organized sites, it is useful to consistently provide up, down, previous and next links on each page. Such links are especially useful in situations where a user enters a site in its “middle” as the result of having previously bookmarked a page, or linking to a page via a search engine.
1.6.4. Hypertext Links
Keywords appearing within text should be included as links to detailed information about the keyword. This allows for natural, ad hoc document browsing. Explicit link references, e.g., For more information about our professional services click here, is generally discouraged in favor of implicit references, e.g., We provide a variety of professional services.
1.7. Browser Interface Limitations
The browser interface has been optimized for user interaction with hypertext documents. As such, it centers about the retrieval and viewing of pages. Simple form input fits well within the browser framework, since forms are little more than pages with input fields, similar to the fill-in-the-blank, paper forms of the physical world.
Sophisticated data manipulation applications however do not fit cleanly within the hypertext document model. User interaction cannot always be shoehorned into the page-submission-retrieval model. Data manipulation typically works not at the page-level, but at the much more finely-grained record-level, and complex data manipulation applications do not typically lend themselves readily to the linear navigation models of document browsing. Key browser navigation devices such as forward-back buttons have no place in the context of non-linear, event-handling applications providing ready access to a multitude of operations and data views.
1.8. Key Application Interface Concepts
This section describes several of the most fundamental aspects of modern Graphical User Interface design. Good interfaces are:
1.8.1. Modal vs. Modeless Interfaces
Modal interfaces are those that force a user to explicitly switch between single-operation modes. For example, a customer record maintenance system could be designed so that a user must first select an action to be performed such as “add”, “change”, or “delete”. After entering, for instance, “change mode”, the user would specify a customer key, update the desired fields, and then commit the change operation. If the user then wanted to add a new customer record, he would exit “change mode” and enter “add mode”.
Modeless interfaces provide access to all operations at all times. In our example, instead of entering different editing modes, the user would instead work within a multi-function environment in which all functions are readily available. A customer record could, for example, be added and immediately changed without having to switch from “add mode” to “change mode”.
It is generally recommended that modeless interfaces be preferred to modal ones.
1.8.2. Object-Action Interface Paradigm
Modal interfaces are implemented through action-object interfaces. Modeless interfaces are implemented through object-action interfaces.
In the object-action paradigm, a user first selects some object, and then selects from a set of available actions applicable to the selected object-type. For example, modern word processing programs implement copy and paste via an object-action mechanism: The user selects some text (the object); copies it to the clipboard (the action), selects the insertion point (the object); and pastes text from the clipboard (the action). Early word processors implemented copy with a cumbersome, modal operation. Selecting the copy command would place the user into “copy mode” which would prompt “Copy what?” and “To where?”. In other words, copy was implemented as an action-object operation where the user first selected the operation, copy, and then the object, the source text.
Object-action is seen as a far more intuitive analog of real-world object manipulation. In the real-world, for instance, you grab a piece of paper (the object). You cut the paper (the action). You then fold the paper (another action on the previously selected object). People don't typically operate modally in the real world. In the modal, action-object version of paper cutting, you pick up a pair of scissors (enter “cut mode”) and then go looking for paper that needs cutting.
1.8.2.1. Drag and Drop
Drag-and-drop is a graphical implementation of the object-action interface paradigm. An object is selected, and dragging it to another object invokes an action. Drag-and-drop user interfaces are often referred to as object-oriented interfaces since the act of dropping one object on another effectively invokes a method on the receiving object, with the dropped object supplied as an argument to the method.
1.8.3. Maintaining the Context
It is important to maintain a user's sense of continuity when working within a program. Abrupt changes in the flow of an electronic dialog disrupt continuity, impeding user operation of a program. Pop-up message boxes provide a mechanism for calling the user's attention to some condition, while maintaining the context of the underlying window of operation. Full screen messages effectively “pull the rug out” from under a user, wrenching his attention away from the task at hand, which can be confusing and disruptive to the workflow.
Another way in which context can be lost is through excessive nesting. Nesting is implemented through mechanisms such as pop-up child windows or cascading menus. Each successive level takes the user to some deeper level of detail. It is generally recommended to design nested interfaces to a maximum of two levels from the top, since users tend to “get lost” at deeper levels, losing track of the navigational flow.
1.8.4. Forgiveness
Interfaces are made forgiving through support for undo, confirm, and revert operations. Undo reverses the previous operation. Confirm is a request for a user to confirm some action (usually an irreversible one) before its execution. Revert is an operation that discards all changes made since the last save operation (checkpoint).
1.8.5. Providing Feedback
It is important to keep users engaged by an application, and informed about the status of executing operations. Results of actions should be indicated through a consistent status reporting mechanism such as a log window or status line. Currently selected objects should be indicated through visual highlights. It is especially important to indicate long-running operations through mechanisms such as changing the cursor to an hourglass. Progress of exceptionally long-running operations should be communicated through mechanisms such as progress meters.
1.9. Browser/Application Integration: The Webtop
The requirements of hypertext document browsing and data manipulation require interface specialization in different areas. The focus of browsers is to provide for easy navigation of hyper-linked pages, while applications provide for the simultaneous viewing and editing of structured information such as record-oriented data. The tremendous success of the browser paradigm however demonstrates that the browser interface is extremely intuitive and easy to use for both advanced and casual computer users. It would seem advantageous then to incorporate into application interfaces the applicable elements of the browser paradigm. The following table describes the incorporation of browser interface elements to application interfaces.
The browser replaces the conventional desktop with a “webtop”, primarily providing application location and launch services, and displaying application-generated textual information such as reports and help. Most other application operations are handled through conventional GUI interface mechanisms, possibly including overlapping windows not contained within the display area of the browser itself.
1.10. Designing to the Most Common Denominator
When designing an interface it is important to consider the display capabilities of the target execution environments. Fortunately, today's lowest common denominator is quite high. Still, innovations are constantly being introduced. The advent of the Web has enabled major software vendors to make major new releases available as frequently as every six months.
It makes sense to incorporate non-standard platform features only in cases where significant value is added to the product by doing so, and where it is anticipated that a significant user-base will be enabled with those features within a reasonable time-frame. Interfaces should be designed to provide full underlying product functionality through features of the lowest or perhaps the most common denominator. Interface mechanisms built on non-standard platform functions should be optional product components, and optimally should appear automatically on platforms on which they are supported.
1.11. Implications of Next Generation Access Devices
As next generation access devices such as hand-helds and WebTV's become mainstream, it is important to consider whether these devices provide important outlets for deployment. These devices pose serious constraints including:
Capability to be deployed on these devices can necessitate maintaining radically different user interface designs for a single system. As discussed later in this document, it is critical that user interface programs be developed with very clean decoupling of presentation logic from processing logic, so as to allow maximize code reuse across a wide range of presentation formats.
Previous discussions have discussed interface elements provided via the windowing system, toolkits, or off-the-shelf class library. Application suites built upon a common set of these interface elements achieve a high degree of consistency. This section discusses consistency achieved by standardizing the specific usage and interaction of lower level elements to produce functionality specific to the application suite or problem domain.
1.11.1. Basic Elements
Several key elements are those that identify and display applications domain objects. Some important areas that need to be standardized within and between applications include:
1.11.2. Complex Elements
Other important aspects of application standardization involve standardizing the use of complex interaction elements such as:
1.11.3. Data Viewing
Database-type viewing operations are extremely common and so should also be standardized. Specifically, standard mechanisms should be developed to handle:
1.11.4. Data Navigation
Related to data viewing, is how navigating among data objects should be handled. Operations requiring standardization in this area include:
1.11.5. Window Management
Different windowing systems provide for different window management schemes. Generally the host windowing environment provides window management functions such as tile and cascade as a means of organizing open windows. These different schemes should be considered when developing systems that will target multiple environments.
1.11.6. Geometry
Geometry refers to the method used to determine the size of a window and relative position of its components. Modern GUI toolkits provide “layout managers” that dynamically position components according to the available screen size. Dynamic layout management should be used as much as possible. It is also important to consider the smallest display resolution necessary to display an application.
1.12. Application Backplane Services
In the “thin client” paradigm, monolithic applications are broken into small applications components loaded as needed by a user. Standard mechanisms should be established to allow seamless integration of small, modular application components.
1.12.1. Application Installation Services
1.12.2. Application Management Services
1.12.3. Inter-Application Communication Services
1.12.4. Component Architectures
1.13. User Customization
Users should be entitled to customize the application, at least within reasonable extents. For example, the following customizations would be allowed:
1.14. Internationalization
The ability to write an application that supports more than one human language is essential as computers proliferate into more and more areas of the world. A global marketplace provides obvious new opportunities for growth, and many companies are taking advantage of this potential. Especially alluring is the prospect of existing applications gaining international market share without rewriting them.
Unfortunately, internationalizing an existing application is a nontrivial task. Many issues go beyond simply translating the language used in the application. For example, date, time, number and currency formats change; the language may use a different character set; or foreign hardware and operating system platforms may be incompatible with the original application platform. All of these issues, and others, need to be addressed.
The most common method for internationalizing software has been to retrofit the application, redesigning and rebuilding much of the application. This is expensive, often costing as much as the original development and resulting in new sets of source code to support. International language versions of an application often ship months or even years after the native language version, thereby missing significant revenue opportunities. Needless to say, developers have been looking for a better method for supporting multiple languages.
Internationalization, or globalization, is the act of creating a program that can support any written language. On the surface, this sounds straightforward, simply translate the text. In practice, however, it is much more complicated. Languages are complex when you consider that some languages are alphabetic, some are syllabic, and others are ideographic. And the language is just the tip of the iceberg. Internationalization needs to address a wide range of issues, including currency, date, time, and number formatting, and so forth.
1.14.1. Character Rendering
Character rendering, the display of characters on a screen, is a fundamental issue in internationalization, sometimes abbreviated as I18N because it starts with an “I,” is followed by 18 characters and ends with an “N.” In order to translate an application's text into another language, it must be possible to display the characters associated with that language. For example, to display Japanese characters on the screen, a font must be available that includes Japanese characters. Usually, the operating system makes fonts available. Whether the operating system is DOS, Windows, OS/2, or Motif is not important at the conceptual level. What is important is that the character exists and can be displayed. In the U.S. and most European countries this is not a problem. The standard ASCII character set, and its many variants, supported by popular operating systems, generally includes enough characters to support translation into Latin derived languages. However, non-Latin languages such as Asian and Middle-Eastern languages pose difficulties.
Fortunately, most of today's major operating system & browser vendors are working to support non-Latin languages. Almost all operating systems & browsers are now available in Japanese, with Microsoft Windows now available in over 20 languages including Japanese, Chinese, Korean, Hebrew, and Arabic. For translators, this means that operating system fonts may now display most international characters. While all of this is promising, many problems still exist. Each language version of the same operating system may pose specific difficulties, and not all operating systems contain the fonts necessary to support all languages. Current operating systems contain little support for displaying multiple languages simultaneously. And support is limited for difficult-to-render languages like Arabic, which has multiple visual presentations for the same character code.
1.14.2. Input Methods
The flip side of rendering is the input method. An input method is the means whereby an application user, or localizer, types characters.
Obviously, Arabic and Japanese users have a totally different input method for entering their native languages into the computer. Right to left (Middle East) editing, multiple keystroke character entry (Asia), and the combination of keyboard and mouse character entry are good examples of input method complexities often overlooked by American and European application programmers.
Each input method requires a different approach. Asian versions of Windows, for example, use the mouse, or a keystroke combination, to toggle different input method modes, while composing characters in the actual field being edited. The visual effect is unexpected to a programmer not exposed to the method. Additionally, when using DOS/V to support an Asian language, the “Alt” key is used to access an input method on the last line on the screen. The “last line” input method is used to compose characters which are then transferred into the current field using “Enter.” Clearly, supporting multiple input methods within a single set of source code can be difficult and expensive, and isn't generally practical.
1.14.3. Character Mapping
Different operating systems often use different internal character representations, Unix frequently uses a character representation known as “EUC,” while Japanese Windows uses “Shift-JIS” and Macintosh uses “WorldScript”, which creates obvious difficulties for developers concerned with cross-platform issues as well as internationalization. Unfortunately, the same problems confront single-platform developers, too. Different language versions of the same operating system may also use different internal character representations, Windows offers a good example. Without the use of an internationalization tool, the Japanese Windows version of an application will not run on Chinese Windows, neither version will run on English Windows, and all versions of an application must treat character mapping differently.
For the programmer or Web site designer, this poses a great challenge. Ideally, a single character representation supporting all languages would be the most generally applicable at translation time. Since each operating system and language combination supports different character representations, this is usually not possible. The difficulty lies in designing and coding conversion tables to change an application's internal character representation into the representation used by an operating system, especially since this may need to be done differently for each operating system.
1.14.4. Collation Sequences
Collation, or sorting of different languages, is another complex yet often overlooked internationalization issue as each individual language sorts itself uniquely.
U.S. programmers generally think of text sorting as a simple table-based algorithm. This is not the case in most countries and in most languages. Even in the U.S., telephone directories often sort last names such as “Macfarlane” (all one word) and “Mac Farlane” (two words) together rather than placing the version with the embedded space before the name “Macallister,” as a simple table-based sort might suggest.
Outside the U.S. the complexity increases. In Spanish, the letter combinations “ll,” “rr,” and “ch” have been considered as individual characters for the purposes of sorting, while treated separately for the purposes of storing and rendering. In Asian languages the difficulties escalate dramatically. Characters, syllables, and proper names may all create different sorting complications, and often the national standards themselves are unclear.
1.14.5. Character Rendering/Hardware Support
When writing an application for international distribution, the programmer must realize that different hardware platforms and operating systems dominate the computing landscape of each locale. Nonstandard hardware, by U.S. and European perception, is the norm in Japan, for example. In Europe, keyboard layouts vary subtly in order to support the unique input needs of individual locales. Due to the huge number of possible combinations and the inaccessibility of translated documentation it is expensive to test the application sufficiently, but must be done in order to fully support all combinations of input and output devices.
1.14.6. Internal Representation and Portability
The internal representation of characters is the most critical of all issues in dealing with internationalization. In order to support all language versions and operating system versions of a product with a single set of source code, it is necessary to have a single standard character representation.
Unicode support is vital to completely globalize an application. Without a unified character standard, moving data files from one platform to another is difficult. A good example of this difficulty might be moving files for Windows-J Shift-JIS format, to Unix which uses the EUC format.
Even though both files contain Japanese language characters, both are incompatible due to their character representation and must be mapped to a new code table before use.
The key to avoid these kind of problems is to ensure that all characters and strings are encoded using Unicode. Unicode is a single table of 2{circumflex over ( )}16 (or 65,536) members containing the fundamental characters of written languages worldwide. The advantages to this architecture are numerous enough to warrant detailed attention. It is enough here to note that Unicode support is vital to completely globalize an application. Unicode allows a single source code strategy and general operating system independence, which cannot be addressed adequately in any other implementation.
1.14.7. The Unicode Standard
Any internationalization discussion would be incomplete without discussing Unicode. To provide truly international language support, a program must be capable of using the Unicode character set. (A complete description of the Unicode standard can be found in The Unicode Standard, published by The Unicode Consortium. They can be contacted at Unicode, Inc., 1965 Charleston Road, Mountain View, Calif. 94043, at phone number 1-415-961-4189, or unicode-inc@unicode.org.)
In 1984, the International Organization for Standardization (ISO) started work on a worldwide character set. ISO published a report in 1991 called the Draft International Standard (DIS) that described the work pertaining to the ISO10646 standard which described the universal character set. This standard was rejected when voted on, however, because another group was completing a standard called Unicode and there was concern that two competing standards would further complicate the issue. Thus, ISO and the Unicode Consortium, a nonprofit organization created to develop and maintain the Unicode standard, joined forces and co-developed a standard. Unicode was modified to be compatible with the 16-bit specifications of ISO10646, ISO10646 also defines a 32-bit standard, but also extends the specification somewhat.
The Unicode standard provides a comprehensive character set and sets rules for its use. Currently, the character set contains definitions for more than 30,000 characters. The character set is organized as a table of 16-bit values and thus is capable of representing 65,536 characters. The characters represented in the Unicode character set include alphabetic, syllabic, and ideographic characters as well as many mathematical and scientific symbols and dingbats, etc.
Clearly, Unicode takes internationalization to a higher level by providing a standard character set from which a program can obtain character definitions for any of thousands of characters. The Unicode character set contains character definitions for most written characters in most languages, and expansion room for more. The Unicode character set also provides information on how characters should be arranged such as the placement of characters in some languages, such as Thai, that depend on the context of surrounding characters.
1.14.8. Internationalizing an Application
Internationalization is a two step process: enabling and localization. In the enabling phase the programmer adds support for multiple languages and locales at the code level. During the localization phase the application get translated, preferably without recompiling the source code.
1.14.8.1. Internationalizing an Application
Internationalization is a two step process: enabling and localization. In the enabling phase the programmer adds support for multiple languages and locales at the code level. During the localization phase the application get translated, preferably without recompiling the source code.
1.14.8.2. Localization
Localization is the process whereby a program is adapted to use data formats appropriate for a particular locale. This means that the program formats date, time, currency, and number fields, and displays text in a manner consistent local practice. Using one of the examples stated above, a currency-formatted Zinc object might appear as $1,234.50 in the U.S., while appearing as £1.234,50 in the Netherlands.
1.15. Consistency through Inheritance
The easiest way to achieve consistency is to require that all developers use the same code base, and derive custom GUI elements directly from common toolkits.
GUI Toolkit. Reusable view, menu and command objects. Standard third-party GUI classes.
1. HTML/Web Application Content Guide
This section is intended to outline the most common approach to creating applications that are completely based on HTML and the Web. Typically, these applications are relatively simple, and are intended for information distribution, rather than extensive data manipulation.
For example, companies typically place the employee handbook on the intranet. Companies typically spend a lot of money printing and distributing the employee handbooks, but these books are used infrequently by the employees. The cost per employee for the paper approach is rather high. This cost is dramatically reduced by placing the employee handbook on the corporate intranet. Not only does this eliminate the printing and distribution costs, this approach also ensures that the employees always have the most up to date information.
1.1. Purpose of the Web Site
Early in the process of creating the web pages, the author should spend some time articulating the goals for the documents. Web pages can be categorized by purpose. Being responsible to a specific purpose can dictate certain design choices.
1.1.1. Are the Web Pages Providing a User Interface to a Service?
HTML browsers can be used with some facility to create form-based user interfaces (FUIs!) that allow people to choose products to buy, configure computers or search for information, to name only a few uses. Web pages that present these kinds of user interfaces must be easily understood with a minimum of study and documentation. Well done, they can be easily scanned and the expected actions inferred from the layout and controls. Pages tend to be short, uncluttered, and easily navigable.
For example, this can a bookstore interface that allows people to search an inventory list and place orders on-line.
1.1.2. Are the Web Pages Trying to Sell Products or Services?
Information presentation on the web has many guises. If the pages are selling something, then the pages need to present things very succinctly, especially if they are to “hook” a person who may be a reluctant reader. Everything in the pages that require a person to search, navigate or otherwise use their browser's controls will reduce the chances of getting them to read to the end of the pages, and hence the sales pitch. Lots of detail and presenting many branches (which may work well for other types of web information) can confuse and frustrate your audience. This graphical product presentation is easy to scan, and allows easy recognition and evaluation of potential products. (It's also a product line well-suited to this presentation, being hard goods that photograph well, rather than less visually differentiated goods, or worse, services.)
1.1.3. Are the Web Pages Presenting Information to an Interested Audience?
Sometimes, the Web site author can assume that many of the site readers will arrive at the site because they need and want the information being presented. In that case, the author can use longer pages, present more detail, and worry less about “channel-switching” behavior on the part of the audience. There's a tension between the amount of “packaging” that is done to the content and the audience's desire to get the information they need as efficiently as possible. What might be a good format for a product advertisement could fail dismally when presenting product documentation because of the frustration incurred when people are forced to navigate and visualize a web of short segments, and are given tantalizing but incomplete glimpses of the answers they need.
For example, much of HotWired's presentation (http://www.hotwired.com), a popular online magazine, approach uses longer pages, and narrower columns. This results in a very readable table-based layout that starts to resemble more familiar, paper-based page design.
1.1.4. Are the Web Pages Providing a Collection of Links?
Many of the web pages on the web today are lists of references to other things. This is the easiest kind of web page to create, as it requires the least amount of original content. Many personal “hotlists” are such lists, collections providing references to bits of information that the author found useful, interesting, and/or fun. The most successful of these are those lists that annotate and categorize the items they present, providing value beyond a rote recitation of pointers.
The Quality, Guidelines & Standards for Internet Information Resources list from the Australian National University (http://coombs.anu.edu.au/SpecialProj/QLTY/QltyHome.html), is an excellent resource because of its authors have qualified and evaluated many of the resources listed.
1.2. Audience of the Web Site
Early in the web site design process, the author of the web site should try to define the audience. The more specifically the web site author can catalogue the needs of the people reading your web pages, the better the site will be able to meet those needs. The following questions should be answered, in detail:
1.2.1. What is the Latency & Bandwidth of their Internet Connection?
Generally, the slower the link over which the Web site reader will be retrieving the web pages, the more important it is that you maximize “value” and usable content, and minimize document size and load time. Most of the differences between design for web-based media and design for more common computer and traditional media design revolve around perceived performance, and the ways in which the performance unpredictability of Internet connections will affect the audience's perception of your product quality.
The degree to which graphics are used, such as the size of your images and overall pages, and the way in which the information on the Web site is partitioned will be perceived differently depending on the speed and quality of the user's Internet connection.
See the discussion regarding choosing the right network model in the Performance section, below.
1.2.2. Who Will be Using Your Pages?
The amount of prior knowledge the users of the Web site have of the contents of the Web site, the less background information (such as an extensive online help system, or an extensive dictionary explaining the Web site terminology) is necessary to make the Web site successful.
1.2.3. Answer the Question “What Problem is My Reader Trying to Solve?”
Design the contents of the Web site with this question in mind. If the users of the Web site cannot use the application to get their questions and or problems resolved, then the Web site will not be successful.
1.2.4. What Browser are they Using?
The Web site author should clearly understand the consequences of designing, implementing, and testing the Web site using only a single browser, or intentionally optimizing the Web site for single browser, without first understanding the type of browser the users are using.
Usually, the Web site author should not make assumptions about how someone will be viewing the Web pages. A properly designed site should try to accommodate people with a wide range of viewing capabilities, from those with text-only browsers on slow links, to true technoids with fast, 24-bit color displays served by high-bandwidth direct network connections. There are some cases where the site may need to use the features of a particular browser to present the information well. A common case is using Netscape's <TABLE> or <CENTER> constructs, which are currently supported on Microsoft Explorer as well, but are not part of the current HTML standards. The author, however, should be cautious, as there may be many people in the audience who use other browsers. If the Web site author wants to support all the browsers available, yet retain some of the nonstandard formatting commands, the author should consider creating a second set of documents that don't look as good, but use only standard HTML. The server can then be configured to serve the right document, depending on the user's browser type.
The Web site author should weigh the advantages and disadvantages of using a browser-specific technique carefully, and try to make the documents usable and valuable to the broadest number of readers.
1.3. Frames technology
Frames technology was first introduced in Netscape Navigator v.2.0 (see browser chart in section 4.1.4, below). For the first time, Frames allowed the web site designers to have multiple, independently scrollable and navigable pieces of real estate in the browser window. The analogous GUI transformation was going from a single textual screen to a windowed approach, where separate text applications can run in each text emulator. Frames technology was one of the greatest improvements in the Web, since it completely changed the way users navigated through web sites. It was now possible to have a link in a frame manage the content of a different frame, thereby allowing the perfect navigational bar, similar to the menu bar in a traditional GUI application (after all, the menu bar doesn't go away or get completely regenerated, just because the content of the application window changes!)
1.3.1. Managing Multiple Frames
The only difficulty with the way frames were implemented in the original Netscape browser was the way the forward and back button behavior was implemented. For example, consider the behavior of the original (v2.0) functionality of the back button: Rather than taking the user to the previous impression that the user had of the site (that is, undo the last change, regardless of what frame it occurred in), the back button took the user to the page that referred the user to the page with frames on it. From the user's perspective, that could have been many, many hyperlink references ago.
For example, consider this sequence of actions, which refer to the diagram of a typical web page, below:
If the user were to hit the back button now, Navigator 2.0 would have returned the user to the search engine results listing page, since that was the last page before the frames interaction began. Logically, however, the back button should return the user to the NL average leaders page, since that is the last impression that the user had. This behavior was changed in revisions after Navigator 2.0. Only then did frames begin to be used all over the Web.
1.4. Generic Page Style Guide
The following generic page style has been adopted as more or less as a standard across the web. It was first made popular because Netscape started using it as the generic page on their web site (http://www.netscape.com). The following is a snapshot of such a page, taken from the a sports site (http://www.sportsnation.com/mlb/mlb.html), as seen on a Sun workstation running the Netscape Navigator v3.0 browser:
There are three major frames: The header, the side frame, and the main content frame.
1.4.1. The Header Frame
The header frame typically contains three major pieces, although the example above only contains two of the following three:
1.4.1.1. The Logo
The Logo is probably the most important element on any page. It should clearly identify who is the author of the page.
1.4.1.2. The Global Navigation Bar
The global navigation bar is typically placed in the header. This navigation bar serves two purposes: let the user know where in the site they are located, and give the user the ability to jump to other major parts of the current web site. In the above example, the statistics field is a different color than the rest of the fields, indicating that the current page is part of the statistics application.
If the user wants to jump to a different part of the current web hierarchy, such as the “Injuries” section, they could click on the “Injuries” hyperlink.
In a traditional GUI application, these elements would represent the top level entries in the menu bar (File, Edit, etc.)
1.4.1.3. The Forward/Backwards Buttons
The above example is missing this element, but, if the site is structured in a such a way where sequential viewing is possible and makes sense, they are typically a part of the header. They allow the user to navigate between the current page, and the previous/next logical pages. The browser forward/back buttons could use the same function, but those buttons don't work as expected when a user jumps directly into the middle of the web site, such as when selecting an item from a hotlist, a bookmark list, or a search engine query result list.
This particular site does not require the forward/backwards buttons since there is no logical next/previous pages. But a site that has a long, sequential document, for example, should have them.
1.4.2. The Side Frame
The side frame contains the local navigation bar, that are relevant to the current selection in the header frame. For example, if the current global selection contains several options, they are typically displayed in this frame.
This navigation bar also reflects the currently selected option. In the above example, the current selection is displayed in a different color than the rest.
In the traditional GUI application, these entries would reflect the actual entries in a given menu (such as for the File menu, the New, Open, Close, etc. options).
1.4.3. The Content Frame
This frame contains the actual contents of the page, as selected by the navigation bar in the header frame, and the local navigation bar in the side frame.
In the traditional GUI application, this would be the main output window, where all the application typically resides.
1.5. Fonts on the Web
The web is actually a composite of two different philosophies: HTML, which looks different on different browsers, and images, which look almost identical across browsers (color issues aside, see the discussion of colors and color maps in the next section). This dichotomy allowed Web designers to choose what they wanted to be seen exactly the way they envisioned, and what they didn't.
Since different web browsers interpreted different font style, size, and weight differently, designers knew that things that had to be displayed in an exact way (such as corporate logos, for example), had to be rendered as static images. The key to making a web site look good, however, was to keep the number of fonts displayed in all the images on the web site to a minimum, and not try to correlate the fonts in the images with the fonts outside the images (since that kind of effort would fail).
1.6. Colors & Colormaps
Netscape navigator (and many other application programs) has a pre-defined set of colors, or color table that it uses to display images in HTML pages. If a color used in an image is not found in the color table, the software will either substitute a color from the color table which is similar to the color specified in the image, or it will dither the colors to approximate the desired color. A color which is “dithered” will appear to be made up of pixels of two colors, which blend together visually to approximate the desired color.
Netscape Navigator (starting with version 2.0), allows a person to set a color policy in their application preferences. The default setting is “automatic.” In this mode, the browser will use an algorithm to decide if colors should be dithered, or if “close” colors should be substituted. In addition, the browser may load a custom color table for a particular image, if that image is the only one on a page. Interestingly enough, Netscape Navigator will not dither colors in background images.
Microsoft Explorer, on the other hand, does not allow any options with respects to color policy. Microsoft Explorer uses the default Windows color policy, which is to use the closest possible available color.
Dithering can reduce the quality and legibility of an image. To avoid dithering, authors can create images which use the colors specified in the browser's built-in default color table. If this is done, the colors will be rendered without dithering.
The only problem with this approach is that browsers running on PC/Macintosh platforms use a different default color table than do some UNIX versions of the software. Compounding the problem is that the differing color tables have very few color values in common. If color dithering will be a large page quality issue, then the color table used by the majority of the audience must be used, or server-side automation and scripting can be set up to provide platform-specific images, chosen on the fly based on the version of the browser being used.
The next two sections provide images which use the complete default color tables from the PC/Macintosh and UNIX versions of Web browsers.
1.6.1. PC/Macintosh Color Table
The PC and Macintosh systems, when using 8 bit display hardware, use a 6×6×6 color “cube” for rendering all pictures and images. This means that the color table contains 216 distinct colors. Each side of the cube uses colors with RBG values of hex 00, 33, 66, 99, CC and FF, for a total of 216 colors. The decimal values for Photoshop and other applications are 0, 51, 102, 153, 204, and 255.
1.6.2. UNIX Color Table
Most UNIX systems, or at least those with a 256 color display, use a 5×5×5 color “cube”, for a total of 125 distinct colors used for rendering all pictures and images. The colors in the table use RGB values of hex 00, 40, 80, BF, and FF. The decimal values for Photoshop and other applications are 0, 64, 128, 191 and 255.
1.6.3. Conclusion
Dealing with colors in a platform and system independent way is a hard thing to do. Unfortunately, the WWW has yet to mature in this respect. The easiest approach is to determine the target audience, and use that color map. Alternatively, two different sets of images, rendered with the two different color maps described above, can be set up. The server can then be configured to serve one or the other depending on the type of platform being used.
For more information, please consult the Color Technology Page, maintained by Charles Poynton at http://www.inforamp.net/-poynton/Poynton-colour.html.
1.7. HTML Layout Styles
If a web site were to use different designs for each of the pages in the site, that site would be extremely hard to navigate (unless the web site designer was trying to make a premeditated artistic impression). For example, consider a paper book. Each page has the title of the chapter at the top, the name of the book opposite the chapter title, and the page number on the bottom, with the text of the page in-between. Imagine how disturbing it would be if, in consecutive pages, the three page elements listed above were randomly placed within the page.
Similarly, the layout style used for the generic page should be used throughout the web site, with the possible exception of the home page, and other key pages within the site (those pages that correspond, for example, to the beginnings of chapters in a book).
1.8. Home Page Style Guide
The site “home page” is typically the first impression the user gets of the web site (that is, unless they entered the site through a different entry point, such as through a bookmark or through the results of a search engine query). As such, the first page gives the user the impression of what the overall site experience would be. For example, what kind of information is available in the web site, how often does the information change, who is presenting the information, etc.
The following two points are recommended for all home pages:
In addition, all home pages should contain the following:
1.9. Help Page Style Guide
Web sites, similarly to all well developed applications, should have context sensitive help. That is, every single page in the web site should have a help link that directs the user to the appropriate place in the help hierarchy. The help link could be a simple hyperlink, but is more typically an image of a question mark. This link should be in the same place in all the pages.
1.9.1. New Browser Window vs. New Page in Current Browser Window
One thing to consider when building the help section is whether the help information should override the current page, be placed in a separate frame in the page, or be placed in a separate browser window altogether (the ability to automatically launch a brand new navigator window with separate content was first introduced in Netscape Navigator v2.0).
Typically, help is most useful if it is placed in a different window, so that the user can read the help text while trying to manipulate the application, without having to constantly switch from the application to the help window. To that end, help information should minimally be placed in a separate frame, but ideally in a separate browser window.
1.9.2. Should Have “Back” Button that Returns User to the Previously Logical Page
Since the user can enter the help system at any given page, it is critical that the help system be self navigating. That is, each page in the help system should have a link to the previous logical page, the next logical page, as well as an up navigational button that takes the user to the beginning of the current help section. This allows the user to browse the help pages, rather than just looking for context sensitive help by first finding the appropriate application window, then pressing help.
1.10. Bookmarking Issues
Since the beginning, browsers offered the user to “bookmark” the current page. Effectively, the browser kept a database of pages that were “bookmarked”, and allowed the user to return to that page on the Web simply by selecting an item from a menu, a list box, or a tree widget. For browser users, this was an important element, since it allowed them to keep handy references to frequently used pages, or simply references to section of the web that they wanted to explore in more detail at a later time.
Unfortunately for the web designers, this implied that users can enter the Web site at any arbitrary point in the site, that is, whatever page they happened to bookmark previously. This caused several problems:
Search engine search result pages also allow users to enter the site in arbitrary places, so in this respect, search engine result pages are very similar to bookmarks.
1.10.1. Works with “GET” Style Pages, not with “POST” Style Pages
Unfortunately, bookmarks only work with “GET” style pages, not “POST” style pages. A GET style page is a page that is retrieved via the GET HTTP command. In GET style pages, all the information is passed from the client to the server as part of the URL, making URLs extremely long and “ugly”. A typical URL may be:
In this example, the client is sending two values back to the server, a and b. This information will get stored in the bookmark database, as part of the URL.
However, these kind of URLs are seen as “ugly”, or “unpure”. Also, some implementations of browsers or proxies have size limitations on URLs, making this method of information transfer restrictive. POST style pages address these issues, by passing additional information from the client to the server as a separate field in the HTTP transaction. This information, however, is not stored in bookmark files.
If a user tried to select a POST style page from a bookmarks file, the server would not have sufficient information to generate the page, and may have to either generate an error, or worse yet, generate a page that is not comprehensible.
The way to get around this is to allow the user, at arbitrary POST pages, to generate an equivalent GET style page (by encoding all the POST data as part of the URL), and then getting the user to bookmark that page. However, since the size of URLS is restricted, this approach may not always work.
2. Web Browser Guide
This section compares the behavior of the different browsers available on the market today, and attempts to quantify and qualify the similarities and differences. A chart comparing the various different browsers used on the market today is in section 4.1.4.
2.1. Browser Feature Comparison
2.1.1. Web Browser Market & Players History
When the NCSA first released the Mosaic graphical browser software, little did they know what trends they were starting. That group of programmers split up into two different companies, Spry (who continued developing the Mosaic browser), and Netscape (who continued developing the same code base, but called the browser Navigator). The key difference between the two companies was that Netscape gave their browser software away for free, whereas Spry charged a minimal amount of money for it (approximately $49.95, bundled with Internet in a Box software, which also included PPP dial up software). However, this gave Netscape a key edge, as over 90% of the users on the Internet used the Netscape browser.
Given such a huge market share, Netscape enjoyed the freedom associated with a monopoly: They were able to dictate the direction of the web market simply by supporting features in their browser. For example, rather than going through the standards bodies to determine extension to HTML, Netscape decided to implement some nonstandard tags, such as the CENTER and TABLE tags. Also, rather than going through the Internet Engineering Task Force (IETF) before implementing a security protocol, Netscape designed, implemented, and released SSL. Netscape also felt that the web could use a scripting language, so they designed and implemented JavaScript. All of these decisions on Netscape's part have become a de-facto industry standard, because the vast majority of browsers on the web supported them.
At some point, however, Microsoft decided to get into the web browser market. Starting with the original code base from NCSA, they adopted the original Mosaic browser into the current day Internet Explorer software. They have also implemented all of Netscape's nonstandard, proprietary extensions (including reverse engineering JavaScript), but also added their own (such as an HTML tag that allows playing background music while a page is being viewed).
Although Microsoft and Netscape are by far the two largest browser companies, other companies have tried to implement browsers along the way. Both CompuServe and AOL tried to implement their own browser, but each failed miserably to keep up with the browser market (in addition to continually developing their own products), and have adopted either the Netscape or Microsoft browsers.
2.1.2. Current Day Players
Currently, there are two major browsers: Netscape Navigator, and Microsoft Explorer. Different publications have attributed different percentages of the current day market to either of these browsers. Some publications claim that the Netscape browser continues to dominate the browser market, even speculating that 85% of the browsers being used are Netscape browsers. Other publications say that the market is about even, with each side enjoying close to a 50% share.
2.1.3. What Browsers are People Using?
It is hard to say what browsers people are using. The only way to measure this is to consider the logs for a given web site, and calculate the frequency of hits per browser. However, this type of approach is biased, since the nature of the site itself may attract a certain group of people who are already biased towards a particular browser.
For example, http://www.sun.com receives significantly more hits from Netscape Navigator browsers than any other browser. This site, however, also gets a significant number of hits from UNIX users, who have no choice but to use the Netscape Navigator browser (Microsoft Explorer does not run on the UNIX platform, at least not yet).
2.1.4. High Level Chart that Shows What Browsers (and Revision of Browsers) Support What Features
The following chart shows a high level comparison of the various browsers available today. Lynx, shown below for comparison sake, is a text only browser available only on UNIX platforms. It is used by a very small percentage of users on the Web, either in situations where graphics are not possible (such as via a text terminal dial-up session), or where connectivity is too slow to contemplate downloading graphics.
Notes:
Microsoft has announced and released a Macintosh port of the Internet Explorer v3.0 browser in late December, 1996. Also, they announced that a UNIX port of their browser would be available shortly.
Interestingly enough, the only browser available for Windows 3.1 is the Netscape browser. Java does not run on the Windows 3.1 versions of the Netscape navigator. However, Netscape has announced that Java will be supported on Windows 3.1 in the 4.0 version of their browser, to be available by end of the 1st quarter in 1997 (end of March, 1997).
2.2. What to do to Make Sure that Your Web Site Work Across all Browsers
Since different browsers interpret the same HTML commands slightly differently, the web designer is always challenged with making the web site look as good as possible on all the browsers. For example, HTML specifies 6 different heading tags, from H1 to H6. However, on Internet Explorer and Navigator, different fonts and font sizes are used for the same tags.
Since the HTML standards bodies move slowly (as standards bodies tend to do), and since the browser market place has become so competitive and fast moving, the latest and greatest browsers are always going to be pushing the envelope of the market, and adding proprietary tags. Such examples are the CENTER and TABLE tags, first implemented by the Netscape Navigator browser. The standards body eventually implemented a mechanism for centering text (as an option to other tags), but did not adopt the CENTER tag as implemented by Netscape. However, since so many people were using the Netscape navigator, the CENTER tag has become a de-facto standard, and is commonly used.
Web users, or at least the browser that they used, can be categorized into three groups: The technoids, who always have the latest and greatest browser on the latest and greatest hardware, those who are technical and can manage to use their own ISP, but don't particularly care about having the latest and greatest browser, and those that depend on commercial online services, such as America Online, CompuServe, or Prodigy, for access.
2.2.1. The Technoid: The Ultra-Sophisticated User
Typically, the web designer does not have to worry about making the web site look good for this kind of user, since this user will always have a browser that will accept any kind of input.
2.2.2. The in-between User
These users can manage on their own, and typically have a reasonable browser, but not necessarily the latest and greatest one. If they find a web site that requires a newer browser, they will be able to download it and install it themselves (or, more likely, request that their system administrator install it for them). So typically, the web designer does not have to worry about this group, either.
2.2.3. The Rest . . .
The rest of the users of the Internet depend on commercial service providers, such as America Online, CompuServe, or Prodigy. As early as a year ago, these companies were developing their own browser, rather than licensing browser technology from Netscape or Microsoft. Since their development efforts were concentrated on their main product, little effort was put into the browser, and it showed in terms of features set supported. For example, on the Prodigy browser, the CENTER tag was supported, but it only worked if no other tags (such as a bold tag) followed it, so the designers had to conscientiously put the CENTER tag at the end of the sequence of style formatting tags. AOL & CompuServe's browsers did not even support the CENTER tag.
However, especially since America Online claims over 6 million customers alone, these service providers probably represent over 10 million users, which is by far the largest group of the users on the Internet.
Web designers, then, were always challenged to make web sites look good on modern browsers, but still look decent on the commercial service provider browsers. Designers approach this two ways:
2.3. Caching Issues
As usage over the Internet increased, the load on servers increased as well. Due to the exponential growth of usage on the Internet, server administrators had a hard time matching the demand growth with additional hardware (some of the difficulties were financially driven, such as for educational institutions, which typically have small equipment budgets, others were simply a time issue, such as for large corporations with limited internal resources).
This growth issue was resolved in one of two ways:
2.3.1. Web Server Proxies Introduce Another Layer of Cache Management
Proxies were seen as the best way to meet the demand on the Internet. However, they introduced a key problem: The cache policy is now determined by the proxy server system administrator, rather than the user.
In the Netscape browser, the user has a choice of how often the cache is checked, whether once per session, every time, or never. This policy can be determined by the user. The same sort of policy management scheme exists for the proxy servers, but that is under control of the proxy server system administrator, rather than the user. If the proxy server is configured to check the web server for new updates periodically, rather than for every request, the user could potentially be seeing old information. In other words, proxy servers introduced a document propagation delay to the Web.
2.3.2. Ensuring that Users Have the Up-to-Date Stuff
Fortunately, there are ways around the propagation delays. Since proxies and other caching servers use the file name as the key into the cache database, if the web site designer were to change the filename of a file, this would force the proxies and browsers to download a new version.
However, changing file names does have some potentially undesirable effects. For example, bookmarks to the old page will now fail. Also, search engine entries for the old page will now fail as well. See section 3.10 for more details.
2.3.3. Ensuring that File Names are Consistent to Maximize Cache Usefulness
To maximize the effectiveness of caching servers, as well as the local browser cache, the web site author should ensure that only a single copy of each distinct page or image is stored on the site, and referred to in a consistent way. That way, the file or image is only loaded from the web server once, and stored in the web browser cache.
The most common application of this approach is the corporate logo, which is typically present on every single page. If it were to be loaded separately for each page, the performance of the site would be degraded unnecessarily. Also, all modern browsers allow a given image to be stretched both horizontally and vertically. That way, if the corporate logo is needed in different sizes, the same base image could be used, and expanded or shrunk by the browser as necessary. This is implemented using the WIDTH and HEIGHT arguments to the IMG tag in HTML.
2.4. HTML Issues
2.4.1. What are the Current Day HTML Standards
The current proposed HTML standard is v3.2. Please consult the World Wide Web Consortium home page, at http://www.w3.org, for up to date information regarding the HTML standards process, as well as the actual standards documents.
2.4.2. Exceptions to HTML Standards that are Supported by all Major Browsers
Since the HTML standards bodies have moved slower than the web browser markets (as standards bodies tend to do), the browser companies have implemented proprietary extensions to HTML in their browsers. Typically, the other browser companies have implemented those extensions as well, for compatibility purposes. For example, Netscape implemented the following tags:
Microsoft also implemented some proprietary extensions, such as one to allow background music to be played while the page is being viewed.
2.4.3. What HTML Tags to Avoid
The best approach to writing portable HTML is to use the standards, rather than using the proprietary approaches. So, for example, the best way to center text is to use the ALIGN=CENTER argument to the various HTML tags that support it, rather than using the CENTER tag explicitly.
2.4.4. HTML Subset that Works Across all Browsers
All current revisions of browser support HTML version 3.2. Please see the browser comparison chart for more details on what browsers support what versions of HTML.
3. Java Style Guide
3.1. Java vs. JavaScript vs. Plugins vs. ActiveX
3.1.1. Java is an Industrial Strength, Object Oriented Environment
Java is described as a simple, object-oriented, distributed, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, and dynamic language according to the Java Language white paper.
Java, formerly known as oak, is an object-oriented programming language. It shares many superficial similarities with C, C++, and Objective C (for instance for loops have the same syntax in all four languages); but it is not based on any of those languages.
Java is sometimes referred to as C++++. The language was originally created because C++ proved inadequate for certain tasks. Since the designers were not burdened with compatibility with existing languages, they were able to learn from the experience and mistakes of previous object-oriented languages. They added a few things C++ doesn't have like garbage collection and multithreading; and they threw away C++ features that had proven to be better in theory than in practice like multiple inheritance and operator overloading.
Even more importantly Java was designed from the ground up to allow for secure execution of code across a network, even when the source of that code was untrusted and possibly malicious. This required the elimination of more features of C and C++. Most notably there are no pointers in Java. Java programs cannot access arbitrary addresses in memory.
Furthermore Java was designed not only to be cross-platform in source form like C, but also in compiled binary form. Since this is frankly impossible across processor architectures, Java is compiled to an intermediate byte-code which is interpreted on the fly by the Java interpreter. Thus to port Java programs to a new platform all that is needed is a port of the interpreter and a few native code libraries.
Finally Java was designed to make it a lot easier to write bugfree code. Shipping C code has, on average, one bug per 55 lines of code. About half of these bugs are related to memory allocation and deallocation. Thus Java has a number of features to make bugs less common:
At the lowest level the advantage of Java to the web is that it provides a secure, cross-platform way for code to be executed. At a somewhat higher level Java adds several features to existing web sites.
3.1.1.1. Arbitrary Graphics
Java lets the server draw pictures in a window on the client. In theory this allows a web page to do anything a regular program can do by drawing in a window.
3.1.1.2. Arbitrary Data Types
In practice rather than using graphics primitives to create your desired web page you'd use a graphics program to draw the page and then write a program that could read and display the file formats of that program. Java lets you write content handlers that display any particular data format. This way you can download your data and your data display program rather than downloading a bitmapped snapshot of the display. People are already using this to add sound and animation to web pages. Rather than having to download a file and spawn an external viewer, the viewer is included with the data; and the data is displayed right on the page.
3.1.1.3. Less Load on the Server
CPU intensive cgi-bin scripts place a large load on a server, particularly at busy sites. With Java you can offload the calculations to the client's PC. I've written an applet that calculates all possible ram configurations for a given Mac model. However on models with many memory slots the sheer number of permutations can tie up even a fast machine for several hours. Publishing this as a cgi-bin would bring my server to its knees, but by publishing it as a Java applet I can distribute the load across all the machines that want to run it.
3.1.1.4. More User Interaction
Finally Java allows for more interaction with the user. Java not only allows you to paint arbitrary data on the screen. It also allows you to collect input from the user in the form of mouse clicks, keystrokes and the like. This lets you put almost any application on your web page that doesn't require disk access.
3.1.1.5. Availability
Sun has made a Java development kit available for Sparc and X86 Solaris, Windows NT for Intel, Windows 95, MacOS 7.5 on PowerMacs and 68030 (25 MHz and faster) and 68040 Macs.
An IRIX port has mostly been completed by Simon Leinen. SGI's own port is available at http://www.sgi.com/Products/cosmo/cosmo_instructions.html
A Linux port is in fairly good shape. See http://java.blackdown.org/java-linux.html.
IBM has ported Java to Windows 3.1, OS/2, and AIX. It is working on ports for MVS and OS/400. See http://ncc.hursley.ibm.com/javainfo/hurindex.html.
The OSF has ported Java to Unixware, the Bull Estrella or other PowerPC running AIX4.1, X86 running DASCOM OSF/1, the Digital Alpha running Digital UNIX 3.2, the HP700 series running HPUX 10.x, the NCR Globalyst (Pentium) running UNIX SysV, and Sony NEWS (MIPS) running Sony NEWS 6.1.1. See http://www.osf.org/mall/web/JDK/.
Other ports are underway for Nextstep, SunOS 4.1, the Amiga and possibly other platforms.
3.1.2. Javascript is Just a Simple, Scripting Language, not Meant for Serious Applications
Javascript is a scripting language developed by Netscape for its browsers in order to augment limitations in the HTML language. This language originally started out named Livescript to fit into Netscape's Live Architecture (e.g. LiveWire, LiveConnect, Live3d, and more . . . ) but was renamed in order to capitalize on Java's popularity. Javascript as a language provides limited interactivity in the browser environment. It provides some string manipulation and comparison capabilities, and some arithmetic functions. Javascript is mainly used to handle field validation in HTML forms.
Microsoft reverse engineered Javascript into Jscript for MS Internet Explorer 3.0. At that time, Netscape had not released Javascript into the ECMA standards body.
Microsoft has announced in a press release that they are currently working with ECMA to incorporate features from Jscript into the standard scripting language to called ECMAScript. The reason for the name change is due to the fact that the Javascript name is owned by Netscape.
3.1.3. Plugins are Browser/Platform/Version of Browser Specific
Plugins extend the browser to include additional capabilities such as multimedia. Plugins are dynamic code modules which are native to the specific platform on which the browser runs. They allow existing platform dependent code to integrate with the browsers core functionality to support new data types.
In the Netscape platform, plugins reside on the user's local drive and are detected by Navigator when it starts up. When Navigator encounters data handled by a plugin (either embedded in an HTML page or in a separate file), it loads the appropriate plugin and gives it access to all or part of a window. The plugin remains active until the associated page or file is closed.
MS Internet Explorer 3.0 supports Netscape plugins on the Wintel platform.
The installation of plugins is still a distinct event. When a browser encounters a data type with which it is not familiar, it cannot automatically install the necessary plugin. The user has to search and find the necessary plugin, download it, and install it. It is essentially the same process as having a helper application.
Plugins are complementary to platform native inter-application architectures such as OLE and OpenDoc, and platform-independent programming languages such as Java. In fact, Netscape through their LiveConnect architecture allows Java applets to access native methods stored in plugins. The reverse interoperability is also true: plugins can also use functionality available in Java classes; in fact, many ISV's are writing the common elements of their plugins in Java (the Koan plugin comes to mind).
There is no security involved with plugins. Installing plugins is very much like installing software off the Internet or some foreign BBS, users do it at their own risk.
3.1.4. ActiveX is Browser/Platform Specific, and are Huge Applications
ActiveX extends Microsoft's existing Object Linking and Embedding (OLE) and Component Object model (COM) technologies to the web. It serves as a component framework. ActiveX ‘controls’ are components that plug into the ActiveX framework. They are embedded into web pages.
Microsoft at this time has only turned over parts of ActiveX to The Open Group (TOG), a standards body formed by X/Open and the Open Software Foundation. Important APIs such as database access services or Windows-based ActiveX services are still proprietary.
ActiveX is currently only supported in Microsoft's Internet Explorer browser on the Wintel and Mac platforms. The Netscape browser on the Wintel platform has an ActiveX plugin provided by NCompass Labs; however, in order for the ActiveX component to be recognized by Netscape, it must be referenced by a different HTML tag. Netscape uses the <EMBED> tag whereas Microsoft uses <OBJECT>. This means that pages with ActiveX components must use both tags to be recognized by both browsers.
ActiveX components are used much like plugins in browsers. When the browser hits upon the appropriate data type, it will then load the ActiveX component. If the component is not already installed, the browser asks the user whether to download it.
The ActiveX security model is considerably different from the Java model. Java achieves security by restricting the behaviour of applets to a set of safe actions. ActiveX, on the other hand, places no restriction on what a control can do. Instead, each ActiveX control can be digitally “signed” by its author in such a way that the signature cannot be altered or repudiated. The digital signatures can then be certified y a trusted “certifying authority”, such as VeriSign, to create the equivalent of a shrink-wrapped software package.
This security model places the responsibility for the computer system's security entirely upon the user. Before Internet Explorer downloads an ActiveX component, the browser presents a dialog box indicated who signed the component, if at all. The user can elect to abort the transfer or may continue.
The ActiveX certification process ensures that ActiveX controls are not tampered with by third parties after its publication. However, the certification process does not ensure that a control will be well-behaved. To illustrate this danger, an ActiveX control called Exploder was published to the Internet. This control, which was bully signed and certified, shutdowns any Windows95 machine that downloads it. The shutdown occurs automatically soon after the user views the HTML page that contains the Exploder control. Exploder is relatively benign compared to the possible damage that other more malicious controls may do. These controls may reformat the user's hard disk or plant a virus. In fact, it is possible that an ActiveX control could take some subtle action, such as transmitting confidential confidential information from the user's harddisk, that would escape detection for a long period of time.
Unlike Java, which is a platform-independent programming language, ActiveX controls are distributed as executable binaries, and must be separately compiled for each target machine and operating system. At this point, ActiveX is only supported on Wintel and Mac platforms. Support for Unix is not available and there has been little news on the progress so far.
ActiveX components are generated as large OLE Custom Controls (OCX) files with Internet extensions. In order to address the issue of size, it is important to look at the history of OLE. The technology for Object Linking and Embedding is over seven years old. The first incarnation of it, OLE 1, was built upon Window's dynamic data exchange (DDE). It was a very clumsy slow protocol. In 1993, it was revised to OLE 2. At this point, Microsoft decided no longer to attach versions behind it and just incrementally add new functions. They will be simply buried within new releases of Windows or new releases of Microsoft's Visual C++. This means that OLE is no longer a separate product but very much a part of MS Windows. In 1994, Microsoft introduced custom controls (or OCXs), possibly referred to as OLE 2.1.
An OCX is a combination of OLE in-process server and an OLE automation server. In order to support OCXs, it is necessary to have in place several dynamic link libraries (DLL files). This is made worse by all the legacy interfaces it must support due to previous versions. OLE is massive; in order to make it easier for programmers to develop OLE components, Microsoft created a class frameworks called Microsoft Foundation Classses (MFC) in Visual C++2.0. MFC has added another wrinkle to the volume of libraries needed to support OLE containers. When writing for the Internet (as in ActiveX), the authors cannot assume that the users already have all these libraries in place; therefore, they compile all the libraries into their ActiveX component resulting in massive file that must be installed on each of the users machine.
Note that MS Internet Explorer indefinitely caches each ActiveX component it encounters.
3.2. Java Applet vs. Java Application
The Java environments allows business applications to be deployed in two different ways, each with advantages and disadvantages. The first business application model, and most common application of Java, is as a “Java Applet”. In this model, the business application is actually integrated into a web site. Extensions to HTML were made to accommodate integrating a Java Applet into an HTML page. The Java applet is downloaded over the Internet, and executed on the local client. The other model, the Java Application, is similar to traditional GUI applications, where the application must already be loaded on the local client. The Java Application is started either via the command line, or via an icon, or menu item.
3.2.1. Applet Security implications
Applets loaded over the network are untrusted. The only way to be sure than an untrusted applet cannot perform any malicious actions (e.g. deleting files on the local hard drive, sending out fake email that looks like it came from the browser user, using the browser client as a remote file server, etc.) is to run it in a very limited environment. For this reason, Web browsers carefully restrict what an applet is allowed to do.
3.2.1.1. What are the Applet Restrictions?
Different web browsers may place slightly different restrictions on applets, and some may even allow the user to relax some of these restrictions, but in general, applets are not allowed to:
3.2.1.2. Local Applet Restrictions
When an applet is loaded from the local file system, instead of through a network protocol, Web browsers may relax some, or even many, of the above restrictions. The reason for this is that local applets are assumed to be more trustworthy than anonymous applets from the network.
3.2.1.3. How to Get Around them?
Obviously, applet restrictions are necessary, but are overly restrictive, at least with respects to modern day applications. Most applications, need, at the very least, import and export local data, as well as print. To accommodate those requirements, the following approaches are possible:
3.2.1.3.1. Class Files on Local Disk
Since local applets, or class files, are subject to a more relaxed security model, a hybrid solution can achieve the advantages of network loading and updating, and a relaxed security model. Classes that need access to local data or to the local printer can be given to the user with instructions to install them on the local client, whereas the rest of the applet can be retrieved over the network.
3.2.1.3.2. Plugin/Java Interaction Support
Plugins, as well as ActiveX components, do not have a security model in place. Applets can use LiveWire from Netscape or ActiveX from Microsoft to communicate with the plugin or ActiveX components, and have those components do the tasks that are restricted to the applet.
3.2.1.3.3. New Sandbox Security Model for Signed Applets
New browsers will have a new security model for signed applets. Signed applets carry an attached digital signature and cryptologic checksum. Using public key encryption technology, this would enable a Web browser to verify that an applet is from the source it claims to be from, and that it has not been modified in transmission. With these guarantees, it is possible to load a trusted applet (one that can run without severe security restrictions) over an untrusted network as long as you trust the source of the applet (i.e. whatever individual, corporation, or certification agency has attached their digital signature to the applet).
For more detailed information about this, please consult the following article, at http://www.packet.com/packet/garfinkel/96/53/index2a.html.
3.2.2. Startup Implications
Java applets actually start when the browser encounters a special HTML tag, APPLET. The browser then begins to download the applet from the web server, and start execution.
Applications, on the other hand, are started directly by the operating system, either by executing a command on the command line, or by double clicking the icon for the application. Applications, however, can be started from the browser, the same way helper applications (such as custom viewers for images) are started. This is accomplished by reserving a mime type for the application, and configuring the browser to start the Java application whenever that mime type is encountered.
3.2.3. Download/Version Control Issues
3.2.3.1. New Versions of Applets are Automatically Downloaded by the Browser
As described in the previous section, applets are automatically downloaded from the web server by the browser, whenever the browser encounters a special HTML tag. The browser then caches the Java applets for use the next time the applet is initiated. What happens, however, if the Java applet is updated on the web server? The answer is that the same behavior applies to Java applets as to HTML pages. Before using any page out of the browser cache, the browser (by default) queries the server for any updates to the applet. If there are any, the new applet is downloaded. If there aren't any changes, the cached applet is used. The Netscape Navigator browser can be configured to check the server every time the applet is loaded, or once per session (for example, if the applet is started multiple times without exiting the browser software), or not at all (in which case the browser always uses the cached version. Microsoft Internet Explorer does not have such options. Rather, it checks every time an applet is started.
3.2.3.2. Marimba's Castinet Product Simplifies Application Download
Java applications, however, are not downloaded from the web server. Rather, they must be present on the local disk before an application can begin. Specifically, the application developer (or, more likely, the system administrator) is responsible for ensuring that the latest and greatest version of the application is distributed to all the users.
Marimba, Inc., has a product called Castinet that allows applications to become self updating, similarly to the way Java applets are. Before an application is started, the Marimba product queries the “application server” for any updates to the application. If there are any, they are downloaded before the application is started. For more information, see http://www.marimba.com, or the chart comparing different extended GUI components, below.
3.2.4. Screen Real Estate
In the applet model, since the applet itself is directly associated with a browser, the applet itself can use part of the browser's screen real estate for its output. The most common example of this is the animation applet, that is embedded as part of the HTML page. However, if the user navigates away from the page where the applet was started, the applet will be stopped. This restriction makes this model useful for applets that are tightly integrated with the web page around them, but not for applets that are intended to be real, long lived applications.
An applet, however, can use none of the browser's output window, but rather launch its own, independent window. This resembles the typical GUI and Java application models.
Typically, these two models are combined. An applet first starts in the browser's output window, if nothing more than to provide a mechanism to start the application (via a start button), or to provide the authentication screen, before launching a separate window for the rest of the applet.
A Java application, on the other hand, is not associated with a browser. A Java application must launch its own window.
3.3. Browser Compatibility Issues
3.3.1. What are the Differences Between Java on the Same Browser on Different Platforms?
At this point in time, this can only be truly observed with the Netscape Navigator browser. The Mac version of the MS Internet Explorer with Java support is still in beta.
The Java Virtual Machine (JVM) is well implemented across multiple platforms. Applications appear and behave similarly across different machines with the except of the Mac. The JVM on the Mac has not been well implemented and results in applications sometimes appearing differently or running improperly. Apple is currently working on implementing the JVM directly into the MacOS.
Java performs at different levels due to the underlying platform and operating system. For example, threaded Java runs a lot more quickly on operating systems that natively supports threads. This has been seen under Solaris on SPARC platform. Solaris natively supports threads and applets with threads run much faster. On the other side, operating systems that do not support threads natively (in the OS) such as Windows have applets running much more slowly as the JVM for Windows has to handle threading by itself without help from the OS.
3.3.2. What are the Differences Between Java on the Same Browser on the Same Platform But Different Revisions?
Again, at this point in time, the only browser that has Java support in different versions is the Netscape Navigator. Microsoft has only started to support Java in version 3 of Internet Explorer.
Different versions of the Netscape Navigator browser (versions 2 and 3) have so far implemented the same Java Virtual Machine (JVM). The differences between have only been in adding security patches and bug fixes, and sub-subreleases of Java (i.e. version 1.X). The early version of Navigator (version 2) supported a beta release of the Java Developers Kit (JDK). The current version (3.01) supports the current release of JDK 1.02.
The next versions of both Netscape (Communicator) and MS Internet Explorer (4.0) are both supposed to support the next release of Java (version 1.1). This release is supposed to support the Java Database Coonectivity (JDBC) kit.
3.3.3. What is this JIT Thing I Constantly Read about? Would it Significantly Speed Up My Application?
When the Java compiler is executed on a Java program (*.java source), it converts the code into Java bytecode and puts it into a class file. This class file can then be interpreted on any machine which has a Java Virtual Machine on it. The Java Virtual Machine processes each of the bytecodes in the class file and executes them. This process is similar to what other interpreted languages do, such as LISP or Smalltalk.
When a Just-in-time compiler (JIT) is present, the Java Virtual Machine does something different. After reading the class file for interpretation, it hands the .class file to the JIT. The JIT will take the bytecodes and compile them into native code for the machine that you are running on. The native code is optimized for the platform it is running on thus it runs faster.
JIT promises to speed up Java execution times. Like Java interpreters, JIT compilers convert Java byte code into native on the fly, but they cache the converted code in memory while the program runs. The memory cache enables Java to run faster by the fact that much of the bytecode is repetitive. The JIT compiler can identify which bytecodes it already has compiled previously and runs those directly from cached memory. Moreover, applications running from memory cache always run faster.
Java is a dynamic language, thus all the class files cannot be “statically” compiled into machine specific code until they are actually called. Thus the JIT is really just-in-time as it compiles methods on a method by method basis just before they are called. If the same method is called more than once, the JIT'ed code pays off as the method does not need to be recompiled; the native code is simply re-executed from the cache.
3.4. Look & Feel
3.4.1. Native Methods (Standard JDK)
Java's Abstract Windowing Toolkit (AWT) is a standard class library that encapsulates basic GUI components. The aim of AWT is to enable applications to appear as native applications creating an intermediate peer service that maps to a corresponding routine in the native operating system's API. For example, Java has a class called Button that display a push button on the screen. Push buttons are common to all GUIs. On a Wintel platform, Java calls the button routine in the Win32 API. On a Mac, Java calls the button routine in the Toolbox. On a Unix system, Java may call the routine in Motif. This abstraction gives the Java button that looks like a native button on screen.
3.4.2. Pure Java Methods (Netscape IFC)
The Netscape Windowing Internet Foundation Classes (IFC) 1.0 is an all-Java user interface application framekwork. It allows Java applications to be created of independent of operating system-specific windows and user interface protocols.
IFC is writen completely in Java and is supposed to run on all Java-enabled platforms including non-Netscape browsers.
Applications created with this library of visual widgets will have the same look-and-feel regardless of the underlying platform. IFC applications have a distinct look different from Motif, Mac and MS Windows.
The IFC library includes window hierarchies, integrated drag and drop, and more.
3.5. GUI Components
3.5.1. Menus
In release 1.02 of the Abstract Windowing Toolkit (AWT), menus can only reside in menubars. Furthermore, menubars can only be attached to separate frames; i.e. menus cannot exist in applets that reside within the browser space-they must be in free-floating “windows”. The next release of AWT will support pop-up menus which are not attached to a menubar and thus are relevant to in-browser applets.
Note that is possible for developers to write their own pop-up menu routines and use AWT graphics primitives to paint the pop-up. However, such a pop-up loses the native look and feel of menus because it is drawn by hand and not by a menu peer (which access the underlying operating system menu call).
Tear-off menus are implemented under Motif and are menus that, as their name indicates, may be torn off and placed aside for quick access. Tear-off menus have perforated line at the top of the menu. Once torn off, they exist as their own window and behave almost like a freefloating menu pallette. Note that this feature is not supported in menus on Windows 95.
Help menus are also support by the AWT. Under Motif, help menus are located in the right and are right-justified on the menubar. Java apps running under Motif also show this behaviour—they show up on the right side of the menu bar. Windows 95 does not right-justify the help menu and instead just places it as the right-most menu and Java taking the look-and-feel of the unerlying operating system shows the same behaviour: the menu in Java on Windows 95 is just the last menu on the menubar but is not right-justified.
Menus under Java also support the following features:
3.5.2. Buttons
The AWT currently only supports plain text buttons. These are buttons that just contain a text label. However, there are a variety of third party libraries that implement different buttons. For example, the Graphic Java Toolkit (GJT) library, published by SunSoft Press, includes two new buttons: ImageButton and StateButton.
The ImageButton essentially displays a image instead of a text label. A more common name for it is the picture button.
The StateButton graphically shows the state of something when pressed. For example, a StateButton may depict a wheel. When pressed, the wheel spins while some event triggered by the button is running.
Both of these buttons can have additional properties such as being springy or sticky. A springy button pops back up when pressed. Whereas a sticky button stays down the first time you press it and pops up the next time you press it-its behaviour is akin to an on/off switch.
The button class provided by AWT is flexible so that it can extended in additional new ways. The examples above are only show a few extensions.
3.5.3. Scrollbars
The Scrollbar component is used to specify a particular value in a range of values. The orientation can be either vertical or horizontal.
Scrollbars can be used in a variety of ways. A free-floating scrollbar can be used as control meter to adjust values up or down. Traditionally scrollbars have been used with other components for situations in which the particular component does not fit the container. For example, when displaying an image that does not fit the dimensions of the window, the scrollbar is used to move the image so that sections of the image can be broght into view. Scrollbars can appear dynamically as they are needed or the developer can specify that they never appear or are always present.
3.5.4. Images
Java is able to natively (within the JDK itself) display both GIFs and JPEGs. Additional image types, such as BMPs, PICTs need outside libraries to provide routines to manipulate them.
While images are being loaded, they can either be presented as partial chunks as it is loading or to wait until the image is loaded completely before displaying it. Depending on how the program is writing, the loading can occur either synchronously or asynchronously. It is possible to load an image and do other things at the same time.
There are a variety of options to manipulate images such as putting it through filters, resizing and more.
Java programs can freely use images as background.
The Graphic Java Toolkit by SunSoft Press has a Sprite animation library.
3.5.5. Fonts
There are five default fonts within Java:
These fonts are always mapped by Java to fonts that actually exist on the client machine. For example, on a Windows system, Helvetica is mapped to Arial. Other fonts can also be used if they exist on the client machine. Developers can create their own font mappings.
Java has its own FontMetrics class. Fontmetrics allows typesetting to be manipulated. For example, font properties such as ascender, height, descender, leading baseline, and others can be customized.
3.5.6. Cursors
Java defines a number of standard platform-independent cursors that can be specified as the mouse pointer. The pointers are:
Additionally there are a number of cursors which are used for resizing and appear depending on which direciton is being resized. These cursors included resizing from the top or NORTH, right or EAST and so on (SOUTH, WEST) and including combinations such as NE for the top right corner.
3.5.7. Dialog Boxes
Both modal and modeless dialogs are support in the current AWT implementation. Modal dialogs bring the application to a halt (in terms of user interaction) until some vital question of the moment can be answered, such as whether to cancel a transaction. Modeless dialogs, on the other hand, can be left open and answered or manipulated at any time, enabling the user to flit from task to task without being forced to complete any of them.
In order to design a proper dialog box a few rules needs to be followed. A dialog box may not have menus. Some type of nomenclature must be provided such as a title bar. Finally there always must be away to get out of the dialog box. This is traditionally provided by the combo of OK and Cancel buttons.
The OK and Cancel buttons are the most common element to appear on dialog boxes. It is important that they be consistently used. In most windowing systems that has meant that they appear at the bottom of the dialog box and a horizontally centered.
3.6. Layout Management—Why it is so Important?
Layout in Java, as well as other platform neutral GUI applications (such as X11/Motif), are essential to the correct behavior of the application. This is because as the application is moved from platform to platform, the screen resolution, font sizes, and window sizes all change dramatically. In Java, the programmer does not specify absolute positions for interface elements. This is very different from Microsoft Windows or Macintosh programming, for example, where the x,y coordinates of each GUI element are hard coded into the source code.
Java has a much more general and elegant mechanism. When GUI elements are added to a container (such as a dialog box, or a window), the general rules for layout are specified. Rules are specified by first attaching the outer GUI elements to the window borders, then logically attaching GUI elements to one another.
For example, assume a dialog box has two buttons, and an input element. Typical rules would be: button a is to be placed immediately to the left of button b. Another rule could be both button a and button b should be placed a certain offset above the bottom border of the window. Yet a third rule could say that the GUI element immediately above the two buttons should expand to fill up the entire window space (presumably, this kind of element would be some sort of input element, such as a text input box, or a list box. Both of these elements would show more information if the window was expanded).
Using these kind of rules, the Java environment, at run time, would determine the locations of the buttons, based on window size, font sizes, button sizes, and other rules that the environment imposes (for example, window managers in the X11 system typically put a border around the window. The width of the border is determined by the window manager at runtime).
3.7. Java Color Model
The Java color model is similar to the Web browser color model, as described in section 3.10. In addition to the color map colors, the java.awt. Color class predefines a number of constant color values.
3.7.1. List of Predefined Colors
The following colors are predefined by Java. These colors are guaranteed to exist across all the platforms, regardless of the color model.
3.7.2. Advantages of Predefined Colors: Avoid Colormap Hell
Although a Java applet or application is by no means restricted by to the predefined colors, sticking to the predefined sections avoids any colormap issues.
3.7.3. Custom Colors: The Road to Colormap Hell
If custom colors are desired for a given application, Java supports two different color models, the RGB model and the HSB model.
3.7.3.1. RGB vs. HSB
RGB stands for Red, Green, Blue. This is the basic system that most color systems use. To create a custom color, the red, green, and blue components of that color must be specified. Each of these values ranges from 0 to 255, for a total of 256 possibilities. Hence, using this model, it is possible to specify 256×256×256, or 16,777,216, or over 16 million colors.
Another system for specifying colors is the HSB system, or hue, saturation, and brightness. Each of these values can range from 0 to 255, for the same number of colors as the RGB model. There are actually algorithms that translate from one color model to the other, so the two systems are actually equivalent. The same colors are produced. The only difference is how the colors are specified.
3.7.3.2. Colormap Hell
Colormap hell occurs when an application tries to use more colors than are available in the system. In that case, depending on the system that the application is running on, one of two different scenarios can occur:
3.8. Extended GUI Components
The following section outlines the various different components that are available on the market today:
Notes:
Netscape will ship the IFC with their communicator (Netscape Navigator successor) product, which is currently in beta in the Windows 95 Environment. For other platforms, it needs to be downloaded as part of the applet or distributed as part of the application.
Marimba also ships the Castinet/Tuner, which allows for automatic software update capability and broadcasting. They have an agreement with Apple, which means it will be included with the next OS release.
Shafir provides functionality similar to Netscape's IFC. Shafir has more components than the IFC, but it is doubtful that they can compete with the mindshare accessible to Netscape in future releases.
Marimba's product offers a complete packet that is unfortunately too immature to fully endorse. Performance is lacking, and with the imminent release of JDK 1.1 with Java Beans, they will have an uphill battle against much larger and established competitors.
Notes:
Microline's Component Toolkit is the best performing widget suite currently available. However, the API is awkward, and it lacks support for anything other than iconic images and text in the table/hierarchy widgets.
KL Group's LiveTable product supports arbitrary Components. The product is mature and absent of surprises. The widget feels slightly sluggish, but appears to handle large numbers of records just as well as few.
Notes:
NetFactory is the only commercial charting vendor that the Java Design Center, Sun Microsystems is aware of. The product performs well and is extremely comprehensive.
3.8.4. Geographical/Map Widgets
While the Java Design Center is not aware of any Java specific Geographical/Map widgets, there are several companies who are making map software available over the web. Here is a list of companies:
These corporation sell geographic information on CDROM, which perhaps can be used to write a Geographical/Map widget.
3.9. Practical Limitations of Java GUI Components—A Guide Line
As with all GUI components and GUI systems, there are some practical limitations to Java GUI Components. Specifically, the following issues exist:
3.9.1. What are the Alternatives?
There are alternatives, but sadly there are no direct resolutions to the above problems. The alternatives all involve downloading and storing the information piecemeal, rather than all at ounce. For example, consider the list box: only the information that is currently being displayed needs to be download from the web server. If the user navigates the scroll bar, the applet can go back to the server and retrieve the information necessary. If some clever caching algorithm is used (such as caching the information immediately below what is being displayed, in addition to what is being displayed), then a simple scroll down may not require a query to the server. Another approach is to have a background thread downloading new information while the user is browsing cached information. That way, the program is literally one step ahead of the user.
The other alternative approach is to use a hierarchical widget, which only stores information about nodes that are expanded. When the user wants to expand a node, the application retrieves the necessary information back from the server.
A third alternative allows the user to specify the subset of information that is needed by typing it in. The application would then query the server for the subset of information that is required. If the size of the result is large, the server could notify the applet, and the user can be prompted with a dialog box. The selections of the user could then be stored in a separate text box. This process would repeat until the user has selected all the items required.
All these alternatives assume large number of queries between the client and the server. In order for these alternatives to work well, a network model with low latency is necessary.
3.10. Shortcuts
In a Java GUI application, users are able to cycle through visual widgets (such as text fields) through the use of the TAB key. This is a default behaviour; note, however, that this is broken in Windows 95 and Javasoft is working on fixing this.
The AWT provides facilities to trap keyboard events (including combination of keystrokes such as ALT-X or CONTROL-C). This allows developers to create custom keyboard accelators and mnemonics. A common application of this is to reach menus without having to use the mouse. Users can hit ALT-F to reach the File menu.
Accelator keys lets power users to quickly access menu functions without having to move away from the keyboard.
Here are some common accelarators that are common across different platforms (Mac, Windows and Motif):
Although accelator keys are very useful, note that accelator keys still have not been standardized across all platforms. For example to quit or exit an application: on the Mac, the keys are Apple-Q; on Windows and some Motif/CDE applications, it is ALT-F4. On OpenLook, it is META-Q.
3.11. Error Messages
Error messages should be displayed in a dialog box. This way, the users can move the error dialog to the side of the screen and have the opportunity to look both at the area that is causing the problem and error message itself.
A bad way of implementing error messages is in the web/CGI forms interface. After a user has completed a long web form and submits it to CGI, the response page returns with a number of errors. The user is instructed to click an URL or hit the backpage in order to resubmit the form. Oftentimes, the form has been cleared of all contents so the user has to start from scratch. Also at this point, the error message has disappeared so the user has to rely on memory to know what was the problem with his earlier input.
3.12. Delivery Mechanism/File Formats
Java requires each object or class in a program to be stored in a separate file. For typically sized applications, however, this could mean that the applet or application could be composed of thousands of separate files (since those applications are typically composed of thousands of separate objects). Managing and downloading that many separate files has created real problems.
3.12.1. Using Standard ZIP/JAR Files
To solve this problem, Java a ZIP or JAR file, which is a file composed of many separate files, with a header identifying the contents of the file, as well as an optional signature. This has the advantage that the entire Java applet is downloaded all at once, rather than piece meal. Also, for a Java application, the system administrator is responsible for distributing only a single file, rather than a collection of files.
3.12.2. Signed ZIP/JAR Files
Signed ZIP/JAR files allow cryptographic security that the ZIP/JAR file has not been tampered with since it was created. This gives the user of the ZIP/JAR file the confidence that the file that was received, through whatever mechanism (network transport, floppy, etc.), completely intact, and unmodified.
3.12.3. Using ZIP/JAR File to Ensure Version Consistency Across all Class Files
ZIP/JAR files also solve some versioning problems. For example, consider this scenario:
Using ZIP/JAR file avoids this problem by encapsulating all the correct classes in a single file.
3.12.4. Is it Possible to Have Application in Multiple ZIP/JAR Files???
Sometimes, for download time and memory efficiency reasons, it is not desirable to download the entire application at once. For example, consider Microsoft Excel: we can safely assume that a vast majority of the users of Excel do not use most of the features (the 80/20 rule probably applies: 80% of the users use 20% of the functionality) of the product. However, when Excel is installed onto the hard disk or loaded into memory, the entire product is loaded. The majority of the application is not being used, yet it is using up system resources.
In the Java model, this could be solved if the application can be divided, by functionality, into separate ZIP/JAR files. That way, when the user starts using an advanced function, the ZIP/JAR file that corresponds to that functionality could then be downloaded.
This is NOT possible in today's world, however. The only available options are separate class files (which would address the above problems, since in the Java model, only the necessary class files are downloaded, not all of them, but this approach has other problems as outlined above), or the ZIP/JAR file approach, which would download the entire application.
3.13. Privileged Class Download Management
In the hybrid scenario described in section 5.2.1.3.1, a version control issue comes up. What if the interface for the class on the local disk is different than the rest of the application? For example, what if a new application was downloaded for the web server, without the corresponding privileged class files installed on the local disk?
One way to control this scenario is to put a PUBLIC STATIC member in each privileged class that gets loaded on the local disk, which holds the version number for that particular class. That way, the Java applet can query the version of the classes that are loaded locally. If there is a version mismatch, the applet can put up a dialog box stating that the user must download and install a new version of the local files.
3.14. Managing Context Sensitive Help
All business applications these days must have context sensitive help. It is no longer acceptable to have a help button that simply pops up the user manual, without presenting the appropriate sections that document the specific functionality of that part of the application.
3.14.1. Java Applet Model
In the Java applet model, this can be easily implemented by using the browser window as the hypertext documentation viewer: Each component of the application needs to store a URL, which points to the specific documentation for that component back on the web server. When the help button is selected on that particular component, the Java applet redirects the browser window to that URL, which is then loaded from the web server. This model has several advantages:
3.14.2. What to do for Java Applications??
Java applications, on the other hand, do not have the Web browser associated with them. For Java applications, like all standard applications available today, would have the online help incorporated directly into the application, or could be dynamically loaded off the local disk at runtime. Either way, the help section takes up local resources. Also, the application would be responsible for incorporating a help file viewer. This can be solved by taking some of the publicly and/or commercially available HTML browser classes and using them. Netscape, for example, has such a class hierarchy in their Internet Foundation Classes product.
3.15. Managing “Tool Tips” or “Balloon Help”
Using the AWT a developer can custom implement tool tips or a third party library can provide it. For example, Marimba's Bongo library provides a type of ballon help.
With Marimba's library, the user places the mouse pointer over some item in question. A little yellow rectangle with the help message pops up after a prescribed period of inactivity.
Another type of help is to provide the help message in the status bar of the browser/application. This automatically occurs when the user moves the cursor over the area in question. For example, when a user moves the mouse pointer over a certain button, the status bar of the browser displays a message explaining what the button is used for. This type of help is limited by the amount of space the status bar is able to provide. Long messages cannot be displayed completely and are cut off.
Ballon help has a similar limitation as very long help messages are overwhelming and distracting to the user. There are times the user does not want to see the message.
These types of help, despite their limitations, provide application users with a quick way of understanding what something does without having to resort to the manual or the help option.
3.16. Managing Data Export
Most business applications need the ability to import and export data in and out of the application. At the very least, most applications need to be able to access the printer, or the printer spool, in order to print documentation. Also, applications typically require the use of local configuration files, for saving user specific information.
As per the Java applet model, these things are not possible with a pure Java applet. Several scenarios for overcoming these restrictions are possible, however. See section 5.2.1 for a more detailed discussion.
3.17. Managing Job/Task Scheduling
Job scheduling is another requirement of some business applications. Job scheduling allows the user of the application to schedule lengthy tasks, such as spell checking an extremely large document, to periods where the user is not going to be using the client, such as overnight, or during lunch time.
The Java Applet model does not have direct support for scheduling, or batch processing. However, since Java fully supports multiple threads, writing and running a thread that is simply responsible for waiting until the next scheduled start time, and then starting another thread that is responsible for handling the scheduled task is trivial.
3.17.1. Task Scheduling in the Java Applet Model
The only issue is that in order for the scheduler thread to be running, the applet must first be started. Since applets are started via the web browser, the web browser must first be started, and made to point at a specific page, where the applet resides. This can be done by configuring the system to start the browser at startup, and have the browser's default page be the page where the applet starts. Configuring the system to automatically start whenever the system starts is a system specific task. Under Windows 95 and Macintosh, the browser icon is placed in the Startup folder. Under UNIX, the/etc/rc*/* scripts are modified to automatically start the browser.
3.17.2. Task Scheduling in the Java Application Model
Since a Java application is started the same way as any other application on the system, the business application can be started via the system specific startup mechanism, described above.
3.18. Internationalization Using Java
The global Internet demands global software; that is, software that can be developed independently of the countries or languages of its users, and then localized for multiple countries or regions. JDK 1.1, to be FCS by Sun Microsystems in February, 1997, provides a rich set of Internationalization APIs for developing global applications. These APIs are based on the Unicode 2.0 character encoding and include the ability to adapt text, numbers, dates, currency, and user-defined objects to any country's conventions.
The Internationalization APIs are concentrated in three packages. The java.text package is new for JDK 1.1 and contains classes and interfaces for handling text in a locale sensitive way. The java.io package contains new classes for importing and exporting non-Unicode character data. The java.util package contains the Locale class and the localization support classes as well as new classes for date and time handling. Some additions and corrections have also been made to classes outside these three packages.
3.18.1. Design Goals for JDK 1.1
The fundamental objective for the JDK 1.1 Internationalization APIs is to allow developers to easily write global applications and applets. The following are the design goals used to achieve this objective.
3.18.1.1. International by Default
Traditionally, internationalization has been a separate process that is optionally performed after normal development. This model does not work for developers writing Internet programs in “Internet Time”. By contrast, Java programs should be internationalized by default. This implies that it should be easier than not to write internationalized Java code.
3.18.1.2. Object-Oriented Design
Traditional internationalization support has been procedural in design and has relied on global state to affect locale-dependent operations. Java internationalization requires an extensible, object-oriented design that avoids global state.
3.18.1.3. Multilingual Support
Not only is every major language on the planet used on the Internet, but users often need to use combinations of these languages in order to communicate with each other. Java must provide multilingual support as well as support for many individual languages.
3.18.1.4. Platform Independence
Java programs must function on many different platforms.
Internationalization must always work the same, independent of the platform. Therefore, the Java Internationalization APIs must be platform independent.
3.18.1.5. Support for Unicode
Unicode enables multilingual programs. Java is unique in programming languages in having chosen Unicode as its primitive built-in character type. JDK 1.1 supports the Unicode Standard, Version 2.0.
3.18.1.6. Backwards Compatibility
An API implementation needs to remain backwards compatible. This includes classes, interfaces, and methods that cannot be internationalized because of inherent design limitations. These limitations are noted and alternative classes, interfaces, and methods provided.
3.18.1.7. Focus on JDK 1.1's Clients
Enabling users of JDK 1.1 to create global programs is the focus of this release. Internationalization and localization of the JDK itself is not a goal for this release; this will be done in a later release.
For more information, please consult http://www.javasoft.com/products/JDK/1.1/docs/guide/intl/index.html.
4. Performance Style Guide
This section aims to discuss some of the issues with regards to performance style and performance tuning.
The Internet has posed several performance challenges, as compared with its peers, the intranet and the extranet. These challenges are described here.
4.1. The Network Model
Describing and understanding the network model that best describes the network behavior is one of the most important tools need to tune the performance of an application. The network model, in its simplest form, can be best understood by categorizing and describing the throughput and latency of the connection between the client and the server infrastructure.
4.1.1. Latency/Round Trip Timing
Typically, latency in telco terms is defined as the amount of time it takes for information sent from end of a circuit to reach the other side. Latency is introduced by a several factors, including:
For the purposes of client/server type of applications, it is easier to manage latency if it is defined as the round trip time between a client sends a query to the server, and the client receives the response from the server. For the sake of network performance discussions, it is assumed that the server takes no processing time to respond to the query (obviously, this is not true, but server delay is beyond the scope of the style guide, and requires a whole different model to describe and understand).
4.1.1.1. The Internet is High Latency
The Internet, in general, can be thought of as a high and variable latency network link. The reasons for this are as follows:
In conclusion, the Internet has a high, and variable, latency. The latency certainly will change among different connections, and possibly within the same connection.
4.1.1.2. The Extranet/Intranet is Low Latency
The Extranet/intranet models typically have low latency for the following reasons:
In conclusion, the intranet/extranet network model shows that the latency is low.
4.1.2. Throughput
Throughput in telco terms is the amount of bandwidth that can be sent via a given point over a period of time. That is, how much information can be fed into the circuit over a given period of time. This is typically measured in number of bits (or bytes) per second. For example, Ethernet is 10 megabits/second, whereas a T1 circuit is approximately 1.5 megabits/second, and a T3 circuit is 45 megabits/second.
4.1.2.1. Internet is Variable But Potentially Medium to High Throughput
The nature of the Internet makes it difficult to discuss throughput, since each client on the Internet is connected to the next router in the process at different speeds. For example, a person dialed up to the Internet from their home is typically connected either at 14.4 kbits/second, or 28.8 kbits/second, or if they are lucky, they have ISDN service, which allows for 64 kbits/second (or 128 kbits/second depending on the service). They typically connect to infrastructure that is significantly faster than that. On the other hand, a corporate Internet user could be connected via a dedicated circuit ranging from a T1 on the low end, to a T3, or several T3's, on the high end. However, being connected via a high speed link doesn't necessarily guarantee that the total throughput between the client and the server is at that high speed, since all the circuits in between would also have to be at that speed. The circuits in between the client and the server are also shared among all the different clients on the Internet, further clouding the issue. Time of day also plays a role in throughput calculations, since the Internet is more heavily used during certain times of the day than others (for example, Lunch time on the east and west coasts of the United States are when the Internet experiences the heaviest loads).
In conclusion, the bandwidth model for the Internet is hard to model correctly, but the total throughput could be high.
4.1.2.2. Intranet/Extranet Allows for Consistently High Throughput
The intranets and Extranets typically provide for high bandwidth and throughput, since they are custom networks that are scaled to match the required bandwidth. Extranets are also composed of dedicated links between the client and the server infrastructure, making the model easier to construct.
What model is the best? Clearly, the Internet model is the cheapest, since Internet connectivity is a commodity item these days. However, its constantly changing and unpredictable model make it impossible to guarantee service. Therefore, any application that absolutely demands a service lever guarantee cannot rely on the Internet for its communications infrastructure.
4.2 Multimedia Issues
In the past, the Internet was purely text based, everything fit nicely into the 80 column, 24 line display. Today, the Internet has become much more multimedia oriented. The World Wide Web now fully supports graphics, animations, audio, and even video.
4.2.1. Graphic File Formats
As of today, there are many different graphic file formats, each optimized for a specific function. The two most popular on the World Wide Web today are GIF (Graphic Interchange Format) and JPEG (Joint Photographic Experts Group). GIF was developed by CompuServe for use on their online system during the late 1980's. JPEG was developed later as a way of further compressing images.
4.2.1.1. GIF
The GIF (Graphic Interchange Format) file is a popular image format due to the many available viewers cross all platforms, as well as its compression algorithms. The GIF format was first developed in CompuServe, and patented in 1987. CompuServe redesigned the image format to allow for transparency and interlacing, and repatented the file format in 1989. The GIF standard was popular in the World Wide Web in the beginning, since that was the only file format supported by the original Mosaic browser, as well as the initial Netscape browser. However, due to the patent that CompuServe holds over the standard (and the constant threats from CompuServe to actually impose the patent and start charging royalties for the use of the standard), as well as the integrated support of other image formats in all major browsers, the World Wide Web is now moving away from the GIF standard, to the JPEG standard.
4.2.1.2. Interlaced GIF Images
Netscape introduced interlaced GIF graphics as a means of “virtually” speeding the transmission of GIF graphics, where an immediate low-resolution image is loaded with the text content of the page, then the low-resolution proxy is gradually updated in four passes until the full-resolution GIF images is displayed. This gives the user a quick impression of large graphics as they download, and also give the user almost immediate access to text and hypertext links on the page.
This feature is now supported by Microsoft Explorer as well.
4.2.1.3. Loading Low Res/Hi Res GIF Images
Netscape has implemented a scheme that allows you to specify a set of smaller, low-resolution graphics to load in quickly when the user first opens a page, but which will later be replaced by high-resolution images. Netscape will load all of the low-resolution graphic “proxies” on the first pass through the page, then make a second pass that replaces the low-resolution proxies with the full-size high-resolution source graphics. By manipulating the Netscape HTML width and height extensions you can “stretch” or scale up the small, low-resolution graphic proxies so that they display at the same screen size as their high-resolution counterparts. This will give the web site users a relatively quick impression of the whole page layout (particularly on pages that contain many large graphics) without forcing them to wait to begin reading or scrolling while all the high-resolution graphics gradually load into the page.
HTML IMG tag for a pair of low/high resolution source graphics:
4.2.1.4. Animated GIFs
Netscape also introduced a method for doing animations on the World Wide Web. The GIF standard, as documented by CompuServe, allows a series of images to be stored in a single file, with meta data describing the delay, in microseconds, between the images, as well as whether the sequence should be repeated or not. Netscape first implemented Animated GIFS in Navigator v2.0. Since then, Microsoft Explorer has also implemented Animated GIFs.
Today, it is hard to find a web site that does not take advantage of this simple, yet incredibly useful, feature.
Netscape Navigator, as well as Microsoft Explorer, now supports the industry-standard, publicly available, non-patented JPEG (Joint Photographic Experts Group) compression format for inlined WWW graphics. Given the huge compression ratios that can be achieved with JPEG compression and the recent legal uncertainties raised by CompuServe over the status of the GIF image format, JPEG will likely evolve as the standard for WWW graphics over the next few years. However, many existing browsers (such as Mosaic, and the AOL browser) currently in use do not support inlined images in JPEG format, and this still limits the current utility of the JPEG format for broad use in WWW design.
If your WWW viewer does not support inlined JPEG images (like Mosaic1.x) the JPEG-format files may be transferred to an external application (like JPEGView under Windows95) instead of being displayed as an inlined image within the example page, or may not show up at all.
For more information, consult the JPEG frequently asked questions page, at http://www.cis.ohio-state.edu/hypertext/faq/usenet/jpeg-faq/top.html.
4.2.2. Audio File Formats
4.2.2.1. WAV Files vs. AU Files vs. RealAudio
Currently, there are two classes of audio players on the Web: Those that play in real time (while the sound data is being transmitted over the Internet), and those that wait until the entire audio data is downloaded before starting to play the audio.
Initially, when the World Wide Web was in its infancy, only the second model was possible. Audio files were completely downloaded to the client by the Web browser. The audio player software was then directed to play that piece of audio. Naturally, there were many different audio file formats, such as WAV, AIFF, AU, snd, etc. Each format, as with their graphics counterparts, had its advantages and disadvantages with respect to the sampling rate, sample size, and compression algorithms.
WAV files, since they are most common on the Windows platform, are the most popular, but it is very common to include the same sound in several different formats, and allow the user to choose which to download.
As time went along, another method was introduced that allowed for real time audio that was played as the sound was downloaded. The first such product was called RealAudio. There are now several such products, each optimized for different things (there are several bi-directional such products as well, such as the WebPhone). These products are less reliable than their predecessors, since they require consistent bandwidth between the client and the server, but since the human ear is capable of making up for short dropouts, this method has actually gained popularity. The majority of traffic over the Internet backbones is actually RealAudio traffic.
In conclusion: To maximize the likelihood that a given client would be able to play the sound file, several different file formats need to be made available.
4.2.3. Video File Formats
Although video is not yet completely ubiquitous on the World Wide Web, the amount of available bandwidth is quickly reaching the point where real time video is possible. Currently, there are two competing standards, MPEG and Quicktime.
4.2.3.1. MPEG
The MPEG standard is a standard for encoding video and accompanying audio into a single bit stream, so that it can be stored or transmitted. MPEG is an incredibly complex compression algorithm designed to minimize the amount of bandwidth required to transmit live video and audio. MPEG typically requires specialized hardware support for real time encoding and decoding.
For more information, consult ftp://pit-manager.mit.edu/pub/usenet/comp.multimedia/.
4.2.3.2. Quicktime
Quicktime is a standard developed by Apple Computers for encoding video and accompanying audio into a single bit stream, so that it can be stored or transmitted. On the World Wide Web, Quicktime has several advantages over MPEG:
1.1.1 AT&T's Competitive Products
AT&T offers the following network management tool for their high-end customers.
You will find other products compared. Please keep in mind that these products offer only a couple features of 800 Network Manager but warranted being included.
Accumaster Services
Introduced in 1989. It is a user friendly management tool for monitoring and controlling Inbound and Outbound (SDN) services. It is based on a SUN SPARC station workstation equipped with a variety of software, ranging from expert systems for network planning and configuration to marketing analysis. Word on the street is that AT&T is not marketing the Workstation anymore but is selling the software for use under the Accumaster name. However, there are a lot of workstations still in existence as this product continues to be MCI's main competitor in bids for new business from AT&T.
1.1.1 Routing Manager
1.1.1.1.1 Routing Control Service On-Line
AT&T offers more control over their Call Prompter service through RCS. Specifically, customers have the capability to add and delete layers of their Prompter applications as if they were building blocks. For example, a customer may normally have a single layered prompt structure (Press 1 for Sales, Press 2 for Customer Service); however, under special circumstances, they want to be able to add a second layer under Customer Service (Press 1 for Technical Support, Press 2 for Billing Inquiries, Press 3 for General Comments, etc.). We believe that customers can very quickly make these kinds of changes to their prompts with RCS.
RCS does not allow customers to change their DNIS digits as can be done through CM. Customer must provide their own personal computer or dumb terminal. Same routing change/install capabilities/parameters as RCS Online. But (unlike RCS) do data entry into your PC off-line, then batch upload to AT&T computer (or download current data in AT&T computer for modification off line at your computer) in very short call.
RCS Assurance
(for rcs online/rmi users)
Get 800 RCS assurance credit equal to monthly charge per billing account (only one credit per account per month) if you can not use RCS online/rmi for more than 1 hour. Assurance does not apply to interruptions due to customer negligence/failure to report problems or allow testing or repairs or failure of non AT&T systems.
Routing on Demand—
“Poor Mans RCS”. You call AT&T 800 advanced features service center (except during maintenance hours) in St. Louis on 800 #, give id and pin, tell what pre-stored alternate routing plan/s to use. Change effective w/in 5 minutes or can be delayed to specific date/time. Effective until changed again.
1.1.1.2 Next Available Agent Routing
Specify Sequence of up to 99 alternate sites (trunk groups) where calls can be routed if primary site busy/already handling MCA (maximum calls allowed). AT&T network hunts through alternate routes in specified order looking for site to take call. Must also specify MCA at each site (max MCA each site is number of receiving lines). Can also reroute calls to announcements, network busy signal, network ringing, or Network Queuing. Can change MCA by RCS Online or RMI free, or Routing on Demand ($50 fee).
Network Queuing—
AT&T network holds calls in queue until customer site able to take call; requires Next Available Agent Routing. Can set up to serve single site (fixed queue) or multiple receiving sites (variable queue). You specify how many calls (slots) can be held in queue for each receiving site; beyond that callers get busy signal. You can change number of slots by RCS-Online, RCS-RMI, or Routing on Demand ($50 fee). Other changes require AT&T personnel and fee. When caller put in queue, delay announcement (custom or generic; 4 minutes max; routing information only). Can stay in queue max 30 minutes until completed or caller hangs up. Free “keep holding” announcement played every 30 seconds after initial announcement.
1.1.1.3 TOPMS/ICP
1.1.1.3.1 TOPMS Overview
TOPMS is a non-tariffed product, and therefore the following information is the latest from competitive sources and is subject to change.
AT&T's TOPMS is a real-time system that allows customers to monitor multiple call centers through one central ACCUMASTER Service Workstation. TOPMS can monitor up to 24 ACDs in real time and allows the user to set their own measurement thresholds. Some of the thresholds available are average speed of answer, talk time, average hold time, and number of calls in queue.
TOPMS data can be displayed in map-like graphics or in table formats that contain individual centers and/or ACD splits. The customer can monitor multiple centers out of one location.
TOPMS allows customers to define thresholds and alarming. This alerting feature provides visual or audible alarms whenever certain performance thresholds are exceeded in any call center or ACD split. In addition to monitoring and alerting capabilities, TOPMs has a detailed algorithm that makes recommendations on how to shift traffic through percentage allocation and/or staffing adjustments.
TOPMS is used by large Call Center customers to help them make 800 load balancing decisions based on real-time information from all ACDs across their network. TOPMS does NOT make the actual routing changes—customers must still make the actual routing change using Call Allocation (percentage routing), Area Code Routing, or Command Routing. They can initiate these changes themselves at their ASW or call AT&T to make the changes.
TOPMS Conditions
TOPMS requires an Accumaster Services Workstation system. The customer currently may ONLY use the Sunsparc WS.
1.1.1.3.2 ICP Overview
AT&T's 800 ICP combines the routing capability of the AT&T Switched Network with the intelligence of a Host Processor located at the customer premise to route 800 calls on a call-by-call basis. Whenever an AT&T 800 number is dialed, if there is an ICP “trigger point” in the 800 routing plan, the AT&T network sends a “What do I do with this call?” query to the host processor (known as the CRP—Customer Routing Processor). The CRP then tells the AT&T network where to send the call. The information sent from the AT&T network to the CRP can include any or all of the following:
In other words, the routing intelligence resides on the customer premise, not in the network. Additionally, AT&T is NOT looking at actual ACD statistics, across multiple centers. If that information is needed, it must be provided by the customer into the CRP, along with the routing algorithm that tells AT&T where to route the call.
ICP Conditions
ICP Pricing (ICP is a Tariffed Product)
1.1.1.4 Select Routing
This feature allows a customer to set up and store as many as six routing plans, per 800 number, in the AT&T network. At any given time, one of the plans must be active—actually processing calls—while others are held in reserve. Customers can activate any of the reserve plans by using on the RCS or by calling in to AT&T. A user access code and PIN are required when customer calls in to enhance network security.
Customers can also have certain “reserve” plans activated automatically at some prearrange time. They call in to schedule or implement with RCS.
Example: A customer can design a routing plan for “normal” conditions and others for special situations that arise from time to time—such as an end-of-the-month call surge, a weekday holiday a special promotion period, and others. The customer can then have the appropriate “reserve” plans activated as needed or on some prearranged schedule.
1.1.1.5 Customer Direct
The AT&T Customer Direct Platform is targeted to midrange customers and supports five network management applications—Order It!, Manage It!, Control It!, Optimize It!, and Analyze It!. This platform has been designed to help manage all vital corporate network assets: VTNS, Cellular, IntraLata, International and more.
The Order It! Application allows customers to electronically submit orders for Virtual On-Net, Switched Access, Cellular, and IntraLata locations to AT&T. It also helps customers to track the status of pending orders.
The Manage It! Application is a unified solution for all network configuration information. It provides management of authorization codes, flexible routing, and screening groups. Manage It! Allows customers to complete, accurate and current inventory of their network locations and features.
Control It! Allows customers to monitor network costs, call volume and network integrity. Access to this up-to-date information will help customers minimize expenses and make decisions based on the most current data. This includes cost justification studies to determine if changing a switched access location to dedicated access will generate savings.
With the Optimize It! Application customers can improve network productivity through easy access to information on calls completed, line load and traffic trends. Recommendation Reports help identify where dedicated access lines are underutilized and switched access would be more efficient.
Analyze It! Uses CD-ROM technology to give customers accurate, up-to-date billing records and analysis tools that are easy to access, use and store. Analyze It! Lets customers access and analyze their records, with more than 160 standard reports (as well as the ability to create custom reports and applications).
Manage It! For AT&T Customers Direct allows customers to manage their Toll Free network management features and locations. It operates using a mirror image of their network database, which resides on a PC or server designated by the customer. All modifications are made to this one database and are then uploaded to AT&T to take effect in the customer's network.
Although multiple users on a local area network (LAN) can access and read the information provided by Manage It! Only authorized user can make changes to the information. This helps ensure the integrity of the data. Manage It! Is not available to multiple users across a wide area network (WAN). AT&T Customer Direct can currently run on Novell NetWare 4.X LANs and Windows NT.
Manage It! Gives customers a complete list of their locations—virtual on-net, dedicated, switched access, even “featureless” switched locations. The application communicates directly with the AT&T Network Service Management System so customers can be sure they are getting an accurate, current picture of their SDI at all times. Any changes and updates entered are typically active within 15 minutes. In addition, Manage It! Helps customers to maintain a local database on their PC, including their PBX trunk groups, T1.5 data, account codes, and voice mail data.
1.1.1.5.1 Manage It!
1.1.1.5.1.1 Competes with 800 Network Manager's Low end Customers
Offered on AT&T's Customer Direct Platform that supports five versatile network management applications, Order It!, Manage It!, Control It!, Optimize It! and Analyze It!. Each application offers quick and easy operation in the window environment.
Manage It! is a unified solution for all network configuration information. It provides management of authorization codes, flexible routing and screening groups. It also allows a customer to view a complete, accurate and current inventory of their network locations and features.
Features:
1.1.1.5.1.2 Managing Authorization Codes
If customers need to update authorization codes whenever employees join or leave the company, Manage It! Gives them an easy way to do it. Customers don't need to maintain a separate database for their on-net or Network Remote Access (NRA) option 1 authorization codes. The application stores the codes and allows customers to add, delete, or change them as needed.
Customers can even use the Import/Export capabilities of Manage It! To add large volumes of authorization codes or to move codes from one screening group to another. With Manage It! Customers can even match authorization codes to an employee name or ID code of up to 15 digits. In addition, customers can manage fraud protection and cost containment by regulating calling privileges for on-net, off-net, and international long distance calling.
1.1.1.5.1.3 Standard and Customized Report Options
Manage It! Provides access to more than 45 pre-defined reports—and allows customers to download any of their network data to create their own customized SDI reports through the Question Report Writer included in the software.
1.1.2 Sprint's Competitive Products
1.1.2.1 Sprint Insite Product Line
Sprint's Insite product line provides a full complement of Customer Network Management (CNM) capabilities designed to meet customers' changing CNM requirements. The Insite family of products is composed of Insite Executive, Insite PC, and Insite Agent. Each product line was designed to meet the challenging CNM needs of today's business.
Insite Executive is Sprint's evolving, integrated network management platform based on a high-performance workstation. Designed to provide customers with a truly integrated services management system, Insite Executive will manage all Sprint's voice, private line, and packet switched offerings using a single workstation with a consistent graphical user interface.
Insite PC provides management of Sprint services via the customer's personal computer. Designed to provide an economical means of managing multiple Sprint services, Insite PC provides network control, operational measurements, administrative maintenance and trouble management functions.
Insite Agent provides customers with the ability to monitor the health and performance of their networks. Insite Agents currently operate with the use of the Simple Network Management Protocol (SNMP) in conjunction with the Management Information Base (MIS) browse component of the customer's Network Management Station.
1.1.2.2 Insite Executive Call Director
Call Director is Sprint's routing control service, which runs on Insite Executive. Customers can add, change or delete Enhanced Routing Trees or routing plans in near real-time (within 5 minutes) for their toll free numbers. Customers access Call Director functionality from a Sprint Station or from a customer provided SPARC workstation that utilizes Call Director Software. Customers may create as many routing plans as they wish. Plans may be validated and stored for future activation, as far as two years in advance.
Redirect 800 numbers as the need arises or store for response to typical network conditions. Dial up and Dedicated Access Supported.
1.1.2.2.1 Site RP
Customer's own on-premise computer (Site Routing Processor) tells Sprint Network how to route 800 calls to different customer sites real time. call by call. Customers decides and maintains routing tree. CRP can be Sun Workstation to IBM Mainframe.
Routes calls individually based on customer provided parameters.
Sprint provides software and link to network. Customer provides the processor (PC, minicomputer or mainframe). Customer installs software and perform any additional programming.
Requires X.25 dedicated data links from CRP to each Sprint CRP (5 circuits total) Sprint buys from Telco and passes to customer as flat $1,155 per month (total 5 circuits).
1.1.2.2.2 Network Call Distributor
Provides load balancing throughout the network. NCD processors are in the network. Customers control from their sites (through Insite PC or Executive). Requires X.25 circuits from each ACD to Sprint network. NCD collects real time data from customers ACDs on agent/site availability and routes calls to best site. User gets real time routing without tying up time/money in personnel and equipment.
User can change routing logic/parameters by calling Sprint or by logging into Insite or Insite Executive.
1.1.2.3 Sprint's Insite Strategy
The Insite strategy is to allow customers to more effectively use and leverage Sprint's inherent network capabilities to manage their business. Customers can make decisions based on real network data that can be consolidated across different services and locations.
Insite PC 1.7/Insite PC Managers
Insite PC, being re-named Customer Network Manager will initially handle inbound and card traffic. The Toll Free network management capabilities will be released IQ97.
Currently, Insite PC Managers offers the following features in a text-based, Windows compatible format:
MCI Background
The current MCI ServiceView (MSV) product line provides MCI Business Market customers with Windows based client-server applications for customer network management and call usage analysis. These applications include: Perspective, TrafficView, 800 Network Manager, Outbound Network Manager, Fault Manager, Direct Dispatch, Call Window, and System Administration and were built and deployed between 1994 and 1997.
Although the MCI ServiceView PC applications reside on a common platform and use objects to promote common look and feel, there is little cross application interoperability and data sharing. The customer must use the separate applications to gain access to their data. There are additional customer network management applications (e.g.—HyperScope, Call Manager, Portfolio) which are not MSV based and therefore do not share the same PC configuration and communications as the MSV ones.
The Next Generation product suite, also known as Starbucks, allows MCI to leapfrog the competition by offering a consolidated Web based network management product to the MCI business customer. There are many reasons for providing a web-based solution for these requirements:
User access—depending on needs, web applications may be made available to anyone with Internet access either internally behind a firewall, or externally to anyone on planet Earth.
Training & support—a critical part of most application deployment is the plan for training and support. Web-based applications can eliminate much or all of this need since they utilize existing client software which users have already installed and learned how to use.
Platform independence—a well-designed web application should work with most web browsers on whatever hardware and OS platform the user selects. Additional requirements analysis are not needed to specify the supported user environments. The choice is where it belongs: with the user!
Productivity—the development cycle for web applications is shorter than for traditional client-server applications due to improved development environments and the plethora of easy-to-use, high-powered tools.
Availability of tools—there are a large and rapidly increasing number of tools available at low or sometimes no cost for implementing sophisticated web applications.
Communications problems—the Achilles heel of many applications has traditionally been their connectivity to the user community. Web-based applications shift the burden of connectivity to the user and the Internet provider using standard hardware and software. These issues are resolved before the web application ever hits the street.
Installation and configuration—the other main problem area for traditional applications has been the initial setup and installation. Again, the web applications avoid this problem by utilizing existing software and facilities.
Minimal client development—since the client side of web applications uses off-the-shelf browsers, development is limited to specifying screen layouts and data presentation using a common interface. In many cases, users can design the screens using standard word-processing and web screen design tools.
The main point is that web-based applications allow MCI developers to focus their development on the specific products and services unique to MCI, without wasting development, test, and support energy on other aspects of software delivery.
1.1. MCI Internet Gateway Security Standards
All external MCI Web sites must obey the Internet Gateway Security Standards enforced by MCI Network Computing Services (NCS, the owners of Infolink which is the network that all our computer systems use). Placing a web site on the Internet and then allowing our customers to use it to access sensitive MCI account information is a very serious proposition. To do this a certain server architecture must be obeyed to ensure systems security. We will all probably have to architect and assess the cost of our systems around the NCS standards set forth in the NCS document (http://estf.mci.com/estfpage/internet.html).
Below is a summary of the basic architecture that all MSV and other web sites that communicate with customers most obey. In a nutshell, no customer may directly connect from their PC to a web site or web page link running on a midrange, DBMS or warehouse server connected on the MCI Intranet. EVERY web site link including presentation pages will run on web servers in the DMZ, and at the same time these web servers will have NO connectivity to any midrange or host server on the MCI Intranet, EXCEPT for special proxies and/or relays that use sophisticated and some what cumbersome security measures to make SPECIFIC secure connections to application hosts on the intranet. This architecture model separates all server processing, data storage and legacy connectivity from any web system that directly interacts with a customer in order to insure MCI systems integrity and security.
Strong security is an essential characteristic of this application. In support of that the following measures are included:
Firewall—access to the web server is restricted to authorized customers and staff. Access behind the firewall is not available to external connections. The firewall is integrated with existing firewalls for other external MCI web applications.
Front-End Access Security—initial user authentication and user access management including user cancellation and password change processing.
Strong password security—customers will be assigned hard-to-guess passwords. These are long strings of random letters and numbers. Customers may request immediate suspension of a password if they believe it was compromised, but new passwords will only be provided to authorized mail or email addresses. In an emergency, passwords may be delivered by phone to a verifiable and known phone number.
Secure server communications—The application resides on a secure server supporting SSL (Secure Sockets Layer) for encrypted communications between the server and customer.
Transaction-level security services—library of routines for validating individual transactions against user privilege specifications, the privilege model
Digital Certificate validation—a 2-way set of services for validating new users against standard Digital Certificates and for guaranteeing our authenticity for users.
Automated log monitoring—utilities are included to monitor the log for hacking attempts. These are immediately reported to MCI security for follow-up using SNMP.
Customer Security Guidance—a document will be provided to the customer advising them of suggested customer security precautions.
MCI and Customer reporting—usage reports are delivered via e-mail to the customer and MCI account reps.
Even though we will take every reasonable security precaution, customers should be advised that it is impossible to guarantee 100% security and that MCI will not be liable for any security breaches.
1.2.1.1. Uniform, Browser-based User Interface
The Next Generation platform is browser-based. The browser is a powerful new interface paradigm for information delivery. Use of this interface where appropriate will leverage customers familiarity with and preference for the browser, and position the software to be delivered over the public internet.
The set of applications currently lashed together in the Service View platform were separately developed, organized around the specific MCI product offerings which they supported. They use different delivery technologies (e.g., C+/zApp, FoxPro), and different user interface models. To the extent that Next Generation is a more integrated, easier-to-learn, single application, it is vital to unify the use of all the components. This does not imply a critique of any particular existing interface; consistency is the issue.
1.2.1.2. Unified Content
1.2.1.2.1. Consolidated Reporting
The Next Generation Reporting component of the new system unifies the reporting functions of TrafficView, Perspective in all its flavors, Portfolio, NIMS, and HyperScope. This implies consolidated reporting across product lines (as in Portfolio), across customer hierarchies (as in Portfolio and Perspective), and drill up/down do call detail (as in Perspective).
1.2.1.2.2. Common Data
The goal of Unified Content joins to the goal of New platform/framework for CS products at the junction of a common database. This implies a common CDR format for all billed call data; if possible this could be cross referenced to the RTM format to unite TrafficView analysis with billed call reporting.
1.2.2. Internet Availability
Delivery of the Starbucks platform over the internet, as opposed to the existing “extranet” dial-up, allows for authorized customers to manage and analyze their networkMCI service from any browser on any computer anywhere in the world. Realization of this goal represents a significant marketing advantage for the networkMCI services.
Moreover, MCI's customers are increasingly connected to the internet in the course of their daily business. Internet availability will allow the Next Generation offering to work within this context, instead of requiring a dedicated dialup connection.
1.2.3. Platform Independence
The current Service View system is tied to the Microsoft Windows platform. The Next Generation offering should run on whatever platform the customer has in place or at hand. This “Write Once, Run Anywhere” strategy provides advantage in non-Windows environments and insulates the offering from technology and version changes.
1.2.4. Timelier Data
1.2.4.1. Overnight vs. EOM for Priced Call Info
Priced call detail is currently provided on a monthly basis via the Perspective CD-ROMs. It is the goal of the Next Generation platform to deliver priced call detail on a daily basis for the previous day's call activity.
1.2.4.2. 98%/2 Minutes vs. 95/5 for Unpriced Call Info
Real-time unpriced call detail is currently provided with 95% of call attempts available within 5 minutes of the call. It is the goal of the next generation platform to deliver detail on 98% of call attempts within 2 minutes of the call.
1.2.5. New Platform/Framework for NetworkMCI Customer Service Applications
1.2.5.1. Web Browser/Java Paradigm for Client
There are several objectives by using this new paradigm:
1.2.5.2. Thin client
Using Java technologies, a thin client can be developed that has the following characteristics:
1.2.5.3. Quicker Time-to-Market for New Products
Using Java, applications can be developed faster, with fewer bugs. Since Java has integrated threading and dynamic memory management (i.e. garbage collection), applications can be developed significantly faster than in C/C++.
1.2.5.4. Easier Enhancement/Maintenance for Existing Products
Since Java is an industrial strength object oriented language, all the usual benefits from object oriented techniques apply. These techniques include:
1.2.5.5. Automated Software Distribution/Installation
Java applets, or more specifically, the necessary sections of Java applets, are automatically downloaded over the World Wide Web. This eliminates the software distribution costs typically associated with current day applications. All MCI has to do to distribute a new version of the applet is to copy it to the web server. Clients will automatically download the newest version the next time the applet is started.
1.2.5.6. Secure Environment for Customer Data
The Java applet security model assures users that their systems and information are safe from malicious programs and viruses. Java applets are loaded and executed under a security manager which assures that only approved actions can be taken by the applet. This assures users that their data is safe from tampering or disclosure. As customers become more aware of network security, they will demand this level of confidence in the safety of the Next Generation product.
1.2.5.7. Improved Capacity
With current systems at their maximum capacity, MCI has to look for a system that both improves the current capacity, and is scaleable to accommodate all future growth.
1.2.5.8. Internationalization
MCI, being a global company with customers all over the world, must ensure that the software written can be customized to local standards. For example, money figures in reports must be represented using the local currency symbol.
Java has built in support for Internationalization, which will support automatic formatting of dates, times, time zones, and currencies. Support for multi-language versions of the application also exist.
FIG. 1 is a simplified distributed view of the platform components of the present invention, with generic service components shaded.
FIG. 2 is a high-level illustration of the present invention illustrating the relationship of client, web-server, dispatch, middle tier services and the messages interfaces therebetween.
FIG. 3 is a simplified high-level illustration of the Graphical User Interface class relationships as provided in the present invention.
FIG. 4 is a simplified and diagrammatic illustration of the application framework of the present invention.
FIG. 5 is a diagrammatic view of the physical, end-to-end architecture of the present invention, beginning with the customer web browser to the enterprise midrange servers and existing mainframe systems.
FIG. 6 is a diagrammatic illustration of a 3270 pass-thru architecture used to enable access to legacy systems.
FIG. 7 is a diagrammatic illustration of one embodiment of the security infrastructure that combines public key encryption with a digital signature to provide both message security and sender authentication.
FIG. 8 is a diagrammatic illustration of another embodiment of the security infrastructure that combines public key encryption with a digital signature to provide both message security and sender authentication.
FIG. 9 is a screen print of a representative home web page that may be used in the present invention.
FIG. 10 is a diagrammatic illustration of the overall CRISP architecture that provides the reporting infrastructure for customers.
FIG. 11 is a simplified high-level illustration of the customer access to the CRISP functionality from a customer's web based front end over modem-POTS, ISDN and FrameRelay links.
FIG. 12(a) is an illustration of the current MCI Call Manager product architecture.
FIG. 12(b) is an illustration of the new MCI Call Manager as particularly adapted for use with the present invention with web-based client/server functionality.
FIG. 13 is a diagrammatic illustration of customer to legacy application communications through the Starbucks dispatcher and application proxies.
FIG. 14 is an illustration of the message formats passed between the dispatcher and the proxies at the web-server-dispatcher communications interface.
FIG. 15(a) is an illustration of the messages created by the client Java software to be transmitted to the StarWeb server via single or multiple parameters to the POST operation.
FIG. 15(b) is an illustration of the Java client message as decoded by an RMI server into Java object method calls.
FIG. 16 is a screen capture of the InBox Java applet as launched from the home page of the present invention.
FIG. 17 is a diagrammatic illustration of the internal Intranet application to horizontal services architecture used in the present invention.
FIG. 18 is a web enabled application architecture model used in the present invention.
FIG. 19 is a diagrammatic view of the Common Object BackPlane architecture used in the present invention.
FIG. 20 is a simplified view of the Common Object Model-View-Controller event processing as enabled in the present invention.
FIG. 21 is a simplified view of the Common Object entitlements architecture illustrating user privileges and authorizations to view disparate application reports and to request application services.
FIG. 22 is a simplified view of the interaction between security classes in the Common Objects implementation of the present invention.
FIG. 23 is a simplified view of the present invention which details the interfaces between the internal and external systems of the present invention, the application GUIs, the application servers, the StarOE server, the universal in-box and integrated messaging systems.
FIG. 24 is a diagrammatic view of the StarOE (Order Entry) application architecture.
FIG. 25 is a diagrammatic illustration of the StarOE (Order Entry) application architecture illustrating the billing and fulfillment interface.
FIG. 26 is a screen capture of a New User Java applet that may be used to add or modify a user for the StarOE (Order Entry) application.
FIG. 27 is a set of Java classes for creating messages to be sent tot the StarOE server.
FIG. 28 is a high level context diagram of the systems used by StarWRS (web reporting system) of the present invention.
FIG. 29 illustrates the next level of logical processing used by the web reporting system illustrated in FIG. 28.
FIG. 30 is a graphical representation of the physical databases created for use with the web reporting system of the present invention.
FIG. 31 is a graphical illustration of the physical and user determined events that interact with the Java applets of the present invention to drive the web reporting system of the present invention.
FIG. 32 illustrates the message interface between the web reporting system of the present invention and the Report Manager Server.
FIGS. 33(a) and 33(b) illustrate typical web page screens having a Star WRS applet embedded therein.
FIG. 34 is a sample physical data model of a report template screen control object used by the report requester of the present invention.
FIG. 35 is a sample physical data model of a metatree hierarchical screen control object used by the report requester of the present invention.
FIG. 36 is a diagrammatic illustration of a horizontal scaling paradigm for the Perspective backend server to provide capacity for future growth.
FIG. 37 is a diagrammatic illustration of the high level process flow for the 800 network manager system, as adapted for use in the present invention.
FIG. 38 is a diagrammatic illustration of the high level process flow for the HyperScope viewing and network reporting system, as adapted for use in the present invention.
FIG. 39 is a diagrammatic illustration of the front end of the present invention, illustrating the client system interaction with the call manager data server.
FIG. 40 is a diagrammatic illustration of the software architecture for the call manager system illustrated in FIG. 39.
FIG. 41 is a diagrammatic illustration of the main GUI objects of the client interface code, resident with the client browser.
FIG. 42 is a diagrammatic illustration of the application proxy server of the present invention.
| Number | Date | Country | |
|---|---|---|---|
| 60060655 | Sep 1997 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09160725 | Sep 1998 | US |
| Child | 10835326 | Apr 2004 | US |
