Macromedia has been making an all out push of what they call Rich Internet Applications and have been trying to get developers to make this their new front-end web-based technology standard. What went wrong? What went right? What other options are there? What are the real requirements that we as user experience designers face that all these technologies miss the boat on?
The web browser has changed the very shape of what it means to create applications with centralized or peer-to-peer shared repositories of structured and unstructured data. For most users, the web is a bank, a store, or an information-gathering tool. For others, the web has become their primary means of interacting with cross-enterprise and intra-enterprise applications.
What has made most of this possible is the tremendous re-architecting of server- and mainframe-based systems that are now able to communicate with each other through agreed upon standards (usually called web services), as well as the development of application servers that generate web browser-interpretable pages. Most of the time this is done solely in HTML, and that is the point of this article.
Examples of application servers are BEA WebLogic, IBM WebSphere, Microsoft’s Internet Information Server and the free Apache Tomcat. These are powerful systems because of the amount of logic that can be programmed into them, and because of their connectivity to complex databases. This logic remains resident on the server, and limits the amount of bandwidth required to send information to the end-user’s local machine for processing business logic or doing dynamic interface layouts.
Where is the application?
A thin-client isn’t just an application; it is an application that runs inside another discrete application. The end result is that standards such as a menu bar or tool bar become redundant to the workings of the browser itself. Users get confused about which “File,” “Edit,” or “View” they should use. Users also insist on being able to use a ”Back” button, which can cause page and link management issues, especially if you are trying to use frames to solve other problems.
Accessing the desktop
Technology solutions for weary designers
Now that we understand the problem set a bit, lets talk about what is out there to help a weary and frustrated designer. This list is far from being comprehensive, and a real programmer or system architect would probably evaluate these technologies in a different way. Some of these options run inside the browser while others do not.
Macromedia Flash MX, www.macromedia.com/flash
Probably the 2nd most ubiquitous browser-based technology in the world (behind HTML). Flash, until recently, has been relegated to random acts of usability terror when used as a GUI front end. Most people think of it is an animation and game-making tool, and many “serious” business people think of it is as eye candy that they will only consider for their custom marketing needs. The latest version of Flash is part of an initiative by Macromedia to lead the back and the front end of middle-tier web development. By making Flash more accessible, easier to internationalize, and including widgets and other components, Macromedia hopes to make their product an HTML killer.
What about back-end connections? Can an application server work with Flash? Yes! J2EE, JSP, ASP, and .Net can all work by using the Flash Remote Server to send data to and from Flash-based applications.
While Flash hits the mark on its new front-end capabilities, it doesn’t do it from a developer’s perspective. The overall developer environment is still focused toward animation development. The program uses a score in which you add cast members within a timeline – a method used for traditional animation. But linear timeline-based development just doesn’t make sense in an application environment.
One last positive note for Flash: other companies have begun developing tools for creating Flash player files. Adobe (www.adobe.com) is one and a startup company Lazlo Systems (www.laszlosystems.com) claims to have a tool geared specifically to applications. There is hope that either Macromedia or other third-party companies will come up with a robust developer solution.
Developed by MIT University and now owned by a privately-held corporation, Curl was developed as an alternative to HTML. It requires its own runtime engine in order to interpret proprietary files. If you go to the Curl site there is a great demo which shows an enterprise business application running. It is clear that there are definite widget controls and customization abilities which lend to a desktop application feel, even though much of the logic is on the server.
Curl lacks maturity and support. The demos are interesting but they are just that, demos. Curl also lacks end-user support. In an enterprise environment, you might be able to dictate the use of a plug-in that isn’t widespread, but in a cross-enterprise environment this becomes increasingly difficult. The run-time environment – which they call Surge – is currently only available in Windows, another limiting factor.
Java 2 (with Swing) , java.sun.com
Well, we can always use Java, right? Java is a great cross-platform, cross-browser, just-in-time development language. And in Java 2 and Swing there are even significant APIs available between the applet and the operating system, as well as a very juicy set of controllable and customizable widgets. However, the footprint of most Java applets is pretty large. In addition, Java applets are dependent on raster images in many situations. More importantly than any of this, Java, regardless of its promise, has many kinks that make cross-platform use very hard to manage from a quality assurance standpoint. The other problem with Java 2 is that it’s not a ubiquitous standard; even Flash is more widely used and accessed. The Sun Java Virtual Machine (JVM) is required as a separate install to run Swing-based applets. And to run the Sun JVM, the Microsoft JVM that some other sites and applications may be using must be turned off. This complicates things tremendously, as it forces the user to download Swing code every time the application is used. This tacks a significant footprint onto “easily distributed” applications.
Water is more like an HTML replacement than a true thickening agent for web-based thin-clients. It is also immature with very few developers. It requires Java 2 to be installed.
This solution shows some promise. It is a Java-based interpreter for a new XML language. There is a widget set that you define using its easy to learn XML standard. Because it is XML-based it is very flexible, but it still requires a special download and currently has a very small developer base. One of the things that I really like about it is that it can be initiated from a browser, but runs exclusively in its own OS window.
Norpath Elements, www.norpath.com
Norpath’s Elements product is very similar to Flash except that the primary programming methodology is visually based. It can connect to databases and have logic based on data or behavior. It also uses a timeline development environment like Flash, but this is secondary to its primary interface for adding visual elements and logical elements. There are pre-fabricated widgets, and you can also build your own. Resulting files are XML packaged with images and accompanying text. The problem with Norpath is market saturation – there isn’t any. Otherwise, there is a lot of promise here. I think Macromedia, Adobe, and Microsoft can learn a few things from Norpath, especially from their visual programming model.
General models to consider
What do we really need? Are there examples of distributed thin-client applications out there that have enough client-side functionality? The answer is yes and no. There are simple applications out there in the world, many with very specific purposes. The best example I can think of is Instant Messaging (IM) software. Some IM software runs on Java, so it is portable across platforms. More often though, it is developed specifically to the operating system. While this means that you can’t have a single code base, these applications succeed because they are practically self-updating. From an user perspective, they are easy to maintain.
The most complex thin-client I have seen to date, has to be Groove’s client. Some might even say it isn’t a thin-client at all, but I would define it as such because its components get installed individually. A calendar or a meeting applet are requested and maintained separately. The connectors between the applets are not clear, but overall the experience of using Groove is very good and easily maintained.
The idea of self-updating software is not new. At Documentum, we have internal applications that do this already. An outdated version of our software will lock a system and force an upgrade. Upgrades in the LAN-space are relatively easy. But over a 56k modem, the experience can be painful; even a single megabyte applet is a dread to download. This, however, has not stopped companies like Microsoft, Adobe, Macromedia, AOL, et al, to rely on the concept of self-updating software. Microsoft’s Windows Update is probably the most ambitious, as it updates the operating system in chunks instead of all at once. Apple has followed suit with similar updating functionality.
Taking it to the enterprise
Taking all this to the enterprise requires special design considerations. The biggest is that “out of the box” applications are seldom used. Most applications by PeopleSoft, SAP, Siebel and Documentum, for example, are extremely customized for the individual end user (enterprise). These customizations are time consuming. This also means that having multiple code bases for each platform can be cost- and resource-intensive. Because of this, a single code base is practically a requirement. When a vendor updates its core offering, how are updates achieved? Can they occur without upsetting the previous customizations? This is a big question, as many vendors make revenue on these upgrades, and the customers want these upgrades because they mean bug fixes and added functionality. So when updates are done, they need to be done with a minimal effect on the customizations. Even with current HTML solutions, this is not easy to achieve.
Ultimately, I don’t see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing.
The reality is that we are trying to do too much with a language that was never meant for such heavy-duty applications. We have used incredible ingenuity to make up for the faults of HTML by putting all of the real processing effort on the server side, but the time has come to create a new system that is low bandwidth, utilizes a single code base for all platforms, and is componentized enough to make updating and customizations easy using internet-based distribution. Lastly, we need to develop these applications to run in their own space, without a web browser In the end, this may change the way we think of web browsers. It will also change the way platforms need to be developed, in order to support a wide array of thin-clients that are accessed and addressed directly from the operating system as opposed to from a browser.