Bits And Buzz, by @JeremyChone

Nowadays, building [rich] Web applications can be quite challenging, as the proliferation of Web technologies has become overwhelming and confusing. The real challenge is that many interesting new Web technologies are being promoted by various groups, and it can be quite difficult for a developer or architect to filter the practical and future-proof ones from the cool and volatile ones.

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.

Read the rest of this entry »

Software technologists tend to learn by oscillating. We never arrive directly at the right solution; we just come closer to it by going back and forth. We always think (or like to think) that our current solution is correct; only to realize, some years later, that we overshot and need to take a few steps back. The evolution of the software application model is a great example of this syndrome. Every technologist knows about the three main application model phases—Mainframe, Client/Server, and Web [1.0]—and many of them think they know what the next phase will be. In fact, two models are currently being promoted. In order to better understand the current trend, it is important to first understand the three original model phases.

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.

Read the rest of this entry »

With the emergence of new technologies such as AJAX, Flash, and Silverlight, and popular applications such as Google Map and iPhone, the temptation for developers to fully and deeply animate their upcoming applications has become almost irresistible.

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). 

Read the rest of this entry »

Over the last few years, we have witnessed the emergence of a new type of software platform – the Service Oriented Platform (SOP). The SOP concept is to offer an application platform as a network service (inside or outside an enterprise firewall), providing a centralized runtime to execute and manage distributed or centralized applications.

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.

Read the rest of this entry »