The release of Google Gears will hopefully ignite some interest in focusing more on the distinction between a web application for a web service (i.e. essentially a GUI that runs completely within your browser communicating with a server hosting a web service) and a desktop client for a web service (e.g. Google Talk, ecto, IMAP clients, etc.).
While keeping the browser as the center of application activity has the benefits of being cross-platform, easily accessible, and having “the same look and feel wherever”, it would seem that we have gone through great pains simply to account for differences in browsers and to make the process a little more manageable.
This of course raises the question of how valuable a within-browser application is, especially for a well established company like Google. Would it be more valuable (though it will likely take more resources) to focus on desktop clients for web applications–clients that play friendly with the host operating system and desktop environment? Somewhat impractically, what if Mac Mail, for example, had a Google plugin where a few interface changes like conversation views (web applications like Gmail are of course not just a protocol for data exchange, they provide an interface specification) and Mac address-book synchronization took place? This kind of thinking isn’t unheard of.
Gears certainly gives us a little more of a practical playing field for designing web applications to be resilient to “flaky” network activity. Though the underlying principles are not completely unexplored, it will be nice to see progress on the application-design standpoint. The various decisions on how to handle the synchronization activities from a UI perspective will be challenging. For example, it is fairly intuitive that the level of “local” activity and roughly the “rate” of synchronization has basic relations to the “collaborativeness” of the application. For highly collaborative applications (e.g. Google Docs), much emphasis would need to be placed on network storage and fast synchronization, whereas for more personal applications this is not the case. Getting this kind of application to work “intuitively” well, and better yet, withstand critique are both tall orders.
In any case, it’ll be interesting to see where things head…whether the browser takes the monopoly for many apps or not. Microsoft’s solution appears to be still heavily focused on the browser, and I too find GNOME’s proposed plan a bit unclear.