Standalone Web Applications: Have it All
Ajax and the fancy “Web 2.0″ trend are causing all sorts of web applications to pop up. The most familiar examples are the many services that google is making available, and gmail especially. Gmail is, for many people, a desktop mail client replacement. And why not? It contains the functionality that one would expect in a desktop application - viewing mail, composing new messages, and creating filters to sort incoming articles of text. It is a nicely packaged application with a decent interface. It does however have one major flaw: it doesn’t control the application used to view it.
We aren’t talking cross-browser compatibility problems or the folks using text-only browsers such as lynx. The issue that spans all browsers is that they contain navigation buttons. Back, forward, and refresh, these are all elements that can make the execution of a web application occur in an order unintended by the developer. From a software engineering perspective, this presents new problems previously not encountered when designing and developing software. From a programmer’s perspective, this introduces new complexities in the code because the state of execution can change at any time. Additionally, the code monkeys have to handle sessions that may not terminate properly, half-open connections, and navigation issues that will creep up from the user jumping around your application.
A solution to this problem that hasn’t been completely explored is to combine the benefits of desktop applications with the advantages of web applications. Desktop applications are self contained, meaning the interface to that application is completely controlled by the developer. The state of execution again becomes reliable, hooks into the process’ termination can execute cleanup code, and even cross-browser issues may be ignored. Web applications need only a web browser to load them. By embedding the rendering engine of your web browser of choice (as far as I know, Mozilla’s, Internet Explorer’s, and Safari’s rendering engines can be embedded) in an application, the only thing the user see is exactly what you want them to.
The only complication that arises from this situation is the initial distribution of your application. But because the desktop ‘launcher’ application is going to be nothing more than a frame with some logic to handle any initializing or cleanup you wish to do, it is going to be a very small download. And if you are a company that produces a lot of applications, your launcher can be modified easily to support all of them from a single application. Attractive, isn’t it? This also allows for targeting an older demographic that has been slow to catch on to web trends by deploying to them something familiar: an icon on the desktop to be click clicked.
Now for the business stuff. If you already have a solid web application that conquers the navigation and other issues that plague them, you are one step away from redeploying your application to a new market. And while speaking of markets (and thus money), if your application is driven by advertisements, controlling the platform means that the user won’t be able to block your ads. Physical distribution also becomes possible at this point. Your launcher could be bundled with an installer and distributed by CD to be sold on the shelves in brick and mortar establishments. Now your application will be reaching all corners of the current software markets, bridging gaps of technical understanding, and all without your users blocking the media you want them to see. If you are just starting development with this paradigm in mind, you are going to save development time which can be refocused on implementing features for your users. The result is a better web application that is available to everyone.
The benefits gained don’t take a lot of convincing to sell. Simplified development, a cleaner application, and reaching broader markets all from changing the means of distribution?
Money.
You’re right - this is still a widely untapped market. You didn’t mention a couple of the problems with such an approach though (although, they do have known working solutions):
-Cross platform support: not that big of an issue, but a web page by itself is platform independent. Once you make it into an executable, you lose that.
-Connection dependent: alright, sure if you have a web application, you are connection dependent. But once you repackage it as a desktop application, people expect it to act in the same manner as other desktop applications: fast response time (56k modem isn’t going to see this), no dependency on being connected at all - certain features shouldn’t even require a connection to the internet ex: a word processor, etc.
-Yet another installer: the only other problem I have with this approach is the fact that I have to download and install something (but that’s just me, others may certainly feel quite differently - maybe even like the fact that there’s yet another icon on their desktop/start menu). This could also be worked around by still allowing people to access the application through their own browser - the only problem with that though is that instead of simplifying things by packaging this desktop application, you now have two “systems” to maintain and support.
However, this idea doesn’t seem to be completely ignored by “the industry.” Adobe’s Apollo is, in some ways, exactly what you are describing. Google Gears provides some methods for getting the desired effects as well. It is quite likely that we may see some of these types of applications rolling out relatively soon. In fact, http://www.finetune.com - an internet radio site I use on occasion does have a desktop application (http://www.finetune.com/desktop) that runs on the Adobe Integrated Runtime environment (AIR) aka Apollo, which is already platform independent. I haven’t used it, though - nor do I plan to.
Aug 30th, 2007 at 11:17 pm