RIAs, Dumb Terminals and Business Applications
There has been a lot of talk recently about Rich Internet Applications (RIAs) and how they are dramatically changing the way we interact with the web. Nearly every day, I discover a cool new RIA that once again raises the bar and reveals yet another way to employ this new technology. I’m always amazed at how innovative people can be when they are given a good set of tools. You can find tons of examples of what I’m talking about at http://flex.org/showcase. These applications are intuitive, attractive and just plain cool.
How can we take this same technology and use it to build better business applications? I’m talking about business applications that are used throughout the day by nose-to-the-grindstone users as part of their job function. I’m convinced that this is a huge opportunity for RIAs but we first have to take a step back and recognize that the rules are completely different. Here are some of the factors that I consider important:
- UI Speed and Efficiency
With consumer-facing applications, the end user usually has no prior application experience so it is imperative that the application be intuitive to a very wide audience of users. Since this type of application is typically sales and marketing oriented, it also needs to be attractive so that the user remembers the experience and comes back again and again. With business applications, however, the priorities are completely different. It’s not about being intuitive and attractive; it’s about being fast and efficient! Here’s an example (which shows my age a bit): In the late 80s and early 90s, I was an application developer in a large call center that used mostly mainframe applications (IMS, VM /CMS, TSO, Nomad2, etc.). These were the ugliest applications you have ever seen and were anything but intuitive. Users interacted with these applications using cryptic commands on dumb 3270 terminals (commonly called “green screens”). Despite the ugliness and complexity, experienced users were able to navigate these systems faster than is possible with most modern-day UIs. I remember watching in amazement as a veteran customer service rep navigated through multiple screens at a blinding pace to reconcile a customer’s account. The transition from one screen to another was accomplished by entering a text command that looked something like “=5.3.4” followed by the F3 key (huh?!). It seemed like some sort of secret code but it was obvious that once the user learned this “code”, he or she could maneuver very quickly.A few years later, I was working as a consultant for a major telecommunications company that was implementing a large Windows-based, client-server application to meet a similar set of requirements. Like most Windows-based applications, the interface was built around traditional controls such as drop-down menus, selection lists, radio buttons, etc. To get from screen A to screen B, the user simply had to click a dropdown menu, expand a menu selection and then choose the desired screen. After careful mouse navigation and three or four clicks, the new screen would appear and the user would go back to analyzing and entering data. It was all very intuitive but it took about four seconds longer to transition from one screen to another than it did with the old-school green screen system.So, is the four second delay worth the benefits of having a more intuitive application? Well, consider for a moment that this particular call center received thousands of calls per day and the average rep would handle around 70 of these calls. Each call typically required five screen transitions so over the course of an average day, a rep would go through 350 total transitions. If you introduce a four second delay for every transition by requiring the user to grab the mouse, navigate menus and select a screen from a menu, you create 23 minutes of wasted time per customer service rep per day! It’s true that the old system required much more training but at 23 minutes a day of productivity; it quickly makes up for it. This is an extreme example and I’m obviously ignoring other benefits but hopefully you see my point – the rules are different when building a business application UI.
- UI Value Density (UVD)
UVD = Relevant Data I See Relevant Data I Need
Every UI has a UVD. If a dialog only contains five useful pieces of data but I need 20 pieces of data to make a business decision, the UVD is 5/20 = 25%. It’s a simple concept but building a UI with a high density in multiple situations is a real challenge. For example, consider a mobile phone business. A dialog containing the customer’s current and past-due balance information has a 100% UVD if I simply need to see the financial status of the account. However, if I’m trying to quickly determine if the customer is a high risk of churning (leaving for a competitor), I might also need other information such as trends in usage, number of times they exceeded their rate plan, number of dropped calls, age of their hardware, number of complaints, etc. The UVD in this case would obviously be very low and would require me to jump to other screens and other systems to get a real “feel” for the customer. Business applications need UIs that present a lot of information quickly, – but there is another factor to consider…
- UI Comprehension Time (UCT)
UCT = How much time it takes for the user to comprehend the data
You could take every piece of information about a customer and present it as raw data on a large dialog and have 100% UI Value Density. This, however, creates a new problem – it takes too long for the user to comprehend and analyze the information. Business application UIs need to present data with the end goal in mind. In the mobile phone business example above, presenting the customer’s balance as a raw number is OK since it’s easy to comprehend. However, usage trend information would be better presented as a graph with problem patterns (such as exceeding their rate plan) visually highlighted. Other visual cues could be added to notify the user of potential problem areas, troublesome trends, etc. Business applications need intelligent UIs that are dynamically constructed based on the need.Summary – give me only what I need in a way that I can quickly consume it and make an informed decision.
Building a better business UI
During the past few years, we’ve seen a lot of new web browser-based business apps. Although there are a lot of obvious benefits to using a standard client, it is quite bizarre that we are back to building applications that use a relatively dumb terminal (a web browser) as the primary user interface! For many years, the web browser was the only widely distributed client runtime. As a result, it quickly became the least common denominator that applications had to use despite the lack of capabilities and inconsistencies between browser brands and versions. For years, most developers reluctantly accepted this and wrote tons of browser-based applications which, if you forget the cosmetic benefits, offered only a bit more functionality than the old dumb 3270 terminals.
Adobe Flash, Flex and AIR
With Flash Player, we now have a feature-rich, high performance, universal client (which by the way, is already installed on literally billions of computers). With Flex and Flex Builder, we now have real development tools and familiar object-oriented methodologies for building sophisticated UIs with advanced navigational controls, high-end data presentation and consistent performance. And with AIR (Adobe Integrated Runtime) we now have a way to bring this technology out of the browser to the desktop where we can implement offline functionality, access locally stored data, integrate with the desktop, etc.
LiveCycle Data Services takes this functionality and data-enables it with a sophisticated messaging infrastructure capable of two-way messaging, client-server synchronization, data push, conflict resolution and much more. The UI and the backend server can now communicate in new ways. For example, the client UI can now send a request to the server and listen for a response independent of the user’s actions. Also, the server can now send data to the client UI as it becomes available without the client having to repeatedly poll. This opens the doors to a whole new type of rich application.
One caution – I’ve already seen eager developers use Flex and AIR to reproduce a bad UI resulting in an even worse UI (as defined by the rules in this article). Giving a new UI cool effects, rounded corners and better colors doesn’t make it a better UI. It’s time to think beyond the capabilities of dumb terminals!
Remember my example above where the customer service rep was transitioning from screen A to screen B? The problem with this system and many other systems is the screens mirror the data model. There was a set of customer screens to maintain the customer master, a set of receivables screens to manage receivables data, and so on. Imagine, instead, a UI that dynamically builds a logical flow of relevant UI elements as they are needed, eliminating the need for traditional screen transitions. For example, if a user is reconciling a customer’s account, the UI could be designed so that the moment key customer information is entered, the server immediately starts to work on gathering the needed data based on the customer’s profile and the context in which the data is being requested. Meanwhile, as the results are pushed back to the UI, it responds by automatically creating any additional UI controls that are appropriate and intelligently notifies the user of any important discoveries in the data. The user would have the precise data needed and have this data presented in a way that can be quickly comprehended.
- The ability to save work-in-progress becomes an easy client-side feature to implement with AIR’s built-in database. This feature can also be used to cache frequently accessed static data, create off-line capabilities and much more – see docs
- AIR’s drag and drop capabilities easily enable the user to attach files to the case, drag attachments to the desktop, etc. – see docs
- Multi-monitor virtual desktops can be fully utilized – I wish more apps could do this! – see docs
- Toast-like notifications can notify the user of important events such as a high-priority customer issue. Unlike web browser alert windows, these notifications do not steal keyboard focus and can be set to automatically expire and close after a few seconds – see docs
- AIR applications can detect if the user becomes idle and handle it accordingly such as automatically saving the work in progress – see docs
- AIR applications are desktop applications so they can be auto-launched at login, run from a desktop icon, etc. – see docs
- AIR includes an HTML engine (Webkit) allowing the application to integrate HTML/JS/CSS seamlessly with Flex and Flash – see docs
Every feature mentioned above is easy to implement and available today with AIR. I’ve only scratched the surface on ways AIR can be utilized.
Sure, it’s possible to build these types of capabilities using other technologies but it quickly becomes challenging and it is almost always impractical. Using the Adobe technologies discussed in this article, it’s now within the reach of most developers.
In future articles, I’ll explore how to build such an application. I’ll also discuss how Adobe LiveCycle ES and ColdFusion can add even more sophistication and value to the final application by extending backend capabilities and simplifying complex server tasks.