Actually, for 95% of the web, HTML works great for delivering content to users. However, when large-scale enterprise transactional applications are being deployed via the Web, HTML often simply does not deliver what users want. We’ve been called in on numerous application efforts where the “old” client/server application was replaced with the new web application only to find frustrated users telling us stories about how a typical transaction takes far too many mouse clicks, requires multiple pages to navigate, and produces mayhem if the Back button is clicked. It appears the “click/refresh” issue of HTML/browsers is not going away anytime soon; yet, the main usability issue associated with transactional enterprise Internet applications is slow response time. Noble attempts at solving these usability and performance issues are often handled by hard-working development teams; but, in the end, what we often see is a huge set of unwieldy JavaScript code, late projects, and frustrated end-users.

A UI design pattern is a technique for describing in detail a proven solution to a known design problem. We classify UI design patterns into high level “domains” as a way of grouping similar operation models, task patterns, and deployment constraints. While the HTML/browser combination has been an excellent fit for the B2C (business to consumer) domain, it quickly breaks down in more complex domains like B2E (business to employee) and B2B (business to business) where usage frequency, complexity, and scale increase significantly. Often these domains contain applications provided by the company to its employees where there is no choice but to use it (CRM, ERP, etc.). As companies look to leverage what they’ve learned on their external facing systems, they will often find that the user types are very different and the deployment constraints, like browser support, are not as broad. Extending browser functionality to meet the needs of these UI pattern domains often requires a new set of technologies, standards for deployment, and usability testing to ensure the new patterns are leveraged for an optimal user experience.

UI Constraints on These Patterns

The high cost of supporting “thick client” solutions followed by many attempts at “zero footprint” thin client solutions has finally led us to the next generation of rich UI clients, shown as “smart” clients in the diagram below. These smart clients can use a web server and server extensions to load as much or as little client code as is necessary to optimize the user experience, while meeting the existing network bandwidth and architecture constraints. Often, there is a small Java applet or proprietary software that manages communication with the server-side extensions to facilitate the “smart client” behavior via XML or Java. Flexibility in the way the client and server communicate is critical as you deploy complex enterprise applications. As we learned during the client/server era, it is critical to separate the presentation, business, and data layers. Rich client solutions that force you to place business logic in the UI layer will be less stable and more difficult to maintain, as we already have seen with the HTML/JavaScript solutions deployed over the last few years. The deployment of smart clients can vary from mobile phones and PDA’s to browser implementations and stand-alone applications. Because of the wide range of users and tasks in today’s large companies, we feel a solid enterprise Internet application platform should fully support the occasionally connected user model, as this UI pattern domain is quickly becoming commonplace.

The next generation of Internet applications will be capable of much more than simply rendering pages. They will be able to perform complex calculations, handle data manipulation, send and receive data asynchronously, and allow occasionally connected users to perform tasks in a mobile environment. Presentation issues like redrawing sections of a screen or displaying multiple views simultaneously will be commonplace, and all of this will be available independent of the backend architecture it is connected to.

   Good Example (SAP) – Tabs and Data Manipulation

This example illustrates the use of a basic summary/detail form. Yes, this can be done with HTML; however, the page refresh delays associated with each click of a tab in high-volume transactional systems will create excessive network traffic and slow the response time of the system. Users accustomed to sub-second response times of traditional client/server and mainframe applications will often forget data as they move tab to tab or simply avoid navigating to other tabs to avoid the frustrating delays. When implemented as an enterprise Internet application, this type of visual design pattern should enable the development team to tune the application to quickly load the first tab being displayed and asynchronously load secondary tabs as a background task if necessary. In essence, a robust enterprise Internet application should allow you to tune the client deployment load based on the various constraints of the platform, usage models, and network bandwidth.

   Good Example (Flash) Visual Floor Selector

This example illustrates a good use of Flash to provide a rich, interactive method to quickly select and display the visual rendering of the selection without making round trips to the server. We feel visual configuration scenarios are one of the best uses of Flash-rich client interfaces.

We believe choosing a rich client platform will be a strategic decision similar to J2EE vs. .Net on the server. At first glance, some teams may feel they are simply purchasing widget libraries; however, for enterprise applications, a solid infrastructure and framework that easily integrates with your middleware platforms will be critical for long term success. Also, if you are deploying high-volume transactional systems, you will need to fully understand how your rich client solution can be tuned to allow either more or less code to run on the client or server.

Right now, the playing field for enterprise Internet applications seems to be falling into a few distinct camps. The following table is a summary of the key things to consider for high-volume transactional Internet applications.