The Relationship between Websydian and Java

Introduction

One of the first questions Advantage Plex users tend to ask when they first hear about Websydian concerns its relationship with Java.  "Does Websydian use Java?", and "Why would I want to use Websydian when I can use Advantage Plex's Java Client Generator?" are two of the most commonly asked questions. And they are very good questions indeed. This document attempts to provide some perspective on both the questions and their answers.

Using Websydian

With Websydian you build what we call Web Applications, i.e. applications whose interface is a Web Browser and which use HTML documents as the basic way of interfacing with the application's users.  You can add a Web-based user interface to basically any application you can build with Advantage Plex.

Using the Java Client Generator for Advantage Plex

Java is one of the most intensely hyped information technologies ever, if not the most hyped.

Its promise: Higher productivity in application development; compile once, run anywhere applications; operating system insulation; and much, much more. All this is wonderful, of course, if realized (much of the promise of Java is still just that - a promise).  With the Java generators, Advantage Plex users will be able to take advantage of all that without doing much more than regenerating and recompiling their application (we don't know yet exactly what will be required, as the Java Client Generator for Advantage Plex is not available when this is being written [Q2, 1998]).

What we do know, however, is that the promise of the Java Client Generator for Advantage Plex is to reproduce the application clients using Java technology that we currently produce using Windows technology.  What you get, in other words, with the Java Client Generator, is essentially the same as what you get currently, only using a different underlying technology. 

The point here is not that this is not valuable or important - it certainly is, very much so.

What is the point, however, is that the intended use of the Java generated application clients is the same as with Windows GUI clients: The same assumptions have been made, the same requirements have to be met, and the same advantages and disadvantages apply.

Basically, what you do when you build user interfaces using today's GUI technology (whether it be Windows, Macintosh, X Motif, or something else) is to devise an interface designed specifically for the application in question.  The advantages of this approach are considerable, the most important being that the interface is optimized to work with that particular application - you can design the interface to get the best productivity possible for the users of the application.

The price the users pay for this productivity is variation, i.e. different applications have different interfaces. You have to get acquainted with an application's user interface before you can be effective in using it. In many settings this is a perfectly reasonable price to pay, because the "return on investment" for learning to use the interface is higher productivity later on. 

In some settings, however, this model of investing to learn a user interface and then reaping the benefits later does not work very well - namely in the cases where the required investment is greater than its potential return!  This situation tend to occur when users do not use an application very often, or perhaps only once.

Using Web Browsers as Generic User Interfaces

In this situation the only solution to returning to a reasonable proposition for the application's users is to reduce the investment required to use the application effectively. 

The Web Browser is such an investment reducing solution, because it can serve as a generic user interface to essentially any kind of application.  For users it is worthwhile to invest in learning how to use a Web Browser because they can use it to take advantage of all kinds of applications and information resources.  The investment is "amortized" across lots of applications and over a considerable time span.

Clearly, Web Applications are still very different.  However, the differences between them are embedded into Web Documents (as opposed to engrained in the GUI interface itself) into which explanations can be embedded, potentially telling the users what is required of them at every point.

Java Clients and Web Clients: Perfect Complements

The ability of Java clients to work seamlessly across the Internet makes it relevant to compare them to Web Browser-based clients.  However, from a user interface perspective they are really just "regular" GUI-based clients with a particularly clever technology operating underneath to make them platform independent, etc.  For the purpose of the following discussion we'll talk about GUI-based clients in general.

Basically, (traditional) GUI-based clients and Web Browser-based clients are appropriate under different circumstances. 

GUI-based clients are more appropriate when the users' investment in learning how to operate the user interface has a good chance of yielding a reasonable return, basically that he or she is going to use it extensively.  This is the case in most corporate settings, which - of course - is why GUI-based clients are standard fare in business-critical systems everywhere.

Web-based clients are more appropriate when the intended users are unlikely to use the application very much, or very often.  Under those circumstances, the chances of obtaining a reasonable return on learning a new, application-specific GUI-based interface are not very good, and so it makes sense not to require that investment of the users.  By using the Web Browser and Web Documents as the user interface, the investment of the users can be considerable reduced, and so the chances of the application being accepted by its potential users are improved considerably.  This situation occurs in many Internet and Extranet settings, where the users use the application very irregularly, or perhaps only once or twice during its production life.

In some situations, an application may require both kinds of user interfaces, as is the case when organizations decide to allow their partners, customers, or suppliers to access part of their business-critical application.  In that case, the external users are best served by a Web-based user interface, whereas the internal users continue to be better served by the "regular" GUI-based interface.

In summary: Application-specific, GUI-based clients and generic, Web Browser-based clients complement each other very well.  Which one is better in any given situation, depends on the balance between the user interface investment required by the users, and the potential return on that investment.