At the beginning of December, I took over as the lead developer of the indie racing game GeneRally.  I’ve been a member of this game’s astonishingly dedicated community since its inception, back in 2002 when a tentative release of a beta version by original authors Hannu and Jukka Rabina, spawned a community that must have been beyond their wildest dreams.

GeneRally’s development stopped in 2003 and slowly, but surely, the community began to die.  Since 2007, I’d been talking to Hannu about the possibility of taking over development of the project – but a lack of motivation for either of us to initiate the ‘hand-over’ meant that nothing much got done until December 2010.

It’s quite an exciting feeling to get the opportunity to lead the development on a game you’ve previously sunk untold hours of your time into… “finally,” you think, “I can fix those bugs and add those features I’d always wanted to see.”  To an extent, that’s been true – but a lot of the past couple of months has been a learning process.

We made a new release of the game (v1.10) back in February and pushed out a bug-fix release last month, as well… but the development is ongoing.  Along with my friend, Markku, we have been constantly implementing new features and fixes for GeneRally – attempting to make it compatible with modern operating systems and starting to bring it up to the visual/interaction standard that people expect from indie games these days.  Our focus at the moment is mainly on rewriting some of the old, buggy features and improving the AI to make them a little less “gung-ho!”

If you find yourself with a free moment, do take a look at the game (which will run on Windows XP or later, or via WINE/Darwine) and let me know what you think could be improved, fixed or just generally updated (no pun intended)!

The first facet of this poor design was the UI. When talking of a crowded and largely ‘unusable’ interface, Word’s classic use of toolbars are often cited as an example:

Obviously, this is a bit of a misnomer, given the ability to hide/show relevant toolbars at relevant times, but the point still remains: a crowded interface is not desirable in the slightest. But when getting my hands on this system for the very first time, it became clear that this over-crowded nature was inherent in every part of this enterprise system. Wherever you looked, labels overlaid text boxes, text fields were positioned off-screen, with no way to scroll to them, text sizes were erratic to cram in as many form fields on one page as possible and standard UI conventions (such as button hover effects, etc.) had been replaced by inconsistent alternatives.

For years I’ve wondered how it was that so many government systems failed, and further puzzled at the regularity with which said systems completely lost data and were, inevitably, decommissioned – but no longer. The chance for three hours with this government-endorsed system answered a lot of questions. It’s become clear to me that the primary failure in systems like this is poor design from the outset. Sure, even the best-designed system fails at some point, and every enterprise system is put under huge stress and strain that could lead to downtime, eventually… but many are simply plagued with underlying flaws that should have been ironed out in the design phase.

The system in question, though, is a maze of menus, features that overlap, crowded data outputs and show-stopper bugs. Basic design principles, such as retaining the ability to tab through form fields have been completely left out, and standard system shortcuts are abused and repurposed. 90% of the program’s features are not available within 8-10 mouse clicks, and even the regular users of the system seem to just randomly click poorly-labelled buttons and scroll through lengthy list-based screens until they find what they need. The data input forms are all but abandoned in favour of importing Excel spreadsheets for each entry (apparently using the spreadsheets and the program’s import function is far, far quicker than attempting to enter the data in the system itself) and the system lacks a reliable reporting interface. Validation is nowhere to be seen, and coming across text in the phone number field, and the like, is the norm.

But if the user interactions and the UI weren’t bad enough, the underlying system is, quite simply, a dog. A simple task such as searching a table of 500 rows on a particular, simple, condition such as “WHERE gender=’F'” took nearly 30 seconds to report, with no indication of the progress of the task given. Completely devoid of the idea of threading, the program enters a ‘Not Responding’ state every time a simple task is requested of it, and crashes when the data inputs are outside of expected ranges. I’ll admit that Microsoft SQL Server isn’t my favourite SQL deployment platform (for a variety of non-performance-related reasons), but no system should perform this poorly, unless it has major underlying flaws.

Using this system reminded me of a case study I undertook back in University about the London Ambulance Service’s attempts at a computerised dispatch system in the early ’90s: the project was given to the lowest bidder (who bid over £700,000 less for the project than any other bidder); came in massively over-budget; failed completely during it’s first deployment; had major interfacing bugs with the purpose-designed hardware; resulted in the death of twenty people whose calls were either not routed in the system correctly or were disconnected; ‘lost’ ambulances from its tracking software at the rate of several per hour; and was ultimately scrapped less than 24 hours after it had been initially deployed.

‘Fundamentally flawed’ is the only way in which I can describe the system I had the privilege misfortune of using last Friday, and I’m very glad that it’s not responsible for a safety-critical area of our public service sector!

It’s no wonder that so much data has been lost by government organisations when even the most simple data protection controls and security measures are completely absent in many existing enterprise and government systems. And if that’s not bad enough, consider the number of extra hours public workers need to be paid, on the tax-payer’s dime, just to navigate the poor and unreliable user interfaces that are haphazardly plastered on top of flawed system architecture.

The fact that so-called ‘professional’ software developers get away with systems like this is laughable. And, I suppose, sometimes you have to laugh… or you’d cry.

This version optionally allows you to specify a path to the “Bookmarks” file used by Chromium, instead of using the default path to Google Chrome’s “Bookmarks” file. Hardly a world-shattering improvement, but hey!

Prior to the release of the beta, Microsoft had been touting comprehensive CSS3 support (supposedly a superior subset of the selectors than offered by the major competition), hardware acceleration (currently beginning to be employed in most major browsers) and a faster JavaScript engine – it all seemed to good to be true.  At present, after a little bit of testing on my part (and a tonne on the part of benchmarking geeks worldwide), it seems as though the IE team have delivered on their promise.  Not only do we have nearly-full CSS3 support, but we have a solid HTML5 implementation (including HTML5 video) and better support for embedded fonts.

The only part I’m not so sure about is the announcement that IE9 will not be supported on Windows XP at all, nor will any of the HTML5/CSS3 features be back-ported to IE8.  On the surface of things, this probably isn’t a major issue: but when we observe that, supposedly, over 50% of desktop PCs are still running Windows XP, we begin to see a major issue.  Web developers have, up until now, been unable to make use of HTML5 properly without breaking IE support (or, without using a JavaScript workaround), as previous versions of IE do not allow styling of ‘unknown’ elements (such as many of the elements present in HTML5).

What this means in practice, then, is that for as long as Windows XP maintains a decent market share (which, given the poor take-up of Vista in both personal computing and in commercial circles, could take longer than ‘normal’), HTML5 is going to do one of two things: break in IE, or break without JavaScript in IE.

Of course, I can fully understand Microsoft’s reasons for not spending a huge amount of effort supporting an operating system that’s getting on for 11 years old, but you’d also not expect an 11-year old product to have a greater market share than it’s two successors.

However this pans out, it’s good to know that Microsoft are at least pushing users towards the use of IE9 and towards greater standards compatibility.  I know I’ll be grateful when I can write mark-up once, and have it work… not have to write it several times, with a variety of workarounds – it’ll go a good way to halving the time I spend writing mark-up.

Anyway, a few things that may interest from the past few months:

• I started up a creative media company, Pure Water Studios.
• Kate and I got married (Facebook albums #1 and #2) and bought a house!
• I finished after a year at theological college to pursue self-directed study and freelance work.

Hopefully, then, this will be the start of the resurrection of this blog – stay tuned. If you were subscribed to the feed before, please re-subscribe (RSS icon is in the top-left), as the feed URL has changed with FeedBurner – thanks!