From an internet technology point of view, 2006 and 2007 could be characterized by the rejuvenation of client technologies for web-based applications.

The main theme of this trend is to enable web applications to borrow as many characteristics from desktop application as possible without losing their inherent web attributes such as seamless deployment and cross platform/devices support.

We can identify two phases for this quest.

The first, which is well underway, consists of using more capabilities from “modern” internet browsers, often referred as AJAX, to enhance or build better web applications. GMail and Google Map are probably the most notable examples of this trend, although most of the traditional web applications nowadays are using such techniques to incrementally but dramatically improve their web user experience (e.g., Yahoo, Netflix, and Facebook). While these new techniques are huge steps towards improving the web application user experience, the fundamental capabilities of the web browser have not really changed that much. Every web application is still confined within the browser container which limits (purposely) advanced operating system access such as local storage access and desktop integration.

The second phase, which is gaining serious momentum due to the involvement of major technology providers (e.g., Adobe, Google, Mozilla, Microsoft, and Sun), aims to provide an environment for developers and end-users to go beyond the current browser constraints while preserving most of the benefits of the web. The challenge is as technical as social, given that “normal-users” (i.e. non-geeks users) have learned to trust the current web browser with its constraints.

There are basically two ways to accomplish this goal. The first (Option A) is to extend the existing browsers with new capabilities while keeping the user within a browser experience. The second (Option B) is to create a new application container for a new generation “Internet Desktop Application”.  They both have their pros and cons and probably are both needed. Interestingly, most of the players have a strategy for both.

Below is an overview of the different technology-provider solutions.

Adobe

Adobe is probably the technology provider which has the made the most headway on both options. On the browser side, Adobe Flash can almost be considered as a de facto standard for browsers; with Flex, it has become a robust platform for building rich web components or applications.

From a desktop perspective, Adobe is also pushing Adobe AIR, which brings HTML/AJAX and Flash/Flex to the desktop with deep desktop integration. It is a little bit too early to say that this will have the same success that Adobe Flash, but it does look promising from a technology point of view.

Google

A few months ago, Google introduced Google-Gears which allows developers to extend web applications with offline capabilities.

On the desktop side, Google has been aggressively pushing their Google Desktop product to end-users, and has opened it up somewhat to developers. While Google-Desktop is not a “full desktop application container,” it definitely has some of its characteristics, and potentially can become one if Google wants it to (which does not seem to be the case today).

Microsoft

From a cross-platform point of view, Microsoft has decided to focus only on extending the browser with a Flash direct competitor called SilverLight, with an emphasis on Video and on XML/HTML interoperability.

Mozilla

Mozilla Firefox extension model has proven to be one of the best ways for developers to extend Firefox browsers. However, this is obviously limited to Firefox only.

In October 2007, Mozilla launched Prism, an experiment allowing developers to build and deploy desktop applications using the Mozilla Firefox technologies (i.e., HTML/Javascript/XUL). It is kind of a re-launch of XUL Runner, and in many ways, it is an alternative to Adobe AIR.

Sun/IBM

On the Java side, Java applet was probably one of the oldest ways to extend the Internet browser. However, despite some early success, it did not really scale with the market demand. Adobe Flash and AJAX seem to have taken this part of the cake.

On the desktop side, in a traditional Sun-Java vs IBM-Java, we have JRE/WebStart (Sun) and Eclipse RCP (IBM) as robust cross-platform desktop frameworks. IBM is pushing RCP heavily in the enterprise, and SUN is working on making Java cooler with its latest JavaFX addition.

As we can see, internet client technologies have become a hot topic again, with many big players competing aggressively (i.e. for free). In short, I think that Adobe has a head-start, Mozilla has the glory, Google the fame, Sun the legacy, and Microsoft the money. However, I would not place my bet just yet… Only time will tell.  

Disclosure: I was the Director of Product Management & Strategy for Flex in 2006/2007.

Update 2008-03-23: Great post from Techcrunch about Prism and the market

One thing I have always wished for is to get from OpenOffice functions that I cannot get from Microsoft Office. OpenOffice does a good job at providing similar functionality as Microsoft Office. However, while OpenOffice provides innovation and modern functionality, it does not provide much more than Microsoft Office, at least not in a "Web 2.0" sense.

For example, in nowadays, most Web Applications (such as Flickr, Blog Service, Wikis, …) offer some powerful Web services. It would be useful to integrate these services directly into the OpenOffice editing experience. Here are a couple of features I would love to see in OpenOffice:

• Use OpenOffice Writer as [super] blog publishing tool (for WordPress, Bloggers, and TypePad).
• Use Flickr or any other photo services directly into Writer, Impress or even Calc., basically, being able to search and insert images from any photo services (i.e. ‘a la Flock‘) while editing my document.
• Use any blog and Wiki services as a data source for Writer and Impress. For example, while writing a document or presentation, having the ability to quote a section of a blog or Wiki page (e.g., Wikipedia).
• Many other possible integrations exist.

I am sure the OpenOffice platform and architecture allows for such extensions. It would also be great to include some of these integrations in the default OpenOffice package … just to stimulate engineering creativity and to offer a good reason to use OpenOffice even if we still have to use Microsoft Office, at least for a while ;).

Overall opinion: Not too bad for no WYSIWYG editing. I need to play a little bit more with it. However, for a more involved post, I might be using Dreamweaver. BTW, it would be nice if Dreamweaver can add some of these blog posting capabilities … just a thought.

Here are my quick pros/cons:

• Pros:
  • Easy configuration: Not too hard to configure your blog settings (connects well with Wordpress). Easy to start blogging.
  • Useful preferences: Can be on system tray, can start with last open post, can configure proxy (per blog!!), and can export/import preferences
  • Good HTML tag support: For people who like to edit HTML code, it does provide a simple yet useful HTML code editor with a “helper” toolbar like Wordpress’s “quick tag toolbar.”
  • HTML preview: Good HTML preview tab.
  • Spell check: Good spell check capabilities.
  • Offline support: Simple but good enough offline support.
  • Support categories: It does download your categories from Wordpress.
  • Good post synchronization: This is pretty cool – you can go back to previous post from Tools>Post>Last 5 Posts. It will then download it back, and you can make your changes and republish it. Unfortunately, it does not sync with our local one (.post) that you created previously.
• Cons
  • No WYSIWYG editing: It does not seem to be that important in blogger’s world, However, I would really like that. Not saying that I do not want to still be able to look at the code. A program like Dreamweaver would be a good compromise. There are some blog editors that does offer this functionality, though I will try to profile them.
  • No source formating: This does not allow you to “XML format” your html code. Since it generates mostly XHTML, it should not be too hard, and will help readability for a complex HTML document. However, I guess that hard core HTML coders prefer having full control over their HTML code.
  • No tag autocomplete: Again, this is not a must but should be easy to do for a native application. The simplest one is to autocomplete the closing tags.