Will 2004 Be the Year We Abandon HTML?
What’s Wrong With HTML?
Which UI Design Patterns Need More Than HTML?
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.
How Enterprise Internet Applications Work
Examples of Rich Client Applications in Action
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.
Choosing an Enterprise Client Platform
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.
Key Features to Consider for Enterprise Internet Platforms
- Standards-based (XML, J2EE)
- Server-side database integration
- Extend server objects to the GUI
- Support off-line operations on the client
- Support stateful persistent client sessions
- Support for automatic server push to the client
- Support standard security approaches (data encryption, digital certificates, client sandbox)
- Allows a less complex development model