Re: Adobe's RIA Technologies

The first RIA platform is JavaSE from Sun. Now more than 10 years old, and therefore mature.
It's a platform with a vast array of standard libraries, much more "business oriented" than something like Flash.
It's user interface, Swing, is nowadays fast and snappy. Sun invests heavy in Java to make it more "desktop" friendly. The desktop has been neglected because of Java's huge success on the server and on mobile devices. Java is now also open-source as opposed to proprietary technologies like Flash and Silverlight. Now with the rise of the RIA hype, Sun and others are investing more in desktop Java to make it a viable option. In fact, Java has been a viable option for RIA's long before the buzz existed. But due to limiting band-width (dial up) and because it's easy to slam together a HTML page which looks much better than a mediocre Swing app (it takes more work and expertise to make a good looking Swing ui) it wasn't widely used. Now times are changing, and desktop Java seems to have a bright future.

Date: Wed, 29 Oct 2008 15:31:44 -0700
From: nandelin@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Adobe's RIA Technologies

From: Pete Helgren
Great observations Nathan...

Thanks for the feedback. I'll share a few more observations. My Flash based email client (gowebtop) provides a Login prompt as an application entry point. It happily entertains with various visual transitions such as fade-in effects and progress bars while it transfers the code to display the login prompt, which takes about 15 seconds. Actually the ubiquitous "Transfering ..." status never goes away so you're never quite sure when it's done. Unfortunately it doesn't download code to set focus to the User ID input element, so I click on the input element to set focus. And if you tab past the password prompt, the cursor moves to hidden fields, so you grab your mouse and click again.

It takes another 15 seconds to authenticate the user and transfer more code to display the first screen. You get used to the "Transfering ..." status. I guess the point is that it takes quite a bit of code to display a set of windows and populate data elements. So as Web applications go, it appears to me that Flash needs a lot of bandwidth to initially activate a screen. After that, it behaves much like a desktop application from a functional point of view, except for the lag time to fetch new data from the server, which seems to run at the speed of HTTP plus whatever technology you use for responding to HTTP requests, where runtime performance ranges widely from one request to the next. You never quite get the feeling that you're in control of the user interface because of widely differing lag times. Sometimes it's quick. Other times it's slow.

Another pattern that seems to emerge in Flash based data entry applications is to store data locally, at least temporarily in memory, until the Save button is clicked. Say you have a classroom gradebook for teachers, and you enter scores for 30 students in the course, then click the Save button. In one demo I watched it took about 10 seconds to refresh the screen with new scores, which I think was running on a pretty much dedicated server. You've got to hope that the service is not disrupted between the time the data entry window is displayed and the time the scores are posted. That would make a teacher mad.

But hey, the visual transitions are cool...

Nathan.




--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

_________________________________________________________________
Uniek: Onbeperkt chatten op je mobiel voor maar € 2,95 per maand!
http://www.overaljevriendenbijje.nl/#superdeal