Rich Internet Applications

The UltraLightClient team is pleased to announce that the a first bunch of community contributions has been ported to the new UltraLightClient ‘08 release.We are planning to port all relevant contributions to UltraLightClient ‘08 during the next few weeks.

Some words on the UltraLightClient community. The community has two intentions: first of all, it is a component repository for our customers, secondly the UltraLightClient team uses it as a playground to explore new concepts related to UltraLightClient.

Let’s look at these two intentions in some more detail:

UltraLightClient community as component repository for customers
Customers can find ready to use components in the UltraLightClient community that implement a wide range of requirements. Usually these component come from real world projects where Canoo engineers were engaged either as consultants or as developers. I recommend you to have a look at the following gems in the UltraLightClient community:

UltraLightClient community as playground to explore new concepts
The standard approach for new concepts is not to directly integrate them in the release but to explore them first in a separate project that is hosted on the community. This gives you a chance to see what the UltraLightClient team is currently working on. Successful concepts will be integrated in future versions of UltraLightClient. For example, the UltraLightClient ‘08 release integrated the following contributions from the UltraLightClient community:

• Forms: inspired by the Form Model and the Validation Components contribution
• Sortable and filterable tables: inspired by the SortedTableModel and FilteredTableModel contributions
• Easy Sevlet deployment: inspired by the Easy Deployment contribution
• Project generator: inspired by the Eclipse IDE Integration contribution

Link summary
ULC Code Community
List of migrated contributions
Canoo UltraLightClient product page

What contributes to the richness of a RIA (Rich Internet Application)?
What contributes to the poorness of a PUWA (Poor Ugly Web Application)?
How does a RIA compare to a PUWA?

In this post, I’ll discuss forms and what they look like in a RIA. Forms are the sort of things that you find a lot in business applications. For example, bank employees use them to manage customer data, to view account transactions, or to calculate mortgage offers. Or what you, as a brave citizen, use to submit your taxes. But forms are not limited to business applications. You can find them in games to set up your player or to configure the game server.

Consider the following screenshot showing a form to calculate a mortgage offer:

What exactly makes the above form a rich form? Can you spot it? Sorry to disappoint you, but it is not possible to see form richness. The only way to decide that a form is rich or not is to feel the form. And of course with a static screenshot it is really not possible to feel the form. Richness comes from interaction design and not from graphical design. This is a common source for misunderstanding. So let’s repeat it: Richness comes from interaction design and not from graphical design. Two topics in interaction design define the richness of a form: input feedback and input support.

Input Feedback
Let’s start with input feedback. The easier the user can connect the feedback to his or her user interaction, the richer the form. Given this fact, a form within a PUWA can never be rich. A PUWA is page-oriented and the user does not get feedback at the time when he or she enters wrong values. Instead he or she gets feedback only when he or she commits the form (see this groundbreaking article that compares PUWAs with Ajax-based web applications). A measurement for the richness of the feedback is the kind of feedback that is available to the user. Basically we distinguish between syntactical and semantic feedback. Syntactical feedback tells the user that field input is not well formed, e.g. error messages such as this is not a number, this is not an email address, this number has to be between 0 and 18. Whereas semantic feedback puts the input in a broader context and checks for business rules, e.g. the total loan amount may not be greater than 80% of the object’s value, or you are not authorized to withdraw more than 2000€ per week. The more semantic feedback the richer the form.

Input Support
The second measurement for the richness of a form is input support. One well known example for input support is suggesting valid field values as the user types. You can check out this feature at Google Suggest. Other forms of input support are the calculation of dependent values (e.g. calculating the city name for a given zip code) or disabling of non-mandatory fields (e.g. fields defining the legal guardian for underage persons). The more input support, the richer the form.

How does UltraLightClient ‘08 fit into this? First, its server-side architecture is a perfect fit for ultra-easy semantic feedback. This is because all of your code runs always on the server-side. There is no need to split code and propagate business logic to the client. Just access the business objects you need, it is that easy! Second, UltraLightClient ‘08 includes an high-level form component out-of-the-box. This makes the implementation of forms both, efficient and ultra-easy. The application that provided the screenshot above is implemented with UltraLightClient ‘08 and contains all forms of input feedback and input support.

Summary
Richness comes from interaction design (feel) and not from graphical design (see). There are two measurements to decide if a form is rich or not:

• Input feedback: the more semantic feedback the richer the form
• Input support: the more support the richer the form

UltraLightClient ‘08 is a perfect fit for both measurements. Its server-side architecture makes it ultra-easy to provide full semantic input feedback and its high-level form component enables full input support out-of-the-box.

In this blog post series, I am revisiting some of the arguments for a Java-based RIA library such as UltraLightClient. Please leave a comment and share your views. Read Part 1 here.

Why ULC? (Part 2)

Within UltraLightClient the programming model and the execution model are server side based. ULC applications are installed and run on the web server. On the client side, a small, browser-like presentation engine, that is generic for all applications, links up with the server to display the corresponding user interface component.

Fair enough. But how will your business web application project benefit?

Consider the following reasons:

1) Faster development - re-use instead of re-invent

UltraLightClient was designed for complex web applications in the business world, such as typical data entry applications with tonnes of data, tables, table trees, tabs, forms, charts. The library offers a full range of user interface components to build better web interfaces for enterprise applications.

From a developer’s angle, UltraLightClient takes care of the client/server environment. It handles distribution between the two very efficiently, and as a developer, you do not need to worry about the client/server split. All the application code, presentation and domain logic are run on the server. Development tasks such as distributing the logic between client and server are not required.

Another huge advantage during development time is that you can preview, test and debug without deploying the application. See Chapter 2 of the ULC Essentials Guide for a detailed description of the ULC DevelopmentRunner.

2) Re-use existing HTML application platform

ULC applications share the entire software platform with HTML applications and are easy to integrate with HTML applications. ULC has a typical web application architecture and can be easily used alongside many excellent tools and libraries (e.g. Spring, Hibernate)

3) Better security

In general, ULC applications are easier to protect against security attacks than AJAX-based applications. Java is less vulnerable than JavaScript. ULC applications are secure from cross site scripting (XSS) attacks.

No application code is shipped to or run on the client. The presentation engine is generic and is less susceptible.

4) Profit from Java EE scalabilty options

Standard Java EE is supported. This means that all the scaling options available for Java EE can be used to deploy ULC applications.

5) Highly responsive applications

From the very start UltraLightClient was designed to develop web applications with a desktop-like user interface. The communication has been highly optimized for the web. This ensures fast responses and ensures an increase in user productivity in comparison to the sluggish performance of AJAX applications. ULC applications easily keep pace with the performance requirements of knowledge workers and supports this user requirement out-of-the-box, i.e. you will not need to spend extra time trying to make your web application more responsive.

Link summary:
Why UltraLightClient? (Part 1)
Top reasons to use ULC
Case Studies

I stumbled across this report discussing Web 2.0 within an enterprise context, which I would like to recommend:

“Web 2.0 Gets Down to Business”.

The report discusses the results of an Information Week survey and presents some interesting charts and numbers, e.g. why companies introduced RIAs , or what type of apps are in the pipeline.

(…) rich apps are the wave of the future as Web users, customers, and employees demand capabilities matching what they’ve experienced on cutting-edge sites. IT must respond, either by effectively outsourcing development or by delivering the goods itself.

(…)

But IT can get a lot of return from a more fluid user experience for employees, too. Many insurance companies create RIAs for their sales agents, using platforms such as Adobe Flex to create forms that make it easier to complete complex insurance applications and pass them in an industry-standard format to underwriting systems. Other companies use RIAs to deliver personalized management dashboards – the No. 1 choice when we asked what apps are in planning or development – as well as workflow and multimedia training tools.

Data visualization is another common RIA use that can transform the productivity and creativity level of managers and knowledge workers. A telecom company might use an RIA to support engineers by providing a visual view of complex network events and possible correlations to problems. Though RIAs generally are overkill for simple Web forms and information displays, they’re particularly well suited to support complex interactions with multiple inputs and pages, large data sets, and the multimedia content seen in geospatial data or complex medical records, for example.

At Canoo, we strongly believe in the benefits of a Java-based approach to build richer business web applications. In various service projects, our customers have greatly benefited from this strategy.

We would like to convince more companies to try out UltraLightClient for their web app projects. Within this context, I would like to start a new UltraLightClient blog post series discussing reasons how the Canoo RIA library will benefit your upcoming web project.

Obviously I will be listing the reasons for UltraLightClient. Please feel free to list your comments. In fact, I would like to encourage you to list your doubts and questions. After all, this is a blog. And between you and me, we are a company that likes a good discussion.

One of the first reasons we like to list is:

UltraLightClient is a “Single Technology” approach to building better interfaces for business web applications.

It is a lean Java library that can be easily integrated into your current web app infrastructure. It relies on the Java platform and delegates functions to Java EE and Java SE wherever possible.

What does this mean for your project?

1. Faster and simpler development, because your development team does not need to switch between various programming languages, development tools, or technology concepts.
2. The only language used to build rich user interfaces is Java. UltraLightClient follows standard Swing concepts and its API.
3. It is easier to find developers with the right skill set. Java is a well-established, proven language and you will be able to hire from a wider pool of developers. By selecting Java, you have access to a vast array of open source and commercial libraries and tools (e.g. excellent IDEs).
4. Debugging, testing and maintenance tasks are easier than within an AJAX-based project. Software defects within a single technology space can be tracked much more easily.
5. ULC’s single technology approach is more than skin-deep. With AJAX you might have a nice high-level JavaScript-only API. But as soon as you try to extend an AJAX library, you are exposed to all the ugly details of DOM, XML, CSS, etc.
6. The single technology approach substantially reduces configuration problems when trying to find the right combination of libraries and tools. In a multi-technology environment this is much more time-consuming.

And at the end of the day, these points will save you “real” time and money and reduce the overall risk that your business web application will fail.

Next post in this series: Server-side Architecture

About Canoo and its RIA Technology

Canoo is a solution provider for Rich Internet Applications (RIA) based in Basel, Switzerland. It offers consulting services and end-to-end development of Enterprise Web applications.

Canoo develops and maintains UltraLightClient, a library to create enterprise-class Rich Internet Applications. UltraLightClient bridges the gap between Java Swing user interface components and a Web architecture, providing a cost-efficient, single technology and mature alternative to AJAX.

See also:
“Top reasons to use ULC”
Stefan Ried’s Forrester Report

Here is a link to an older Computerworld.ch article comparing Google Web Toolkit and Canoo’s Java RIA library, UltraLightClient (in German only).

Google Web Toolkit und Ultra Light Client

Die Anbindung an das Internet und ein Browser gehören heute zur Standardausrüstung eines jeden Arbeitsplatzrechners oder Heim-PCs.

Stefan Thomas

Viele neue Anwendungen werden darum als HTML-basierte Web-Anwendungen implementiert, die leicht verteilt und aktualisiert werden können und von überall, zu jeder Zeit genutzt werden können. Durch den Einsatz von AJAX-Technologien konnte die Benutzerfreundlichkeit der Oberflächen in den letzten Jahren deutlich gesteigert werden, allerdings bei gleichzeitig wachsender Komplexität in der Anwendungsentwicklung. Bibliotheken, Toolkits und Frameworks versprechen hier eine Erleichterung. Beispielsweise durch die Abstraktion der unterschiedlichen JavaScript-Implementierungen der Browser oder durch vorgefertigte, komplexere Bedienelemente wie Menübalken, Tabreiter oder Baumstrukturen.

The article was written by UltraLightClient customer Dr. Stefan Thomas. Dr. Thomas is an independent consultant, that has developed two large corporate web applications with Canoo’s UltraLightClient for a global retailer.

GWT vs. ULC:

Comparing the two is a bit like comparing apples and pears (the article discusses this). On the other hand, the two widget libraries can be used for similar web applications. And both of them address Java developers.

See also the corresponding product websites:
Google Web Toolkit
Canoo UltraLightClient

The August 2008 issue (Volume 31, No. 4) of Informatik Spektrum has published a background article by Hans-Dirk Walter on Rich Internet Applications. The article is in German and can be purchased online at the publisher’s website:

“Rich Internet Applications” – Eine perfekte Kombination benutzerfreundlicher Schnittstellen mit Webtechnologie

Zusammenfassung “Rich Internet Applications” (RIA) sind Webapplikationen, die mit einer wesentlich interaktiveren Benutzerschnittstelle ausgestattet sind, als wir das bisher von den auf HTML basierten “poor ugly web applications” (PUWA) gewohnt waren.