September 2009

The foundations of the application were built by considering a few of the first use cases:

  • The application should have a single main window, whose position and size is saved on shutdown and restored upon startup.
  • Users want to create new databases, with optional encryption. I used a wizard framework for this, as there were several choices to be made.
  • Users want to open databases, being repeatedly prompted for the password if it’s detected that the database is encrypted.
  • Users want to open multiple databases simultaneously, and switch between them.
  • Users want to be able to close the currently selected databases, or all open databases.
  • Users want the set of open databases to be saved at shutdown, and upon restart, those databases should be re-opened, with the last selected database being made current.
  • All the above should be accomplished from the application menu, with the appropriate menu items being greyed out (disabled) when not appropriate. e.g. If no database is open, the ‘File/Close’ item is disabled;
  • A small number of recently-opened databases should be present under an ‘Open recent’ option of the File menu; the order of this should change to reflect usage patterns.
  • This necessitated the storage of user preferences in a file, separate from any database
  • Once a database is open, allow the user to choose from several views into that database, effectively, the main screens for the application, each view being on a separate tab in the main window. Remember the open views, and the currently active one, restoring it upon restart.

Some software components were chosen during this initial work: Log4J for logging (I’ve always used it, and that’s not going to change just because Sun wrote their own system and shipped it with Java) JUnit 4 and EasyMock for unit/integration tests; Spring for dependency injection; H2 as the embedded database, accessed via Spring’s JDBC Templates (with the possibility of using Hibernate if the DAO-based approach became too onerous); Swing as the GUI framework; the Netbeans Wizard library for wizards. I’m using the JGoodies Plastic Look and Feel for Windows and Linux; Quaqua for Mac OS X.

Build tools: Eclipse, Checkstyle, EclEmma, m2eclipse. Also, some infrastructure: Subversion for version control; Maven 2 for the build; Hudson for continuous integration. Numerous metrics and static analysis tools running in Maven and Hudson to aid investigations into quality.

Writing the code for these led to several other pieces of work, some of which bordered on YAGNI (You Ain’t Gonna Need It), but were essential in any ‘quality desktop application’:

  • There was no actual financial management functionality present at this stage, and so the database schema would inevitably need to change over time to incorporate new functionality. So, ensure that the code and database schema versions were recorded in the database, to allow for schema evolution upon software upgrade.
  • No application is complete without an About Box, but this one was useful, giving developer credits (essential, if a community was to form around the application), and license information.
  • Although using test-driven design and development, with continuous integration throughout, there would inevitably be times when something went wrong and a user would have to repair their database, so a rudimentary facility for diagnosing database problems was added, in the form of a special view screen containing an SQL console.
  • This view wasn’t to be available unless explicitly requested, so a Tools / Options dialog was added, to which parts of the application could contribute options panels.
  • The settings chosen in the options panels were stored in the user preferences file.

I considered the initial user experience, and how the user might engage with the developer community, send feedback/bug reports, and receive notification of new releases:

  • Provide a ‘welcome screen’ that explains the overall facilities of the application. Show this automatically on first startup, but not on subsequent startups; allow it to be started from the menu.
  • Provide a ‘What’s new in this release’ screen that shows a nicely-formatted change log of changes and enhancements in this release of the software. Allow this to be easily shown from the initial welcome screen, and the menu.
  • Allow the detection of fatal exceptions via a problem reporting dialog that would provide a user-friendly synopsis of the problem, and sufficient detail that could be cut-and-pasted into an email, to be sent to the developers.
  • So that users might discover new releases of the software, add an update availability checker. Note: this is not an update download system as in Firefox
  • If an update is available, inform the user via a nicely-formatted display of all new functionality from the version the user is running, to the latest release version.
  • This update check would have to go out over the Internet, and some users are rightly concerned about applications that ‘phone home, so before any update check could take place, the user must be asked whether this is acceptable to them; this choice must be stored in the user preferences.
  • If they allow the update checks, schedule a background check for updates (only runs once in a given day), and also allow the update check to be manually triggered from the menu.
  • Applications that spew many popups into the user’s face when they start up are infuriating if you just want to get work done. Although it’s inessential to the correct operation of the software, I felt that the welcome / what’s new messages on first startup / upgrade were important enough to be shown automatically. An update check would happen soon after every startup, and if the user opened the application each day, this could rapidly become tiring, and they’d want to turn the feature off. So, a simple message queueing system was introduced such that parts of the system that wanted to get the user’s attention would post a message to a queue. The presence of any messages in that queue would enable a button on the main window that would pulse gently, but not in an obtrusive manner. The user could click the button and see the message list – or, they could completely ignore it.
  • Allow for certain messages to be presented with a ‘Don’t show this again’ checkbox whose state is persisted to user preferences.

That’s quite a bit of functionality, and apart from a few screens in the ‘new database wizard’, there wasn’t much in the way of personal financial management functionality present. It was time to rectify that.

However, it was mid-December 2008, and Christmas was approaching. The above code was written using an old IBM Thinkpad running Ubuntu Linux, on the train during my morning commute. (This ‘hour a day’ will be a topic for another post) Over Christmas, the development office kindly provided by South Eastern trains was no longer available, and any spare time I found was spent working on another ongoing project for a while, until mid-February 2009. Then, I switched to a Mac as my main development system. I also had an idea for another project – also a desktop application using an embedded database as its storage.

… to be continued.

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.’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.

Things appear to have been pretty quiet round here for a while; the odd post here and there, with microupdates via Facebook. This does not mean I’ve been idle – in fact, I’ve been busier writing Open Source Software than ever.

Now it’s time to start publishing information, and, more importantly, code.

A couple of years ago, I had (and still have) a classic problem that Open Source alleges to solve. We use a piece of proprietary software. This is a very well-known application for managing home finances. We’ve upgraded this a couple of times, upgraded to Windows XP, and it still works very well. However the manufacturers announced in 2005 that they’d no longer be supporting the UK version. This leaves us with several problems. If our XP system needs reinstalling, we’d have to reinstall this application. Would the online activation still work? Would any updates still be available? If Microsoft shipped an update that unfortunately broke compatibility with this application, we’d also have problems. (To their credit, Microsoft are very good at maintaining backwards compatibility with older apps – at the expense of a clean operating system – and this works in the favour of end-users, not kernel developers. We have to be pragmatic: Who’s the customer?)

We could, of course, switch to another application. I was considering Microsoft Money, but now Microsoft have stopped producing this entirely. I looked at several Open Source home financial management packages, but for various reasons, didn’t take that investigation too far: lack of maturity, lack of cross-platform compatibility (the application we use is the last one tying us to Windows XP), ‘interesting’ user interfaces and feature sets. I suspect they’ve improved in the last couple of years – indeed, I notice some new ones have started.

Also in the last few years, the web has finally become viable as an application platform, although cross-browser problems are still there. See Bruce Eckel’s recent post about this. There are some online apps in this area, but I worry about security, connectivity and usability.

So I decided to scratch my itch, and write my own application. I like being creative!

Over the coming weeks, I’ll write about the development so far, and where I take it from here.

…to be continued.