Determining the User Interface | Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit

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.

User Service Layer Considerations

Several factors should be considered when choosing the architecture for the user service layer:

Do any application requirements specify the type of UI?

Do security issues such as firewalls impact communication between user workstations and server-side computers?

Which operating systems must be supported on user workstations?

Which Web browsers must be supported?

Can COM components install and run on user workstations?

Are remote COM components accessible from user workstations?

The answers to these questions will help the development team determine which type of UI architecture is most appropriate for the application.

Application Requirements

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

Security issues in three primary areas must be addressed:

Authentication of users

Control of access to application components and data

Encryption of application information

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:

Reconfigure the firewall Firewalls can be configured to permit Distributed COM (DCOM) traffic and to allow the proxy servers to show user workstation IP addresses. Normally, this is not a practical solution, because proxy servers are not likely to be under the development team's control, and corporate policy may not permit modifications to the firewall.

Implement Internet tunneling DCOM traffic can be sent over encapsulated in Hypertext Transfer Protocol (HTTP), which is sent via TCP/IP. This Internet tunnel of DCOM traffic over TCP/IP typically uses HTTP's port 80. As most firewalls permit HTTP traffic through the firewall, using the TCP/IP protocol helps avoid the firewall issue. However, to penetrate proxy servers, the team must configure the proxy servers to permit tunneling on port 80. Again, this solution might not be practical, because the proxy servers are not likely to be under the development team's control.

NOTE
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.

Use Remote Data Services (RDS) RDS can be used to marshal ActiveX Data Objects (ADO) Recordset objects over DCOM or HTTP. Generally, RDS can marshal calls over HTTP from client-side code to any server-side business object that exposes an IDispatch interface. This option allows the use of the COM programming model, but avoids firewall and proxy server issues. This technique can be used from either native or Web-based applications. (We discuss using RDS to access remote business objects later in this chapter.)

Redesign applications Applications can be structured so that they don't need to make COM calls through a proxy server or firewall. This option normally implies a Web-based application, typically implemented using Active Server Pages (ASP), to allow users to access the applications through a Web browser. ASP pages use server-side scripting to create and use business objects, and subsequently generate Web pages to return via HTTP to users' computers. These pages might contain client-side scripts and components, but they would never reference remote COM objects through a firewall. (We look at how to access business objects from ASP pages later in this chapter.)

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.

Desktop Operating System Constraints

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.

Web Browser Constraints

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.

NOTE
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.

NOTE
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.

Client-Side COM Components

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

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.)

Distributed COM Components

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.)

NOTE
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.

Internet and Intranet Connections

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:

The types of connections implemented by users.

The number of connections implemented.

The variety of connection speeds at which users will access the product.

An array of connection types with differing bandwidth capabilities are available:

Analog modems, up to 53 Kbps download

ISDN modems, up to 112 Kbps download

Cable modems, up to 10 Mbps burst download

DSL modems, up to 6 Mbps download

T1 and similar telecom connections, 1.5 Mbps and up

Satellite dishes, up to 10 Mbps burst download

Corporate networks, typically 10 Mbps or 100 Mbps shared Ethernet download

Selecting a User Service Layer Architecture

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.

Native Application User Service Layer

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:

DirectX multimedia.

Open Database Connectivity (ODBC).

OLE DB for Data Access.

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 User Service Layer

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.

Combination Native and Web-Based User Service Layer

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.