The user interface (UI) is the portion of an application that displays and receives information from the application's users. Typically, the application users are people that perform particular activities to accomplish their intended work. Although another application could be considered a user of the new application, we primarily refer to user interface as the interaction point for humans not other applications.
Many times project teams have said "Why bother with designing and creating a user interface—doesn't everyone know how to use computer? This is simple, and if someone can't figure it out, they shouldn't be using the program anyway!" Although these statements can be argued forever without convincing some team members, a good user interface design and implementation will significantly improve the efficiency and productivity of the application's users.
Before setting out to determine the look and feel for the application, which is primarily called the UI, it is important to determine how the UI will be presented. This manipulation to provide information to the users is provided by the user service layer. Although the user service layer does not contain the actual UI, for simplicity we will refer to the user service layer as also including the UI.
The user service layer displays data from business objects, displays data objects to users, and retrieves data from these users. The Microsoft Windows Distributed interNet Applications (DNA) Architecture supports a wide range of user service layer architectures, from native Win32 applications to pure HTML Web-based applications. In all cases, the user service layer uses COM to access services from business layer components.
An application's business logic is encapsulated in its business service layer (middle-tier) components, rather than in the user service layer. This arrangement makes the business logic easier to reuse if the user service layer needs to be changed. The user service layer communicates with the business logic using COM method calls. The user layer might also use COM-based ActiveX controls to display the actual UI. The same ActiveX controls can be used in native and Web-based applications running on Microsoft Windows, so it is possible to reuse user service layer code among applications with different types of UIs.
Several factors should be considered when choosing the architecture for the user service layer:
The answers to these questions will help the development team determine which type of UI architecture is most appropriate for the application.
Whether the application will use a native or a Web-based UI might be dictated by business or use requirements for the application, relieving the team of responsibility for making this decision. Often, diverse user needs determine the presentation platform that must be implemented. For example, if users must be able to access the application over the Internet, a Web-based architecture is almost always the logical choice. Developers can write native applications that communicate with server-side code over the Internet; however, users must logically be able to access a particular application through a Web browser to use it over the Internet.
In enterprise applications, application UIs often have some common characteristics. A corporate policy may even dictate the type of interface the application must use. For example, to reduce costs, some organizations have standard UI styles for all their in-house applications.
Many organizations are standardizing on Web-based applications because employees can access Web pages more easily than they can run multiple native applications with which they may not be familiar. Additionally, the cost of maintaining Web-based applications will likely be lower than that of maintaining native applications.
Security issues in three primary areas must be addressed:
Chapter 11 is devoted to the issues surrounding application security, but we'll discuss them briefly here because firewalls and security policies that have an impact on communications between user workstations and server-side computers also have an impact on the architecture choices available to the development team. Firewall and security issues primarily affect Web-based applications, in which users access applications over the Internet. However, similar issues can also apply to applications running on a wide-area network (WAN).
We suggest the following four options for resolving problems caused by firewalls and proxy servers:
Internet Tunneling via TCP/IP is included with Microsoft Windows NT 4.0 Service Pack 4 and Microsoft Windows 2000. Client-side support is also available for Microsoft Windows 95 and Microsoft Windows 98.
Network traffic from server computers may pass through firewalls that permit only certain communication protocols to access the server. User workstations may need to use proxy servers to access remote computers. In such situations, it may be difficult to use DCOM components to communicate between the user and business layers. Although DCOM can work through a firewall, this normally involves modifying the firewall to permit DCOM traffic to pass through. Access through proxy servers presents an additional challenge, because most proxy servers hide user workstation IP addresses. Normally, DCOM network protocols need workstation IP addresses to establish proper communication between workstation and server computers.
It's important to determine in the early phases of a project which operating systems must be supported by client-side code. If the user layer needs to run only on Win32 operating systems, all of the technologies discussed in this chapter are available.
One constraint involves COM's possible unavailability on certain target platforms. If COM is not available, the application cannot use client-side COM objects, nor can it communicate with remote COM objects. Even if the development team can access COM, DCOM may not be available with such operating systems as Microsoft Windows 3.1 or Macintosh. With Windows 95, DCOM95 must be installed on client computers to use DCOM. If DCOM is unavailable, the application cannot communicate with remote COM objects. In this case, a distributed user layer that uses a server-based ASP page to generate Web pages for a client is probably most suitable.
Another constraint is that COM components are normally distributed as platform-specific binary executables. To use client-side COM objects, components must be available for each target platform. Otherwise, special versions of the user layer must be created that don't use such components.
Finally, UI or Web browsing services supported on each platform can vary. To work around platform differences for native applications, a platform-neutral UI framework can be used. To work around platform differences for Web-based applications, it may be necessary to use a restricted subset of HTML and scripting languages. Otherwise, platform-specific user layer applications must be written.
It may be necessary to support multiple Web browsers even when supporting only a single operating system. When writing a Web-based application, it's important to determine early in the development process which HTML tags, scripting languages, object models, components, and so on are supported by the targeted browsers. Application developers must either find a common feature subset supported by all browsers, or write browser-specific presentation layer applications.
The browser detection capabilities provided with Microsoft Internet Information Server's (IIS) ASP lets developers dynamically generate Web s that use the highest possible level of browser functionality. Developers can find out which browsers request ASP pages, and what feature set is supported by those browsers. Because the Browser Capabilities component determines supported features using an .ini file indexed by the browser's HTTP user agent string, developers can easily customize the .ini file to provide information about any desired browser features.
Because browsers have different capabilities, deciding which browser(s) to support helps determine how the team will implement certain Web features. Different browsers implement slightly different object models, so the team will need to watch for incompatibilities among these models that may break the script code. In general, if client-side scripting is being used, European Computer Manufacturers Association (ECMA) script (Microsoft JScript) should be used for browser-neutral applications.
Server-side scripts can be written in any scripting language supported by the Web server, because those scripts are never sent to the browser.
It is important to know which browsers are available to the application's primary users. If the application is to be distributed over a corporate intranet and the organization has implemented a single browser standard, such as Microsoft Internet Explorer 5.0, the development team can confidently utilize the innate capabilities of the browser. Otherwise, the team may have to design for a much broader range of browser capabilities. For example, an organization that utilizes electronic commerce cannot afford to turn away customers just because they don't have the latest browser. In such cases, developers must plan their designs to accommodate older browsers and HTML versions to capture the largest possible user audience. (This is referred to as degrading gracefully.) Users with older browsers should be able to view a text-only version of the site, or at least see a notification that they need to upgrade their browser, along with a link to the appropriate download site.
In the United States, Canada, the European Union, and Japan, users generally have a robust browser—typically a minimum of Internet Explorer 4.x or Netscape Navigator 4.x.
If developers code to the HTML 3.2 standards, they may not have all the layout or data manipulation tools they need, but their Web pages will work across virtually all platforms, even on mobile operating systems such as Microsoft Windows CE. However, coding with HTML 3.2 does not ensure consistent visual display across platforms or browsers, at least not with pinpoint accuracy. User display sizes can vary from 640 x 480 pixels to 1600 x 1200 pixels, drastically affecting browser window size and thereby affecting on-screen page rendering. Visual display can also be affected by color depths, which range from 16 colors to millions of colors. The rendering engines themselves visually build pages that can vary by several pixels from browser to browser, with some older browsers not properly rendering certain features at all. Developers should test on every screen size, platform, and browser version possible to work around hurdles posed by HTML 3.2. Once this version of HTML renders appropriately on all target systems, developed applications will usually operate smoothly. The truth is, if developers don't know or can't control the variety of platforms and browser versions on which users will run the application, they can't be completely sure how the application's pages will display.
If the UI is a native application, installing and running COM components on user workstations probably isn't an issue. A Win32 application needs to be installed, but the COM components are simply treated as part of the application's installation routine. Things are somewhat more complicated for Web-based applications. Providing that a particular browser supports client-side COM components, the components usually download and automatically install on users' computers the first time the component is accessed.
ActiveX controls are COM objects that are sent from a Web server to execute on users' desktop with their browser. Some users, or the organizations for which they work, might worry about the security of automatically downloading and installing executable code on client computers. Some users might not allow any components to be downloaded to their computers. If Web-based applications must support such users or organizations, it is best not to use any client-side COM components (including ActiveX controls) unless the components already exist on the users' computers. Some users want to decide on a case-by-case basis whether to download and install particular components on their computers. In this case, developers might choose to use client-side COM components. (Later in this chapter, we examine ways to make client-side COM components available to user computers.)
To be able to access remote components, the users' computers must be able to make remote COM calls, using either DCOM or RDS. Client-side browsers must also support the creation and scripting of COM objects. In addition, accessing remote components usually requires the installation of some code or registry entries on the users' computers. If an application uses vtable-binding or early-binding to access COM components, proxy/stub DLLs or type libraries must be installed on the users' computers. (We explore binding methods and COM in greater detail in Chapter 8.)
Most applications rely on registry information to locate remote server computer names, and remote components might also present a perceived security issue to users. (Later in this chapter, we examine methods of making remote components available to user computers.)
When producing a Web-based application, it is important to verify that needed functionality is exposed via the IDispatch interface. Most scripting languages supported by Web browsers support late-binding only through IDispatch. If the required functionality is only exposed on another interface, the components will probably need to be modified.
If HTML is used for business reasons, the user layer might need to be coded for a variety of browsers. A user layer based on HTML must be served to users through a TCP/IP network connection, so development decisions will also be affected by:
An array of connection types with differing bandwidth capabilities are available:
Choosing the appropriate UI within the user service layer can be a difficult task. Looking at these considerations can help lead the team toward creating a native application or Web-based application UI. Often, the team will choose to implement both types of interfaces for the application.
Applications that require operating system client support are generally classified as native applications. On today's Windows platforms, native applications use operating system APIs to provide programmatic functionality. The Win32 API is typically used for 32-bit applications on Windows systems such as Windows 95, Windows 98, Windows NT, and Windows 2000. Thus, if the team has a well-defined target desktop, native applications can be created.
Because it encompasses a complete operating system, the Win32 environment allows developers a huge range of local computer control and precise UI capabilities. Developers can create specialized Win32-based applications available to a large audience. Additional technologies can be incorporated into operating systems and utilized by application components. Examples of such technologies are:
Several languages, such as Microsoft Visual C++, Microsoft Visual Basic, and Microsoft Visual J++, can create native applications. In turn, these applications can be compiled and distributed to any number of systems. These languages create truly compiled applications, so if the UI requires a lot of intricate control or has a strong use of graphics, a native application will be the best choice.
Because application UIs require the use of specific functions from a given operating system, they are generally installed locally. This installation process allows for local high-bandwidth content and remote low-bandwidth content to be mixed during the application's use. For example, Microsoft Office applications can contain 120 megabytes of executable files and DLLs. However, data files and server applications can transfer much smaller pieces of information, thus saving significant network bandwidth. As most of the native applications that are created today require installation and configuration on the desktop systems, if the team will be continually changing the application, or the application executables are very large, a native application may not be the best choice.
The use of native applications also enables the easy incorporation of significant new technology. For example, Office 2000's new XML parsing capabilities can quickly be added to applications without having to create XML function libraries for each application. Thus to take full advantage of other native applications that can exist on the desktop, the team's application should also be a native application to provide the strongest interaction capabilities with other desktop applications.
Web-based UIs offer compelling user layer features with nearly universal distribution methods and ready-made rendering engines. Freely distributed Web browsers provide easily accessible application interfaces. These interfaces also help make application deployment more efficient. Initial deployment and subsequent upgrading is one of the hardest parts of producing an application. Using Web-based interfaces significantly reduces deployment and application maintenance time because the application doesn't have to be manually distributed to every individual user. Therefore, Web-based applications should be created when distribution, deployment, and continual application maintenance are significant issues for the team.
It is important to remember that Web-based interfaces are primarily designed as a method of displaying information on a screen. In the last couple years, the advent of scripting languages has introduced extensive programmatic and algorithmic capabilities to Web-based interfaces. Web-based navigation can be accomplished by "hotspots," or links can be included on each page to access and execute additional pages. These links can trigger the execution of code within the page or in a referenced file, as is often the case with new dynamic HTML (DHTML) Web-based interfaces. The control available to Web-based applications has significantly improved with the addition of client-side scripting and DHTML. If a lot of screen manipulation or calculations are required, Web-based interfaces are not the best solution.
Most of today's intranet systems are advanced enough to allow development using HTML 4.0, DHTML, and cascading style sheets. The target coding level will have been identified during the Envisioning Phase. All aspects of the application will have been tested in a variety of browsers using proof-of-concept systems created during the Planning Phase. Throughout the Planning and Development phases, developers should consider the range of connection types and determine how graphics, applets, components, and page loading speeds will affect development performance expectations.
The team should not consider the decision to create a native or Web-based UI as a mutually exclusive choice. As noted with the sample RMS application, applications can have both native and Web-based UIs. Each interface may be similar, or one can provide only specialized functions. Remember, even choosing two UIs means significant portions of the user services can be shared and reused by both interfaces. This is one of the benefits to creating a user service layer to provide the interaction between the UI and business objects.