Boxes And Arrows : The Design Behind the Design

HTML's Time is Over. Let's Move On.

by David Heller on 2003/01/26 | [119 Comments]

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?

Background

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.

The problem

Application servers send a combination of HTML, JavaScript, and Cascading Style Sheets (CSS) to the web browser. These combined technologies are called Dynamic HTML (DHTML) and are standardized around a Document Object Model (DOM). While the basic core of these technologies has remained consistent, the interpretation of them has not been standardized across all platforms and web browsers. For example, while Netscape 7 and Internet Explorer 6 both claim they support specific standards, the way they interpret these standards differs dramatically. Then there are issues with backwards compatibility, bandwidth, and other technology limitations. For example, how many people can say, “I’m only going to design my site for Netscape 7.0 and IE 6.0 for Windows (which Windows?), IE 5.5 and Netscape 7.0 for Mac (which Mac?), and Netscape 7.0 for Unix (which variety?).” The truth is that no one with a conscience can be that specific. Netscape 6.2 is still the Netscape standard and, in many ways, is a far cry from Netscape 7.0. Even the Macintosh world is still not clearly aligned around a single browser. Where does this leave us? Most companies developing what are commonly called thin-clients use a “lowest common denominator” level of DHTML that is not able to take advantage of what few advances in DHTML technology there have been. It also leaves us with the issues mentioned above that don’t go away with any version of DHTML, and design issues beyond those, including:

Bandwidth

Bandwidth limits how much data can be downloaded to the client. Visual representations used to be the big problem, limiting graphics and the like, but today these issues are mostly under control due to better education of most web designers. Now, the bulk of the size of a web page in a web application is in the non-display code and in assets such as JavaScript and style information (CSS). In applications with large data sets, the end HTML size becomes so important to the overall performance of the application that reducing attributes in tags is a requirement.

Accessibility

The use of DHTML, or more importantly JavaScript, seriously impedes accessibility. Where it doesn’t impede accessibility, engineers will often need to add to their code logic and variables to handle the differences between browsers and platforms. This increases both coding time and quality assurance resources in order to accommodate accessibility.

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

DHTML requires assisted technologies in order to gain access to the user’s desktop. Any sort of desktop registry information with any substance cannot be accomplished with DHTML. JavaScript doesn’t have access to the local files system or to the primary components of the browser system, such as Open and Save dialogues. For example, anyone who has tried to add an attachment to a web-based email program knows that you have to choose one file at a time, initiate the upload, and then repeat for each new file. Sometimes, being able to transfer data from the local system to the centralized one is of such primary importance that it must not only be done in bulk, but it must be able to be controlled both visually and logically. Another side of this issue is that using standard GUI conventions like Drag and Drop and Clipboard are not available between the desktop and the application in the web browser.

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.

Upgrading to newer versions of Flash has become almost painless. Also, the footprint of the Flash runtime engine is relatively small compared to other similar plug-in player technologies. The footprint of the transferred media is also small due to several factors: all graphics and text are rendered as vector information, which is a lot smaller than traditional raster bitmaps like gif or jpeg; flash applications can be streamed in components as they are needed, or components can be pre-loaded and stored for later use as other components. Flash can also connect to the desktop, and uses a programming language based on ECMScript (the standard for JavaScript).

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.

Curl, www.curl.com

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.

Honorable Mentions

Water, www.waterlang.org

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.

XWT, www.xwt.org

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.

Conclusion

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.