Exactly one year ago when I started on the latest iteration of WorkPapers.Pro, the web application development took front and center position, and a desktop integration was an after-thought… for a couple of reasons. First, I had already developed about four different versions of the desktop application in multiple languages, so was not worried about generating another iteration to accommodate the web application rapidly. On the other hand, developing a web application for the internet (versus intranet) was a new experience and took more time.
The release times reveal this. The web application took about nine months to develop into its current incarnation, and one can argue that the development of a web application never really stops at version releases. The desktop application took all of about ten weeks to put together since we could re-use a lot of the web application code.
Anyways…. yesterday morning I set out once again to figure out a way to package a web application into a desktop package that end-users could install and be happy. For some reason, with all the web application (notice I did not use the word ‘cloud’) buzz you would think that users would not require a desktop application, but I have found that 80% of my users are willing to purchase the monthly subscription because we offer a desktop application.
To answer the end-user craving for a desktop application and to eliminate the requirement to manage two code sets, I am willing to go great lengths to deliver the web application in its entirety to the desktop application users. The first solution that came to mind was to develop a dedicated browser that throws the web application into a consolidated browser – hence, Prism from the Mozilla projects, and Fluid on OS X. Both of these solutions basically take your favorite web application or web site and put them into a dedicated browser experience, create a desktop icon, and isolate the browsing experience. With WorkPapers.Pro isolated into Prism, the experience was actually impressive. It really felt like a desktop application because all of the code is browser loaded script. Facebook, on the other hand, felt cumbersome because it constantly called back to the server to reload something and I felt like that experience actually belonged in a browser tab.
After a couple of hours of trying to package Prism with Advanced Installer and a couple of other solutions, I gave up and decided it was time to try something else. Then I went through the Mozilla projects page to see that Prism was becoming a deprecated project, patted myself on the back for giving up, then found Chrome-less. Chrome-less is an effort to allow developers to create whole web browsers with Javascript (and no you morons…. javascript has absolutely nothing to do with Java), HTML, and CSS. This development project offers a lot of potential, but it is so new that Mozilla still has not come up with an icon for the project and all of the tutorial and getting started links point to links to the tutorial and getting started links, which point to all the tutorial and getting started…. you know what I mean.
One big technology behind the Chrome-less project is XULRunner, which is the run time and SDK upon which Firefox, Thunderbird and many other commercial and non-commercial projects are built. I dabbled with XULRunner and discovered that you can build a whole browser with about 30 lines of Javascript and XML, if you are willing to accept the fact that the project file structure has to be a certain way without any real explanation for why it has to be that way.
In the end, I opened up RealBasic Pro and put an HTML viewer in a document window, coded a couple of pre-compile directive #if statements to tell Windows clients to use Firefox rendering if available or IE 8 if available, and had a custom browser that displayed the WorkPapers.Pro web application just the way I wanted it to. Bye, bye desktop code! This decision is not final, but close to it.Here is a screen shot.

Click of the link for a bigger image. You can see that a dedicated browser without the navigation bar, navigation buttons, and browser menu can take a web application and make it look like a desktop application. There are some motivations for this effort:
1) Eliminates having to setup firewalls for desktop application to replicate data – especially in corporate environments
2) Eliminates data replication altogether
3) Generally speaking, data is safer on a server instead of spread out on everybody’s hard disks
4) Manage a single code base and include the dedicated browser code development with web app development
5) Users do not have to pay the additional cost of a desktop application
While most of the WorkPapers Browser was completed with just a few hours of coding, there are still a couple of necessary enhancements, such as proper file download handling, enhanced rendering for Linux, and installation file setup. After all this is done, will make the final decision – deprecated the WorkPapers desktop application once and for all, or keep on maintaining a second set of code?