• Home
  • Events
  • About
  • Community Contributions for UltraLightClient ’08

    August 27th, 2008

    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.

    UltraLightClient Code Community

    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:

    Description Sample Link Community Link
    A native browser component that fully supports HTML and browser plugins (e.g. is able to play YouTube videos) start open
    An interactive charts component that can display all kinds of business charts start open
    A small process framework that helps you to manage and visualize background processes start open
    Input support for text fields à la Google Suggest start open
    An interactive map component that offers the functionality of Google Maps start open

    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:

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

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    RIA forms

    August 25th, 2008

    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:

    Rich Mortgage Calculator

    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.

    UltraLightClient '08

    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.

    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.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Server-side Architecture (Part 2)

    August 20th, 2008

    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

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Not deploying RIAs is “not an option.”

    August 8th, 2008

    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.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Why UltraLightClient? (Part 1)

    August 5th, 2008

    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

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks