As a rule of thumb, open technologies tend to be more pervasive and longer lasting (especially for the Internet) than proprietary technologies, which tend to bring more advanced capabilities early on. Consequently, Web application developers need to be pragmatically-open, by choosing open technologies whenever possible, but also by not hesitating to use proprietary ones when required. It is not about being religious about openness or anything else, but rather about being diligent so that one is able to choose the right technology to maximize the chances of success of the target application. In other words, it should not be a personal and emotional decision, but rather a business and rational one.

Today, for mainstream rich Web applications, there are two main technologies: Flash and Open Web (i.e., HTML, CSS, JavaScript, SVG, etc…). While SilverLight and JavaFX are definitely interesting upcoming technologies, they are still unproven Web entities, and, for the sake of simplicity, this article will focus on Flash and Open Web.

Having worked for many years on the subject, and having spent time in both camps, I can honestly state that they both have their pros and cons and, depending on your rich Web application requirements, you might even need to use both. The trick to making a good business decisions is to have an objective look at each technology and to strip out all preconceived emotional opinions.

To help answer the question of what to use when, here is a technology-capability matrix, followed by short explanations.

SEO (Open Web)

While Google is making some good progress at indexing Flash content, SEO for Flash is still in its infancy, and, if your application depends on SEO to succeed, you better stick with well known URLs and HTML best practices. SEO is hard enough with regular page-based HTML content without adding unproven SEO-technologies to the mix. Even adding Ajax the wrong way could be extremely damaging to SEO. For example, the “#” URL trick that is used by many single-page Web applications might not be as SEO-friendly as it seems (Ajax and SEO will probably be the subject of a future post).

Mobile Web (Open Web)

Mobile Web is another place where Flash is still behind. Although Adobe is making promising progress in this area, if your are not building a 2D game or  video/media centric application, there are very few reasons to encumber the overhead and uncertainty of another virtual machine on top of the already very capable modern mobile Web browsers. Nowadays, most of the new high-end devices have desktop-like browser capabilities (often based on WebKit) which allow developers to take full advantage of Open Web technologies such as Ajax and CSS 2.1+. Consequently, the best way to maximize your mobile application reach is to stick with Open Web technologies and architect your Web user interface in such a way that it progressively degrades for simpler mobile browsers. Alternatively, developers can to take advantage of the current mobile app stores trend that promotes device specific applications, but this is outside the Web scope of this article.

Rich HTML Display & Editing (Open Web)

While Flash 10 has some technologies which ease the development of HTML layout and editing components, it is still nowhere near the browser’s native capabilities. It is probably a fair guess that Flash 11 will have even better HTML capabilities, perhaps even embedding WebKit, but, for today, if you want to display and edit rich HTML, not surprisingly, the Web browser is your best friend.

On-Demand Performance (Open Web)

On-demand performance is the experience a user gets when accessing a Web application for the first time (i.e., when none of the application assets are in the browser’s cache). The common expectation for consumer Web applications is usually sub-second responsiveness. As outlined in a previous post about Compiled vs. Interpreted Web, the interpreted nature of the Web makes it very efficient for executing on-demand content & interaction, whereas the compiled nature of the Flash application model is more optimized for post-load execution. So, for applications requiring Web-fast first-time interaction experiences, the Open Web model is the best one.

Post-Load Performance (Flash)

Conversely, the compiled approach of Flash and frameworks such as Flex makes it much more optimized for post-load interactions. So, if you do not mind having a “loading-bar” on your application and have a very high logic execution performance requirement, then Flash might be a good solution. Note that new JavaScript VM such as Google Chrome V8 and Mozilla Firefox SpiderMonkey with TraceMonkey are really breaking the barrier of interpreted language performance. Unfortunately, Microsoft Internet Explorer is still behind (even IE 8) in terms of JavaScript execution speed. While we may suspect that Microsoft is going to work on optimizing their JavaScript engine soon, for now, the best way to have high execution logic performance across browsers is with Flash ActionScript 3.

Animation (Flash)

If you want to make pixel flies, then Flash is your best friend. While this statement is still true today, it is also important to note that, with modern browsers (including IE-8-) and Ajax toolkits such as jQuery, applications have access to some decent sets of animation capabilities using 100% Open Web technologies. So, unless animation is a cornerstone of your application, animation alone should not be a critical or decisive factor one way or  the other.

2D & 3D (Flash)

This is definitely a stronger one in favor of Flash. While Open Web is promoting some 2D standards and implementations (e.g., Canvas and SVG), nothing beats Flash performance and capabilities in reference to pixel and vector graphic creation and manipulation. While Canvas and some SVG are pretty well supported by Firefox and WebKit based browsers (i.e., Safari and Google Chrome), Microsoft IE is still not implementing those. Developers can circumvent this Microsoft limitation by using compatibilities such as JavaScript or even Flash libraries, but this usually comes at the cost of features and performance. In other words, while it is possible to do an online Photoshop or Visio-like applications in SVG/Canvas/VML, the investment required to do it with flash technology is definitely worthwhile. Unfortunately, Flash does not support the interpreted model, so Web developers will have to fully jump into the Flash development model and tools, which can be relatively high barriers of entry, especially for small visual components (e.g., Charting). There are some interesting Flash SVG libraries (e.g., sgweb) which allow Web developers to use Flash to rendSVG renderer and the browser JavaScript VM to run the scripts, however this comes at a performance cost.

File handling (Flash)

File handling has always been completely left-out by the different Open Web standardization and implementer groups. Building an effective experience for accessing local files through a Web browser has always been challenging, to say the least. Even the most modern browsers still have the 1995 simple file-input component which allows for the selection of only one file at a time. Flash, while far from being perfect, does add some nice features in terms of this realm, such as multiple file selections and, more importantly, a way to read selected files of clients before sending them to the server. Unfortunately, enterprise Web applications would really benefit from file drag & drop support from and to the desktop (and File Explorer), but, somehow, this feature is always given a very low priority by the various decision makers (or is somehow labeled as a security hazard). Alternatively, you can use Java technology, as does Facebook for their photo uploader, which gives almost complete file-system control for signed applets (note: somehow, it feels kind of strange to write the word “applet” in 2009). Advanced clipboard support is also another neglected requirement.

Video & Audio Playback (Flash)

Two of HTML 5’s big new features, besides off-line support, are the video and audio tags. However, there still lot of discussion about the support format of video tags. One of the biggest issues is that the best video formats are not royalty free, and, while commercial vendors such as Adobe, Microsoft, and Google are willing to pay the video tax for their users, the open source community finds itself in a catch-22 situation. So, from an application developer standpoint, Flash is by far the best option to bring high quality video and audio to your application. With the latest support of H.264/mp4 video support of Flash, there is no good reason to really look elsewhere for now.

Video & Audio Recording (Flash)

I am splitting out media playback from recordings because, if they are not split, the later tends to be forgotten. It’s difficult to believe, but, in the 2-way Web era, the big promoters of Open Web technologies have no implementations or plans to support Web Video and Audio recording and uploading. Luckily, Adobe Flash has a pretty mature solution to this need, and while they have not opened the code, they have opened the APIs and protocols to allow developers to freely use the Flash player as a video recording device (see Red5 for an open source alternative to Adobe Flash Media server).

So, as can be seen, there is no one size fits all technology. It depends on the application requirements you might need to use multiple technology sets. Obviously, as a technology vendor or advocate your goal is to build and promote your technology for as many scenarios as possible, however, as an application developer, your only goal should be to ensure the success of your application, no matter the technology you end up using or switching to. Developers should rationally and objectively evaluate each of the technologies before investing too much time and money in any one of them. Also, avoiding over-hyped terms such as RIA and Social Network when defining application requirements will go a long way to help in terms of focusing on what really matters to users.

If you liked this article, a re-tweet is greatly appreciated.

If you are in the midst of choosing your technologies for your next rich Web application, do not hesitate to contact me at jeremy.chone@gmail.com. (I provide everything from free advice to complete rich Web architecture and strategy consulting and services.)

1) Mainframe

The first application model was the mainframe;  the client was simply a screen (typically green) and a keyboard that could display and send characters back and forth through a network. The server had all the definitions of the screens (i.e. User Interface), application logic, and data, and was communicating with the client by sending characters (which represented the UI and data) back and forth.

This approach had the benefit of being relatively simple, cost effective to scale, and was easy to manage because the application could be centrally managed. The limitation was obviously that the client’s lack of richness limited the type of application that could be offered. For example, a Google Map on a green screen would have been a challenge to implement.

2) Client/Server

The second application model came with the popularization of personal computers by IBM, Microsoft, and Apple. Now that users were able to have actual processing and display power on their desktop, the application UI and the logic could reside on the client side, while the data could reside either locally or remotely on servers. The application UI and logic were usually packaged and optimized (i.e. compiled), and had to be physically installed on the client side. When the user needed a new application or a new version of the application, s/he had to explicitly acquire and install the new application or upgrade package. In this scenario, the server’s responsibility was to synchronize data.

The benefit was that new applications could take advantage of Moore’s law on both ends of the network, which consequently allowed for a wide variety of applications, such as word processing, CAD/3D tools, and games, just to name a few.

The downside was that the application life cycle (e.g., installs and upgrades) required the user’s intervention, making some application scenarios relatively expensive to deploy and manage.

3) Web

Then came the Web; at first, it was mostly used to access (i.e. browse) content. However, through its simplicity and network-centric characteristics, it quickly became a very effective way to deploy networked-based applications. The model was similar to that of the Mainframe, where the server sent UI instructions to the client. But this time, the client could do much more; although still relatively primitive, the Web model had some extended UI elements that included image, text, and input fields, and even allowed the payload to carry some logic (i.e. JavaScript) that would be interpreted and run on the client side.

Although not as rich as the Client/Server application, the benefits of the Web were unparalleled when it came to deploying applications over the network. The fact that the server had complete control of all aspects of the application—UI, logic, and data—made this application model a genuine standard for Internet applications.

However, there were two disadvantages to this model. First, the UI primitives were not as rich as its Client/Server counterpart, making the appearance and interaction of Web applications less competitive. Luckily, the Web had a very inclusive architecture, and allowed plug-ins vendors, such as Sun and Adobe, to extend the Web primitives with capabilities such as video and audio. Second, the application granularity was the screen (i.e. page), meaning that each user interaction required a screen refresh that updated the UI, logic, and data simultaneously. While the single screen model was easy for developers to understand, it made highly interactive applications quite a challenge to build, and often resulted in a poor or confusing user interface experience.

4) ???

So, where are we now? What is the fourth phase? Currently, there are two possible directions: the Compiled Web and the Interpreted Web.

4.1) Compiled Web

The Compiled Web model is, in a way, the Client/Server model inside a browser. First introduced by Java, with Applets, and now being revived with Adobe Flash/Flex, the concept is to compile all the application user interfaces and logic into one or more packages (.jar for Java, .swf/.swc for Flash) that will be downloaded and run by the client; this time, inside a Web browser. This model is often based on browser plug-ins such as Sun Java or Adobe Flash, and usually relies on typed and object-oriented languages like Java or ActionScript 3. Such applications communicate mainly with servers, as the Client/Server did, in order to synchronize data or to call Web services.

The advantage of this approach is that it offers Client/Server developers a very familiar application model while allowing the end-result application to leverage some of the Web deployment characteristics. The other significant benefit is that browser plug-ins such as Java, Flash, and Microsoft SilverLight extend a browser’s capabilities with video, audio, 2D/3D apis, and threading (for Java/JavaFX), allowing applications to take full advantage of the client’s computer processing and display power.

However, the Compiled Web model does not fully take advantage of the dynamic characteristics of the Web. By fixing the UI definition and behavior at the time of compilation (i.e., design time), the Compiled Web model removes the server’s ability to fully participate in the UI generation and orchestration, which could be limit many Web applications, such as model-driven applications. Also, this packaging phase reduces the application’s life-cycle flexibility since any update or enhancement will require a large part of the application, if not all of it, to be rebuilt and redeployed. While modularization is possible, modules have to be carefully thought-out; once designed, they are relatively fixed.

There is also a misunderstanding about performance, which asserts that because a compiled code runs faster than an interpreted code, a Compiled Web application performance must be greater than a regular Interpreted Web application. While theoretically correct, this reasoning does not take into consideration the on-demand nature of the Web, whose applications are expected to be instantly accessible from several entry points. The compiled approach is not suitable for this requirement because it requires the entire application (or large parts of it) to be downloaded before anything can be displayed to the user. This is retrograde from the Web application model, which allows a more organic interaction in which only the required resources for a specific interface (i.e. a screen) need to be downloaded. As a result of this limitation, loading progress animation has become a very common experience for many Compiled Web-style applications.

4.2) Interpreted Web

On the other hand, the Interpreted Web, is just the natural evolution of the traditional Web application model with an extended set of user interface constructs and capabilities, as well as an asynchronous way (i.e., AJAX) to send requests and to recover resources over the network without requiring a screen refresh. This AJAX capability, coupled with the complete dynamicity of Web technologies, where any part of the application such as UI structure, UI style, logic, and data can be dynamically updated, offering limitless architecture possibilities.

This approach still leverages all the benefits of the Web model, while extending the user interface richness and breaking down the page granularity to virtually any piece (UI, logic, and data) of the application. This allows a wide spectrum of application styles, from a single page style (Google Docs) to a page-based style with highly interactive components (Facebook or SalesForce.com). By allowing the server to be a complete part of all aspects of the application (UI, logic, and data), this model is an ideal approach for model-driven applications that require the user interface to be dynamically generated from the server, as well as large suites of applications such as Google Apps or Facebook. Also, the extended granularity offers unparalleled application life cycle agility. Upgrading or enhancing an application only requires updating of the necessary pages or resources of the application, and the user will only download these modified resources when he requests the updated interface.

The downside to all of this is that browsers still have a limited set of UI capabilities. For example, video and audio still require third party plug-ins (which usually rely on a different application model); and 2D/drawing apis are still cumbersome (no DOM for Canvas and not-as-HTML-friendly SVG). Thanks to the Web-inclusive architecture, it is relatively easy to embed plug-in components for these advanced functionalities (i.e. charting, video, audio, and drawing), although they do not always blend very well with the Web model.

Now, to add some confusion to the mix, it is possible to implement Compiled Web framework with interpreted technologies and vice versa. Google GWT is a perfect example of such hybrid model by exposing a Swing API to the developer and deploying HTML/Javascript code. The reverse can also be done in Java/JavaFx by interpreting XML UI elements (e.g., Nexaweb XAL technology) and using a scripting language like Groovy or JavaScript/Rhino. Interestingly enough, SilverLight is already a hybrid of the two models because it supports dynamic and compiled languages via the .Net CLR technologies and allows XAML to be dynamically evaluated. Unfortunately, it is harder to have an Interpreted Web architecture using Flash technology since, for business and performance reasons, Adobe seems to have rejected the interpreted model by making most of their technologies—ActionScript 3, Flex, FXG—compiled centric: no evaluations and no runtime MXML (you can build your own, but you are up for a ride). (see also: Why FXG is not based on SVG).

Which one?

So, which one is better? Which one should you base your application on? Well, it depends on what type of application you want to build and what skills you have available.

If you want to make a desktop application and deploy it over the web, the Compiled Web approach might be a good solution. This is also true if your engineering team has strong Client/Server development expertise (i.e. Windows MFC, Swing, etc.). Using a modern Compiled Web framework, such as Flash/Flex, might be a good path, because Open Web (i.e. Html/CSS/Javascript/SVG/Canvas) development could be frustrating for non-Web developers.

On the other hand, if you want to do a rich Web application that leverages as many Web characteristics as possible, and most of the logic needs to be on the server side, the Interpreted Web approach will give you unparalleled flexibility and functionality.

The good news is that if you choose the Interpreted Web model as your main framework, you can always add compiled-based components. YouTube or SalesForce.com are good example of such an approach. However, the reverse is much harder, if not impossible.

This was a relatively long post, but was the reflection of many years working on the subject.

If you are in the midst of designing your rich Web application architecture and would like third-party validation and advice, I would be more than happy to offer an hour or so (free of charge) over the phone (i.e. Skype). Just email me at jeremy.chone@gmail.com

While slick animations and transitions are certainly useful for emotionally driven applications, such as car configurators, and some applications or components such as Google Map and charting, they should not be used as a substitute for a good interactive design. Application developers need to realize that these animations and transitions come at an extra design and development cost (no matter what tool they are using). 

In fact, the most successful and influential Internet consumer applications (e.g. Yahoo, eBay, Amazon, Craigslist, Facebook, FriendFeed, and YokWay) use animations and transitions relatively lightly.

In the desktop and mobile arena, Apple has become (and probably always has been) the most famous and admired pixel maestro. However, it is important to note that screen orchestration is a new art and comes at a cost. Even in Apple’s case, flying pixels come with a feature cost, whereas iPhone users can very elegantly scroll their contacts but cannot search them, and can slide from application to application but cannot cut and past between them.

Obviously, the point here is not that including animations and transitions is a bad practice, but that the animations and transitions need to be carefully and thoughtfully considered and planned. So, here are the good, the bad, and the five rules about flying [your pixels]:

The good

• Natural Feel: In the real world, things do not disappear and reappear as they used to do on computer and mobile screens. As shade and gradient are making shapes easier on the eye, animations and transitions are useful techniques to bring a more natural feel to the application.
• Visual Continuity: Good animations and transitions for some types of information can dramatically improve their access (e.g., maps and multi-level charting).
• Perception: Perception is everything, and nowadays a couple of flying pixels can go a long way toward obtaining some good marketing/user buzz and management visibility. iPhone without the flying pixels would not be iPhone.

The bad

• Distraction: Users can be overwhelmed by too many flying and flashing pixels, and developers can spend too much time animating them. The order of priorities should be: first, interaction design; second, visual design; and finally, “orchestration design.”
• Perception: Cool flying pixels might give a false sense of design quality when, in fact, they can hide some serious design flaws or even deteriorate the real use of the application.
• Costs: Flying is not free. First you need your team to learn new APIs, tools, and, sometimes, languages, and secondly, you need to acquire good screen orchestration design skills. Making moving parts feel natural is not as easy at it might seem (even with the right tools and APIs)

5 rules about flying [your pixels]:

• Hire a pilot
• Fly when you need to, not when you can.
• Fly from A to B, not A to A.
• Don’t fly too high — it might suck out all your oxygen.
• Don’t forget to land.

My belief is that animations and transitions are like lipstick; the good ones are the ones you do not notice… except if you are selling lipstick, I guess.

SOP services can range from application aggregation, presentation, linking (e.g, Mashup), provisioning, componentization, and context augmentation (e.g., Social Graph and common application data). As SOPs mature, it would not be surprising to see these platforms offer most, if not all, of the traditional application platform services in a service-oriented manner, such as application testing, versioning, data migration, and much more.

In the consumer space, the best SOP examples would be Facebook, OpenSocial, and Ning. In the enterprise, a good example would be SalesForce.com (including their latest Force.com addition) and some of the newer smaller players such as Coghead, DabbleDB, and BungeeConnect. Note that SOP solutions can be offered as a hosted service (Platform as a Service, aka PaaS), or can be packaged as a product (not as common yet). In many ways, enterprise portal architecture can be considered the SOP ancestor.

We can identify four distinct but complementary main SOP access modes. Most SOP providers (such as Facebook and SalesForce.com) offer more than one access mode. Others, like OpenSocial, have thus far focused only on one.

Below is a simplified visualization of these modes and their corresponding descriptions.

A) Proxy Mode:

In this mode, the SOP is in between the user-browser and the application, and proxies all browser requests to the applications. The best known example of this model is the Facebook FBML application model.

Here is the simplified application lifecycle for the SOP Proxy mode:

1. Each page request goes through the SOP server, which forwards the request to the application with some additional SOP context (e.g., Identification and Social Graph information).
2. The application then returns the requested page to the SOP server in a specific presentation format (e.g., FBML for Facebook). The SOP server then translates the “SOP-formatted page” into a standard HTML/AJAX format for the browser to read.

This mode allows developers to focus on the content of the application while reusing pre-built SOP components and delegating presentation to the SOP server.

The main caveat of this approach is performance, since each page request [usually] requires an additional http-request to get the result back to the user. Another caveat is the SOP dependence. Usually, this model also requires applications to output a proprietary XML (e.g., FBML and SNML), which limits application portability.

B) iFrame Mode:

In this mode, the SOP server is between the browser and the application only at initialization time, and all subsequent application users’ interactions are forwarded directly to the application (usually using the browser’s iFrame client-sandboxing mechanism). This is commonly known as the Facebook “iFrame mode,” or the not-yet-released Google OpenSocial “type=URL.” This mode also requires the SOP server to have a strong set of REST/SOAP APIs, since this will be the only way for the application to access SOP context information (e.g., Social Graph).

Here is the simplified application lifecycle for the iFrame mode:

1. When a user clicks on the application page, the SOP server initializes the application and returns an HTML page to the browser with an iFrame pointing directly to the application.
2. Every subsequent user’s interaction with the application will be in the context of the applications, as if the application had its own browser window.

This mode enables full user interface control and maximum application portability. However, developers will not be able to use the SOP presentation and component services, and will have to re-implement common components and look & feel.

Note: To my knowledge, most Facebook applications are using the Proxy mode mainly for to avoid these two caveats.

C) Client-Mashup Mode:

Another mode similar to the iFrame mode is the Mashup mode, which executes the application on the client side (in JavaScript) by providing AJAX APIs to get data from the SOP server (i.e., SOP Context) and the application server.

Here is the simplified application lifecycle for the Client-Mashup mode:

1.  When a user clicks on the application page or component, the SOP server initializes the application and returns the HTML and JavaScript content for the browser to execute.
2. The application (JavaScript) code can make AJAX calls to the applicationaccess content and methods.
3. A JavaScript API is also provided to the application to access SOP data and methods.

For heavy JavaScript developers, this approach can be very attractive. It also forces the application to take maximum advantage of the AJAX model and offer a consistent way to access SOP and application data and methods. It is a common and convenient means for developing widgets (note: OpenSocial is based on the Google Gadgets application model).

However, for full applications, this approach can be a little too JavaScript-heavy and limits portability. It also requires the developer to re-implement some basic browser functionalities, such as page navigation, since each user click will need to be handled in JavaScript.

D) Server-Embedded Mode

The Server-Embedded SOP mode is probably the most involved from an SOP implementation standpoint. In this mode, the SOP server stores, manages, and executes the application codes and data. This approach usually requires the SOP server to provide a browser interface to develop, test, and manage the application. In the consumer market, Ning, Coghead, DabbleDB, and BungeeConnect are good examples of such a model, as well as Force.com on the enterprise side.

This mode works very similarly to the Proxy mode, except that now the application runs in the process (theoretically speaking) of the SOP server.

So, here is a first pass at the Service Oriented Platform concepts. SOP has already made a significant impact on the software industry, as we have seen with Facebook and SalesForce.com. It is probably safe to assume that SOP will become even more relevant to the consumer and enterprise software market as time goes on. From a theoretical architecture point of view, it is interesting to see the lines between online, hosted, distributed, and centralized being blurred.

Note to self: Probably a good time to update my Buzzpad.

Related Links:

• Facebook v. OpenSocial from Widget Box
• OpenSocial and Facebook Platform side by side comparison from Iosart blog
• Bungee Labs opens developer platform-as-a-service from Larry Dignan