Rich Internet Applications

In the news:
Blickpunkt KMU, a Swiss business magazine addressing small and medium sized enterprises, published an article on Rich Internet Applications (RIA) for business software. The article is in German and was written by Tobias Baumann at Soreco. Soreco is an ISV that has decided to use Canoo’s Java RIA library for their business software.

Besides discussing AJAX and Flash-based technologies, the article mentions two main reasons for choosing a Java-based approach:

• robust technology,
• and excellent performance.

In more general terms, the article concludes that the next generation of business software will offer a marked increase in efficiency, thanks to RIA technology. Business management applications will resemble conventional desktop applications regarding usability, features and performance, while offering all the benefits of a web-based solution. Current costs for software acquisition, maintenance and distribution will be reduced to a minimum.

Download the article here (pdf, in German).

See also:
Jazoon Thursday
RIA Technology for BPM Software

Between releases 1.0 and 1.1 of the Music Pinboard application, we succeeded in reducing the application’s footprint significantly. As we described in the overview that footprint is now around 5.1MB, which includes the Java FX (JFX) Runtime and a hefty (2.8MB) blob of an XML API called JAXB, which we could potentially replace with something lighter, given a little bit of time for re-design.

Large as this may still seem, there is actually plenty of reason to assume that this figure could come down (without any re-design of the application) by using Sun’s Pack200 technology. Unfortunately, when we tried to use Pack200 we ran into bleeding edge syndrome in conjunction with Java Webstart described here.

But when it comes to consumer satisfaction, it is not typically application size which causes irritation, but the cumbersome, lumbering JRE itself. By now you have probably heard what Steve Jobs apparently said of Java on mobile devices:

“Java’s not worth building in [to the phone]. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

Given the ubiquity of Java on mobile devices today (estimated at around 4 billion JREs) this statement seems pretty harsh. And true to his word the iPhone does not come delivered with a JRE and nor is it likely to in future. It also has to be said that even some of Java’s most fervent supporters agree the JRE contains too much machinery by default, much of which never gets to be executed in the average application.

For many attendees of JavaOne 2007, one of the biggest and brightest announcement concerned “Consumer JRE”. Consumer JRE seeks to address the Java end-user’s points of pain directly i.e.

1. Startup times: Consumer JRE introduces functionality called Quickstarter, which according to Sun should “radically” reduce application and applet startup times.
2. JRE install and launch times: The Java Kernel project seeks to break up the monolithic Java platform into discrete units of functionality. These then get downloaded and installed according specific application needs. the remainder of the platform is then streamed down to the consumer’s device in the background.
3. Deployment: Also part of Consumer JRE, a Deployment Toolkit should make it easier to detect and install a prerequisite JRE.
4. User-friendliness: Startup pop-up windows containing licensing information are to be re-designed to (hopefully) look a little less like a legal writ.

You can read more about these and yet more positive sounding developments here. Release is currently set for an update to Java SE6 in early 2008.

So what does all this mean for JFX? Obviously as long as the promise of “radical” improvement turns out to be true, it can only be great news for a technology that itself seeks to enhance the end-user experience. For too long Sun has been relying on increasing bandwidth, more powerful devices on the patience of end-users. In the meantime many have already switched to leaner solutions, and in the case of arguably the biggest advance in the mobile phone experience in recent years, Java has been left out in the cold altogether.

See also:

Some Background Information about the “Music Pinboard” Application

By special request I have annotated the chart I mentioned in my previous post to show where Canoo’s Java RIA library, UltraLightClient (ULC) is positioned within the Rich Internet Application (RIA) space:

Thin Swing

UltraLightClient is a Java library which offers the full Swing widget set for your web applications, i.e. a server-side API for Swing. It is a thin client where no application code is deployed on the client. A small, generic Presentation Engine displays the user interface and solves typical versioning and distribution issues experienced with conventional Swing fat clients.

A drawback for some consumer applications is the Java plugin requirement on the client and the size of the JRE download. This is one of the reasons why Canoo is closely watching JavaFX (see Mike’s posts on JavaFX) and other consumer JRE discussions. In a business scenario, UltraLightClient is a cost-effective alternative to offer responsive, desktop-like user interfaces for web applications that need to run on various platforms.

See the UltraLightClient product website for further details:
Top reasons to use UltraLightClient
Advantages vs. Swing and Java Web Start
Case Studies

High velocity in software development translates to more than just profits. High velocity is the ability to respond fast to continuously changing conditions - either in the marketplace or on an ongoing project. Velocity enables innovation. Velocity reduces development costs. Any company that wishes to remain viable long-term needs to focus on velocity, and to ensure that velocity continually increases over time.

Aside
The term velocity has found increased usage in the agile development community of late, which is why I choose to use it here. However, my preferred term is actually throughput, which in terms of software development I define as the rate at which features [feature = unit of client-valued functionality] can be produced by a team or organization. Throughput is also the preferred term of process guru Eliyahu Goldratt of The Goal and Theory of Constraints (TOC) fame. Among other things Goldratt and the TOC movement have argued (and convincingly demonstrated) that focus on throughput as opposed to cost is a vastly superior strategy for increasing profits, among many other advantages. Indeed, cost focus turns out to be detrimental to the performance of virtually any business process, not to mention potentially destructive for employee relations. I’m aware that making this claim is akin to heresy in many CTO’s books, and in any case we don’t want to lose sight of the purpose of this post, so suffice it to say that if you want to make money now and in the future, then throughput/velocity has to be one of your top priorities.
End aside

Now if we compare our experience with the JFX-based Music Pinboard application with our experiences in developing RIA applications in alternative technologies, which include Swing, ULC, SWT/JFace, Ajax, Flex and others, then we are forced to conclude the following: The rate of feature development is impressively high with JFX. Here, roughly, is a list of features which comprise the Music Pinboard application:

1. Enter search criteria
2. Display artist name as title
3. Display “related artists”
4. Display associated albums
5. Display associated videos
6. Display associated pictures
7. Scrolling through associated albums
8. Scrolling through associated videos
9. Scrolling through associated pictures
10. Display and allow scrolling in a “display shelf”
11. Video playback
12. Consistent look and feel throughout
13. Minimal response time enabled through parallel loading of items
14. Download and run application
15. Present application in a movable, shrinkable, closable window; closing window terminates app [this feature was introduced in Release 1.1 of MP]

So knowing the number of features (originally 14), developers (2-4) and the number of person days invested (20), it would not be difficult to compute a rate of feature development. Of course, the MP effort included learning time (discussed in Part I), so such a computation would not be terribly meaningful until a number of projects gone through the pipeline. The rate of feature development is clearly also influenced by feature complexity. This a further motivation for collecting productivity data over a series of projects over time, as only then can a meaningful average rate by calculated.

Nevertheless, we feel it is safe to say that JFX looks like a very promising technology when it comes to developer productivity. Certainly the development of equivalent functionality using Swing or equivalent object-oriented framework with no additional high-level support for Java2D effects (such as are provided in JFX) would have taken significantly longer.

And this can only be a good thing for the organization’s long-term financial health, as well as - let us not forget - our clients.

See also: JavaFX Script Productivity Part I of II: Learning.

Source: Photo by Joe McDonald

In the past couple of weeks I noticed an increase in blog posts discussing possible definitions of Rich Internet Applications (RIA). Not surprising given that companies such as Microsoft, Sun and Adobe are staking their claim.

Java FX Comparison

The above diagram shows Philip’s classification of Java FX versus other UI technologies.

RIA versus AJAX

Redmonk analyst Michael Coté suggests the following criteria to define RIAs:

My simple sieve consists of three parts:

1. Is it something trying to act like a web application (only better!), including connecting to and interacting with the web?
2. Is it trying to go beyond standard web application UI technology using something more than Ajax?
3. Did you have to download a browser plugin or other runtime?

He suggests differentiating between RIA and AJAX. This is indeed interesting, since RIA and AJAX have often been used as synonyms. At Canoo, we are using RIA as an umbrella term to refer to “rich client capabilities in a web infrastructure”. It really depends a lot on your project requirements what technology you should select to offer a better GUI. If one of your requirements is “no browser plugin” then AJAX is a viable option to consider to improve usability. If the web application will run within a corporate environment where a Java plugin is pre-installed, a Java-based approach will probably save you time and money.

I find his discussion of possible areas of application more significant. See also Ryan Stewart’s response, who lists Pownce, Nike+, British library and Finetunes as examples of RIAs.

The Three Religions of RIA

InfoQ provides a summary of a recent blog post by Simon Morris discussing a possible taxonomy.

These attempts to classify RIA are not new. And we’ll probably see many similar posts.

Planet-RIA.org

Canoo has set up a blog aggregator to help you keep up with RIA news and developments:
http://www.planet-ria.org

The feed aggregator is based on work by Glen Smith at http://groovyblogs.org and collects news about RIA. It is a beta version, i.e. if you have suggestions how to improve it, please feel free to leave a comment below.

(update July 19th) Simon Morris takes the discussion further:

“Rich Internet Application” denotes a type of client application which is functionally identical to regular desktop applications, but uses a means of deployment closer to a web page. Physically it is transient, living only at the end of a URL.

If you are not familiar with the term Web 2.0, this introductory article lists some links as a quick jump-start. In the second part, we try to point out what this development means for enterprise software.

Tim O’Reilly was among the first to come up with the term. Web 2.0 represents a shift in who creates content, moving from a small group of programmers and content developers to nearly everyone that has a computer and Internet access. One of the effects is the increased focus on web user interfaces and the technologies that are being used to develop a better, improved user experience. These new technologies make the interface smooth and intuitive just like desktop software and hide distributed processing from the user.

This Wikipedia article explains the background of Web 2.0. Listed below is a collection of useful Web 2.0 links:

Overview of Web 2.0 Applications and Web Services

• Web 2.0 References as Icons: www.go2web20.net
• German Web 2.0 References: www.web2null.de

Applications

• Google applications: www.google.com/a/
• Google’s Online word processing application: online word processing application
• Web based mail client: mail.yahoo.com
• Online image manipulation application: demo.neximage.com

Blogging

• Blog tool and weblog platform: wordpress.org
• Blog search: technorati.com

Collaborative Work

• Project collaboration, management and tasks: www.basecamphq.com
• Get and stay organized: Keep your to-dos, notes, ideas and schedule online: backpackit.com
• Collaborative writing software online with Writeboard. Write, share, revise, compare: www.writeboard.com
• Think together - collaborative online mind mapping tool: www.mindmeister.com
• A place to share and discover slideshows and presentations: www.slideshare.net
• Open source messaging, calendar platform: www.zimbra.com

Developing

• Public source code repository to store and organize code snippets: snipplr.com
• Sharing developer bookmarks: www.dzone.com

Social Networking

• Maintain your social network - focused on Europe: www.xing.com
• Maintain your social network - focused on US: www.linkedin.com
• Social bookmarking: del.icio.us
• Store, sort, search and share photos: www.flickr.com
• Flex application visualizing Flickr networks: www.marumushi.com/apps/flickrgraph

Traveling / Maps

• Route planning, interactive maps: www.map24.com
• Regional restaurants, shops, business … meet people (German, English coming soon): www.qype.com
• Switzerland: weather, traffic, news, restaurants, culture, shopping: map.search.ch

Enterprise Web 2.0

What does this mean for enterprise software? Increasingly customers will expect business software to offer the same ease of use they are experiencing at other web sites.

For example, users that appreciate Flickr’s “edit in place” description fields will expect other web software to offer similar features.

Or, they will expect the collaborative benefits of tagging, commenting, as well as following changes by RSS feed in their business workflow applications.

See also this recent post by Gapingvoid on the convergence of Enterprise Resource Planning (ERP) and social software:

The main story about social software is not about how it allows you to carry out existing company functions, just more quickly and easily. It’s bigger than that. In the future, companies will grow around social software, not the other way around.

The question is: What does your software need to meet this Web 2.0 culture and how can your business profit?

See also Hans-Dirk’s initial post.

When the majority of a company’s software engineers and consultants are primarily occupied with meeting the needs of its clients, opportunities for brainstorming and investigating new technologies as a team can become scarce. One option is to have staff permanently assigned to research. The problem with this approach is that research staff don’t get to experience first-hand the kind of real-world challenges facing commercial organizations. Another approach is to specifically allocate part of the yearly calendar, during which developers who are normally assigned to client projects, can get together and discuss and try out some of the ideas, which they’ve been bottling up inside their digitally oriented minds.

This is precisely what the annual Canoo Code Camp is designed for, and in May 2007 a group of Canoo’s developers again retreated to the Swiss mountains, carrying on their laptops outlines of some mini-projects, which they hoped to complete over an intense 3-4 day period.

One of the results of those mini-projects was the “Music Pinboard” application. As we state at the “Music Pinboard” download site, this application had a single intention: To investigate Sun’s new GUI scripting language JavaFX Script. Whilst the application may look fairly polished from the outside (a side effect of specifically seeking to create a “cool” look and feel), we need to stress that the app is prototypical in nature and as such was not subject to the rigors of a regular development. We actually think it likely that the application contains some bugs (although we hope not many) and we know for a fact that the application’s design is suboptimal in a number of respects. Here are some examples:

1. Music Pinboard’s footprint is around 5.4MB, which is undoubtedly excessive. Given that the core application (the JFX script, plus a handful of web-service abstractions) is around 100kb, where does the rest of this footprint come from? Primarily from three sources: (i) The JFX Runtime; (ii) The dedicated web-service APIs from Amazon, Flickr etc.; (iii) The JDIC browser component used to playback YouTube’s video. Add these up, and as long as you’re not using some additional compression technology, you end up with figure above.
2. Not being able to move the MP window around the screen would obviously be an unacceptable deficiency in a production application, but could be added in seconds given JFX’s declarative constructs. We’ve since asked ourselves why didn’t we think of this at the time
3. Although the user-response time is primarily dictated by the response times of the web-services (which, incidentally, vary significantly according to time of day/week), we could almost certainly improve the handling of these calls, as well as the rendering and caching of the corresponding results.

There are really two things to note about these points.

Firstly, some big improvements could certainly be made with little effort, and so it would be incorrect to assume these deficiencies are intrinsic to JFX. On the contrary, the ease with which these improvements could be made is to JFX’s credit.

Secondly, although from a technical perspective it is important to distinguish between deficiencies in the Java platform and deficiencies with JFX-alpha, whatever problems there are with Java that are not specifically addressed by JFX will, of course, be inherited by JFX (one could name having to download and install the JRE as an example).

Finally, these issues do nothing to diminish the success of the Music Pinboard mini-project, which provided us with insights that could not have been gleaned from reading about JFX alone, and which we will continue to share with the wider community.