I’d decided to scratch my itch, and write my own home financial management application. But should it be a web application or an installed ‘fat client’ application?

The web has its benefits: cross-platform; zero installation for the user; data is always there in the cloud; developers get to write in wonderful languages like Ruby.

The web has its disadvantages: there is still cross-browser woe (i.e. IE); having to write too much low-level user interface code (toolkits help, but you’re still trying to work with the modern equivalent of a 3270 terminal); developers get write in wonderful languages like JavaScript; hosting costs the provider in terms of availability, security, backups; if the users’ connection is down, they can’t use the app (although Google Gears helps here – it’s a workaround); if the ‘series of tubes’ is clogged then the user experience is impaired, etc.

One of the use cases I had to consider was encryption of the data. The existing commercial application I aim to replace allows individual databases to be encrypted, and this was something I had to provide. If I were to develop my application as a web application, I’d have to host every users’ data in the same database (MySQL, PostgreSQL, etc.) and ensure there was no way a hacker could compromise anyone’s data – tough. Security between the browser and the server would have to be provided via SSL, requiring a certificate that probably wouldn’t be cheap, especially for an open source project.

The languages and toolkits issue also swayed me away from the web. Much as I love Ruby, I can’t kick my Eclipse/Java habit. I still have the option of using JRuby in the project. Swing UIs can be attractive and responsive – plus, Swing is a proper GUI toolkit, not a series of disparate technologies glued together with duct tape.

User installation of applications is not without problems – the user would also have to install the correct version of Java, or I would have to ship the application with a JRE. I didn’t want to have to do that – so I made the choice that an installed JRE would be a prerequisite. This is a no-brainer on the Mac and relatively painless on Ubuntu. Windows remains a little painful with regard to Java installation, since there is no centralised package management – every application provides its own update installer these days (and there will be more about this later, when I discuss how I plan to address this in the application itself). On Windows, the Java update checker runs in the background, and nags the user to update – as do countless other applications. This might be fine for technical users such as myself, but for the user base I hope to target, it’s awful. Ubuntu and the Mac have a better system for update notification – at least for Apple-provided code on the Mac: you’re notified about updates in one place, and you trust it. Several non-technical users I know ask me “Should I accept this Java Update it’s offering?” These users have to work out for every application that does this whether they should accept. They also presumably get to find out that the mass of implementations of update systems are quite variable in quality – which might be the reason they’re afraid of using them.

Once the JRE’s in place, they’d have to download and install the application itself. This has to be made as painless as possible. There’s a great post about this – see How to Successfully Compete with Open Source Software – that I wholeheartedly agree with; I won’t reiterate the points made there, except to say that on the project’s home page, there would be a prominent link to enable the user to download for the platform of their choice; possibly involving some platform-sensing as is done on e.g. OpenOffice.org’s download page.

As for installation, this had to be tailored to the three platforms:

  • On the Mac, you drag the application’s icon to the Applications folder (yes, it’s that simple, it need not be any more complicated, as you’d expect from the gold standard in user-centred computing)
  • On Windows, you run an installer, typically a .MSI file
  • On Ubuntu, add a repository to enable the app to show up in their usual package manager.

That didn’t sound too painful – although it imposes some additional platform-specific build tool requirements and infrastructure burden on me, but there wasn’t any choice – ‘download from a SourceForge page’ and ‘run this Ant script to install’ are not viable options.

…to be continued.