I attended today’s Orbit-iEX talk on Rich Internet Application strategies and frameworks by Sibylle Peter and Dieter Holz of Canoo and Markus Pfeisinger of Crealogix.

Here is a summary of the talk in my own words.

Disclaimer: if I get anything completely wrong, please feel free to leave a comment or add your own thoughts.

The first part of the talk presented some issues you should consider if you are moving into RIA development.

Many developers that first start out in RIA development have lots of experience building HTML applications. They are in the phase where they have recognized the need for RIA. They have selected an RIA technology (e.g. based on AJAX, Flash or Java). They have started implementing first projects.

The talk identified 5 frequently-encountered misunderstandings regarding RIA development within this first phase.

Similar to the Phelps tractor (a steering mechanism that was useful for horse-drawn carriages, was not as useful for motorized cars), there is more to RIA than just exchanging the technology.
For example in HTML applications, check boxes are frequently used to select more than one entry. This works well for HTML apps, but in RIAs these check boxes are no longer required because multiple table entries can be selected directly.

RIA technology offers more user interface components. Developers need not rely on typical HTML conventions to build their applications.

Similarly, paging in HTML apps is useful because it offers a way to manipulate long data tables.
But in RIA, paging is no longer required. Here Sibylle compared the Zimbra web email client with Canoo’s sample app ULCMail. Zimbra is available as an HTML client and as a richer “advanced” version offering some AJAX features. But both versions offer the same user interface, even though the advanced version feels more desktop-like. Using paging for a richer interface like this can be even confusing.

Another misunderstanding is that RIAs need to be self-explanatory. Sibylle showed this interesting graph:

which positions applications from simple look-up HTML apps via typical RIAs and productivity tools to games based on the frequency of interactivity and GUI richness.

With RIA you can get a lot closer to productivity tools.

A typical target group that requires productivity tools are office or knowledge workers. Typically this group uses an application for long periods of time per day and is thus motivated to spend more time learning how to use it.

Applications need to be fast, interactive, smart, offer a good interaction design. And they need to be robust and stable since they are used daily. I.e. efficiency is important, more important than ease-of-use.

Misunderstanding number 3: many developers believe RIA frameworks can be built without much prior experience in the new technology.

For example, HTML apps have a sequential page flow. A request is sent to the server and
every request has a separate page view. Typically a view does not need be observable and does not need to be monitored.

RIA does not have a sequential page flow. Views need to be monitored.

RIA frameworks need to sync various different views for the same data, allow modifications to a selected item, etc.

Misunderstanding number 4: RIAs can be “generated” from service definitions. In HTML apps there is a “one to one” relationship between views and service calls. In RIA this is a “one to many” relationship and interaction design becomes important.

And finally the last misconception developers have regarding RIA development is that presentation logic is the same business logic. In general, HTML apps tend to have less presentation logic.
For RIA, the views are more complicated and you need to separate between presentation logic and business logic. RIA requires a presentation model to watch and monitor the views.

For example, if you enable a button after a form has been edited, this will need to be monitored in some way.

The talk offered an overview of the effects that RIA development will have on your software architecture:

RIA is event driven. A presentation model is used to administer the presentation logic.

RIA requires a different kind of service:

• fine granular requests to service layer
• service design independent of view design

Application components are reused in a different way (reuse of the actual code instead of by URL).
And the presentation logic and business logic will differ.

Regarding the general setup of projects, RIA requires more input regarding:

• interaction design
• the distribution of business logic and presentation logic
• framework development and integration (some AJAX libraries are still fairly new
• and there is some need to build component libraries, esp. for large, complex applications

The interaction design needs to consider the possibilities and limitations of RIAs, the target audience, what domain knowledge is available, as well as usability engineering.

Besides these typical pitfalls,
RIA is the way to go to provide efficient and fast web applications for power users, offering

• better interaction
• better work experience
• performance
• robust
• good look and feel

In the second part of the talk, Markus Pfeisinger presented to frameworks for Adobe Flex / Flash development:

• Cairngorm
• PureMVC

He briefly provided an overview of their main characteristics and discussed the benefit of using a framework in general and these two in particular. He seems to prefer PureMVC.

Finally, he gave a short peek view of the Flex Code Generator.

Interesting aside: Markus used Sliderocket to present his slides.