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.

There were several attempts to add more sophistication to the browser using technology such as Java applets and early versions of Flash, but most browser-based business applications were based on simple HTML forms and traditional request/response communications. Recently, new techniques such as Ajax have started to move things forward again. Ajax is amazing, in my opinion, because it takes existing technologies and does something surprisingly cool with it. Was this the result of frustrated geniuses? Using JavaScript, XHTML, CSS and some asynchronous server communications, developers can now create web UIs that exchange data with the server in small units rather than using the old-school page-level request/response model. This allows applications to be more interactive and feel more “attached” to the backend server. Although this is a huge step forward, and a great solution for many applications, it still has some constraints grounded in the browser’s limitations, in particular, the communication limitations of HTTP. In my opinion, Ajax falls short when it comes to building high-end business application UIs.

Adobe Flash, Flex and AIR

OK, we’ve come to the inevitable subject of Adobe Flash Player, 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.

AIR removes the confines of the web browser and enables some interesting new possibilities for our app (note: the doc links below are specific to AIR apps written in Flex – you’ll find the similar features for AIR apps written in HTML/Javascript and Flash) :

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

~ by Greg on January 31, 2008.

3 Responses to “RIAs, Dumb Terminals and Business Applications”

  1. Some excellent points Greg! Having worked with you in the past and in fact at that same call center you mention (i.e. not close to being as old though 😉 I definitely understand the different types of constraints and requirements that we have within the enterprise where speed and efficiency are high priority concerns. I believe this is the first article I have read thus far that that directly hits on this topic of the enterprise perspective in a Web2.0/RIA world. Hopefully you will have many more to follow 😉 The other big thing that comes to mind for me that is different for the enterprise is security. In many industries the possibility of data getting into the wrong hands is a huge concern and in that respect PDF, with its abilities around encryption, signatures, and rights management is huge enabler for companies both internally and when reaching out to their customers, partners, and other constituents. I expect we will see an increase in the trend around the usage of PDF and similar technologies as enterprises become Web2.0 enabled and begin reaching futher out of their corporate boundaries.

    Anyway, a good read! Thanks!

  2. A great article Greg! I think you raise some excellent points to how new technology applies to business applications and how effective it can be…if done right or ineffective if done wrong! I think the term “Putting Lipstick on a Pig” comes to mind .

    I think your concept of UVD and UCT are sound theories. The formula’s may not be a science by any stretch but having worked in this business for some time now I am ashamed to say how many times I have witnessed and been forced to participate in the process of applying “Lipstick”. As a matter of fact one of the business applications that I work with as a part of my job has just been recently “upgraded” to be a RIA. The result is an application that is LESS functional than the HTML version based one. (Although now I have fancy screen transitions as I mercifully click around the application to try and solve my needs.)

    I think one of the profound statements you make is “..first we have to take a step back to recognize the rules are completely different”. Any development effort to build a RIA should…no must take this step to be successful. If you think about how many of the first green screen applications were primarily developed to mimic the paper process and get the data into a database. From there developers mimicked those applications into web applications applying the limitations of the first process plus those of the browser etc…and now many are at it again with RIA. While technologies like Flex and AIR remove many of the technology limitations and open so many other opportunities, many companies are not taking the opportunity to remove the limitations imposed in prior designs but instead focus their immediate concern is “How much is it going to cost me to convert my HTML application to a Flex application and how fast can we have it done! So in essence how much will it cost me to build a new application that could impose limitations to my users because of previously used technology that no longer applies! It doesn’t make sense. (oh and btw make it snappy.)

    That is where I think your concept of UVD and UCT come into play. But just as important as data being available to users I think it is paramount to step back and re-think how the users interact with an application as part of their jobs. This is how we make better business applications! Just investing in a RIA for your business application does not make it better. Companies need to invest in rethinking their applications and using these new technologies that have broken down the barriers imposed by dumb terminals, browsers and low bandwidth and create a new breed of business applications that will truly allow them to create “Killer Business Applications”!

    Good Job…Look forward to more!

  3. […] the application I describe in RIAs, Dumb Terminals and Business Applications, the offline capability is an important aspect of the enterprise application, even for connected […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: