By now many of the advantages of XUI should be apparent, however there is rarely anything like a free lunch and most of the advantages of XUI come at a price. This price is generally related to the total cost of ownership in that even though XUI may make it easy to use a particular feature it may not be appropriate for your application or the target devices. Therefore it is often necessaary to choose features to meet actual needs rather than trying to employ all available options.
Java all the way
Using Java on both the client and the server side is of great benefit for developers as it makes development, debugging and testing much easier than an equivalent mix of say Java, HTML and Javascript. Java also has a superb range of libraries and great tools.
Java's great nemesis on the client side is the requirement to have a JVM installed and the startup time of this JVM. However this may be more of an annecdotal problem than a real problem as Java has very high penetration on the client side. If Java is not present the installation is not that complicated and XUI can even be delivered via CD. Sun's forthcoming consumer JRE (due Q2 2008) is also set to resolve the start up speed issue and drastically improve the installation experience.
Despite the pitfalls of Java installation this is rarely an issue with typical XUI applications as almost all corporate PCs will have Java installed.
Separation of concerns
Earlier we mentioned how the separation of concerns at the heart of XUI greatly simplifies development and maintenance and this is almost all a good thing. However, for many frameworks like XUI that use this pattern and use XML for loose coupling of the components the price is that there are more pieces to manage and more pieces to mess up. Some XML driven frameworks are a nightmare to debug if some configuration error occurs. Therefore, from the start XUI provided a debug mode to log all such errors and make it simpler to catch such issues early on. XUI also provides IDE plugins that take care of the configuration and it is not necessary to work with the configuration files directly
Ease of Maintenance
XUI is now a stable environment, and the framework separates concerns making maintenance easy, so what's the downside? With a platform and application that can be modified, enhanced and adapted easily it may be tempting for some to start adding new functionality without fully assessing the long term cost. Of course this is not a new problem or even a XUI specific problem but the change to relative costs of development may make for differences in how projects are managed. We recommend that you stick to what adds value rather than adding features that sound nice, learn to walk before you try running!
Footprint/Deployment
XUI has a small footprint (there is even a MIDP version in the works), it runs over Java Web Start, as an Applet or embedded, so it is quick and easy to deploy. To some though it may seem that this is more complex than html and it some superficial respects this may be so yet in terms of management and delivery XUI applications share many of the same characteristics as html. Pages can be deployed and managed centrally and pages can be generated on the fly and delivered one by one, all much like html.
XUI has many advantages beyond this including the strong security of the Java sandbox and the ability to manage state on the client. The client can therefore hold on to data rather than repeatedly requesting the same data from the server over and again. Translating this into server activity means that a XUI application send less traffic to the server, uses less bandwidth and therefore the application can scale better.
Of course Java is not the browser and this has some downsides. The installation issue mentioned above is something of an annoyance but one of the most often cited issues for RIA technologes is the inability of web robots to index RIA content. In most cases however this is not appropriate and it is not something that you would want for most applications. There are however mechanism of providing the likes of Google with an index - such an index might then use a REST like interface to locate the appropriate RIA content on demand.
Cross platform support
XUI can be deployed to many platforms and many devices, often without any code changes.
Simply put though, supporting more devices means more testing. Virtualization can help simplify the management of a multiplatform system but there are software difference even down to the VM level that need to be considered. For a user interface there can even be differences in the use interface gestures and input mechanisms, so it may not be possible to abstract away all the platform differences.
Despite the inevitable differences the business logic and data handling on most platforms will be sufficiently common that the changes needed for cross platform support in a XUI application can be isolated or implemented in a platform specific plugin.
Rich User Interface
The full power of Java, Swing, Animation, Java2D and Java 3D is available to XUI. Multimedia content can even be added making it possible to build really beautiful and highly visual applications. For the novice it may be tempting to employ some of these features but they some should be used with caution. Content such as video is bandwidth intensive and sometimes visually intrusive (thing of all those flickering adds in websites). Rich content often comes with custom navigation and this can be intimidating for some users, particularly those used to the confines of the web browser.
For RIA that are used intensively there is a fine balance to be struck between richness, usability and performance. What might make an application visually attractive at first might become an irritant in every day use and therefore including the ability to turn features and effects on or off might be worth considering when designing an RIA. Equally, features that are useful for the novice or for helping a new user to navigate or 'learn' an application might slow the power user and again several modes of operation might be advisable.
In this regard XUI also helps as the XUI is separated from the data handling and business logic so it is relatively easy to craft multiple UIs for an application. It is often said that user perception of performance and responsiveness is very difference from the clinical computer science interpretation of performance. Users like to feel in control and if perfomance and capability is added in one area it can shift expectations, perhaps making something that performed acceptably seem sluggish or broken. So while you may not be able to make the application perform instantaneously in all areas it is possible to present a smooth and consistent application that will give the user the impression that the application is working well. Regardless of how easy it is to implement such functionality there is a cost involved and therefore some study of user behavior and expectation could be worthwhile.
On-line/Off-line usage
Like many of the features and benefits mentioned above XUI can make it possible to run an application on-line or off-line in a standalone mode. In some cases this switching of modes can be transparent to the user with the XUI framework taking advantage of whatever communications channels are available (XUI can use parallel/redundant channels). Mostly applications contain read-only data or data that is infrequesntly updated, so it can be relatively easy to make an application work off-line.
Where there are potential conflicts the situation is slightly more complex. Many of today's web frameworks are addressing such issues and XUI can tap into the services provided by backend or web tier components. RIA sessions tend to be longer lived than the browser session and therefore there is potential for greater divergance and greater conflicts in the data. Again consider the cost of this feature, XUI can do off-line usage much easier than browser or web toolkits, but it's not without cost. If you have other requirements such as office or desktop integration then XUI will be an excellent choice.
There are no comments on this page. [Add comment]